From exim@www1.ietf.org Mon Mar 1 01:14:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08362 for ; Mon, 1 Mar 2004 01:14:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxghC-0002mr-2V for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 01:14:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i216EUhV010709 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 01:14:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxghB-0002me-Pg for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 01:14:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08358 for ; Mon, 1 Mar 2004 01:14:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axgh8-0007Ep-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 01:14:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxggB-0007AJ-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 01:13:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axgfz-00075s-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 01:13:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axgfm-0002Y1-6n; Mon, 01 Mar 2004 01:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgfC-0002Ws-K5 for manet@optimus.ietf.org; Mon, 01 Mar 2004 01:12:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08292 for ; Mon, 1 Mar 2004 01:12:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axgf9-000754-00 for manet@ietf.org; Mon, 01 Mar 2004 01:12:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgeE-00071L-00 for manet@ietf.org; Mon, 01 Mar 2004 01:11:27 -0500 Received: from harrier.mail.pas.earthlink.net ([207.217.120.12]) by ietf-mx with esmtp (Exim 4.12) id 1Axgdm-0006xO-00 for manet@ietf.org; Mon, 01 Mar 2004 01:10:58 -0500 Received: from user-2ivfmjq.dialup.mindspring.com ([165.247.218.122] helo=earthlink.net) by harrier.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Axgdi-0004xl-00 for manet@ietf.org; Sun, 29 Feb 2004 22:10:54 -0800 Message-ID: <4042D3EC.7030101@earthlink.net> Date: Sun, 29 Feb 2004 22:10:52 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Comments on draft-clausen-manet-ospf-dbx-00.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To the authors of draft-clausen-manet-ospf-dbx-00.txt, I have a few quick comments on the draft. I'm not sure why you are focusing on OSPFv2. The OSPF WG has decided to focus on OSPFv3, e.g. http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0311&L=ospf&T=0&F=&S=&P=10149 Your scheme seems to imply that a prefix can be used to identify a set of LSAs. In OSPFv3, address and prefix information has been removed from Router and Network LSAs (and moved to new LSA types), which express topology information using 32-bit Router IDs. Router IDs need not be related to addresses and need not have a common prefix. So I am not sure exactly how your proposed scheme will apply to OSPFv3. I'm not saying it can't be applied, only that it it does not seem straighforward or natural. Have you thought about this? However, as I have proposed in draft-ogier-manet-ospf-extension-00.txt, I agree that the concept of Complete Sequence Numbers Packets (CSNP) of IS-IS (or equivalently, periodic Database Description (DD) Packets), can be used both for reliable flooding of LSAs and for database exchange with new neighbors. We all agree that it would generate too much overhead to have every MANET node transmit a full set of DD or CSNP packets periodically. You are proposing to reduce this overhead by using "prefix signatures" (using CRC checksums). I am instead proposing to reduce this overhead either by having only a few nodes (CDS nodes) transmit these periodic messages, or (if MPRs are used) by having each node transmit LS sequence numbers (or LSA headers) only for LSAs originating from nodes u such that p(u) is an MPR selector, where p(u) is a consistently chosen next hop to node u. I am not sure which approach will perform better (but it probably depends on the scenario and other aspects of the protocol). Do you have any simulation results for you proposed scheme? Regards, Richard _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 1 05:54:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09275 for ; Mon, 1 Mar 2004 05:54:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl47-0005G2-41 for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 05:54:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21AsRM4020204 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 05:54:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl46-0005Fn-Rz for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 05:54:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09093 for ; Mon, 1 Mar 2004 05:54:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axl43-0004zU-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 05:54:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axl2m-0004jV-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 05:53:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axl1N-0004YJ-01 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 05:51:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxkoV-0004tZ-3w for manet-web-archive@ietf.org; Mon, 01 Mar 2004 05:38:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxkoE-0003Dp-Re; Mon, 01 Mar 2004 05:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axknw-00039T-5c for manet@optimus.ietf.org; Mon, 01 Mar 2004 05:37:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08407 for ; Mon, 1 Mar 2004 05:37:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axkns-0003Vw-00 for manet@ietf.org; Mon, 01 Mar 2004 05:37:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axkn9-0003ON-00 for manet@ietf.org; Mon, 01 Mar 2004 05:36:56 -0500 Received: from mercury.telscom.ch ([193.72.156.161]) by ietf-mx with esmtp (Exim 4.12) id 1AxkmD-00035b-00 for manet@ietf.org; Mon, 01 Mar 2004 05:35:58 -0500 Received: from vaiooo (193.72.156.77) by mercury.telscom.ch with MERCUR-SMTP/POP3/IMAP4-Server (v3.30.07 AS-2621446) for ; Mon, 1 Mar 2004 09:11:40 +0100 From: "Marcin Michalak" Organization: Telscom To: manet@ietf.org Date: Mon, 01 Mar 2004 09:10:29 +0100 MIME-Version: 1.0 Message-ID: <4042FE05.11304.1EC3648F@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Reply-To: marcin@telscom.ch Content-Transfer-Encoding: 7BIT Subject: [manet] Which frame? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello, I'm reading the 802.11 specification and am a bit confused. In section 7.2.2 there are 4 types of data frames that are used: which of them is used in MANETs? I particularly mean Table 4 there - which addresses are used and how are the Address 1,2,3,4 used? I'd be grateful for a short explaination. Regards, Marcin Michalak ---------------------------------------------------------- Marcin Michalak Research Engineer Mobile: +41 79 330 83 51 Telscom AG _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 1 11:42:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18748 for ; Mon, 1 Mar 2004 11:42:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqU9-0007Lj-Jj for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 11:41:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Gffww028236 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 11:41:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqU9-0007LG-4o for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 11:41:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18252 for ; Mon, 1 Mar 2004 11:41:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqM5-0005CR-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:33:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxqLH-00052b-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:32:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxqKQ-0004g3-03 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:31:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpwc-0002wj-3U; Mon, 01 Mar 2004 11:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axpve-0002Pe-Cc for manet@optimus.ietf.org; Mon, 01 Mar 2004 11:06:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13895 for ; Mon, 1 Mar 2004 11:05:54 -0500 (EST) From: zinin@psg.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axphi-0007QI-00 for manet@ietf.org; Mon, 01 Mar 2004 10:51:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxpTL-0002at-00 for manet@ietf.org; Mon, 01 Mar 2004 10:36:51 -0500 Received: from forestales7.biblioteca.upm.es ([138.100.132.87] helo=forestales7) by ietf-mx with smtp (Exim 4.12) id 1Axp1e-00032E-00 for manet@ietf.org; Mon, 01 Mar 2004 10:08:10 -0500 Date: Mon, 01 Mar 2004 16:06:45 +0100 To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------flgxowwxdljpgtswqpue" Subject: [manet] Camila 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 ----------flgxowwxdljpgtswqpue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.C in file gyugglyc.exe (in abaccd.zip) The file is deleted. --------------------------------------------------------- ----------flgxowwxdljpgtswqpue Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----------flgxowwxdljpgtswqpue Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) abaccd.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------flgxowwxdljpgtswqpue-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 1 11:44:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17096 for ; Mon, 1 Mar 2004 11:25:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqEQ-0005kI-7f for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 11:25:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21GPQSX022071 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 11:25:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqEP-0005jq-TU for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 11:25:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16510 for ; Mon, 1 Mar 2004 11:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqEA-0002fD-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:25:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxqBN-0001xO-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:22:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxqAO-0001P6-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:21:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axq8E-0001AH-Q6 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axq7I-0004mk-1U; Mon, 01 Mar 2004 11:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axq6T-0004iZ-Fm for manet@optimus.ietf.org; Mon, 01 Mar 2004 11:17:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13948 for ; Mon, 1 Mar 2004 11:05:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxpgS-00071t-00 for manet@ietf.org; Mon, 01 Mar 2004 10:50:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxpOh-0001AN-00 for manet@ietf.org; Mon, 01 Mar 2004 10:32:05 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1AxouH-0001HV-00 for manet@ietf.org; Mon, 01 Mar 2004 10:00:33 -0500 Received: from [128.89.81.29] (dhcp89-081-029.bbn.com [128.89.81.29]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i21F02M8001812; Mon, 1 Mar 2004 10:00:02 -0500 (EST) In-Reply-To: <000001c3f8c8$a27155b0$b11cbd84@greenpiece> References: <000001c3f8c8$a27155b0$b11cbd84@greenpiece> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3D7EABAB-6B91-11D8-9A8B-000A95BCB47E@bbn.com> Content-Transfer-Encoding: quoted-printable Cc: From: Ram Ramanathan Subject: Re: [manet] A topology control question? Date: Mon, 1 Mar 2004 10:00:55 -0500 To: "Dong Wang" X-Mailer: Apple Mail (2.606) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable These are good questions, and here are my belated comments. On Feb 21, 2004, at 5:18 PM, Dong Wang wrote: > Hi, > =A0 > =A0=A0=A0 Recently, I read several papers about topology control. My=20= > understanding is that, topology control algorithms generate, or=20 > derive, a simpler topology from the original one constructed under the=20= > common maximum transmission range. And all routing algorithms then=20 > select routes based on the new topology. > =A0 > =A0=A0=A0 Here are several points that I don't quite understand: > 1. While maintaining connectivity,=A0topology control aims = at saving=20 > energy by considering each node or considering the network as a whole? Energy conservation is only one possible goal. The other, in my mind is=20= interference reduction and hence capacity increase. If certain=20 conditions are met, decreasing the power while still keeping the=20 network biconnected often results in better throughput. Large number of=20= nodes operating at max power close together are susceptible to the=20 "parking lot" problem where they come up, are unable to get their=20 discovery messages through and so self-organization fails. People motivating topology control for energy savings should carefully=20= consider the practical aspects. For instance, in many transceivers,=20 transmit power reduction is done by adding more resistors in the path,=20= which does nothing to save energy. > 2. Seems each node adjusts its transmission level only when = the=20 > original network topology has been changed, no matter which node it's=20= > going to transmit data to, does it? In most papers I am aware of, yes. Note that the way papers treat=20 topology control de facto defines the concept, but that does not mean=20 that that is necessarily the way it should be (see below for=20 elaboration). > 3. Topology control removes some connectivity information = from the=20 > original topology, however, I observed that such a removed link=20 > between a node and one of=A0its neighbors may be the part of the=20 > optimal=A0route (which costs the lest energy) to a destination,=20 > therefore topology control actually deviates from its purpose -- save=20= > energy. It depends upon the particular topology control algorithm. If you=20 ensure that this never happens i.e, you never remove a link A->B unless=20= there is a lower energy path A->C1...->Ck->B, this shouldn't happen? If my recollection is right, the excellent paper by Roduplo and Meng=20 (appeared in a JSAC special issue 3-4 years ago) formally sets up the=20 conditiionns for this and gives an algorithm for topology control that=20= is provably minimal energy (again, it is only my recollection, you=20 should check it out). But more generally, yes, topology control may result in excluding=20 certain links that are physically possible from the purview of the=20 routing control system, to the possible detriment of the performance.=20 To extend your point to the interference reduction motivation, topology=20= control may remove a link that is part of the optimal route, causing=20 packets to take longer routes and increasing the net interference. In other words, topology control (as commonly used) deliberately=20 eliminates some resources (links) from being used. Why is this any=20 good? Why not *know* about them but be selective in their use? An answer to this needs context about the alternatives, and the=20 tradeoffs involved. So, to put this in perspective, let me go up one=20 level. I classify such control into three, and generalize it so it=20 doesn't just apply to "power" but more generally, radio parameters. Let=20= T be the richest possible topology resulting from the maximal use of=20 parameters (e.g. maximum power). There are three kinds of parameter=20 control. 1. Physical topology control. Here, node parameters are adjusted so=20 that you get a topology that is a subset of T. Routing is given T and=20 has to work with it. This is the implicit definition of topology=20 control as used today (to my knowledge). 2. Routing topology control. Here, T is discovered and given to routing=20= protocol. The routing protocol then deliberately excludes certain links=20= from consideration as part of the topology database. It can change the=20= links it is "blind to" depending on the situation, 3. Per packet control. This is strictly not topology control. Here, T=20 is discovered and given to the routing protocol. The routing protocol=20 uses all of its links in its routing database. When a packet is to be=20 transmitted from A to B, power is reduced to just what is required.=20 This relates to what I think you have in mind when you asked question=20 #2. As I said, the word "topology control" has generally come to mean=20 "physical topology control". However, in the late 1980's there was an=20 obscure but very good paper by Nachum Shacham that used topology=20 control as routing topology control. Per packet control as in #3 is=20 routinely used by military contractors who have been building ad hoc=20 networks for a living. Now for the pros and cons. The main observation is that there is a=20 tradeoff between control overhead and the information. So #2 reduces=20 overhead over #1 by being selectively "blind" to the changes in some=20 percentage of the links ignoring their state. And #3 reduces overhead=20 further by eliminating the need to even maintain (from a discovery=20 point of view) neighbors. So for the same T' \subset of T produced by=20 routing topology control and physical topology control, physical=20 topology control has less overhead as it doesn't need to worry about=20 some neighbors at all. Also, Hello interference is reduced. Plus, only=20= #1 above eliminates the parking lot problem. Finally, doing #3 means=20 adjusting power in the (fast) forwarding path, which might be a problem=20= for high speed wireless networks. So now to answer your question. Keepinng around that link that gave you=20= the optimal path requires some work -- control overhead wise, and=20 protocol complexity wise. Topology control (physical/routing)=20 essentially takes the position that by giving up some links for=20 simplicity and reduced overhead (which in turn burns energy and=20 increases interference), you may actually win out because the=20 situations like you describe are (maybe) rare. Now, whether or not this position is justified is anybody's guess. I=20 know of no work that compares, say, #1, #2 and #3. Or even articulates=20= the position, or justifies it over per packet control. Most minds=20 (including mine) are seduced by the inifinitely rich graph theoretic=20 and distributed algorithm possibilities :-}). I apologize for the long winded answer, but I hope it gives you a=20 fuller picture. More importantly, I hope it encourages you (and others)=20= to look into this "diferent kinds of topology control" further. There=20 is a lot of scope for further research here. -Ram P.S. The terms "physical topology control" and "routing topology=20 control" are not standard. > =A0=A0=A0 I will appreciate your explanation. Thank you. > =A0 > Gary W > University of Minnesota _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 1 11:59:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21522 for ; Mon, 1 Mar 2004 11:59:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqlJ-0000IE-72 for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 11:59:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21GxPu4001117 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 11:59:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqlI-0000Hw-UJ for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 11:59:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21182 for ; Mon, 1 Mar 2004 11:59:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axqbv-0000m2-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:49:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axqao-0000Xr-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:48:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxqZu-0000LE-04 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 11:47:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqUa-0007VS-8b; Mon, 01 Mar 2004 11:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqU2-0007K7-HI for manet@optimus.ietf.org; Mon, 01 Mar 2004 11:41:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18165 for ; Mon, 1 Mar 2004 11:41:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxqRT-00065u-00 for manet@ietf.org; Mon, 01 Mar 2004 11:38:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxqQX-00060W-00 for manet@ietf.org; Mon, 01 Mar 2004 11:37:58 -0500 Received: from nestor.nmsu.edu ([128.123.34.146] helo=mail.nmsu.edu) by ietf-mx with esmtp (Exim 4.12) id 1AxqQE-0005uy-00 for manet@ietf.org; Mon, 01 Mar 2004 11:37:38 -0500 Received: from PCMullen2 (pc-mullen-2.NMSU.Edu [128.123.245.103]) by mail.nmsu.edu (Postfix) with ESMTP id CB4BC201C; Mon, 1 Mar 2004 09:37:37 -0700 (MST) From: "John Mullen" To: "'David Young'" Cc: "'Charles E. Perkins'" , Subject: RE: [manet] hello protocols inappropriate for link sensing? Date: Mon, 1 Mar 2004 09:37:42 -0700 Message-ID: <005101c3ffab$845b91f0$67f57b80@IEngr.ad.nmsu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20040228042310.GL17009@che.ojctech.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Dave, I think your assumption is about right. I just hedged my language because so many people I've encountered don't appreciate the severity of the problem or the necessity of solving it for MANET implementation. :-) We are about to do some field tests here, but from what I read in the papers, it happens well over 50% of the time. Because its solution often involves timeouts, it leads to a very significant loss in throughput. I made the suggestion because we've noticed a number of papers in which the false routes seem to be a difficulty, but the practitioners attribute it to other sources and miss the essence of the problem. The severity of the problem would depend on such things as the waveform in use, node density, data rates, and the fading factor. For example, if one selects a high fading factor to ensure high reliability on usable links, one simultaneously increases the probability of RREPs from nodes over unreliable links. According to our calculations, there are some things that can be done, but I would say that at this point there is no silver bullet and the ultimate solution will probably involve a coordinated effort on the part of the three lowest OSI layers. John Mullen -----Original Message----- From: David Young [mailto:dyoung@pobox.com] Sent: Friday, February 27, 2004 9:23 PM To: John Mullen Cc: 'Charles E. Perkins'; manet@ietf.org Subject: Re: [manet] hello protocols inappropriate for link sensing? On Thu, Feb 26, 2004 at 05:00:39PM -0700, John Mullen wrote: > Hi David, > > Your interpretation may be right, but I suggest you look at a log of > RREQ and RREP packets. A great deal of capacity is lost due to > occasional successes over unreliable links, causing unreliable routes > to be chosen, which then fail. That is, there may be another cause > for the symptoms you describe. It is an OSPF network, but I know what you mean in the abstract about RREQ/RREP succeeding over unreliable links. The network in question has no alternative routes, so I don't think that's the problem. I am surprised if the RREQ/RREP packets' successes on marginal links are only occasional. I am interested to hear more about that. I have pessimistically assumed that RREQ/RREP discovery frequently yields paths that carry small RREQ/RREP packets fine, but which perform badly with longish TCP segments. 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 exim@www1.ietf.org Mon Mar 1 12:04:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22357 for ; Mon, 1 Mar 2004 12:04:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axqq6-00023Z-Cx for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 12:04:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21H4MgY007899 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 12:04:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axqq6-00023K-7n for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 12:04:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22247 for ; Mon, 1 Mar 2004 12:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axqq4-0003ol-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 12:04:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxqoQ-0003Qa-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 12:02:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axqmy-00037k-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 12:01:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axqmu-0001rP-4S for manet-web-archive@ietf.org; Mon, 01 Mar 2004 12:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqmK-0000lg-R4; Mon, 01 Mar 2004 12:00:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqlT-0000Mo-G5 for manet@optimus.ietf.org; Mon, 01 Mar 2004 11:59:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21298 for ; Mon, 1 Mar 2004 11:59:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axqa0-0000PC-00 for manet@ietf.org; Mon, 01 Mar 2004 11:47:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxqZ1-0000AS-00 for manet@ietf.org; Mon, 01 Mar 2004 11:46:43 -0500 Received: from web60608.mail.yahoo.com ([216.109.119.82]) by ietf-mx with smtp (Exim 4.12) id 1AxqXH-0007RR-00 for manet@ietf.org; Mon, 01 Mar 2004 11:44:55 -0500 Message-ID: <20040301164424.47414.qmail@web60608.mail.yahoo.com> Received: from [211.235.170.119] by web60608.mail.yahoo.com via HTTP; Mon, 01 Mar 2004 08:44:24 PST Date: Mon, 1 Mar 2004 08:44:24 -0800 (PST) From: Jaehoon Jeong To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] MANET Address Autoconf Issues 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Maneters, I send my presentation material in order to discuss "MANET IP Address Autoconfiguration Issues" today afternoon as follows; - PPT file: http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-jaehoon.ppt - PDF file: http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-jaehoon.pdf If participants read this material, you can prepare the discussion well. Also, those who cannot take part in this Seoul meeting can comment on my drafts by email. Thanks. Regards, Jaehoon Paul Jeong __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 1 13:48:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27360 for ; Mon, 1 Mar 2004 13:48:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsSM-0000CC-Kd for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 13:47:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21IlwbG000748 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 13:47:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsSM-0000Bz-AP for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 13:47:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27332 for ; Mon, 1 Mar 2004 13:47:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsSK-0000Vt-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 13:47:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsRN-0000PM-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 13:46:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxsQh-0000JQ-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 13:46:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsQU-0008KB-L7; Mon, 01 Mar 2004 13:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxsQN-0008Jh-RY for manet@optimus.ietf.org; Mon, 01 Mar 2004 13:45:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27261 for ; Mon, 1 Mar 2004 13:45:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxsQL-0000Ho-00 for manet@ietf.org; Mon, 01 Mar 2004 13:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxsPS-0000CJ-00 for manet@ietf.org; Mon, 01 Mar 2004 13:44:59 -0500 Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx with esmtp (Exim 4.12) id 1AxsOf-000077-00 for manet@ietf.org; Mon, 01 Mar 2004 13:44:09 -0500 Received: from user-2ivfj9s.dialup.mindspring.com ([165.247.205.60] helo=earthlink.net) by mallard.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AxsOd-00008s-00 for manet@ietf.org; Mon, 01 Mar 2004 10:44:07 -0800 Message-ID: <40438473.1010506@earthlink.net> Date: Mon, 01 Mar 2004 10:44:03 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] (no subject) CDS vs. MPRs References: <002701c3fcb6$76d2f4d0$c637ad80@qwertyuiop2003> <403E8A03.6040709@earthlink.net> <006601c3fccb$6f7e1380$2502a8c0@triplecom.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, In this message I will try to summarize and address several comments and questions recently posted regarding MPR/CDS flooding in MANETs, and to suggest what I think is a good solution, based on some preliminary simulations I did over the weekend. (I plan to post more complete simulation results sometime next week.) I am not at the meeting this week, but hopefully some of these comments will be addressed at the meeting. The recent comments I am addressing include the following: 1. Some nodes may not be able to determine the neighbor (previous hop) that transmitted the flooded packet. 2. Reliability (i.e., packet loss) is a concern. 3. A CDS can be computed based on 2-hop neighbor information, without having to compute or advertise MPRs. Making the forwarding decision independent of the previous hop not only addresses item 1, but also improves reliability (item 2). This is because a given flooded packet might not be received from a particular neighbor (e.g., MPR selector) due to a collision or bad link, but might be received from some other neighbor (in which case the node can still relay the packet if the forwarding decision is independent of the previous hop). A second factor that can influence reliability is the selection of MPRs using the greedy algorithm (based on differential degree). This results in MPRs that are close to the perimeter of the reception region and are therefore more likely to be short lived or unstable. This issue can be addressed by using min ID instead of the greedy algorithm. (Using min ID also results in a faster, simpler algorithm.) If min ID is used, then another advantage is that nodes can select themselves as MPRs (or as CDS nodes) based only on 2-hop neighbor information. This allows faster recovery from link breakages, since a node can select itself as an MPR or CDS node immediately when a neighbor node reports a link breakage. Therefore, as someone suggested, it might be best to have an algorithm in which each node decides whether it should be in the CDS based on 2-hop neighbor information, as long as: 1. The number of the nodes in the CDS is close to the minimum achievable based on this information. 2. Packets that are flooded via the CDS reach all nodes along paths that are approximately min-hop. Moreover, as I suggested recently, we can require all nodes to participate in the CDS flooding algorithm, but allow a node the OPTION to also forward a flooded packet if the node is a (self-selected) MPR of the first neighbor from which the packet was received. This option can be used if the node can determine the previous hop, and if it is important for the packet to be flooded along min-hop paths. Over the weekend, I ran some simulations to compare a CDS algorithm based on 2-hop neighbor information, to the MPR-based CDS defined by Rules 1 and 2 in the INRIA report http://www.inria.fr/rrrt/rr-4597.html (Note that the MPR-based CDS is NOT based only on 2-hop neighbor information, but actually 3-hop neighbor information, since MPRs are based on 2-hop information and are advertised to neighbors.) 500 nodes were randomly placed in a unit square, with transmission radius equal to 0.4, which resulted in a network of diameter 4. The results are averaged over 10 random graphs. The following measures are compared for the MPR-based CDS algorithm and the CDS algorithm based only on 2-hop neighbor information (which will be described in my report next week). - Average size of the CDS - Average length (hops) of min-hop paths between all pairs - Average length (hops) of CDS paths between all pairs (using only CDS nodes as intermediate nodes). - Ratio of the above two average lengths Results for the MPR-based CDS: Average CDS size: 19.10 Average length of min-hop paths: 1.808 Average length of CDS paths: 1.960 Ratio of CDS hops to min hops: 1.084 (8.4% increase) Results for the CDS based only on 2-hop neighbor info: Average CDS size: 15.80 Average length of min-hop paths: 1.808 Average length of CDS paths: 1.986 Ratio of CDS hops to min hops: 1.098 (9.8% increase) Other CDS algorithms can be used, which may result in more CDS nodes but shorter paths. BTW, the average size of the CDS consisting of all MPRs was about 200. The above results are preliminary, and simulations are needed with mobile nodes that measure packet loss, etc. But the above results and arguments indicate that the best solution might be to use a CDS based only on 2-hop neighbor information. Regards, Richard _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 1 14:41:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00915 for ; Mon, 1 Mar 2004 14:41:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtHm-00040a-31 for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 14:41:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Jf60g015400 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 14:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtHl-00040J-TR for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 14:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00893 for ; Mon, 1 Mar 2004 14:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtHi-0006mK-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 14:41:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxtGl-0006em-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 14:40:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxtFu-0006YB-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 14:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtFl-0003bG-RQ; Mon, 01 Mar 2004 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtFg-0003ap-S6 for manet@optimus.ietf.org; Mon, 01 Mar 2004 14:38:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00808 for ; Mon, 1 Mar 2004 14:38:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtFe-0006WJ-00 for manet@ietf.org; Mon, 01 Mar 2004 14:38:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxtEk-0006Q7-00 for manet@ietf.org; Mon, 01 Mar 2004 14:37:59 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx with esmtp (Exim 4.12) id 1AxtDq-0006CT-00 for manet@ietf.org; Mon, 01 Mar 2004 14:37:02 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id i21JaFs5010553; Mon, 1 Mar 2004 14:36:20 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.3.37) with SMTP id M2004030114361930902 ; Mon, 01 Mar 2004 14:36:19 -0500 Message-Id: <6.0.3.0.2.20040301142912.02a6cec0@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Mon, 01 Mar 2004 14:36:30 -0500 To: Jaehoon Jeong , manet@ietf.org From: Joe Macker Subject: Re: [manet] MANET Address Autoconf Issues In-Reply-To: <20040301164424.47414.qmail@web60608.mail.yahoo.com> References: <20040301164424.47414.qmail@web60608.mail.yahoo.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 03:03 PM 3/1/2004, Jaehoon Jeong wrote: >Hi Maneters, > >I send my presentation material in order to discuss >"MANET IP Address Autoconfiguration Issues" today >afternoon as follows; > - PPT file: I, for one, will not be there so here are a few comments. In summary, I do not agree with your requirements. They are too strict. We should support multiple way of configuring MANETs just as a real network supports this in multiple ways. The use of MUSTs MUST be carefully considered. There are a few common problem areas I think we can define and potentially work on. (e.g., flooding service,etc) -Joe > >http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-jaehoon.ppt > - PDF file: > >http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-jaehoon.pdf > >If participants read this material, you can prepare >the discussion well. Also, those who cannot take part >in this Seoul meeting can comment on my drafts by >email. > >Thanks. > >Regards, >Jaehoon Paul Jeong > >__________________________________ >Do you Yahoo!? >Get better spam protection with Yahoo! Mail. >http://antispam.yahoo.com/tools > >_______________________________________________ >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 exim@www1.ietf.org Mon Mar 1 14:43:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01064 for ; Mon, 1 Mar 2004 14:43:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtJl-0004Ib-46 for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 14:43:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Jh9PK016519 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 14:43:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtJl-0004IM-0Q for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 14:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01019 for ; Mon, 1 Mar 2004 14:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtJi-00073l-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 14:43:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxtIg-0006vI-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 14:42:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxtHn-0006nC-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 14:41:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtHj-0003wP-Ds; Mon, 01 Mar 2004 14:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxtGk-0003tA-0Z for manet@optimus.ietf.org; Mon, 01 Mar 2004 14:40:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00856 for ; Mon, 1 Mar 2004 14:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxtGh-0006e2-00 for manet@ietf.org; Mon, 01 Mar 2004 14:39:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxtFm-0006Xh-00 for manet@ietf.org; Mon, 01 Mar 2004 14:39:03 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1AxtF7-0006Rj-00 for manet@ietf.org; Mon, 01 Mar 2004 14:38:21 -0500 Received: from yosemite.cs.ucsb.edu (yosemite [128.111.40.103]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id i21JcHN04296 for ; Mon, 1 Mar 2004 11:38:17 -0800 (PST) From: Elizabeth Belding-Royer To: manet@ietf.org Content-Type: text/plain Message-Id: <1078169899.9352.35.camel@yosemite.cs.ucsb.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Mar 2004 11:38:19 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] MWCN 2004 CFP 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit *************************************************** ****** CALL FOR PAPERS ********* *************************************************** * * * IEEE/IFIP MWCN 2004 * * The Sixth IEEE/IFIP International Conference on * * Mobile and Wireless Communications Networks * * * * Paris, France, 25 - 27 October, 2004 * * * * http://mwcn2004.lri.fr/ * *************************************************** MWCN 2004 is the sixth annual international conference dedicated to advancing research on mobile wireless networks. In the past few years, there has been growing interest in integrating stand-alone mobile networks with infrastructured wireless networks to create more robust and adaptable wireless networks. To further encourage research in this area, the theme of this years conference is: ** Convergence of Mobile Wireless Networks and the Internet ** You are invited to submit original papers to the conference for review. Potential topics include, but are not limited to, the following areas: * Mobile network architecture * Resource and information management * Mobility support, protocols, and algorithms * Connection management * Applications * Mobile ad hoc networks * Wireless local area networks * Analysis and simulation of mobile networks * Evaluation of mobile network testbeds * Mobile network security * Quality of service * Energy efficiency of protocols and devices All papers should be submitted electronically in Portable Document Format (PDF). Submissions should be in English, and the maximum page length is 6 pages in no smaller than 10 point font. The name and affiliation of all authors should be included on the paper, and the contact information for the lead author should be included in a cover page. Full submission instructions can be found at http://mwcn2004.lri.fr IMPORTANT DATES --------------- Submission deadline: March 31, 2004, 11:59PM PST Notification of acceptance: June 1, 2004 Camera-ready deadline: July 1, 2004 Conference: 25-27 October 2004 Conference General Chairs ------------------------- Khaldoun Al Agha LRI, University of Paris XI, France khaldoun.alagha@lri.fr Guy Pujolle University of Paris VI, Francs guy.pujolle@lip6.fr Conference Technical Program Chair ---------------------------------- Elizabeth M. Belding-Royer University of California, Santa Barbara ebelding@cs.ucsb.edu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 1 20:31:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20057 for ; Mon, 1 Mar 2004 20:31:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyke-00075u-1A for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 20:31:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221VGHq027269 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 20:31:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axykd-00075k-TB for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:31:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19962 for ; Mon, 1 Mar 2004 20:31:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axykb-00009x-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 20:31:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyjb-0007nI-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 20:30:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axyih-0007fQ-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 20:29:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyiW-0006h8-1m; Mon, 01 Mar 2004 20:29:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyhi-0006eU-Fv for manet@optimus.ietf.org; Mon, 01 Mar 2004 20:28:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19748 for ; Mon, 1 Mar 2004 20:28:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyhg-0007Vx-00 for manet@ietf.org; Mon, 01 Mar 2004 20:28:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axygq-0007NY-00 for manet@ietf.org; Mon, 01 Mar 2004 20:27:21 -0500 Received: from web60607.mail.yahoo.com ([216.109.118.245]) by ietf-mx with smtp (Exim 4.12) id 1Axyg0-000766-00 for manet@ietf.org; Mon, 01 Mar 2004 20:26:28 -0500 Message-ID: <20040302012559.26741.qmail@web60607.mail.yahoo.com> Received: from [218.37.227.240] by web60607.mail.yahoo.com via HTTP; Mon, 01 Mar 2004 17:25:59 PST Date: Mon, 1 Mar 2004 17:25:59 -0800 (PST) From: Jaehoon Jeong Subject: Re: [manet] MANET Address Autoconf Issues To: Joe Macker , manet@ietf.org In-Reply-To: <6.0.3.0.2.20040301142912.02a6cec0@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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dear Macker, --- Joe Macker wrote: > At 03:03 PM 3/1/2004, Jaehoon Jeong wrote: > >Hi Maneters, > > > >I send my presentation material in order to discuss > >"MANET IP Address Autoconfiguration Issues" today > >afternoon as follows; > > - PPT file: > > I, for one, will not be there so here are a few > comments. > In summary, I do not agree with your requirements. > They are too strict. > > We should support multiple way of configuring MANETs > just as a real network supports this in multiple > ways. > You are right in the aspect of address selection. I agree with you that MANET can allow several configuration methods; - DHCPv4 or DHCPv6 - IPv6 Stateless Address Autoconf - Dynamic Configuration of Link-Local IPv4 Addresses - Manual Configuration - etc. As you know, MANET address autoconf seems to consist of the following four steps; Step 1: Address selection How to select one of IP addresses in the address space. Step 2: Duplicate address detection How to detect a duplicate address Step 3: Address change negotiation Which node should perform a reallocation procedure Step 4: Maintenance of upper-layer sessions How to let an upper-layer session avoid a connection breakage Especially, it seems that you talk about address selection problem of Step 1. Whichever address selection mechanism a mobile node uses, a unified DAD mechanism is required. > The use of MUSTs MUST be carefully considered. > Sure, I will carefully replace MUSTs with another through the discussion with MANET members including authors. > There are a few common problem areas I think we can > define > and potentially work on. (e.g., flooding > service,etc) > Do you mean that we can use a general flooding service for DAD operation? If so, is it not so general a requirement? Anyway, I agree with you that there are other problem areas. We authors need your feedback and will reflect your comments and suggestions to a revised requirements draft. Thanks. Regards, Paul > -Joe > > > >http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-jaehoon.ppt > > - PDF file: > > > >http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-jaehoon.pdf > > > >If participants read this material, you can prepare > >the discussion well. Also, those who cannot take > part > >in this Seoul meeting can comment on my drafts by > >email. > > > >Thanks. > > > >Regards, > >Jaehoon Paul Jeong > > > >__________________________________ > >Do you Yahoo!? > >Get better spam protection with Yahoo! Mail. > >http://antispam.yahoo.com/tools > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www1.ietf.org/mailman/listinfo/manet > > __________________________________ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 1 20:44:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20984 for ; Mon, 1 Mar 2004 20:44:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyx6-0001YN-HQ for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 20:44:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221i8h7005965 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 20:44:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyx6-0001Y8-DV for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:44:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20915 for ; Mon, 1 Mar 2004 20:44:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyx4-0001on-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 20:44:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyw7-0001f5-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 20:43:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axyv8-0001W0-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 20:42:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyv3-0000wo-M9; Mon, 01 Mar 2004 20:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxyuF-0000oN-RK for manet@optimus.ietf.org; Mon, 01 Mar 2004 20:41:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20598 for ; Mon, 1 Mar 2004 20:41:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxyuD-0001OA-00 for manet@ietf.org; Mon, 01 Mar 2004 20:41:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxytT-0001Hm-00 for manet@ietf.org; Mon, 01 Mar 2004 20:40:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Axysc-0001Ax-00 for manet@ietf.org; Mon, 01 Mar 2004 20:39:30 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Axysd-0000vO-Ci for manet@ietf.org; Tue, 02 Mar 2004 01:39:31 +0000 Date: Tue, 2 Mar 2004 10:39:07 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <17859160117.20040302103907@psg.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] Slides for MANET meeting 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks presenting this afternoon, if you are online, please send me your slides. -- Alex http://www.psg.com/~zinin/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 1 21:05:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22513 for ; Mon, 1 Mar 2004 21:05:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzHe-0004DF-0T for manet-archive@odin.ietf.org; Mon, 01 Mar 2004 21:05:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2225LSE016186 for manet-archive@odin.ietf.org; Mon, 1 Mar 2004 21:05:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzHd-0004Cz-Sr for manet-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 21:05:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22461 for ; Mon, 1 Mar 2004 21:05:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzHb-0004nT-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 21:05:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzGi-0004ek-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 21:04:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxzFi-0004WF-00 for manet-web-archive@ietf.org; Mon, 01 Mar 2004 21:03:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzFO-0003oN-TI; Mon, 01 Mar 2004 21:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxzEZ-0003lO-Vl for manet@optimus.ietf.org; Mon, 01 Mar 2004 21:02:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22319 for ; Mon, 1 Mar 2004 21:02:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxzEX-0004Nc-00 for manet@ietf.org; Mon, 01 Mar 2004 21:02:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxzDh-0004H9-00 for manet@ietf.org; Mon, 01 Mar 2004 21:01:18 -0500 Received: from ent.umds.ac.uk ([159.92.16.14]) by ietf-mx with smtp (Exim 4.12) id 1AxzD0-0004AQ-00 for manet@ietf.org; Mon, 01 Mar 2004 21:00:34 -0500 Received: (qmail 17631 invoked by uid 0); 2 Mar 2004 02:47:53 -0000 Received: from redwood.kcl.ac.uk (137.73.66.71) by ent.umds.ac.uk with SMTP; 2 Mar 2004 02:47:53 -0000 Received: from mamani (213-162-107-101.alimoe070.adsl.metronet.co.uk [213.162.107.101] (may be forged)) by redwood.kcl.ac.uk with SMTP id i221uPv4017389 for ; Tue, 2 Mar 2004 01:56:25 GMT Message-ID: <005e01c3fff8$62c8b980$656ba2d5@mamani> From: "Mona Ghassemian" To: Date: Tue, 2 Mar 2004 01:47:56 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C3FFF8.629F86A0" 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 X-KCL-MailScanner: Found to be CLEAN Subject: [manet] Sensor networks and 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C3FFF8.629F86A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, Do you think that using IPv6 packets consume significant energy because = of the length of their headers? What would be the possible solutions for = addressing fin wireless sensor networks if they work stand alone or = connect to the Internet? Can you please reference me to some of the = publications related to use of IPv6 in wireless sensor networks?=20 Many thanks, Mona ------=_NextPart_000_005B_01C3FFF8.629F86A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,
 
Do you think that using = IPv6 packets=20 consume significant energy because of the length of their headers? = What=20 would be the possible solutions for addressing fin wireless sensor = networks if=20 they work stand alone or connect to the Internet? Can you please = reference me to=20 some of the publications related to use of IPv6 in wireless sensor = networks?=20
 
Many thanks,
Mona
------=_NextPart_000_005B_01C3FFF8.629F86A0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 02:12:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20715 for ; Tue, 2 Mar 2004 02:12:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay44i-0000Vf-Ie for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 02:12:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i227CKxo001916 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 02:12:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay44g-0000Up-GL for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 02:12:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20562 for ; Tue, 2 Mar 2004 02:12:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay44c-0003FJ-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 02:12:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay43d-00036E-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 02:11:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay42i-0002zE-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 02:10:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay42W-0007zo-Jq; Tue, 02 Mar 2004 02:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay41w-0007nV-QT for manet@optimus.ietf.org; Tue, 02 Mar 2004 02:09:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18584 for ; Tue, 2 Mar 2004 02:09:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay41t-0002sV-00 for manet@ietf.org; Tue, 02 Mar 2004 02:09:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay419-0002l4-00 for manet@ietf.org; Tue, 02 Mar 2004 02:08:40 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1Ay40N-0002aS-00 for manet@ietf.org; Tue, 02 Mar 2004 02:07:51 -0500 Received: from jafymobile (jafy-mobile.wireless.ietf59.or.kr [218.37.227.109]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDWHZRZ; Tue, 2 Mar 2004 16:07:27 +0900 Reply-To: From: "HyunWook Cha" To: "'IETF Manet'" Cc: "???????" Date: Tue, 2 Mar 2004 16:07:17 +0900 Organization: ETRI Message-ID: <005301c40025$0235b280$6de325da@jafymobile> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, all. After my presentation is finished, I got two comments. Although Paal's comments which are more technical seem to be resolved(I guess. If wrong, please correct me, Paal), I think that I must tell what is different with existing solutions for MANET Internet connectivity in my draft. As I mentioned at my presentation, my draft consists of two component. Route determination algorithm and Forwarding algorithm. As you know, these are critical parts in this area(Int. Connectivity) and all existing solutions address with their own way. Firstly, route optimization is not mentioned at existing drafts referenced by mine (If wrong, please correct me.) As for proposed forwarding algorithm, forwarding using default route can be done for packets without routing header. I.E, after look up of routing table with destination address fails, forwarding decision is based on source global address of the packet. That is, gw_info list is searched with source prefix. If matched gw_info is found, the packet is forwarded through host route entry for the gw advertising the prefix. Thus, multiple addresses from multiple gateways can be configured in a node and intermediate nodes can forward packets without routing header only if gateway info list is maintained in the node. I request valuable comments on my draft from authors of previous drafts including C. Perkins, Wakikawa, C. Jelger, Pekka. Personally I also believe that this area is very important and it is time to make progress. How about requirement document or merged solution document? Please let me know what is in your mind. Whoever is interested in this topic may be welcomed in this thread. Kindly Regards, HyunWook Cha _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 02:41:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22940 for ; Tue, 2 Mar 2004 02:41:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4Ww-0000X1-5y for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 02:41:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i227fT74002033 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 02:41:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4Wu-0000WU-FI for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 02:41:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22825 for ; Tue, 2 Mar 2004 02:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4Wq-00072w-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 02:41:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4Uv-0006Vv-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 02:39:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay4Tf-0006Du-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 02:38:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay4K5-0002Nh-Br for manet-web-archive@ietf.org; Tue, 02 Mar 2004 02:28:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4Jv-00068N-4X; Tue, 02 Mar 2004 02:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4JA-0005sq-Tw for manet@optimus.ietf.org; Tue, 02 Mar 2004 02:27:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22040 for ; Tue, 2 Mar 2004 02:27:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4J7-00058E-00 for manet@ietf.org; Tue, 02 Mar 2004 02:27:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4IC-00052S-00 for manet@ietf.org; Tue, 02 Mar 2004 02:26:16 -0500 Received: from web60601.mail.yahoo.com ([216.109.118.221]) by ietf-mx with smtp (Exim 4.12) id 1Ay4HF-0004qU-00 for manet@ietf.org; Tue, 02 Mar 2004 02:25:17 -0500 Message-ID: <20040302072448.5169.qmail@web60601.mail.yahoo.com> Received: from [218.37.231.206] by web60601.mail.yahoo.com via HTTP; Mon, 01 Mar 2004 23:24:48 PST Date: Mon, 1 Mar 2004 23:24:48 -0800 (PST) From: Jaehoon Jeong To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA22042 Subject: [manet] Re: Slides for MANET meeting 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I send my material presented at this meeting; - http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-ja= ehoon.ppt - http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-ja= ehoon.pdf "MANET Address Autoconf" requirements draft will be enhanced by your comments. We authors will reflect Joe Macker's and Paal's comments to the revised version. When we are ready, I will circulate it. Have a nice trip in Seoul! Thanks. Paul __________________________________ Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster http://search.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 03:40:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26472 for ; Tue, 2 Mar 2004 03:40:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5RG-0007xP-9j for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 03:39:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i228dgHT030533 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 03:39:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5R7-0007wD-Nc for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:39:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26335 for ; Tue, 2 Mar 2004 03:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5R5-0007V6-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 03:39:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay5Py-0007G9-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 03:38:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay5PU-00079r-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 03:37:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay5PV-0003cW-8c for manet-web-archive@ietf.org; Tue, 02 Mar 2004 03:37:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5Oh-0007Nr-SJ; Tue, 02 Mar 2004 03:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5O3-0007Mi-CF for manet@optimus.ietf.org; Tue, 02 Mar 2004 03:36:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26268 for ; Tue, 2 Mar 2004 03:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5O1-00073g-00 for manet@ietf.org; Tue, 02 Mar 2004 03:36:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay5N6-0006xx-00 for manet@ietf.org; Tue, 02 Mar 2004 03:35:25 -0500 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1Ay5Mk-0006ri-00 for manet@ietf.org; Tue, 02 Mar 2004 03:35:02 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 7D4AB1C2EEE; Tue, 2 Mar 2004 09:34:32 +0100 (CET) Received: from correo.um.es (zape.um.es [155.54.212.102]) by smtp.um.es (Postfix) with ESMTP id 5CD7EA489D; Tue, 2 Mar 2004 09:34:32 +0100 (CET) Received: from correo.um.es (myotis.um.es [155.54.212.92]) by localhost (Postfix) with ESMTP id DFDEF1EED2; Tue, 2 Mar 2004 09:34:30 +0100 (MET) Received: from dif.um.es (dibulibu.um.es [155.54.1.250]) by correo.um.es (Postfix) with ESMTP id 5E15B1EEC9; Tue, 2 Mar 2004 09:34:27 +0100 (MET) Message-ID: <40444491.9090406@dif.um.es> Date: Tue, 02 Mar 2004 09:23:45 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jafy@etri.re.kr Cc: "'IETF Manet'" , ??????? Subject: Re: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt References: <005301c40025$0235b280$6de325da@jafymobile> In-Reply-To: <005301c40025$0235b280$6de325da@jafymobile> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear HyunWook, Please find my comments inline... HyunWook Cha wrote: >I request valuable comments on my draft from authors of previous drafts >including C. Perkins, Wakikawa, C. Jelger, Pekka. Personally I also >believe that this area is very important and it is time to make >progress. How about requirement document or merged solution document? > I completely agree with you on the need for a coordinated effort on this. I submitted recently such kind of requirement draft for IP Multicast internet conectivity (http://www.ietf.org/internet-drafts/draft-ruiz-manet-mcast-gw-reqs-00.txt). Some of these requirements may also apply for the Internet connectivity area. So, I think that trying to define such kind of requirement document for Internet connectivity is interesting. >Please let me know what is in your mind. Whoever is interested in this >topic may be welcomed in this thread. > > My personal view is that currently we have different proposed solutions but it is not possible to decide which one is better because we have not settled down any requirements. I think at this point what we need is to prepare a requirement document stating the agreed view of the group. After that, we can then match different solutions againts the requirements and try to get an unified solution. If you are interested in producing such a requiment document, I'd be happy to contribute. Let's move forward!! Best Regards, Pedrom _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 03:40:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26573 for ; Tue, 2 Mar 2004 03:40:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5Rf-000817-CW for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 03:40:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i228e5x8030776 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 03:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5RZ-000806-Bw for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:40:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26445 for ; Tue, 2 Mar 2004 03:39:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5RW-0007Yo-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 03:39:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay5QP-0007Kr-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 03:38:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay5Pc-00079s-01 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 03:38:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay5JD-0003Ve-Dh for manet-web-archive@ietf.org; Tue, 02 Mar 2004 03:31:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5Iu-0006oJ-3Q; Tue, 02 Mar 2004 03:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay5IA-0006h9-7p for manet@optimus.ietf.org; Tue, 02 Mar 2004 03:30:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26089 for ; Tue, 2 Mar 2004 03:30:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5I7-0006OF-00 for manet@ietf.org; Tue, 02 Mar 2004 03:30:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay5HD-0006Ic-00 for manet@ietf.org; Tue, 02 Mar 2004 03:29:20 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1Ay5GR-0006D6-00 for manet@ietf.org; Tue, 02 Mar 2004 03:28:32 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i228VJZr020244 for ; Tue, 2 Mar 2004 09:31:19 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <404453F5.3050200@dpt-info.u-strasbg.fr> Date: Tue, 02 Mar 2004 10:29:25 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 CC: "'IETF Manet'" Subject: Re: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt References: <005301c40025$0235b280$6de325da@jafymobile> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, I could not go to the IETF but I will have a look at all the latest proposals (HyunWook Cha and Jaehoon Jeong) and will give some coments as soon as possible. I agree with HyunWook Cha that it we could collaborate to write a requirement draft. Regards, Christophe HyunWook Cha wrote: >Hello, all. > >After my presentation is finished, I got two comments. Although Paal's >comments which are more technical seem to be resolved(I guess. If wrong, >please correct me, Paal), I think that I must tell what is different >with existing solutions for MANET Internet connectivity in my draft. > >As I mentioned at my presentation, my draft consists of two component. >Route determination algorithm and Forwarding algorithm. As you know, >these are critical parts in this area(Int. Connectivity) and all >existing solutions address with their own way. > >Firstly, route optimization is not mentioned at existing drafts >referenced by mine (If wrong, please correct me.) > >As for proposed forwarding algorithm, forwarding using default route can >be done for packets without routing header. I.E, after look up of >routing table with destination address fails, forwarding decision is >based on source global address of the packet. That is, gw_info list is >searched with source prefix. If matched gw_info is found, the packet is >forwarded through host route entry for the gw advertising the prefix. >Thus, multiple addresses from multiple gateways can be configured in a >node and intermediate nodes can forward packets without routing header >only if gateway info list is maintained in the node. > >I request valuable comments on my draft from authors of previous drafts >including C. Perkins, Wakikawa, C. Jelger, Pekka. Personally I also >believe that this area is very important and it is time to make >progress. How about requirement document or merged solution document? >Please let me know what is in your mind. Whoever is interested in this >topic may be welcomed in this thread. > >Kindly Regards, > >HyunWook Cha > > > > >_______________________________________________ >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 exim@www1.ietf.org Tue Mar 2 10:11:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13623 for ; Tue, 2 Mar 2004 10:11:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBXV-0002cG-6B for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 10:10:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22FAXfa010050 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 10:10:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBXU-0002c1-Uw for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 10:10:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13531 for ; Tue, 2 Mar 2004 10:10:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBXS-0003mI-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 10:10:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBWT-0003c2-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 10:09:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyBVV-0003Tb-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 10:08:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBV6-0001gw-5D; Tue, 02 Mar 2004 10:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBUd-0001Wz-7h for manet@optimus.ietf.org; Tue, 02 Mar 2004 10:07:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13234 for ; Tue, 2 Mar 2004 10:07:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBUb-0003NL-00 for manet@ietf.org; Tue, 02 Mar 2004 10:07:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBTj-0003H9-00 for manet@ietf.org; Tue, 02 Mar 2004 10:06:40 -0500 Received: from web60907.mail.yahoo.com ([216.155.196.83]) by ietf-mx with smtp (Exim 4.12) id 1AyBSp-00033Q-00 for manet@ietf.org; Tue, 02 Mar 2004 10:05:43 -0500 Message-ID: <20040302150513.84408.qmail@web60907.mail.yahoo.com> Received: from [156.26.108.10] by web60907.mail.yahoo.com via HTTP; Tue, 02 Mar 2004 07:05:13 PST Date: Tue, 2 Mar 2004 07:05:13 -0800 (PST) From: Jas C To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1182510575-1078239913=:83171" Subject: [manet] Will there be a collision??? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1182510575-1078239913=:83171 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA13235 Content-Transfer-Encoding: quoted-printable Hello everyone, =20 This is related to a doubt raised on "strong interfering signals". =20 I need clarification on the following scenario based on a string topology= where any node can only hear its immediate neighbors and a nodes interfe= rence range and transmission range are equal. =20 If there are four nodes placed as A ---- B ---- C ----D , can B transmit= to A and C to D at the same time without there being a collision between= B and C ?=20 =20 I understand that this is a typical exposed node problem and parallel tra= nsmissions are possible depending on the type of MAC protocol being used.= =20 =20 My concern is if B and C are within each other's ranges wouldn't their tr= ansmissions collide whereby A and D would not receive anything ?? =20 I would appreciate any suggestions/pointers to help me clear this doubt. =20 Thanks a lot in advance, Jasmina =20 --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster. --0-1182510575-1078239913=:83171 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA13235 Content-Transfer-Encoding: quoted-printable
Hello everyone,
 
This is related to a doubt raised on "strong interfering signal= s".
 
I need clarification on the following scenario based on a string top= ology where any node can only hear its immediate neighbors and a nod= es interference range and transmission range are equal.
 
If there are four nodes placed as  A ---- B ---- C ----D , = ;can B transmit to A and C to D at the same time without there being= a collision between B and C ?
 
I understand that this is a typical exposed node problem a= nd parallel transmissions are possible depending on the type of MAC = protocol being used.
 
My concern is if B and C are within each other's ranges wouldn't the= ir transmissions  collide whereby A and D would not receive anything= ??
 
I would appreciate any suggestions/pointers to help me clear th= is doubt.
 
Thanks a lot in advance,
Jasmina
 

Do you Yahoo!?
Yahoo! Search - Find what you=92re looking for faster. --0-1182510575-1078239913=:83171-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 10:28:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14991 for ; Tue, 2 Mar 2004 10:28:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBoV-0006Kt-Qq for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 10:28:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22FS7dU024339 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 10:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBoU-0006KK-Qp for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 10:28:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14961 for ; Tue, 2 Mar 2004 10:28:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBoS-00069h-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 10:28:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBnT-0005zP-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 10:27:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyBmf-0005oa-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 10:26:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBmV-0005ya-Fx; Tue, 02 Mar 2004 10:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBm6-0005vi-HL for manet@optimus.ietf.org; Tue, 02 Mar 2004 10:25:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14855 for ; Tue, 2 Mar 2004 10:25:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBm4-0005lu-00 for manet@ietf.org; Tue, 02 Mar 2004 10:25:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBl8-0005eM-00 for manet@ietf.org; Tue, 02 Mar 2004 10:24:39 -0500 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 1AyBkT-0005R2-00 for manet@ietf.org; Tue, 02 Mar 2004 10:23:58 -0500 Received: from SRCATL-MTA by mail.scires.com with Novell_GroupWise; Tue, 02 Mar 2004 10:21:08 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Tue, 02 Mar 2004 10:20:35 -0500 From: "Andreas Yankopolus" To: "<" Subject: Re: [manet] Will there be a collision??? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jasmina, Interference occurs on the receiving end, not the transmitting end, so B = could transmit to A and C to D simultaneously. Given the transmission = ranges in your post, C's transmission would not reach A and B's would not = reach D. Note that B and C would not transmit simultaneously in your scenario when = using 802.11 radios. Suppose B transmits first: C would hear B's RTS and = stay silent until B is finished with its transmission (this assumes = RTS/CTS has been enabled). This is known as the exposed node problem. Cheers, Andreas >>> Jas C 03/02/04 10:05AM >>> Hello everyone, =20 This is related to a doubt raised on "strong interfering signals". =20 I need clarification on the following scenario based on a string topology = where any node can only hear its immediate neighbors and a nodes interferen= ce range and transmission range are equal. =20 If there are four nodes placed as A ---- B ---- C ----D , can B transmit = to A and C to D at the same time without there being a collision between B = and C ?=20 =20 I understand that this is a typical exposed node problem and parallel = transmissions are possible depending on the type of MAC protocol being = used.=20 =20 My concern is if B and C are within each other's ranges wouldn't their = transmissions collide whereby A and D would not receive anything ?? =20 I would appreciate any suggestions/pointers to help me clear this doubt. =20 Thanks a lot in advance, Jasmina =20 --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you're looking for faster. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 10:38:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15529 for ; Tue, 2 Mar 2004 10:38:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBxt-0007Mt-3T for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 10:37:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22FbnO0028317 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 10:37:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBxs-0007MU-Ne for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 10:37:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15501 for ; Tue, 2 Mar 2004 10:37:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBxq-0007Of-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 10:37:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBwr-0007GP-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 10:36:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyBwU-00078R-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 10:36:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBwA-0006lq-9F; Tue, 02 Mar 2004 10:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBvh-0006kg-Px for manet@optimus.ietf.org; Tue, 02 Mar 2004 10:35:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15397 for ; Tue, 2 Mar 2004 10:35:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBvf-000769-00 for manet@ietf.org; Tue, 02 Mar 2004 10:35:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBuf-0006zK-00 for manet@ietf.org; Tue, 02 Mar 2004 10:34:30 -0500 Received: from cartero2.sci.uma.es ([150.214.40.6]) by ietf-mx with esmtp (Exim 4.12) id 1AyBtj-0006nc-00 for manet@ietf.org; Tue, 02 Mar 2004 10:33:31 -0500 Received: from correo2.uma.es (vesta2.sci.uma.es [150.214.40.7]) by cartero2.sci.uma.es (Postfix) with ESMTP id 9769F23D30 for ; Tue, 2 Mar 2004 16:32:59 +0100 (CET) Received: from pc116te.dte.uma.es (atmpc116.dte.uma.es [150.214.59.116]) by correo2.uma.es (Postfix) with ESMTP id 5EBD95D631 for ; Tue, 2 Mar 2004 16:32:59 +0100 (CET) Message-Id: <5.1.0.14.2.20040302163149.02cca3c8@buzonpdi.uma.es> X-Sender: atc@buzonpdi.uma.es X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Mar 2004 16:33:02 +0100 To: manet@ietf.org From: Alicia =?iso-8859-1?Q?Trivi=F1o?= Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] Temporal Logic 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Does anyone know where I could find any paper about "temporal logic" and ad= =20 hoc network? Thanks in advance Alicia Trivi=F1o / Tl. +34-95.213.28.44 Dpto. Tecnologia Electronica E.T.S. Ing. Telecomunicacion Universidad de Malaga Campus Universitario de Teatinos 29071 Malaga, Spain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 11:33:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18021 for ; Tue, 2 Mar 2004 11:33:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCp7-0003cR-2B for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 11:32:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22GWm3d013752 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 11:32:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCp5-0003Wv-TK for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 11:32:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17998 for ; Tue, 2 Mar 2004 11:32:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyCp4-00077a-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 11:32:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyCoC-0006z9-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 11:31:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyCnb-0006pq-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 11:31:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCnO-00038U-IS; Tue, 02 Mar 2004 11:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCnH-00037o-07 for manet@optimus.ietf.org; Tue, 02 Mar 2004 11:30:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17915 for ; Tue, 2 Mar 2004 11:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyCnF-0006pO-00 for manet@ietf.org; Tue, 02 Mar 2004 11:30:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyCmT-0006hE-00 for manet@ietf.org; Tue, 02 Mar 2004 11:30:06 -0500 Received: from csiges9.insa-lyon.fr ([134.214.79.200] helo=mail.insa-lyon.fr) by ietf-mx with esmtp (Exim 4.12) id 1AyClk-0006Wb-00 for manet@ietf.org; Tue, 02 Mar 2004 11:29:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.insa-lyon.fr (Postfix) with ESMTP id D251F4B489; Tue, 2 Mar 2004 17:28:45 +0100 (CET) Received: from [134.214.144.152] (ares-chaudet-1.insa-lyon.fr [134.214.144.152]) by mail.insa-lyon.fr (Postfix) with ESMTP id 7A22B4B606; Tue, 2 Mar 2004 17:28:44 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: "<" From: Claude Chaudet Subject: Re: [manet] Will there be a collision??? Date: Tue, 2 Mar 2004 17:29:10 +0100 To: "Andreas Yankopolus" X-Mailer: Apple Mail (2.612) X-Virus-Scanned: by amavisd 0.1 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, In fact, considering radio propagation and the signal over noise ratio=20= required to decode a frame, if B and C transmit simultaneously, there is a chance=20 that both transmissions will be jammed (it depends on radio propagation though).=20= Using a simple free space propagation model (attenuation of the signal is 1=20 over square of distance) and a SNR threshold value of 10, a signal can jam other transmissions=20= for which the receiver is distant of about three times the transmission range. (Of=20 course, this is the worst case in the worst theoretical modeling of attenuation). In a real-wold situation, interferences at reception can happen or not.=20= There is no way of knowing Moreover, even without RTS / CTS exchange, IEEE 802.11 performs carrier sense before transmission and B will prevent from transmitting if C has=20= already started its transmission. Claude. Le 2 mars 04, =E0 16:20, Andreas Yankopolus a =E9crit : > Jasmina, > > Interference occurs on the receiving end, not the transmitting end, so=20= > B could transmit to A and C to D simultaneously. Given the=20 > transmission ranges in your post, C's transmission would not reach A=20= > and B's would not reach D. > > Note that B and C would not transmit simultaneously in your scenario=20= > when using 802.11 radios. Suppose B transmits first: C would hear B's=20= > RTS and stay silent until B is finished with its transmission (this=20 > assumes RTS/CTS has been enabled). This is known as the exposed node=20= > problem. > > Cheers, > > Andreas > >>>> Jas C 03/02/04 10:05AM >>> > Hello everyone, > > This is related to a doubt raised on "strong interfering signals". > > I need clarification on the following scenario based on a string=20 > topology where any node can only hear its immediate neighbors and a=20 > nodes interference range and transmission range are equal. > > If there are four nodes placed as A ---- B ---- C ----D , can B=20 > transmit to A and C to D at the same time without there being a=20 > collision between B and C ? > > I understand that this is a typical exposed node problem and parallel=20= > transmissions are possible depending on the type of MAC protocol being=20= > used. > > My concern is if B and C are within each other's ranges wouldn't their=20= > transmissions collide whereby A and D would not receive anything ?? > > I would appreciate any suggestions/pointers to help me clear this=20 > doubt. > > Thanks a lot in advance, > Jasmina > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Search - Find what you're looking for faster. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > Claude. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 11:54:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18979 for ; Tue, 2 Mar 2004 11:54:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyD9K-0006jc-Gu for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 11:53:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22GrgU3025887 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 11:53:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyD9K-0006jS-6X for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 11:53:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18948 for ; Tue, 2 Mar 2004 11:53:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyD9I-0002G5-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 11:53:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyD8S-00028K-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 11:52:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyD7v-00020b-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 11:52:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyD7i-00067i-Lm; Tue, 02 Mar 2004 11:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyD7R-00066w-Ev for manet@optimus.ietf.org; Tue, 02 Mar 2004 11:51:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18873 for ; Tue, 2 Mar 2004 11:51:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyD7Q-0001yX-00 for manet@ietf.org; Tue, 02 Mar 2004 11:51:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyD6a-0001qF-00 for manet@ietf.org; Tue, 02 Mar 2004 11:50:53 -0500 Received: from nestor.nmsu.edu ([128.123.34.146] helo=mail.nmsu.edu) by ietf-mx with esmtp (Exim 4.12) id 1AyD5k-0001hm-00 for manet@ietf.org; Tue, 02 Mar 2004 11:50:00 -0500 Received: from PCMullen2 (pc-mullen-2.NMSU.Edu [128.123.245.103]) by mail.nmsu.edu (Postfix) with ESMTP id 1F0A2201B; Tue, 2 Mar 2004 09:49:59 -0700 (MST) From: "John Mullen" To: "'Claude Chaudet'" Cc: "'<'" Subject: RE: [manet] Will there be a collision??? Date: Tue, 2 Mar 2004 09:49:59 -0700 Message-ID: <000b01c40076$660bb240$67f57b80@IEngr.ad.nmsu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Claude, Well, this violates the assumptions of the original question, but is certainly a valid point. However, due to stochastic fading, instantaneous differences in signal strength can easily differ from the predicted mean value by plus-or-minus 20 or 30 dB. That is, given the right(?) set of circumstances, the signal from C could actually be stronger at A than at B. Which is one of the things that makes MANETs interesting. :-) John Mullen -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Claude Chaudet Sent: Tuesday, March 02, 2004 9:29 AM To: Andreas Yankopolus Cc: < Subject: Re: [manet] Will there be a collision??? Hi, In fact, considering radio propagation and the signal over noise ratio=20 required to decode a frame, if B and C transmit simultaneously, there is a chance=20 that both transmissions will be jammed (it depends on radio propagation though).=20 Using a simple free space propagation model (attenuation of the signal is 1=20 over square of distance) and a SNR threshold value of 10, a signal can jam other transmissions=20 for which the receiver is distant of about three times the transmission range. (Of=20 course, this is the worst case in the worst theoretical modeling of attenuation). In a real-wold situation, interferences at reception can happen or not.=20 There is no way of knowing Moreover, even without RTS / CTS exchange, IEEE 802.11 performs carrier sense before transmission and B will prevent from transmitting if C has=20 already started its transmission. Claude. Le 2 mars 04, =E0 16:20, Andreas Yankopolus a =E9crit : > Jasmina, > > Interference occurs on the receiving end, not the transmitting end, so > B could transmit to A and C to D simultaneously. Given the=20 > transmission ranges in your post, C's transmission would not reach A=20 > and B's would not reach D. > > Note that B and C would not transmit simultaneously in your scenario > when using 802.11 radios. Suppose B transmits first: C would hear B's=20 > RTS and stay silent until B is finished with its transmission (this=20 > assumes RTS/CTS has been enabled). This is known as the exposed node=20 > problem. > > Cheers, > > Andreas > >>>> Jas C 03/02/04 10:05AM >>> > Hello everyone, > > This is related to a doubt raised on "strong interfering signals". > > I need clarification on the following scenario based on a string > topology where any node can only hear its immediate neighbors and a=20 > nodes interference range and transmission range are equal. > > If there are four nodes placed as A ---- B ---- C ----D , can B > transmit to A and C to D at the same time without there being a=20 > collision between B and C ? > > I understand that this is a typical exposed node problem and parallel > transmissions are possible depending on the type of MAC protocol being > used. > > My concern is if B and C are within each other's ranges wouldn't their > transmissions collide whereby A and D would not receive anything ?? > > I would appreciate any suggestions/pointers to help me clear this > doubt. > > Thanks a lot in advance, > Jasmina > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Search - Find what you're looking for faster. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > Claude. _______________________________________________ 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 exim@www1.ietf.org Tue Mar 2 13:39:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23873 for ; Tue, 2 Mar 2004 13:39:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEnD-0003Yy-QA for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 13:38:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22IcxFK013690 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 13:38:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEnD-0003Yj-MB for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 13:38:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23785 for ; Tue, 2 Mar 2004 13:38:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyEnB-0001fB-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 13:38:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyElf-0001Ew-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 13:37:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyEjX-0000fV-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 13:35:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyEjY-0007WA-2a for manet-web-archive@ietf.org; Tue, 02 Mar 2004 13:35:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEjO-0002UC-TI; Tue, 02 Mar 2004 13:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyEir-0002Sj-5O for manet@optimus.ietf.org; Tue, 02 Mar 2004 13:34:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23139 for ; Tue, 2 Mar 2004 13:34:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyEip-0000Sj-00 for manet@ietf.org; Tue, 02 Mar 2004 13:34:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyEgv-0007iH-00 for manet@ietf.org; Tue, 02 Mar 2004 13:32:30 -0500 Received: from [142.92.39.129] (helo=mercury.dgim.crc.ca) by ietf-mx with esmtp (Exim 4.12) id 1AyEeD-0006yp-00 for manet@ietf.org; Tue, 02 Mar 2004 13:29:41 -0500 Received: from anik2 (anik2.dgrc.crc.ca [142.92.34.76]) by mercury.dgim.crc.ca (8.12.10/Bubba's Mail 0.2.6f) with SMTP id i22ITB6C003529 for ; Tue, 2 Mar 2004 13:29:11 -0500 Message-ID: <007101c40084$404a22e0$4c225c8e@anik2> From: "ying ge" To: References: <5.1.0.14.2.20040302163149.02cca3c8@buzonpdi.uma.es> Date: Tue, 2 Mar 2004 13:29:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [manet] OLSR - questions on MPR calculation 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear group, I'm looking at the proposed OLSR_RFC MPR selection mechanism, and have the following questions: 1) in step 1 of MPR calculation -- "Start with an MPR set made of all members of N with N_willingness equal to WILL_ALWAYS" Does it mean that a "WILL_ALWAYS" neighbor has to be selected as MPR even if it has no connection to any 2-hop neighbors? In this case, the MID and TC messages would be unnecessarily relayed by that neighbor, which may make the wireless media busier. Can we put it as "Start with an MPR set made of all members of N with N_willingness equal to WILL_ALWAYS, and N has at least one 2_hop_neighbor"? 2) in step 4.2 -- "Select as a MPR the node with highest N_willingness among the nodes in N with non-zero reachability. In case of multiple choice select the node which provides reachability to the maximum number of nodes in N2. In case of multiple nodes providing the same amount of reachability, select the node as MPR whose D(y) is greater. Remove the nodes from N2 which are now covered by a node in the MPR set. " If we select neighbors with higher willingness as MPR, regardless how many two hop neighbors it is connected to, may we ended up choose a lot of MPRs? If there is too many MPRs in the network, the control overhead of the OLSR may be very high, which may degrade the routing protocol's performance (more data packet may be dropped because of the busy media, the end-to-end delay of the data packets may be very long...). I have such a question because I used to introduce QoS routing into OLSR, and tried to select as MPR the neighbors which have the best QoS conditions, which is similar to the concept that "to select as the highest willingness neighbors as MPR". From the OPENT simulation, I found that with such mechanism, much more MPRs is selected, compared with the mechanism proposed in OLSR draft version 3 (select the neighbor which have the most reachability to the 2-hop-neighbors). Further more, the OPNET simulation result shows that because of the large numbers of MPRs in the network, the overhead is high, and the routing protocol's performance ("packet delivery ratio" and "end-to-end-delay" for data packets) is not satisfactory. My idea to solve this problem is to define a formula, and put the neighbor "willingness" and "reachability to 2-hop-neighbors" as two inputs -- such as Weight(willingness, reachability) = neighbor' willingness + neighbor's reachability. Then select the neighbour that has the highest "Weight" as MPR. Will this work? Please give me your ideas... Maybe there are some special reasons or special scenarios the proposed MPR selection mechanism should apply? If yes, would you please kindly tell me? Thanks and Best regards Ying Ying Ge Communications Research Centre Canada | Centre de recherches sur les communications Canada 3701 Carling Ave. | 3701, avenue Carling PO Box 11490, Station H | CP 11490, succursale H Ottawa ON K2H 8S2 | Ottawa (Ontario) K2H 8S2 (613) 998-2819 | ying.ge@crc.ca | Web site / Site web : www.crc.ca Government of Canada | Gouvernement du Canada _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 20:15:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17193 for ; Tue, 2 Mar 2004 20:15:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKy6-00052j-4Z for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 20:14:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i231EcaI019385 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 20:14:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKy6-00052a-0I for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 20:14:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17045 for ; Tue, 2 Mar 2004 20:14:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKy3-0004Wv-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 20:14:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKvw-0003yf-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 20:12:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyKtr-0003VA-03 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 20:10:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyKp0-00072u-Tg for manet-web-archive@ietf.org; Tue, 02 Mar 2004 20:05:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKoq-0006PK-7s; Tue, 02 Mar 2004 20:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyKog-0006OE-Kk for manet@optimus.ietf.org; Tue, 02 Mar 2004 20:04:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16054 for ; Tue, 2 Mar 2004 20:04:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyKoe-0002bZ-00 for manet@ietf.org; Tue, 02 Mar 2004 20:04:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyKng-0002T3-00 for manet@ietf.org; Tue, 02 Mar 2004 20:03:53 -0500 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 1AyKml-0002Ds-00 for manet@ietf.org; Tue, 02 Mar 2004 20:02:55 -0500 Received: From 192.168.0.100 ([129.94.173.78] == sitcrc.cse.unsw.EDU.AU) (for ) (for ) By note With Smtp ; Wed, 3 Mar 2004 12:02:42 +1100 From: Justin Lipman To: "ying ge" Date: Wed, 3 Mar 2004 12:02:41 +1100 Reply-To: justin@titr.uow.edu.au Organization: CRC-SIT Subject: Re: [manet] OLSR - questions on MPR calculation User-Agent: KMail/1.5.4 References: <5.1.0.14.2.20040302163149.02cca3c8@buzonpdi.uma.es> <007101c40084$404a22e0$4c225c8e@anik2> In-Reply-To: <007101c40084$404a22e0$4c225c8e@anik2> Cc: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403031202.41698.justin@titr.uow.edu.au> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ying, Just read your email and thought I might offer some thoughts. > If we select neighbors with higher willingness as MPR, regardless how > many two hop neighbors it is connected to, may we ended up choose a lot of > MPRs? If there is too many MPRs in the network, the control overhead of the > OLSR may be very high, which may degrade the routing protocol's performance > (more data packet may be dropped because of the busy media, the end-to-end > delay of the data packets may be very long...). I have a paper on a more generic form of mpr selection which is called Utility Based Flooding. The following is a link to the paper. http://www.cse.unsw.edu.au/~justinl/raid_icon03.pdf UBF has similar performance to MPR in terms of the number of relays selected, but more importantly, allows for those relays to be selected based upon their overall utility. > My idea to solve this problem is to define a formula, and put the > neighbor "willingness" and "reachability to 2-hop-neighbors" as two > inputs -- such as Weight(willingness, reachability) = neighbor' willingness > + neighbor's reachability. Then select the neighbour that has the highest > "Weight" as MPR. Will this work? Please give me your ideas... You can apply the above technique to the UBF algorithm by using a utility function which is a function of willingness and reachability. If you use the greedy MRP algorithm as used by OLSR, then your choice of relay nodes is limited as the 1st step of the algorithm always selects those 1 hop neighbours with distinct 2-hop neighbours first, irrespective of their utility (willingness). Thus the remaining number of possible relays that may be selected based upon willingness is rather limited. UBF circumvents this problem by removing this 1st step and prioritising the selection of relays based upon the highest utility. Thus the best relays nodes are selected first. Those 1-hop relays that "must be selected" because of distinct 2-hop neighbours and which have a low utility are selected at the end (to satisfy coverage). This introduces a little more overhead than MPR, however it allows for the best relays to be selected! I think you may also find that optimised flooding mechanisms such as MPR suffer in the presence of background traffic be it data or other broadcasts. By suffer, I mean the number of nodes in the ad hoc network that are reached by a flood is greatly reduced. You can see the reliability results of some optimised flooding mechanisms (MPR, LMST) and Blind flooding in the following paper: Thus as the network traffic increases, the number of nodes receiving route request information or link state updates decreases. http://www.cse.unsw.edu.au/~justinl/rmst.pdf Hope this helps, Justin -- Research Associate Smart Internet Technology Cooperative Research Centre http://www.titr.uow.edu.au/~justin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 2 20:51:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19568 for ; Tue, 2 Mar 2004 20:51:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLXY-00049u-Hg for manet-archive@odin.ietf.org; Tue, 02 Mar 2004 20:51:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i231pGKk015985 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 20:51:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLXY-00049k-DF for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 20:51:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19553 for ; Tue, 2 Mar 2004 20:51:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLXV-0002XP-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 20:51:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLWZ-0002NH-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 20:50:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLVu-0002Dn-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 20:49:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLVN-0003a5-Nt; Tue, 02 Mar 2004 20:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLVH-0003ZP-Fr for manet@optimus.ietf.org; Tue, 02 Mar 2004 20:48:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19413 for ; Tue, 2 Mar 2004 20:48:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLVF-0002Ae-00 for manet@ietf.org; Tue, 02 Mar 2004 20:48:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLUJ-00022y-00 for manet@ietf.org; Tue, 02 Mar 2004 20:47:56 -0500 Received: from nam.ietf59.or.kr ([218.37.196.23]) by ietf-mx with esmtp (Exim 4.12) id 1AyLTR-0001um-00 for manet@ietf.org; Tue, 02 Mar 2004 20:47:01 -0500 Received: from paul2 (paul2.etri.re.kr [218.37.227.240] (may be forged)) by nam.ietf59.or.kr (8.12.11/8.12.11) with SMTP id i231l0eL006596; Wed, 3 Mar 2004 10:47:00 +0900 (KST) (envelope-from paul@etri.re.kr) X-Authentication-Warning: nam.ietf59.or.kr: Host paul2.etri.re.kr [218.37.227.240] (may be forged) claimed to be paul2 Message-ID: <001801c400c1$adbbca30$f0e325da@etri.re.kr> From: "Jaehoon Paul Jeong" To: Cc: "MANET WG" References: <005301c40025$0235b280$6de325da@jafymobile> Date: Wed, 3 Mar 2004 10:48:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.24.0.6; VDF 6.24.0.35 Content-Transfer-Encoding: base64 Subject: [manet] Re: Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgSHl1bldvb2ssDQoNCkkgd291bGQgbGlrZSB0byBqb2luIGRyYWZ0aW5nIGEgcmVxdWlyZW1l bnRzIGRyYWZ0IGZvciBJbnRlcm5ldCBDb25uZWN0aXZpdHkuDQpNeSBvbmUgY29tbWVudCAgaXMg dGhhdCB3ZSBuZWVkIHRvIGRyYXcgb3V0IHRoZSByZXF1aXJlbWVudHMgZm9yIGJvdGggSVB2NCBh bmQgSVB2Niwgbm90IG9ubHkgSVB2Ni4NCldoYXQgYWJvdXQgbXkgc3VnZ2VzdGlvbj8NCg0KUGF1 bA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkh5dW5Xb29rIENoYSIg PGphZnlAZXRyaS5yZS5rcj4NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDAyLCAyMDA0IDQ6MDcgUE0N Cj4gDQo+IEhlbGxvLCBhbGwuDQo+IA0KPiBBZnRlciBteSBwcmVzZW50YXRpb24gaXMgZmluaXNo ZWQsIEkgZ290IHR3byBjb21tZW50cy4gQWx0aG91Z2ggUGFhbCdzDQo+IGNvbW1lbnRzIHdoaWNo IGFyZSBtb3JlIHRlY2huaWNhbCBzZWVtIHRvIGJlIHJlc29sdmVkKEkgZ3Vlc3MuIElmIHdyb25n LA0KPiBwbGVhc2UgY29ycmVjdCBtZSwgUGFhbCksIEkgdGhpbmsgdGhhdCBJIG11c3QgdGVsbCB3 aGF0IGlzIGRpZmZlcmVudA0KPiB3aXRoIGV4aXN0aW5nIHNvbHV0aW9ucyBmb3IgTUFORVQgSW50 ZXJuZXQgY29ubmVjdGl2aXR5IGluIG15IGRyYWZ0LiANCj4gDQo+IEFzIEkgbWVudGlvbmVkIGF0 IG15IHByZXNlbnRhdGlvbiwgbXkgZHJhZnQgY29uc2lzdHMgb2YgdHdvIGNvbXBvbmVudC4NCj4g Um91dGUgZGV0ZXJtaW5hdGlvbiBhbGdvcml0aG0gYW5kIEZvcndhcmRpbmcgYWxnb3JpdGhtLiBB cyB5b3Uga25vdywNCj4gdGhlc2UgYXJlIGNyaXRpY2FsIHBhcnRzIGluIHRoaXMgYXJlYShJbnQu IENvbm5lY3Rpdml0eSkgYW5kIGFsbA0KPiBleGlzdGluZyBzb2x1dGlvbnMgYWRkcmVzcyB3aXRo IHRoZWlyIG93biB3YXkuIA0KPiANCj4gRmlyc3RseSwgcm91dGUgb3B0aW1pemF0aW9uIGlzIG5v dCBtZW50aW9uZWQgYXQgZXhpc3RpbmcgZHJhZnRzDQo+IHJlZmVyZW5jZWQgYnkgbWluZSAoSWYg d3JvbmcsIHBsZWFzZSBjb3JyZWN0IG1lLikgDQo+IA0KPiBBcyBmb3IgcHJvcG9zZWQgZm9yd2Fy ZGluZyBhbGdvcml0aG0sIGZvcndhcmRpbmcgdXNpbmcgZGVmYXVsdCByb3V0ZSBjYW4NCj4gYmUg ZG9uZSBmb3IgcGFja2V0cyB3aXRob3V0IHJvdXRpbmcgaGVhZGVyLiBJLkUsIGFmdGVyIGxvb2sg dXAgb2YNCj4gcm91dGluZyB0YWJsZSB3aXRoIGRlc3RpbmF0aW9uIGFkZHJlc3MgZmFpbHMsIGZv cndhcmRpbmcgZGVjaXNpb24gaXMNCj4gYmFzZWQgb24gc291cmNlIGdsb2JhbCBhZGRyZXNzIG9m IHRoZSBwYWNrZXQuIFRoYXQgaXMsIGd3X2luZm8gbGlzdCBpcw0KPiBzZWFyY2hlZCB3aXRoIHNv dXJjZSBwcmVmaXguIElmIG1hdGNoZWQgZ3dfaW5mbyBpcyBmb3VuZCwgdGhlIHBhY2tldCBpcw0K PiBmb3J3YXJkZWQgdGhyb3VnaCBob3N0IHJvdXRlIGVudHJ5IGZvciB0aGUgZ3cgYWR2ZXJ0aXNp bmcgdGhlIHByZWZpeC4NCj4gVGh1cywgbXVsdGlwbGUgYWRkcmVzc2VzIGZyb20gbXVsdGlwbGUg Z2F0ZXdheXMgY2FuIGJlIGNvbmZpZ3VyZWQgaW4gYQ0KPiBub2RlIGFuZCBpbnRlcm1lZGlhdGUg bm9kZXMgY2FuIGZvcndhcmQgcGFja2V0cyB3aXRob3V0IHJvdXRpbmcgaGVhZGVyDQo+IG9ubHkg aWYgZ2F0ZXdheSBpbmZvIGxpc3QgaXMgbWFpbnRhaW5lZCBpbiB0aGUgbm9kZS4NCj4gDQo+IEkg cmVxdWVzdCB2YWx1YWJsZSBjb21tZW50cyBvbiBteSBkcmFmdCBmcm9tIGF1dGhvcnMgb2YgcHJl dmlvdXMgZHJhZnRzDQo+IGluY2x1ZGluZyBDLiBQZXJraW5zLCBXYWtpa2F3YSwgQy4gSmVsZ2Vy LCBQZWtrYS4gUGVyc29uYWxseSBJIGFsc28NCj4gYmVsaWV2ZSB0aGF0IHRoaXMgYXJlYSBpcyB2 ZXJ5IGltcG9ydGFudCBhbmQgaXQgaXMgdGltZSB0byBtYWtlDQo+IHByb2dyZXNzLiBIb3cgYWJv dXQgcmVxdWlyZW1lbnQgZG9jdW1lbnQgb3IgbWVyZ2VkIHNvbHV0aW9uIGRvY3VtZW50Pw0KPiBQ bGVhc2UgbGV0IG1lIGtub3cgd2hhdCBpcyBpbiB5b3VyIG1pbmQuIFdob2V2ZXIgaXMgaW50ZXJl c3RlZCBpbiB0aGlzDQo+IHRvcGljIG1heSBiZSB3ZWxjb21lZCBpbiB0aGlzIHRocmVhZC4NCj4g DQo+IEtpbmRseSBSZWdhcmRzLA0KPiANCj4gSHl1bldvb2sgQ2hhDQo+ICAgIA0KPiANCj4g _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 02:04:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12753 for ; Wed, 3 Mar 2004 02:04:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQQS-0007SN-5M for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 02:04:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2374GNt028654 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 02:04:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQQR-0007Rw-Dt for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 02:04:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12119 for ; Wed, 3 Mar 2004 02:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQQN-0004kV-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 02:04:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQPO-0004ZA-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 02:03:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyQOS-0004P5-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 02:02:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQOJ-0006HU-J9; Wed, 03 Mar 2004 02:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQNY-00064Z-QP for manet@optimus.ietf.org; Wed, 03 Mar 2004 02:01:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08664 for ; Wed, 3 Mar 2004 02:01:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQNV-0004FO-00 for manet@ietf.org; Wed, 03 Mar 2004 02:01:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQMY-00044f-00 for manet@ietf.org; Wed, 03 Mar 2004 02:00:15 -0500 Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx with esmtp (Exim 4.12) id 1AyQLa-0003n0-00 for manet@ietf.org; Wed, 03 Mar 2004 01:59:14 -0500 Received: from MobileGravity.wireless.ietf59.or.kr.sfc.wide.ad.jp ([210.93.162.110]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id i236rYUV022777; Wed, 3 Mar 2004 15:53:36 +0900 Date: Wed, 03 Mar 2004 15:58:37 +0900 Message-ID: From: Ryuji Wakikawa To: jafy@etri.re.kr Cc: manet@ietf.org, autonet@ipv6.or.kr Subject: Re: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt In-Reply-To: <005301c40025$0235b280$6de325da@jafymobile> References: <005301c40025$0235b280$6de325da@jafymobile> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I think the first step is MANET WG should make decision whether the WG includes internet connectivity stuff in manet charter or not. Otherwise, many similar drafts are submitted without any progress at IETF. BTW, the statement to our global6 is wrong in draft-cha-manet-aodv-internet. You said [1 global6] which do not use next hop forwarding and require that a sender specifies a gateway in routing header. In appendix D. of global6, we describe AODV operations and it said "When the node sends packets to the internet, it MAY use any of the two methods specified in section 7.1 and appendix C." Section7.1 is for next-hop forwarding. Appendix C is for the routing w/routing header ryuji At Tue, 2 Mar 2004 16:07:17 +0900, HyunWook Cha wrote: > > Hello, all. > > After my presentation is finished, I got two comments. Although Paal's > comments which are more technical seem to be resolved(I guess. If wrong, > please correct me, Paal), I think that I must tell what is different > with existing solutions for MANET Internet connectivity in my draft. > > As I mentioned at my presentation, my draft consists of two component. > Route determination algorithm and Forwarding algorithm. As you know, > these are critical parts in this area(Int. Connectivity) and all > existing solutions address with their own way. > > Firstly, route optimization is not mentioned at existing drafts > referenced by mine (If wrong, please correct me.) > > As for proposed forwarding algorithm, forwarding using default route can > be done for packets without routing header. I.E, after look up of > routing table with destination address fails, forwarding decision is > based on source global address of the packet. That is, gw_info list is > searched with source prefix. If matched gw_info is found, the packet is > forwarded through host route entry for the gw advertising the prefix. > Thus, multiple addresses from multiple gateways can be configured in a > node and intermediate nodes can forward packets without routing header > only if gateway info list is maintained in the node. > > I request valuable comments on my draft from authors of previous drafts > including C. Perkins, Wakikawa, C. Jelger, Pekka. Personally I also > believe that this area is very important and it is time to make > progress. How about requirement document or merged solution document? > Please let me know what is in your mind. Whoever is interested in this > topic may be welcomed in this thread. > > Kindly Regards, > > HyunWook Cha > > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Mar 3 03:25:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10552 for ; Wed, 3 Mar 2004 03:25:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRgA-0004GG-2n for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 03:24:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i238OXXI016374 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 03:24:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRg9-0004G1-PR for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 03:24:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10375 for ; Wed, 3 Mar 2004 03:23:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRfO-00047u-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 03:23:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRe5-0003lZ-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 03:22:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRcA-0003QU-01 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 03:20:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyRP2-0005s5-Kq for manet-web-archive@ietf.org; Wed, 03 Mar 2004 03:06:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyROH-0001NL-7B; Wed, 03 Mar 2004 03:06:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRN9-0001Fg-N6 for manet@optimus.ietf.org; Wed, 03 Mar 2004 03:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09225 for ; Wed, 3 Mar 2004 03:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRMl-0000o0-00 for manet@ietf.org; Wed, 03 Mar 2004 03:04:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRLw-0000cM-00 for manet@ietf.org; Wed, 03 Mar 2004 03:03:41 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1AyRLH-0000NC-00 for manet@ietf.org; Wed, 03 Mar 2004 03:03:00 -0500 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDWH8Q6; Wed, 3 Mar 2004 17:02:30 +0900 Reply-To: From: "HyunWook Cha" To: "'Ryuji Wakikawa'" Cc: , Subject: RE: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt Date: Wed, 3 Mar 2004 17:02:28 +0900 Message-ID: <000001c400f5$df5406f0$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, ryuji. First of all, I am glad to hear your opinion and comment. Definately I agree with you. However, I think that it is valuable job to make a requirement document which is agreed by the whole wg and can be utilized as evaluation metrics for existing solutions and one guideline for upcoming solution designs whether this topic will be accepted as a wg item in near future or not. I know that several MANETers interested in this topic agree with me. Do you think that it is still early to make a requirement document reflecting valuable thoughts related to this topic? Although I admit that I was inspired and motivated by your draft, I do not think that your draft does address all related issues and propose all possilbe solutions. If you are interested in my suggestion, we can have good chance to share ideas and make productive work in this topic. As for your comment on my draft, please take it easy. [The draft says] one including [1 globalv6], [2], [3] which use next hop forwarding for default routes and the other including [1 globalv6] which do not use next hop forwarding and require that a sender specifies a gateway in routing header. If you have any other comments, please let me know. Regards, HyunWook Cha > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > Sent: Wednesday, March 03, 2004 3:59 PM > To: jafy@etri.re.kr > Cc: manet@ietf.org; autonet@ipv6.or.kr > Subject: Re: [manet] Request of Comments on the i-d > ietf-cha-manet-aodv-internet-00.txt > > > > > I think the first step is MANET WG should make decision > whether the WG includes internet connectivity stuff in manet > charter or not. Otherwise, many similar drafts are submitted > without any progress at IETF. > > BTW, the statement to our global6 is wrong in > draft-cha-manet-aodv-internet. > > You said > [1 global6] which do not use next hop forwarding and require > that a sender specifies a gateway in routing header. > > In appendix D. of global6, we describe AODV operations and it > said "When the node sends packets to the internet, it MAY use > any of the two methods specified in section 7.1 and appendix C." > Section7.1 is for next-hop forwarding. > Appendix C is for the routing w/routing header > > ryuji > > > At Tue, 2 Mar 2004 16:07:17 +0900, > HyunWook Cha wrote: > > > > Hello, all. > > > > After my presentation is finished, I got two comments. > Although Paal's > > comments which are more technical seem to be resolved(I guess. If > > wrong, please correct me, Paal), I think that I must tell what is > > different with existing solutions for MANET Internet > connectivity in > > my draft. > > > > As I mentioned at my presentation, my draft consists of two > component. > > Route determination algorithm and Forwarding algorithm. As > you know, > > these are critical parts in this area(Int. Connectivity) and all > > existing solutions address with their own way. > > > > Firstly, route optimization is not mentioned at existing drafts > > referenced by mine (If wrong, please correct me.) > > > > As for proposed forwarding algorithm, forwarding using > default route > > can be done for packets without routing header. I.E, after > look up of > > routing table with destination address fails, forwarding > decision is > > based on source global address of the packet. That is, > gw_info list is > > searched with source prefix. If matched gw_info is found, > the packet > > is forwarded through host route entry for the gw advertising the > > prefix. Thus, multiple addresses from multiple gateways can be > > configured in a node and intermediate nodes can forward packets > > without routing header only if gateway info list is > maintained in the > > node. > > > > I request valuable comments on my draft from authors of previous > > drafts including C. Perkins, Wakikawa, C. Jelger, Pekka. > Personally I > > also believe that this area is very important and it is > time to make > > progress. How about requirement document or merged solution > document? > > Please let me know what is in your mind. Whoever is > interested in this > > topic may be welcomed in this thread. > > > > Kindly Regards, > > > > HyunWook Cha > > > > > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Wed Mar 3 04:53:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15188 for ; Wed, 3 Mar 2004 04:53:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyT3n-0006QS-7V for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 04:53:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i239r2ST024674 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 04:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyT3i-0006Pt-W6 for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 04:52:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15117 for ; Wed, 3 Mar 2004 04:52:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyT31-0003mZ-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 04:52:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyT29-0003dG-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 04:51:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyT1T-0003Uv-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 04:50:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyT0t-0005zT-LJ; Wed, 03 Mar 2004 04:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyT0S-0005yc-OI for manet@optimus.ietf.org; Wed, 03 Mar 2004 04:49:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15046 for ; Wed, 3 Mar 2004 04:49:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyT05-0003Kb-00 for manet@ietf.org; Wed, 03 Mar 2004 04:49:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySz7-0003Ba-00 for manet@ietf.org; Wed, 03 Mar 2004 04:48:14 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AySyH-00033M-00 for manet@ietf.org; Wed, 03 Mar 2004 04:47:21 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i239oBZr051091; Wed, 3 Mar 2004 10:50:11 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <4045B7F7.9020902@dpt-info.u-strasbg.fr> Date: Wed, 03 Mar 2004 11:48:23 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org CC: autonet@ipv6.or.kr Subject: Re: [manet] Default Routes (WAS: Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt) (Intern) References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Paal / all, Of course as one of the authors of a solution that uses default route I don't agree with your statements. ;-) In our draft each MANET node knows which gateway it uses, and (in the steady-state) it knows that all nodes on the "default route" path use the same gateway. With our solution gateways don't announce routes, they just announce prefixes. If two gateways announce the same prefix, an ad hoc node selects the closest gateway (it can be specified that it should from there use the same gateway). The propagation method used to propagate the prefix information ensures that the path to the gateway is made of nodes that also use the same gateway : there is no need of a routing header, and default routes can be used safely. Regards, Christophe Paal.Engelstad@telenor.com wrote: >Ryuji, > >I think your preferred tunneling method (using the routing header) is good. Using default routes, on the contrary, might lead to problems and should be removed as an option: > >If you have two gateways announcing the same default route, the MANET node has no control of which gateway the packet is routed out through. You might get problems with: >- Stateless firewalls: E.g. The first packet of your (TCP-) session might go out through another gateway than the one corresponding to the selected source IP address. Thus, the return inbound packets will not reach the gateway corresponding to the MANET node's source IP address if the gateway is behind i firewall because no state is set in the firewall. >- Ingress filtering: Outbound packets escaping out through "wrong" gateways are filtered out. > >In addition to this, every time a MANEWT node moves e.g. on an OLSR MANET, until the routing converges, internal packets destined for this node might probably be sent out on the Internet along a default route. > >In fact, my comment in the WG meetings against the use of default routes was mainly targeted at the possible use of NATs with a IPv4 MANET. Here you have the additional problem that some GWs will probably implement NATs as a gateway enabling technology. But after second thoughts, I think my comment also applies well to IPv6. > > >Paal > > > >>From: Ryuji Wakikawa [ryuji@sfc.wide.ad.jp] >>Sent: 2004-03-03 07:58:37 CET >>To: jafy@etri.re.kr >>Cc: manet@ietf.org, autonet@ipv6.or.kr >>Subject: Re: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt >> >> >>I think the first step is MANET WG should make decision whether the WG >>includes internet connectivity stuff in manet charter or >>not. Otherwise, many similar drafts are submitted without any progress >>at IETF. >> >>BTW, the statement to our global6 is wrong in >>draft-cha-manet-aodv-internet. >> >>You said >>[1 global6] which do not use next hop forwarding and require that a >>sender specifies a gateway in routing header. >> >>In appendix D. of global6, we describe AODV operations and it said >>"When the node sends packets to the internet, it MAY use any of the two >>methods specified in section 7.1 and appendix C." >> Section7.1 is for next-hop forwarding. >> Appendix C is for the routing w/routing header >> >>ryuji >> >> >>At Tue, 2 Mar 2004 16:07:17 +0900, >>HyunWook Cha wrote: >> >> >>>Hello, all. >>> >>>After my presentation is finished, I got two comments. Although Paal's >>>comments which are more technical seem to be resolved(I guess. If wrong, >>>please correct me, Paal), I think that I must tell what is different >>>with existing solutions for MANET Internet connectivity in my draft. >>> >>>As I mentioned at my presentation, my draft consists of two component. >>>Route determination algorithm and Forwarding algorithm. As you know, >>>these are critical parts in this area(Int. Connectivity) and all >>>existing solutions address with their own way. >>> >>>Firstly, route optimization is not mentioned at existing drafts >>>referenced by mine (If wrong, please correct me.) >>> >>>As for proposed forwarding algorithm, forwarding using default route can >>>be done for packets without routing header. I.E, after look up of >>>routing table with destination address fails, forwarding decision is >>>based on source global address of the packet. That is, gw_info list is >>>searched with source prefix. If matched gw_info is found, the packet is >>>forwarded through host route entry for the gw advertising the prefix. >>>Thus, multiple addresses from multiple gateways can be configured in a >>>node and intermediate nodes can forward packets without routing header >>>only if gateway info list is maintained in the node. >>> >>>I request valuable comments on my draft from authors of previous drafts >>>including C. Perkins, Wakikawa, C. Jelger, Pekka. Personally I also >>>believe that this area is very important and it is time to make >>>progress. How about requirement document or merged solution document? >>>Please let me know what is in your mind. Whoever is interested in this >>>topic may be welcomed in this thread. >>> >>>Kindly Regards, >>> >>>HyunWook Cha >>> >>> >>> >>> >>>_______________________________________________ >>>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 exim@www1.ietf.org Wed Mar 3 05:08:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15698 for ; Wed, 3 Mar 2004 05:08:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTIT-0007QD-4j for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 05:08:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23A8Cad028520 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 05:08:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTIR-0007Pn-Qi for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 05:08:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15655 for ; Wed, 3 Mar 2004 05:07:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTHf-00065V-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:07:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTGj-0005wJ-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:06:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyTGS-0005nX-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:06:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTGN-0006z2-0D; Wed, 03 Mar 2004 05:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTG0-0006xN-WD for manet@optimus.ietf.org; Wed, 03 Mar 2004 05:05:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15610 for ; Wed, 3 Mar 2004 05:05:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTFd-0005me-00 for manet@ietf.org; Wed, 03 Mar 2004 05:05:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTEk-0005ek-00 for manet@ietf.org; Wed, 03 Mar 2004 05:04:23 -0500 Received: from anyida.tts.lth.se ([130.235.18.10]) by ietf-mx with esmtp (Exim 4.12) id 1AyTDx-0005WN-00 for manet@ietf.org; Wed, 03 Mar 2004 05:03:33 -0500 Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id LAA23991; Wed, 3 Mar 2004 11:04:47 +0100 (MET) Message-ID: <4045ADCF.1030300@telecom.lth.se> Date: Wed, 03 Mar 2004 11:05:03 +0100 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jafy@etri.re.kr, manet , Paal.Engelstad@telenor.com References: <000001c400f5$df5406f0$ae70fe81@jafywinxp> In-Reply-To: <000001c400f5$df5406f0$ae70fe81@jafywinxp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Re: Default Routes (WAS: Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I must say that I agree with all the comments about trying to coordinate our efforts. (I am a co-author with Ryuji). It doesn't make any sense at all to have several drafts that say basically the same thing, with some minor modifications. This is really the case right now. But the fact that we have so similiar drafts tells us that we are close to consensus, so making a common requirement document shouldn't be too hard. Having several drafts is really bad, and makes things bad for the implementors. There are implementors out there trying to implement these features, and they are clearly confused by all the different drafts. Nico Bayer have an implementation that he presented last week at EW2004, that closely follows the globalv6 draft. This is great, and although the imp. seems to follow the draft closely, there are some major differences to the draft. This could be explained by the confusion created by the different drafts, but may also implementation choices. Either way, a consensus is needed. >Although I admit that I was inspired and motivated by your draft, I do >not think that your draft does address all related issues and propose >all possilbe solutions. If you are interested in my suggestion, we can >have good chance to share ideas and make productive work in this topic. > > Please point out what you think is wrong. > >As for your comment on my draft, please take it easy. > >[The draft says] >one including [1 globalv6], [2], [3] which use next hop forwarding for >default routes and the other including [1 globalv6] which do not use >next hop forwarding and require that a sender specifies a gateway in >routing header. > > > What do you mean here? This is from Paals mail: > If you have two gateways announcing the same default route, the > MANET node has no control of which gateway the packet is routed > out through. You might get problems with: > - Stateless firewalls: E.g. The first packet of your (TCP-) session > might go out through another gateway than the one corresponding to > the selected source IP address. Thus, the return inbound packets will > not reach the gateway corresponding to the MANET node's source IP address > if the gateway is behind i firewall because no state is set in the firewall. > - Ingress filtering: Outbound packets escaping out through "wrong" gateways > are filtered out. As pointed out earlier, this problem can solved by letting intermediate forwarding nodes search their gateway list for the source prefix. If the source prefix matches an entry in the gateway list, the packet is forwarded to the indicated gateway. I think this solves the problem stated above. However, there is an other problem here. If the node is moving inside the network, it will probably want to switch to different gateways as they become closer. The only way for this to work in the mentioned solution is to onfigure a new address, which is not really a good solution. If the different gateways belong to the same domain, it might not even be possible, and routing header might be to prefer in that case. I discuss this problem among other things in a paper to be presented at WWC04, the main focus of the paper is performance though. regards, Anders _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 05:51:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17856 for ; Wed, 3 Mar 2004 05:51:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTxr-0003L6-5v for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 05:50:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23AoxVw012816 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 05:50:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTxp-0003Kb-LH for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 05:50:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17758 for ; Wed, 3 Mar 2004 05:50:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTxD-0005uV-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:50:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTwD-0005jh-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:49:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyTvH-0005ar-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:48:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTv3-0002hE-Uo; Wed, 03 Mar 2004 05:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTuf-0002eW-FQ for manet@optimus.ietf.org; Wed, 03 Mar 2004 05:47:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17658 for ; Wed, 3 Mar 2004 05:47:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTuH-0005S0-00 for manet@ietf.org; Wed, 03 Mar 2004 05:47:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTtO-0005JB-00 for manet@ietf.org; Wed, 03 Mar 2004 05:46:22 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyTsX-0005AN-00 for manet@ietf.org; Wed, 03 Mar 2004 05:45:29 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i23AmKZr062889 for ; Wed, 3 Mar 2004 11:48:20 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <4045C597.4000204@dpt-info.u-strasbg.fr> Date: Wed, 03 Mar 2004 12:46:31 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Actually each node knows what gateway it uses because there is a special field in the packet used to disseminate the prefix information. This field contains the IPv6 global address of the gateway (and another field gives the prefix length). Moreover, we "almost" don't need a routing protocol (of course don't take this statement too strictly), in the sense that, when a node wants to send data to some node in the Internet, it only uses a default route with next hop being one of its neighbors. The ad hoc node does not even need to have a /128 route to the gateway. Of course on the reverse path this is not the same (i.e. the gateway must have a /128 route to the ad hoc node). Christophe Anders Nilsson wrote: > Hello again, > > Christophe Jelger wrote: > >> >> Of course as one of the authors of a solution that uses default route >> I don't agree with your statements. ;-) >> >> In our draft each MANET node knows which gateway it uses, and (in the >> steady-state) it knows that all nodes on the "default route" path use >> the same gateway. With our solution gateways don't announce routes, >> they just announce prefixes. If two gateways announce the same >> prefix, an ad hoc node selects the closest gateway (it can be >> specified that it should from there use the same gateway). The >> propagation method used to propagate the prefix information ensures >> that the path to the gateway is made of nodes that also use the same >> gateway : there is no need of a routing header, and default routes >> can be used safely. >> > That sounds like a good solution, but the node can't control what > gateway it is currently using. A scenario where this is neeed is when > the node is moving from gateway to gateway. The node is then unable to > know what gateway it is currently communicating through. A node need > to know this when it switches to a new gateway, and "registers" > itself. This reason why this needed is because packets from the > Internet needs to be routed to the correct gateway, which is difficult > when mobile nodes are unware of its gateway. If a Cellular IP type of > solution is used, the routing entries in the access network are > updated by the actual packets flowing through the gateways. But there > is problems here as well, because oscillations easily occurs that > causes a lot of updates, especially when the mobile nodes are mobile. > I have simulated this, and it is harder to maintain than you might > think. If you rely on proactive gateway discovery, the default routing > entries have to be maintained during link breaks and mobility, along > with sequence number maintainence. I have a paper about this, in a > slightly different context, but during mobility and several hops to > the gateway, more complex control is needed. > > regards, > > Anders > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 07:14:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21135 for ; Wed, 3 Mar 2004 07:14:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVGX-0003L7-CX for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 07:14:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23CEL9s012831 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 07:14:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVGX-0003Ks-68 for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 07:14:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21090 for ; Wed, 3 Mar 2004 07:13:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVFs-0003oi-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:13:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVEv-0003eK-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:12:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyVET-0003TP-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:12:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVEF-0002yV-DZ; Wed, 03 Mar 2004 07:11:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVE0-0002xv-GQ for manet@optimus.ietf.org; Wed, 03 Mar 2004 07:11:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20994 for ; Wed, 3 Mar 2004 07:11:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVDc-0003Qy-00 for manet@ietf.org; Wed, 03 Mar 2004 07:11:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVCi-0003Io-00 for manet@ietf.org; Wed, 03 Mar 2004 07:10:25 -0500 Received: from anyida.tts.lth.se ([130.235.18.10]) by ietf-mx with esmtp (Exim 4.12) id 1AyVBs-0003AY-00 for manet@ietf.org; Wed, 03 Mar 2004 07:09:32 -0500 Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id NAA24692; Wed, 3 Mar 2004 13:10:47 +0100 (MET) Message-ID: <4045CB59.3030901@telecom.lth.se> Date: Wed, 03 Mar 2004 13:11:05 +0100 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Jelger , manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> In-Reply-To: <4045C597.4000204@dpt-info.u-strasbg.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello again, That sounds good too. :-) I read your draft again, refreshing my memory, it seems I have forgotten some of it, sorry. Just a few more questions and comments. I think you are forwarding each advertisement upon receiving it from the gateway, as in flooding? But updating it with new information. Have you studied how the delay introduced by intetermediate nodes varies when the number of hops and neighbors increases? I have an other question related to reactive protocols in your draft. Are you saying that mobile nodes should create the routing path to the gateway, reactively? I do think your solution for proactive discovery is good ;-) , I do, but if this proactivness is already taking place, even when a reactive protocol is used, why not also create the default route? You say it breaks the reactive nature of the protocol, I agree, but so does having periodic updates. I like your proactive discovery approach, but I think a reactive solution should be more purely reactive. But, this might need some more work. regards, Anders Christophe Jelger wrote: > Actually each node knows what gateway it uses because there is a > special field in the packet used to disseminate the prefix > information. This field contains the IPv6 global address of the > gateway (and another field gives the prefix length). Moreover, we > "almost" don't need a routing protocol (of course don't take this > statement too strictly), in the sense that, when a node wants to send > data to some node in the Internet, it only uses a default route with > next hop being one of its neighbors. The ad hoc node does not even > need to have a /128 route to the gateway. Of course on the reverse > path this is not the same (i.e. the gateway must have a /128 route to > the ad hoc node). > > Christophe > > Anders Nilsson wrote: > >> Hello again, >> >> Christophe Jelger wrote: >> >>> >>> Of course as one of the authors of a solution that uses default >>> route I don't agree with your statements. ;-) >>> >>> In our draft each MANET node knows which gateway it uses, and (in >>> the steady-state) it knows that all nodes on the "default route" >>> path use the same gateway. With our solution gateways don't announce >>> routes, they just announce prefixes. If two gateways announce the >>> same prefix, an ad hoc node selects the closest gateway (it can be >>> specified that it should from there use the same gateway). The >>> propagation method used to propagate the prefix information ensures >>> that the path to the gateway is made of nodes that also use the same >>> gateway : there is no need of a routing header, and default routes >>> can be used safely. >>> >> That sounds like a good solution, but the node can't control what >> gateway it is currently using. A scenario where this is neeed is when >> the node is moving from gateway to gateway. The node is then unable >> to know what gateway it is currently communicating through. A node >> need to know this when it switches to a new gateway, and "registers" >> itself. This reason why this needed is because packets from the >> Internet needs to be routed to the correct gateway, which is >> difficult when mobile nodes are unware of its gateway. If a Cellular >> IP type of solution is used, the routing entries in the access >> network are updated by the actual packets flowing through the >> gateways. But there is problems here as well, because oscillations >> easily occurs that causes a lot of updates, especially when the >> mobile nodes are mobile. I have simulated this, and it is harder to >> maintain than you might think. If you rely on proactive gateway >> discovery, the default routing entries have to be maintained during >> link breaks and mobility, along with sequence number maintainence. I >> have a paper about this, in a slightly different context, but during >> mobility and several hops to the gateway, more complex control is >> needed. >> >> regards, >> >> Anders >> >> >> > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Mar 3 07:23:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21531 for ; Wed, 3 Mar 2004 07:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVOw-0004wN-P9 for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 07:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23CN20F018985 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 07:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVOw-0004w8-LJ for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 07:23:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21475 for ; Wed, 3 Mar 2004 07:22:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVON-0005FR-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:22:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVNQ-00056Y-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:21:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyVN5-0004yF-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:21:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVN2-0004Zi-CT; Wed, 03 Mar 2004 07:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVMj-0004YU-MQ for manet@optimus.ietf.org; Wed, 03 Mar 2004 07:20:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21366 for ; Wed, 3 Mar 2004 07:20:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVMP-0004wb-00 for manet@ietf.org; Wed, 03 Mar 2004 07:20:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVLT-0004nf-00 for manet@ietf.org; Wed, 03 Mar 2004 07:19:27 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyVKZ-0004eV-00 for manet@ietf.org; Wed, 03 Mar 2004 07:18:31 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i23CLGZr095723 for ; Wed, 3 Mar 2004 13:21:16 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <4045DB5F.6020807@dpt-info.u-strasbg.fr> Date: Wed, 03 Mar 2004 14:19:27 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <4045CB59.3030901@telecom.lth.se> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Anders, The difference with pure flooding is that an ad hoc does not forward the information if it does not use it. With this very simple rule prefix continuity is possible. We did not want to add a default route for reactive protocols because : 1. If there is a default route, how can the protocol be reactive ? (there is always a match in the routing table for any destination) 2. If there is no default route, the gateway can reply to REQ for destinations that are outside the Internet. Of course if we want to guarantee that all nodes on the path to the gateway share the same prefix, we cannot use the route obtained via the reactive protol. Each node must send the packet to the neighbor from which it got its prefix. I'm sure how this could be specified within the operation of a reactive protocol. Christophe Anders Nilsson wrote: > Hello again, > > That sounds good too. :-) > I read your draft again, refreshing my memory, it seems I have > forgotten some of it, sorry. > Just a few more questions and comments. > I think you are forwarding each advertisement upon receiving it from > the gateway, as in flooding? But updating it with new information. > Have you studied how the delay introduced by intetermediate nodes > varies when the number of hops and neighbors increases? > I have an other question related to reactive protocols in your draft. > Are you saying that mobile nodes should create the routing path to the > gateway, reactively? I do think your solution for proactive discovery > is good ;-) , I do, but if this proactivness is already taking place, > even when a reactive protocol is used, why not also create the default > route? You say it breaks the reactive nature of the protocol, I agree, > but so does having periodic updates. I like your proactive discovery > approach, but I think a reactive solution should be more purely > reactive. But, this might need some more work. > > regards, > > Anders > > Christophe Jelger wrote: > >> Actually each node knows what gateway it uses because there is a >> special field in the packet used to disseminate the prefix >> information. This field contains the IPv6 global address of the >> gateway (and another field gives the prefix length). Moreover, we >> "almost" don't need a routing protocol (of course don't take this >> statement too strictly), in the sense that, when a node wants to send >> data to some node in the Internet, it only uses a default route with >> next hop being one of its neighbors. The ad hoc node does not even >> need to have a /128 route to the gateway. Of course on the reverse >> path this is not the same (i.e. the gateway must have a /128 route to >> the ad hoc node). >> >> Christophe >> >> Anders Nilsson wrote: >> >>> Hello again, >>> >>> Christophe Jelger wrote: >>> >>>> >>>> Of course as one of the authors of a solution that uses default >>>> route I don't agree with your statements. ;-) >>>> >>>> In our draft each MANET node knows which gateway it uses, and (in >>>> the steady-state) it knows that all nodes on the "default route" >>>> path use the same gateway. With our solution gateways don't >>>> announce routes, they just announce prefixes. If two gateways >>>> announce the same prefix, an ad hoc node selects the closest >>>> gateway (it can be specified that it should from there use the same >>>> gateway). The propagation method used to propagate the prefix >>>> information ensures that the path to the gateway is made of nodes >>>> that also use the same gateway : there is no need of a routing >>>> header, and default routes can be used safely. >>>> >>> That sounds like a good solution, but the node can't control what >>> gateway it is currently using. A scenario where this is neeed is >>> when the node is moving from gateway to gateway. The node is then >>> unable to know what gateway it is currently communicating through. A >>> node need to know this when it switches to a new gateway, and >>> "registers" itself. This reason why this needed is because packets >>> from the Internet needs to be routed to the correct gateway, which >>> is difficult when mobile nodes are unware of its gateway. If a >>> Cellular IP type of solution is used, the routing entries in the >>> access network are updated by the actual packets flowing through the >>> gateways. But there is problems here as well, because oscillations >>> easily occurs that causes a lot of updates, especially when the >>> mobile nodes are mobile. I have simulated this, and it is harder to >>> maintain than you might think. If you rely on proactive gateway >>> discovery, the default routing entries have to be maintained during >>> link breaks and mobility, along with sequence number maintainence. I >>> have a paper about this, in a slightly different context, but during >>> mobility and several hops to the gateway, more complex control is >>> needed. >>> >>> regards, >>> >>> Anders >>> >>> >>> >> >> >> >> _______________________________________________ >> 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 exim@www1.ietf.org Wed Mar 3 07:34:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22210 for ; Wed, 3 Mar 2004 07:34:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVZ8-0006dE-3Z for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 07:33:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23CXYXJ025486 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 07:33:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVZ7-0006cz-V7 for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 07:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22068 for ; Wed, 3 Mar 2004 07:32:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVYT-00072L-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:32:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVXO-0006p6-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:31:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyVWk-0006dD-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVWf-0005er-KE; Wed, 03 Mar 2004 07:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVWX-0005dq-HB for manet@optimus.ietf.org; Wed, 03 Mar 2004 07:30:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21900 for ; Wed, 3 Mar 2004 07:30:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVWC-0006az-00 for manet@ietf.org; Wed, 03 Mar 2004 07:30:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVVN-0006S3-00 for manet@ietf.org; Wed, 03 Mar 2004 07:29:42 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AyVUa-0006I4-00 for manet@ietf.org; Wed, 03 Mar 2004 07:28:52 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i23CSleU013583; Wed, 3 Mar 2004 13:28:47 +0100 (MET) Subject: Re: [manet] Default Routes From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: Christophe Jelger Cc: manet In-Reply-To: <4045C597.4000204@dpt-info.u-strasbg.fr> References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> Content-Type: text/plain; charset=UTF-8 Message-Id: <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 03 Mar 2004 13:28:47 +0100 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by aun.it.uu.se id i23CSleU013583 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I don't see how you can efficiently handle multiple gateways when using default routes? Especially with reactive protocols that do not have a complete view of the network. Even if you maintain the gateway mapping, how will you deal with hand-overs between gateways? You say that the solution is to force nodes to use the "same" default route, but I do not think that is a good idea. Individual nodes may know best when to switch gateways, and they should be allowed to do so if they wish. How can you guarantee that a default route is not diverted to another gateway at an intermediate node if a packet carries no mapping between the (final) destination and the gateway? How do you handle control packets (from different gateways) that want to change the default route --> gateway mapping? My experience with AODV-UU is that gateway tunneling has many properties that are prefered in an ad hoc network. Tunnels easily support multiple gateways and are transparent for intermediate nodes that forwards the traffic to the gateway. I have a paper pending that clearly shows the advantages of tunnels in this context. Before proceeding with a merged draft on Internet connectivity, I think that the proposal should be backed up with serious research showing problems or benefits of different strategies. I have implemented gateway connectivity in AODV-UU, and my experience clearly points in the direction of tunnels. Regards, Erik Nordstr=C3=B6m On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: > Actually each node knows what gateway it uses because there is a specia= l=20 > field in the packet used to disseminate the prefix information. This=20 > field contains the IPv6 global address of the gateway (and another fiel= d=20 > gives the prefix length). Moreover, we "almost" don't need a routing=20 > protocol (of course don't take this statement too strictly), in the=20 > sense that, when a node wants to send data to some node in the Internet= ,=20 > it only uses a default route with next hop being one of its neighbors.=20 > The ad hoc node does not even need to have a /128 route to the gateway.= =20 > Of course on the reverse path this is not the same (i.e. the gateway=20 > must have a /128 route to the ad hoc node). >=20 > Christophe >=20 > Anders Nilsson wrote: >=20 > > Hello again, > > > > Christophe Jelger wrote: > > > >> > >> Of course as one of the authors of a solution that uses default rout= e=20 > >> I don't agree with your statements. ;-) > >> > >> In our draft each MANET node knows which gateway it uses, and (in th= e=20 > >> steady-state) it knows that all nodes on the "default route" path us= e=20 > >> the same gateway. With our solution gateways don't announce routes,=20 > >> they just announce prefixes. If two gateways announce the same=20 > >> prefix, an ad hoc node selects the closest gateway (it can be=20 > >> specified that it should from there use the same gateway). The=20 > >> propagation method used to propagate the prefix information ensures=20 > >> that the path to the gateway is made of nodes that also use the same= =20 > >> gateway : there is no need of a routing header, and default routes=20 > >> can be used safely. > >> > > That sounds like a good solution, but the node can't control what=20 > > gateway it is currently using. A scenario where this is neeed is when= =20 > > the node is moving from gateway to gateway. The node is then unable t= o=20 > > know what gateway it is currently communicating through. A node need=20 > > to know this when it switches to a new gateway, and "registers"=20 > > itself. This reason why this needed is because packets from the=20 > > Internet needs to be routed to the correct gateway, which is difficul= t=20 > > when mobile nodes are unware of its gateway. If a Cellular IP type of= =20 > > solution is used, the routing entries in the access network are=20 > > updated by the actual packets flowing through the gateways. But there= =20 > > is problems here as well, because oscillations easily occurs that=20 > > causes a lot of updates, especially when the mobile nodes are mobile.= =20 > > I have simulated this, and it is harder to maintain than you might=20 > > think. If you rely on proactive gateway discovery, the default routin= g=20 > > entries have to be maintained during link breaks and mobility, along=20 > > with sequence number maintainence. I have a paper about this, in a=20 > > slightly different context, but during mobility and several hops to=20 > > the gateway, more complex control is needed. > > > > regards, > > > > Anders > > > > > > >=20 >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Wed Mar 3 07:35:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22350 for ; Wed, 3 Mar 2004 07:35:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVaJ-0006rO-0o for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 07:34:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23CYkC2026364 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 07:34:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVaI-0006r9-ON for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 07:34:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22215 for ; Wed, 3 Mar 2004 07:34:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVZe-0007IT-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:34:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVYa-00073b-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:33:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyVXf-0006q8-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:32:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVXf-0005sM-2L; Wed, 03 Mar 2004 07:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVXW-0005oL-Ep for manet@optimus.ietf.org; Wed, 03 Mar 2004 07:31:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21977 for ; Wed, 3 Mar 2004 07:31:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVXB-0006mV-00 for manet@ietf.org; Wed, 03 Mar 2004 07:31:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVWJ-0006cP-00 for manet@ietf.org; Wed, 03 Mar 2004 07:30:40 -0500 Received: from web60609.mail.yahoo.com ([216.109.119.83]) by ietf-mx with smtp (Exim 4.12) id 1AyVVn-0006RR-00 for manet@ietf.org; Wed, 03 Mar 2004 07:30:07 -0500 Message-ID: <20040303122936.25300.qmail@web60609.mail.yahoo.com> Received: from [218.37.231.206] by web60609.mail.yahoo.com via HTTP; Wed, 03 Mar 2004 04:29:36 PST Date: Wed, 3 Mar 2004 04:29:36 -0800 (PST) From: Jaehoon Jeong Subject: Re: [manet] MANET Address Autoconf Issues To: maseweb@net.ie.niigata-u.ac.jp, manet@ietf.org In-Reply-To: <64547.80.15.129.138.1078163702.squirrel@www.net.ie.niigata-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA21985 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Kenichi Mase, --- maseweb@net.ie.niigata-u.ac.jp wrote: > Hi Jaehoon, >=20 > I am now on the trip and quickly send you my > comments. > I think that terminologies such as strong DAD and > weak DAD may not > appropriate. In my paper in WPMC2003, I use > proactive DAD and reactive DAD > in stead. > Proactive DAD is independent of MANET routing > protocol, while reactive DAD > is closely related to MANET routing protocol and > behaivior. The strong DAD > is included in the proactive DAD and weak DAD and > passive DAD is included > in the reactive DAD in my terminology. > Absolutely, I agree with you. However, let's decide it after listening to other opinions. As you know, this is related to our solution draft; http://www.ietf.org/internet-drafts/draft-jeong-adhoc-ip-addr-autoconf-02= .txt =20 > The following different approaches need to be > discussed. > Stateless IP address conf. + Proactive DAD > Stateless IP address conf. + Proactive DAD + > Reactive DAD > Stateful IP address conf. + Reactive DAD >=20 These approaches seem to be really good. However, I would like to suggest that first of all, we need to discuss MANET Address Autoconf requirements. http://www.ietf.org/internet-drafts/draft-jeong-manet-addr-autoconf-reqts= -01.txt Maneters, please, read the draft and let us know your thoughts or suggestions. Thanks. Jehoon Paul Jeong P.S. just call me Paul :) > Is there anybody, who agree or disagree of the > terminology above? > Best regars, > Kenichi >=20 > > Hi Maneters, > > > > I send my presentation material in order to > discuss > > "MANET IP Address Autoconfiguration Issues" today > > afternoon as follows; > > - PPT file: > > > > > http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-ja= ehoon.ppt > > - PDF file: > > > > > http://www.adhoc.6ants.net/~paul/ietf/manet/manet-addr-autoconf-issues-ja= ehoon.pdf > > > > If participants read this material, you can > prepare > > the discussion well. Also, those who cannot take > part > > in this Seoul meeting can comment on my drafts by > > email. > > > > Thanks. > > > > Regards, > > Jaehoon Paul Jeong > > > > __________________________________ > > Do you Yahoo!? > > Get better spam protection with Yahoo! Mail. > > http://antispam.yahoo.com/tools > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > >=20 __________________________________ Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster http://search.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 08:10:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24703 for ; Wed, 3 Mar 2004 08:10:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW8M-000292-KV for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 08:09:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23D9wkk008237 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 08:09:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW8M-00028l-FO for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 08:09:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24495 for ; Wed, 3 Mar 2004 08:09:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyW7m-00061Y-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 08:09:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyW66-0005WT-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 08:07:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyW4d-0005C3-01 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 08:06:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyVsA-0003jw-8d for manet-web-archive@ietf.org; Wed, 03 Mar 2004 07:53:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVry-0000gW-59; Wed, 03 Mar 2004 07:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVri-0000fk-Qb for manet@optimus.ietf.org; Wed, 03 Mar 2004 07:52:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23359 for ; Wed, 3 Mar 2004 07:52:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVrO-0002pg-00 for manet@ietf.org; Wed, 03 Mar 2004 07:52:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVqS-0002fo-00 for manet@ietf.org; Wed, 03 Mar 2004 07:51:29 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyVpf-0002VN-00 for manet@ietf.org; Wed, 03 Mar 2004 07:50:40 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i23CrTZr097611 for ; Wed, 3 Mar 2004 13:53:29 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <4045E2ED.2050704@dpt-info.u-strasbg.fr> Date: Wed, 03 Mar 2004 14:51:41 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id i23CrTZr097611 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Erik, Well about handovers everything is in the draft, but I have to admit=20 that it's not very clear sometimes. I hope to write a new version soon. To summarise : we propose different algorithms used by each ad hoc node=20 to choose (and switch between) a gateway. It can either use the closest=20 gateway (whatever prefix it uses), or a gateway that uses the same=20 prefix than it currently uses (whatever the distance from the gateway).=20 We also proposed slight variants. So first answer to your email is that=20 switching between gateways is controled by each ad hoc node independently. Moreover, and because of our particular (but very simple) way of prefix=20 propagation, we can guarantee that a default route is never diverted (in=20 the steady-state). By steady-state, I mean that of course topological=20 changes can cause trouble during a very small amount of time. The main=20 idea behind our draft is prefix continuity : we "build" contiguous=20 islands of nodes that share the same prefix/gateway. This can be of high=20 interest for providers (e.g. management, services, ...). We have implemented our solution (IPv6) as an independent daemon and it=20 works really well in the presence of multiple gateways and prefixes. We=20 will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI in=20 France). I am also finishing some simulations in which we evaluate our=20 solution : I hope I can submit the results for publication very soon. Well and before everybody says what's best and what's bad, I personally=20 think it's very difficult at this stage to say so. If you have done some=20 simulations of the tunnel approach you have probably seen that results=20 can greatly vary across different simulation scenarios. I think all=20 solutions have pros and cons, and we should be able to find the best=20 parts of all solutions. Regards, Christophe Erik Nordstr=C3=B6m wrote: >Hi, > >I don't see how you can efficiently handle multiple gateways when using >default routes? Especially with reactive protocols that do not have a >complete view of the network. Even if you maintain the gateway mapping, >how will you deal with hand-overs between gateways? You say that the >solution is to force nodes to use the "same" default route, but I do not >think that is a good idea. Individual nodes may know best when to switch >gateways, and they should be allowed to do so if they wish. How can you >guarantee that a default route is not diverted to another gateway at an >intermediate node if a packet carries no mapping between the (final) >destination and the gateway? How do you handle control packets (from >different gateways) that want to change the default route --> gateway >mapping? > >My experience with AODV-UU is that gateway tunneling has many properties >that are prefered in an ad hoc network. Tunnels easily support multiple >gateways and are transparent for intermediate nodes that forwards the >traffic to the gateway. I have a paper pending that clearly shows the >advantages of tunnels in this context. > >Before proceeding with a merged draft on Internet connectivity, I think >that the proposal should be backed up with serious research showing >problems or benefits of different strategies. I have implemented gateway >connectivity in AODV-UU, and my experience clearly points in the >direction of tunnels. > >Regards, > >Erik Nordstr=C3=B6m > > > >On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: > =20 > >>Actually each node knows what gateway it uses because there is a specia= l=20 >>field in the packet used to disseminate the prefix information. This=20 >>field contains the IPv6 global address of the gateway (and another fiel= d=20 >>gives the prefix length). Moreover, we "almost" don't need a routing=20 >>protocol (of course don't take this statement too strictly), in the=20 >>sense that, when a node wants to send data to some node in the Internet= ,=20 >>it only uses a default route with next hop being one of its neighbors.=20 >>The ad hoc node does not even need to have a /128 route to the gateway.= =20 >>Of course on the reverse path this is not the same (i.e. the gateway=20 >>must have a /128 route to the ad hoc node). >> >>Christophe >> >>Anders Nilsson wrote: >> >> =20 >> >>>Hello again, >>> >>>Christophe Jelger wrote: >>> >>> =20 >>> >>>>Of course as one of the authors of a solution that uses default route= =20 >>>>I don't agree with your statements. ;-) >>>> >>>>In our draft each MANET node knows which gateway it uses, and (in the= =20 >>>>steady-state) it knows that all nodes on the "default route" path use= =20 >>>>the same gateway. With our solution gateways don't announce routes,=20 >>>>they just announce prefixes. If two gateways announce the same=20 >>>>prefix, an ad hoc node selects the closest gateway (it can be=20 >>>>specified that it should from there use the same gateway). The=20 >>>>propagation method used to propagate the prefix information ensures=20 >>>>that the path to the gateway is made of nodes that also use the same=20 >>>>gateway : there is no need of a routing header, and default routes=20 >>>>can be used safely. >>>> >>>> =20 >>>> >>>That sounds like a good solution, but the node can't control what=20 >>>gateway it is currently using. A scenario where this is neeed is when=20 >>>the node is moving from gateway to gateway. The node is then unable to= =20 >>>know what gateway it is currently communicating through. A node need=20 >>>to know this when it switches to a new gateway, and "registers"=20 >>>itself. This reason why this needed is because packets from the=20 >>>Internet needs to be routed to the correct gateway, which is difficult= =20 >>>when mobile nodes are unware of its gateway. If a Cellular IP type of=20 >>>solution is used, the routing entries in the access network are=20 >>>updated by the actual packets flowing through the gateways. But there=20 >>>is problems here as well, because oscillations easily occurs that=20 >>>causes a lot of updates, especially when the mobile nodes are mobile.=20 >>>I have simulated this, and it is harder to maintain than you might=20 >>>think. If you rely on proactive gateway discovery, the default routing= =20 >>>entries have to be maintained during link breaks and mobility, along=20 >>>with sequence number maintainence. I have a paper about this, in a=20 >>>slightly different context, but during mobility and several hops to=20 >>>the gateway, more complex control is needed. >>> >>>regards, >>> >>>Anders >>> >>> >>> >>> =20 >>> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> =20 >> > > =20 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 08:24:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25647 for ; Wed, 3 Mar 2004 08:24:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWMF-0003Sp-0s for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 08:24:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23DOIwh013309 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 08:24:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWME-0003Sa-Ta for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 08:24:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25574 for ; Wed, 3 Mar 2004 08:23:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWLe-00011b-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 08:23:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWKj-0000qb-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 08:22:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyWK9-0000gF-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 08:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWK2-00036h-9G; Wed, 03 Mar 2004 08:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWJ6-00032F-9d for manet@optimus.ietf.org; Wed, 03 Mar 2004 08:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25405 for ; Wed, 3 Mar 2004 08:20:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWIb-0000QY-00 for manet@ietf.org; Wed, 03 Mar 2004 08:20:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWHh-0000Du-00 for manet@ietf.org; Wed, 03 Mar 2004 08:19:38 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1AyWGv-0007i3-00 for manet@ietf.org; Wed, 03 Mar 2004 08:18:49 -0500 Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i23DIGUM030617 for ; Wed, 3 Mar 2004 14:18:17 +0100 Message-ID: <016a01c40122$44eb3e80$1f175d80@inria.fr> From: "Philippe Jacquet" To: "manet" References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> Subject: Re: [manet] Default Routes Date: Wed, 3 Mar 2004 14:20:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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 X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Christophe, I like your draft. Just some details worry me. I see that gateways send refresh message every two seconds. Since these messages are somewhat retransmitted by all nodes sharing the same prefix, is it not too much traffic in dense networks? Another question(maybe I misunderstood the basic concept): your protocol helps the node to select their gateway, but if the route to the gateway is given by the routing protocol which is independent of your protocol, how do you guarantee that the data path provided by the routing protocol won't cross different prefix islands and then end to a different gateway? Regards, Philippe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 08:41:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26389 for ; Wed, 3 Mar 2004 08:40:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWbr-0005Nh-VZ for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 08:40:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23DeRpb020679 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 08:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWbr-0005NS-QM for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 08:40:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26308 for ; Wed, 3 Mar 2004 08:39:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWbH-0003oi-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 08:39:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWaL-0003cN-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 08:38:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyWZc-0003Qc-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 08:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWZW-0004uO-OY; Wed, 03 Mar 2004 08:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyWYc-0004hi-60 for manet@optimus.ietf.org; Wed, 03 Mar 2004 08:37:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26165 for ; Wed, 3 Mar 2004 08:36:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyWYG-0003Dn-00 for manet@ietf.org; Wed, 03 Mar 2004 08:36:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyWXN-00033I-00 for manet@ietf.org; Wed, 03 Mar 2004 08:35:50 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyWWt-0002sK-00 for manet@ietf.org; Wed, 03 Mar 2004 08:35:19 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i23Dc8Zr099947 for ; Wed, 3 Mar 2004 14:38:08 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <4045ED64.5050401@dpt-info.u-strasbg.fr> Date: Wed, 03 Mar 2004 15:36:20 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <016a01c40122$44eb3e80$1f175d80@inria.fr> Content-Type: text/plain; charset=UTF-8; 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Philippe, Of course the propagation method implies one retransmission per node every two seconds. While this is not so much overhead (that's a personal opinion), we explain in our draft that our proposal can benefit from a better approach such as flooding with MPR (as in OLSR). Now the propagation method itself leads to prefix continuity, i.e. it guarantees that there exists a path, between a node and its gateway, such that this path is made by nodes that use the same gateway. This is a sort of "recursive" concept ... for each ad hoc node, if it receives the information about gateway G and prefix P from one of its neighbor N1, it means that : - the neighbor N1 uses P and G - this neighbor N1 got the information from one of its neighbors (say N2) that uses G and P as well - the default route of N1 points to N2 - recursively the same conclusions apply to N2 a nd all the upstream neighbors towards G Christophe Philippe Jacquet wrote: >Hello, Christophe, > >I like your draft. Just some details worry me. I see that gateways send >refresh message every two seconds. Since these messages are somewhat >retransmitted by all nodes sharing the same prefix, is it not too much >traffic in dense networks? Another question(maybe I misunderstood the basic >concept): your protocol helps the node to select their gateway, but if the >route to the gateway is given by the routing protocol which is independent >of your protocol, how do you guarantee that the data path provided by the >routing protocol won't cross different prefix islands and then end to a >different gateway? > >Regards, >Philippe > > > >_______________________________________________ >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 exim@www1.ietf.org Wed Mar 3 09:12:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28426 for ; Wed, 3 Mar 2004 09:12:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyX5x-0002HM-5V for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 09:11:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23EBX7l008754 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 09:11:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyX5x-0002H6-0c for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 09:11:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28353 for ; Wed, 3 Mar 2004 09:11:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyX5v-0002Ku-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:11:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyX4W-0001wM-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:10:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyX3f-0001iG-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:09:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyX3W-0001e0-5O; Wed, 03 Mar 2004 09:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyX3K-0001cQ-G1 for manet@optimus.ietf.org; Wed, 03 Mar 2004 09:08:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28061 for ; Wed, 3 Mar 2004 09:08:48 -0500 (EST) From: Paal.Engelstad@telenor.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyX3I-0001fQ-00 for manet@ietf.org; Wed, 03 Mar 2004 09:08:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyX2G-0001SG-00 for manet@ietf.org; Wed, 03 Mar 2004 09:07:45 -0500 Received: from virus-out.ttyl.com ([193.212.240.200] helo=scan.telenor.net) by ietf-mx with esmtp (Exim 4.12) id 1AyX1O-00014G-00 for manet@ietf.org; Wed, 03 Mar 2004 09:06:50 -0500 Received: from tns-fbu-22-208.corp.telenor.no ([134.47.162.90] [134.47.162.90]) by scan.telenor.net with ESMTP; Wed, 3 Mar 2004 15:06:16 +0100 Received: from moffice2.nsc.no ([10.122.115.82]) by tns-fbu-22-208.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 15:06:12 +0100 Message-Id: <9682082.1078322772838.JavaMail.adm-moff@moffice2.nsc.no> To: Christophe Jelger To: manet Subject: SV: Re: [manet] Default Routes (Intern) In-Reply-To: <4045ED64.5050401@dpt-info.u-strasbg.fr> X-Priority: 3 (Normal) X-Mailer: Mobile Office v1.0 (Telenor Business Solutions) References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <016a01c40122$44eb3e80$1f175d80@inria.fr> <4045ED64.5050401@dpt-info.u-strasbg.fr> X-OriginalArrivalTime: 03 Mar 2004 14:06:12.0970 (UTC) FILETIME=[AF9AE4A0:01C40128] Date: 3 Mar 2004 15:06:12 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_943_30091157.1078322772826" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ------=_Part_943_30091157.1078322772826 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Christophe, It seems I triggered some discussion that passed me by, but let me cut into this thread and response to your preference for default routes. This is from Anders' mail: > This is from Paals mail: > > > If you have two gateways announcing the same default route, the > > MANET node has no control of which gateway the packet is routed > > out through. You might get problems with: > > - Stateless firewalls: E.g. The first packet of your (TCP-) session > > might go out through another gateway than the one corresponding to > > the selected source IP address. Thus, the return inbound packets will > > not reach the gateway corresponding to the MANET node's source IP address > > if the gateway is behind i firewall because no state is set in the firewall. > > - Ingress filtering: Outbound packets escaping out through "wrong" gateways > > are filtered out. > > As pointed out earlier, this problem can solved by letting intermediate > forwarding nodes search their gateway list for the source prefix. If the > source prefix matches an entry in the gateway list, the packet is > forwarded to the indicated gateway. I think this solves the problem > stated above. Here I think Anders gets to the core of the matter - i.e destination based routing: Many nodes communicating with the same external host cannot share the same destination-based route and still get to different gateways. 1) Either you need a tunneling solution or some sort, 2) or you need source address based default routing The first is lean and mean, and works in nearly any networking scenario, and with any routing protocol. The functionality of the second is obscure, it is less clean than the tunneling solution, and probably makes routing more complicated. In addition, you bind internet access together with address autoconfiguration, which reduces the level of modularity. Since the latter solution resembles a hack (as compared to the clean tunneling solution), I also think it might lead to unforseen problems sooner or later. For example, if I would use it in an IPv4 setting, it would obviously not work. (Default routes is not a good idea, at least not with IPv4, and should never have been accepted in the experimental RFCs, IMO). Yes, and by the way, here is another problem, which I didn't think of: > However, there is an other problem here. If the node is > moving inside the network, it will probably want to switch to different > gateways as they become closer. The only way for this to work in the > mentioned solution is to onfigure a new address, which is not really a > good solution. If the different gateways belong to the same domain, it > might not even be possible I think I am willing to pay the little extra overhead of tunneling to get a simpler, modular, and more robust solution. Paal > From: Christophe Jelger [jelger@dpt-info.u-strasbg.fr] > Sent: 2004-03-03 15:36:20 CET > To: manet [manet@ietf.org] > Subject: Re: [manet] Default Routes > > Hello Philippe, > > Of course the propagation method implies one retransmission per node > every two seconds. While this is not so much overhead (that's a personal > opinion), we explain in our draft that our proposal can benefit from a > better approach such as flooding with MPR (as in OLSR). > > Now the propagation method itself leads to prefix continuity, i.e. it > guarantees that there exists a path, between a node and its gateway, > such that this path is made by nodes that use the same gateway. This is > a sort of "recursive" concept ... for each ad hoc node, if it receives > the information about gateway G and prefix P from one of its neighbor > N1, it means that : > > - the neighbor N1 uses P and G > - this neighbor N1 got the information from one of its neighbors (say > N2) that uses G and P as well > - the default route of N1 points to N2 > - recursively the same conclusions apply to N2 a nd all the upstream > neighbors towards G > > Christophe > > Philippe Jacquet wrote: > > >Hello, Christophe, > > > >I like your draft. Just some details worry me. I see that gateways send > >refresh message every two seconds. Since these messages are somewhat > >retransmitted by all nodes sharing the same prefix, is it not too much > >traffic in dense networks? Another question(maybe I misunderstood the basic > >concept): your protocol helps the node to select their gateway, but if the > >route to the gateway is given by the routing protocol which is independent > >of your protocol, how do you guarantee that the data path provided by the > >routing protocol won't cross different prefix islands and then end to a > >different gateway? > > > >Regards, > >Philippe > > > > > > > >_______________________________________________ > >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 ------=_Part_943_30091157.1078322772826-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 09:18:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29094 for ; Wed, 3 Mar 2004 09:18:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXC7-00034N-64 for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 09:17:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23EHtOP011798 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 09:17:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXC7-00034D-1e for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 09:17:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29076 for ; Wed, 3 Mar 2004 09:17:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXC5-0003hQ-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:17:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXB9-0003W8-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:16:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyXAS-0003Kc-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:16:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXAJ-0002eu-Gh; Wed, 03 Mar 2004 09:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyX9m-0002ZE-E3 for manet@optimus.ietf.org; Wed, 03 Mar 2004 09:15:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28916 for ; Wed, 3 Mar 2004 09:15:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyX9k-0003GZ-00 for manet@ietf.org; Wed, 03 Mar 2004 09:15:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyX8p-00035Y-00 for manet@ietf.org; Wed, 03 Mar 2004 09:14:32 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AyX7r-0002mR-00 for manet@ietf.org; Wed, 03 Mar 2004 09:13:31 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i23EDSxV005842; Wed, 3 Mar 2004 15:13:28 +0100 (MET) Subject: Re: [manet] Default Routes From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: Christophe Jelger Cc: manet In-Reply-To: <4045E2ED.2050704@dpt-info.u-strasbg.fr> References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> Content-Type: text/plain; charset=UTF-8 Message-Id: <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 03 Mar 2004 15:13:28 +0100 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by aun.it.uu.se id i23EDSxV005842 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jelger, I admit that I am not that familiar with your proposal, and probably should read it more carefully. However, there are some things I question...=20 For example, why implement a seperate flooding mechanism when this is already provided by the routing protocol (for example OLSR)? You propose to optionally integrate this with the routing protocol, but I do not see how that is possible with MPR-based flooding? I am not convinced that you have maximum flexibility when building your prefix islands of nodes. How can nodes part of a prefix island individually choose another gateway? But, I admit, I need to study your draft in more detail. With tunnels you can simply add a flag in ordinary control messages announcing some nodes as gateways. Nodes can then individually choose a gateway and tunnel packets to it. The routing protocol takes care of the rest transparently. This also works well with reactive protocols. /Erik On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: > Hi Erik, >=20 > Well about handovers everything is in the draft, but I have to admit=20 > that it's not very clear sometimes. I hope to write a new version soon. >=20 > To summarise : we propose different algorithms used by each ad hoc node= =20 > to choose (and switch between) a gateway. It can either use the closest= =20 > gateway (whatever prefix it uses), or a gateway that uses the same=20 > prefix than it currently uses (whatever the distance from the gateway).= =20 > We also proposed slight variants. So first answer to your email is that= =20 > switching between gateways is controled by each ad hoc node independent= ly. >=20 > Moreover, and because of our particular (but very simple) way of prefix= =20 > propagation, we can guarantee that a default route is never diverted (i= n=20 > the steady-state). By steady-state, I mean that of course topological=20 > changes can cause trouble during a very small amount of time. The main=20 > idea behind our draft is prefix continuity : we "build" contiguous=20 > islands of nodes that share the same prefix/gateway. This can be of hig= h=20 > interest for providers (e.g. management, services, ...). >=20 > We have implemented our solution (IPv6) as an independent daemon and it= =20 > works really well in the presence of multiple gateways and prefixes. We= =20 > will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI i= n=20 > France). I am also finishing some simulations in which we evaluate our=20 > solution : I hope I can submit the results for publication very soon. >=20 > Well and before everybody says what's best and what's bad, I personally= =20 > think it's very difficult at this stage to say so. If you have done som= e=20 > simulations of the tunnel approach you have probably seen that results=20 > can greatly vary across different simulation scenarios. I think all=20 > solutions have pros and cons, and we should be able to find the best=20 > parts of all solutions. >=20 > Regards, > Christophe >=20 > Erik Nordstr=C3=B6m wrote: >=20 > >Hi, > > > >I don't see how you can efficiently handle multiple gateways when usin= g > >default routes? Especially with reactive protocols that do not have a > >complete view of the network. Even if you maintain the gateway mapping= , > >how will you deal with hand-overs between gateways? You say that the > >solution is to force nodes to use the "same" default route, but I do n= ot > >think that is a good idea. Individual nodes may know best when to swit= ch > >gateways, and they should be allowed to do so if they wish. How can yo= u > >guarantee that a default route is not diverted to another gateway at a= n > >intermediate node if a packet carries no mapping between the (final) > >destination and the gateway? How do you handle control packets (from > >different gateways) that want to change the default route --> gateway > >mapping? > > > >My experience with AODV-UU is that gateway tunneling has many properti= es > >that are prefered in an ad hoc network. Tunnels easily support multipl= e > >gateways and are transparent for intermediate nodes that forwards the > >traffic to the gateway. I have a paper pending that clearly shows the > >advantages of tunnels in this context. > > > >Before proceeding with a merged draft on Internet connectivity, I thin= k > >that the proposal should be backed up with serious research showing > >problems or benefits of different strategies. I have implemented gatew= ay > >connectivity in AODV-UU, and my experience clearly points in the > >direction of tunnels. > > > >Regards, > > > >Erik Nordstr=C3=B6m > > > > > > > >On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: > > =20 > > > >>Actually each node knows what gateway it uses because there is a spec= ial=20 > >>field in the packet used to disseminate the prefix information. This=20 > >>field contains the IPv6 global address of the gateway (and another fi= eld=20 > >>gives the prefix length). Moreover, we "almost" don't need a routing=20 > >>protocol (of course don't take this statement too strictly), in the=20 > >>sense that, when a node wants to send data to some node in the Intern= et,=20 > >>it only uses a default route with next hop being one of its neighbors= .=20 > >>The ad hoc node does not even need to have a /128 route to the gatewa= y.=20 > >>Of course on the reverse path this is not the same (i.e. the gateway=20 > >>must have a /128 route to the ad hoc node). > >> > >>Christophe > >> > >>Anders Nilsson wrote: > >> > >> =20 > >> > >>>Hello again, > >>> > >>>Christophe Jelger wrote: > >>> > >>> =20 > >>> > >>>>Of course as one of the authors of a solution that uses default rou= te=20 > >>>>I don't agree with your statements. ;-) > >>>> > >>>>In our draft each MANET node knows which gateway it uses, and (in t= he=20 > >>>>steady-state) it knows that all nodes on the "default route" path u= se=20 > >>>>the same gateway. With our solution gateways don't announce routes,= =20 > >>>>they just announce prefixes. If two gateways announce the same=20 > >>>>prefix, an ad hoc node selects the closest gateway (it can be=20 > >>>>specified that it should from there use the same gateway). The=20 > >>>>propagation method used to propagate the prefix information ensures= =20 > >>>>that the path to the gateway is made of nodes that also use the sam= e=20 > >>>>gateway : there is no need of a routing header, and default routes=20 > >>>>can be used safely. > >>>> > >>>> =20 > >>>> > >>>That sounds like a good solution, but the node can't control what=20 > >>>gateway it is currently using. A scenario where this is neeed is whe= n=20 > >>>the node is moving from gateway to gateway. The node is then unable = to=20 > >>>know what gateway it is currently communicating through. A node need= =20 > >>>to know this when it switches to a new gateway, and "registers"=20 > >>>itself. This reason why this needed is because packets from the=20 > >>>Internet needs to be routed to the correct gateway, which is difficu= lt=20 > >>>when mobile nodes are unware of its gateway. If a Cellular IP type o= f=20 > >>>solution is used, the routing entries in the access network are=20 > >>>updated by the actual packets flowing through the gateways. But ther= e=20 > >>>is problems here as well, because oscillations easily occurs that=20 > >>>causes a lot of updates, especially when the mobile nodes are mobile= .=20 > >>>I have simulated this, and it is harder to maintain than you might=20 > >>>think. If you rely on proactive gateway discovery, the default routi= ng=20 > >>>entries have to be maintained during link breaks and mobility, along= =20 > >>>with sequence number maintainence. I have a paper about this, in a=20 > >>>slightly different context, but during mobility and several hops to=20 > >>>the gateway, more complex control is needed. > >>> > >>>regards, > >>> > >>>Anders > >>> > >>> > >>> > >>> =20 > >>> > >> > >>_______________________________________________ > >>manet mailing list > >>manet@ietf.org > >>https://www1.ietf.org/mailman/listinfo/manet > >> =20 > >> > > > > =20 > > >=20 >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Wed Mar 3 09:23:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29477 for ; Wed, 3 Mar 2004 09:23:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXH3-0003fT-Ar for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 09:23:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23EN1ST014093 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 09:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXH3-0003f8-1p for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 09:23:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29465 for ; Wed, 3 Mar 2004 09:22:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXH0-0004i7-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:22:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXG3-0004Wb-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:22:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyXFM-0004Ke-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:21:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXFB-0003Ed-Qu; Wed, 03 Mar 2004 09:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXF6-0003DT-6e for manet@optimus.ietf.org; Wed, 03 Mar 2004 09:21:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29295 for ; Wed, 3 Mar 2004 09:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXF4-0004Je-00 for manet@ietf.org; Wed, 03 Mar 2004 09:20:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXEI-00047U-00 for manet@ietf.org; Wed, 03 Mar 2004 09:20:11 -0500 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 1AyXDG-0003qp-00 for manet@ietf.org; Wed, 03 Mar 2004 09:19:07 -0500 Received: from SRCATL-MTA by mail.scires.com with Novell_GroupWise; Wed, 03 Mar 2004 09:16:19 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Wed, 03 Mar 2004 09:15:50 -0500 From: "Pete Sholander" To: Cc: Subject: Re: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If the charter doesn't include "internet connectivity" then it should be, = IMHO :) =20 Standardizing that feature would be most useful to my customer set. = Futhermore having a simple method that scaled to 50-100 node sized MANETs = (with a reasonably-planned set of address blocks) might suffice for now. = A general solution might be a ANS problem. --Pete Sholander Atlanta, GA >>> Ryuji Wakikawa 03/03/04 01:58AM >>> I think the first step is MANET WG should make decision whether the WG includes internet connectivity stuff in manet charter or not. Otherwise, many similar drafts are submitted without any progress at IETF.=20 ryuji At Tue, 2 Mar 2004 16:07:17 +0900, HyunWook Cha wrote: >=20 > Hello, all. >=20 > After my presentation is finished, I got two comments. Although Paal's > comments which are more technical seem to be resolved(I guess. If wrong, > please correct me, Paal), I think that I must tell what is different > with existing solutions for MANET Internet connectivity in my draft.=20 >=20 > As I mentioned at my presentation, my draft consists of two component. > Route determination algorithm and Forwarding algorithm. As you know, > these are critical parts in this area(Int. Connectivity) and all > existing solutions address with their own way.=20 >=20 > Firstly, route optimization is not mentioned at existing drafts > referenced by mine (If wrong, please correct me.)=20 >=20 > As for proposed forwarding algorithm, forwarding using default route can > be done for packets without routing header. I.E, after look up of > routing table with destination address fails, forwarding decision is > based on source global address of the packet. That is, gw_info list is > searched with source prefix. If matched gw_info is found, the packet is > forwarded through host route entry for the gw advertising the prefix. > Thus, multiple addresses from multiple gateways can be configured in a > node and intermediate nodes can forward packets without routing header > only if gateway info list is maintained in the node. >=20 > I request valuable comments on my draft from authors of previous drafts > including C. Perkins, Wakikawa, C. Jelger, Pekka. Personally I also > believe that this area is very important and it is time to make > progress. How about requirement document or merged solution document? > Please let me know what is in your mind. Whoever is interested in this > topic may be welcomed in this thread. >=20 > Kindly Regards, >=20 > HyunWook Cha > =20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/manet=20 _______________________________________________ manet mailing list manet@ietf.org=20 https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 09:40:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00493 for ; Wed, 3 Mar 2004 09:40:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXXZ-00059C-5e for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 09:40:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23Ee4HO019780 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 09:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXXX-00058w-NE for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 09:40:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00422 for ; Wed, 3 Mar 2004 09:40:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXXV-0007nQ-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:40:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXVW-0007OB-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:37:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyXTr-00073O-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 09:36:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXTf-0004MP-Oi; Wed, 03 Mar 2004 09:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyXSf-0004Kf-DG for manet@optimus.ietf.org; Wed, 03 Mar 2004 09:35:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00211 for ; Wed, 3 Mar 2004 09:34:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyXSc-0006qM-00 for manet@ietf.org; Wed, 03 Mar 2004 09:34:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyXRc-0006fE-00 for manet@ietf.org; Wed, 03 Mar 2004 09:33:57 -0500 Received: from www.gawab.com ([204.97.230.36] helo=gawab.com) by ietf-mx with smtp (Exim 4.12) id 1AyXR2-0006TK-00 for manet@ietf.org; Wed, 03 Mar 2004 09:33:20 -0500 Received: (qmail 20820 invoked by uid 1004); 3 Mar 2004 14:38:11 -0000 Received: from unknown (HELO MagedSalah) (magedsalah80@gawab.com@163.121.41.7) by gawab.com with SMTP; 3 Mar 2004 14:38:11 -0000 From: "Maged Salah" To: Date: Wed, 3 Mar 2004 16:36:03 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C4013D.A1517700" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Thread-Index: AcQBLNrRIdMfaC9LSfS9yyMrTRfgnw== Message-Id: Subject: [manet] MANET Applications 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C4013D.A1517700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, I just want to ask if any body know papers that talk about different commercial MANET applications Thanks Maged Salah ------=_NextPart_000_000B_01C4013D.A1517700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi All,

 

I just want to ask if any body know papers that talk about different = commercial MANET applications

 

Thanks

 

Maged Salah

 

------=_NextPart_000_000B_01C4013D.A1517700-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 10:56:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06751 for ; Wed, 3 Mar 2004 10:56:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYin-0007gi-Gr for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 10:55:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23FtjVK029551 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 10:55:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYin-0007gY-B7 for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 10:55:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06728 for ; Wed, 3 Mar 2004 10:55:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyYik-0007Uk-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 10:55:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyYhp-0007K4-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 10:54:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyYh0-00079v-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 10:53:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyYgp-0006y6-Hh for manet-web-archive@ietf.org; Wed, 03 Mar 2004 10:53:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYg9-0007LU-OQ; Wed, 03 Mar 2004 10:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYfw-0007Kp-K8 for manet@optimus.ietf.org; Wed, 03 Mar 2004 10:52:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06614 for ; Wed, 3 Mar 2004 10:52:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyYft-0006y5-00 for manet@ietf.org; Wed, 03 Mar 2004 10:52:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyYf4-0006nF-00 for manet@ietf.org; Wed, 03 Mar 2004 10:51:55 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1AyYeM-0006X4-00 for manet@ietf.org; Wed, 03 Mar 2004 10:51:10 -0500 Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i23FobUM019160 for ; Wed, 3 Mar 2004 16:50:37 +0100 Message-ID: <006b01c40137$930f50a0$1f175d80@inria.fr> From: "Philippe Jacquet" To: "manet" References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> Subject: Re: [manet] Default Routes Date: Wed, 3 Mar 2004 16:52:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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 X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id i23FobUM019160 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I don't see any problem with MPR flooding, when last hop is MPR selector then it will be the upstream neighbor. I think the algorithm could be an application of the recent MPRF draft wi= th the option TTL=3D1. Philippe ----- Original Message ----- From: Erik Nordstr=C3=B6m To: Christophe Jelger Cc: manet Sent: Wednesday, March 03, 2004 3:13 PM Subject: Re: [manet] Default Routes Jelger, I admit that I am not that familiar with your proposal, and probably should read it more carefully. However, there are some things I question... For example, why implement a seperate flooding mechanism when this is already provided by the routing protocol (for example OLSR)? You propose to optionally integrate this with the routing protocol, but I do not see how that is possible with MPR-based flooding? I am not convinced that you have maximum flexibility when building your prefix islands of nodes. How can nodes part of a prefix island individually choose another gateway? But, I admit, I need to study your draft in more detail. With tunnels you can simply add a flag in ordinary control messages announcing some nodes as gateways. Nodes can then individually choose a gateway and tunnel packets to it. The routing protocol takes care of the rest transparently. This also works well with reactive protocols. /Erik On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: > Hi Erik, > > Well about handovers everything is in the draft, but I have to admit > that it's not very clear sometimes. I hope to write a new version soon. > > To summarise : we propose different algorithms used by each ad hoc node > to choose (and switch between) a gateway. It can either use the closest > gateway (whatever prefix it uses), or a gateway that uses the same > prefix than it currently uses (whatever the distance from the gateway). > We also proposed slight variants. So first answer to your email is that > switching between gateways is controled by each ad hoc node independent= ly. > > Moreover, and because of our particular (but very simple) way of prefix > propagation, we can guarantee that a default route is never diverted (i= n > the steady-state). By steady-state, I mean that of course topological > changes can cause trouble during a very small amount of time. The main > idea behind our draft is prefix continuity : we "build" contiguous > islands of nodes that share the same prefix/gateway. This can be of hig= h > interest for providers (e.g. management, services, ...). > > We have implemented our solution (IPv6) as an independent daemon and it > works really well in the presence of multiple gateways and prefixes. We > will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI i= n > France). I am also finishing some simulations in which we evaluate our > solution : I hope I can submit the results for publication very soon. > > Well and before everybody says what's best and what's bad, I personally > think it's very difficult at this stage to say so. If you have done som= e > simulations of the tunnel approach you have probably seen that results > can greatly vary across different simulation scenarios. I think all > solutions have pros and cons, and we should be able to find the best > parts of all solutions. > > Regards, > Christophe > > Erik Nordstr=C3=B6m wrote: > > >Hi, > > > >I don't see how you can efficiently handle multiple gateways when usin= g > >default routes? Especially with reactive protocols that do not have a > >complete view of the network. Even if you maintain the gateway mapping= , > >how will you deal with hand-overs between gateways? You say that the > >solution is to force nodes to use the "same" default route, but I do n= ot > >think that is a good idea. Individual nodes may know best when to swit= ch > >gateways, and they should be allowed to do so if they wish. How can yo= u > >guarantee that a default route is not diverted to another gateway at a= n > >intermediate node if a packet carries no mapping between the (final) > >destination and the gateway? How do you handle control packets (from > >different gateways) that want to change the default route --> gateway > >mapping? > > > >My experience with AODV-UU is that gateway tunneling has many properti= es > >that are prefered in an ad hoc network. Tunnels easily support multipl= e > >gateways and are transparent for intermediate nodes that forwards the > >traffic to the gateway. I have a paper pending that clearly shows the > >advantages of tunnels in this context. > > > >Before proceeding with a merged draft on Internet connectivity, I thin= k > >that the proposal should be backed up with serious research showing > >problems or benefits of different strategies. I have implemented gatew= ay > >connectivity in AODV-UU, and my experience clearly points in the > >direction of tunnels. > > > >Regards, > > > >Erik Nordstr=C3=B6m > > > > > > > >On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: > > > > > >>Actually each node knows what gateway it uses because there is a spec= ial > >>field in the packet used to disseminate the prefix information. This > >>field contains the IPv6 global address of the gateway (and another fi= eld > >>gives the prefix length). Moreover, we "almost" don't need a routing > >>protocol (of course don't take this statement too strictly), in the > >>sense that, when a node wants to send data to some node in the Intern= et, > >>it only uses a default route with next hop being one of its neighbors. > >>The ad hoc node does not even need to have a /128 route to the gatewa= y. > >>Of course on the reverse path this is not the same (i.e. the gateway > >>must have a /128 route to the ad hoc node). > >> > >>Christophe > >> > >>Anders Nilsson wrote: > >> > >> > >> > >>>Hello again, > >>> > >>>Christophe Jelger wrote: > >>> > >>> > >>> > >>>>Of course as one of the authors of a solution that uses default rou= te > >>>>I don't agree with your statements. ;-) > >>>> > >>>>In our draft each MANET node knows which gateway it uses, and (in t= he > >>>>steady-state) it knows that all nodes on the "default route" path u= se > >>>>the same gateway. With our solution gateways don't announce routes, > >>>>they just announce prefixes. If two gateways announce the same > >>>>prefix, an ad hoc node selects the closest gateway (it can be > >>>>specified that it should from there use the same gateway). The > >>>>propagation method used to propagate the prefix information ensures > >>>>that the path to the gateway is made of nodes that also use the sam= e > >>>>gateway : there is no need of a routing header, and default routes > >>>>can be used safely. > >>>> > >>>> > >>>> > >>>That sounds like a good solution, but the node can't control what > >>>gateway it is currently using. A scenario where this is neeed is whe= n > >>>the node is moving from gateway to gateway. The node is then unable = to > >>>know what gateway it is currently communicating through. A node need > >>>to know this when it switches to a new gateway, and "registers" > >>>itself. This reason why this needed is because packets from the > >>>Internet needs to be routed to the correct gateway, which is difficu= lt > >>>when mobile nodes are unware of its gateway. If a Cellular IP type o= f > >>>solution is used, the routing entries in the access network are > >>>updated by the actual packets flowing through the gateways. But ther= e > >>>is problems here as well, because oscillations easily occurs that > >>>causes a lot of updates, especially when the mobile nodes are mobile. > >>>I have simulated this, and it is harder to maintain than you might > >>>think. If you rely on proactive gateway discovery, the default routi= ng > >>>entries have to be maintained during link breaks and mobility, along > >>>with sequence number maintainence. I have a paper about this, in a > >>>slightly different context, but during mobility and several hops to > >>>the gateway, more complex control is needed. > >>> > >>>regards, > >>> > >>>Anders > >>> > >>> > >>> > >>> > >>> > >> > >>_______________________________________________ > >>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 exim@www1.ietf.org Wed Mar 3 12:15:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11125 for ; Wed, 3 Mar 2004 12:15:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZxI-0006IV-Co for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 12:14:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23HEmRp024201 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 12:14:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZxI-0006IG-8L for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 12:14:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11084 for ; Wed, 3 Mar 2004 12:14:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyZxG-0007Ic-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:14:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyZwN-00078u-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:13:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyZvi-0006yv-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:13:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZvb-00064D-15; Wed, 03 Mar 2004 12:13:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZvK-00062c-J9 for manet@optimus.ietf.org; Wed, 03 Mar 2004 12:12:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10937 for ; Wed, 3 Mar 2004 12:12:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyZvJ-0006wR-00 for manet@ietf.org; Wed, 03 Mar 2004 12:12:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyZuR-0006nA-00 for manet@ietf.org; Wed, 03 Mar 2004 12:11:52 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyZtz-0006dC-00 for manet@ietf.org; Wed, 03 Mar 2004 12:11:23 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i23HECZr007590 for ; Wed, 3 Mar 2004 18:14:12 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <40462009.6050900@dpt-info.u-strasbg.fr> Date: Wed, 03 Mar 2004 19:12:25 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id i23HECZr007590 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Erik, (please call me Christophe !) You are right when you say that a node within an "island" can't change=20 its prefix. Our objective is to create these islands, so we don't really=20 want to see a node that breaks this organisation. ;-) I also agree with you that the tunnel-based solution is the best one in=20 terms of control overhead (less control packets sent). I think our=20 proposal has a completely different objective. The only point we try to=20 defend is the concept of prefix continuity : this feature might be of=20 real interest for operators who like to have a somehow organised=20 network. This feature can also allow an operator to do some management=20 control and stuff like that. Regards, Christophe PS : we do not implement a separate flooding mechanism, because this is=20 not flooding !!! (I insist on that !) The information disseminates away=20 from gateways, it look like flooding but it's not ! ;-) Erik Nordstr=C3=B6m wrote: >Jelger, > >I admit that I am not that familiar with your proposal, and probably >should read it more carefully. However, there are some things I >question...=20 > >For example, why implement a seperate flooding mechanism when this is >already provided by the routing protocol (for example OLSR)? You propose >to optionally integrate this with the routing protocol, but I do not see >how that is possible with MPR-based flooding? > >I am not convinced that you have maximum flexibility when building your >prefix islands of nodes. How can nodes part of a prefix island >individually choose another gateway? But, I admit, I need to study your >draft in more detail. > >With tunnels you can simply add a flag in ordinary control messages >announcing some nodes as gateways. Nodes can then individually choose a >gateway and tunnel packets to it. The routing protocol takes care of the >rest transparently. This also works well with reactive protocols. > >/Erik > > >On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: > =20 > >>Hi Erik, >> >>Well about handovers everything is in the draft, but I have to admit=20 >>that it's not very clear sometimes. I hope to write a new version soon. >> >>To summarise : we propose different algorithms used by each ad hoc node= =20 >>to choose (and switch between) a gateway. It can either use the closest= =20 >>gateway (whatever prefix it uses), or a gateway that uses the same=20 >>prefix than it currently uses (whatever the distance from the gateway).= =20 >>We also proposed slight variants. So first answer to your email is that= =20 >>switching between gateways is controled by each ad hoc node independent= ly. >> >>Moreover, and because of our particular (but very simple) way of prefix= =20 >>propagation, we can guarantee that a default route is never diverted (i= n=20 >>the steady-state). By steady-state, I mean that of course topological=20 >>changes can cause trouble during a very small amount of time. The main=20 >>idea behind our draft is prefix continuity : we "build" contiguous=20 >>islands of nodes that share the same prefix/gateway. This can be of hig= h=20 >>interest for providers (e.g. management, services, ...). >> >>We have implemented our solution (IPv6) as an independent daemon and it= =20 >>works really well in the presence of multiple gateways and prefixes. We= =20 >>will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI i= n=20 >>France). I am also finishing some simulations in which we evaluate our=20 >>solution : I hope I can submit the results for publication very soon. >> >>Well and before everybody says what's best and what's bad, I personally= =20 >>think it's very difficult at this stage to say so. If you have done som= e=20 >>simulations of the tunnel approach you have probably seen that results=20 >>can greatly vary across different simulation scenarios. I think all=20 >>solutions have pros and cons, and we should be able to find the best=20 >>parts of all solutions. >> >>Regards, >>Christophe >> >>Erik Nordstr=C3=B6m wrote: >> >> =20 >> >>>Hi, >>> >>>I don't see how you can efficiently handle multiple gateways when usin= g >>>default routes? Especially with reactive protocols that do not have a >>>complete view of the network. Even if you maintain the gateway mapping= , >>>how will you deal with hand-overs between gateways? You say that the >>>solution is to force nodes to use the "same" default route, but I do n= ot >>>think that is a good idea. Individual nodes may know best when to swit= ch >>>gateways, and they should be allowed to do so if they wish. How can yo= u >>>guarantee that a default route is not diverted to another gateway at a= n >>>intermediate node if a packet carries no mapping between the (final) >>>destination and the gateway? How do you handle control packets (from >>>different gateways) that want to change the default route --> gateway >>>mapping? >>> >>>My experience with AODV-UU is that gateway tunneling has many properti= es >>>that are prefered in an ad hoc network. Tunnels easily support multipl= e >>>gateways and are transparent for intermediate nodes that forwards the >>>traffic to the gateway. I have a paper pending that clearly shows the >>>advantages of tunnels in this context. >>> >>>Before proceeding with a merged draft on Internet connectivity, I thin= k >>>that the proposal should be backed up with serious research showing >>>problems or benefits of different strategies. I have implemented gatew= ay >>>connectivity in AODV-UU, and my experience clearly points in the >>>direction of tunnels. >>> >>>Regards, >>> >>>Erik Nordstr=C3=B6m >>> >>> >>> >>>On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: >>>=20 >>> >>> =20 >>> >>>>Actually each node knows what gateway it uses because there is a spec= ial=20 >>>>field in the packet used to disseminate the prefix information. This=20 >>>>field contains the IPv6 global address of the gateway (and another fi= eld=20 >>>>gives the prefix length). Moreover, we "almost" don't need a routing=20 >>>>protocol (of course don't take this statement too strictly), in the=20 >>>>sense that, when a node wants to send data to some node in the Intern= et,=20 >>>>it only uses a default route with next hop being one of its neighbors= .=20 >>>>The ad hoc node does not even need to have a /128 route to the gatewa= y.=20 >>>>Of course on the reverse path this is not the same (i.e. the gateway=20 >>>>must have a /128 route to the ad hoc node). >>>> >>>>Christophe >>>> >>>>Anders Nilsson wrote: >>>> >>>> =20 >>>> >>>> =20 >>>> >>>>>Hello again, >>>>> >>>>>Christophe Jelger wrote: >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>>>Of course as one of the authors of a solution that uses default rou= te=20 >>>>>>I don't agree with your statements. ;-) >>>>>> >>>>>>In our draft each MANET node knows which gateway it uses, and (in t= he=20 >>>>>>steady-state) it knows that all nodes on the "default route" path u= se=20 >>>>>>the same gateway. With our solution gateways don't announce routes,= =20 >>>>>>they just announce prefixes. If two gateways announce the same=20 >>>>>>prefix, an ad hoc node selects the closest gateway (it can be=20 >>>>>>specified that it should from there use the same gateway). The=20 >>>>>>propagation method used to propagate the prefix information ensures= =20 >>>>>>that the path to the gateway is made of nodes that also use the sam= e=20 >>>>>>gateway : there is no need of a routing header, and default routes=20 >>>>>>can be used safely. >>>>>> >>>>>> =20 >>>>>> >>>>>> =20 >>>>>> >>>>>That sounds like a good solution, but the node can't control what=20 >>>>>gateway it is currently using. A scenario where this is neeed is whe= n=20 >>>>>the node is moving from gateway to gateway. The node is then unable = to=20 >>>>>know what gateway it is currently communicating through. A node need= =20 >>>>>to know this when it switches to a new gateway, and "registers"=20 >>>>>itself. This reason why this needed is because packets from the=20 >>>>>Internet needs to be routed to the correct gateway, which is difficu= lt=20 >>>>>when mobile nodes are unware of its gateway. If a Cellular IP type o= f=20 >>>>>solution is used, the routing entries in the access network are=20 >>>>>updated by the actual packets flowing through the gateways. But ther= e=20 >>>>>is problems here as well, because oscillations easily occurs that=20 >>>>>causes a lot of updates, especially when the mobile nodes are mobile= .=20 >>>>>I have simulated this, and it is harder to maintain than you might=20 >>>>>think. If you rely on proactive gateway discovery, the default routi= ng=20 >>>>>entries have to be maintained during link breaks and mobility, along= =20 >>>>>with sequence number maintainence. I have a paper about this, in a=20 >>>>>slightly different context, but during mobility and several hops to=20 >>>>>the gateway, more complex control is needed. >>>>> >>>>>regards, >>>>> >>>>>Anders >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>_______________________________________________ >>>>manet mailing list >>>>manet@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/manet >>>> =20 >>>> >>>> =20 >>>> >>>=20 >>> >>> =20 >>> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> =20 >> > > =20 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 12:18:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11342 for ; Wed, 3 Mar 2004 12:18:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aya0G-0006on-03 for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 12:17:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23HHp54026208 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 12:17:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aya0F-0006oc-FH for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 12:17:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11301 for ; Wed, 3 Mar 2004 12:17:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aya0D-00002Y-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:17:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyZzM-0007g9-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:16:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyZym-0007WF-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:16:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZyW-0006V6-0K; Wed, 03 Mar 2004 12:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZyR-0006Tt-0V for manet@optimus.ietf.org; Wed, 03 Mar 2004 12:15:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11192 for ; Wed, 3 Mar 2004 12:15:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyZyP-0007V1-00 for manet@ietf.org; Wed, 03 Mar 2004 12:15:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyZxR-0007KB-00 for manet@ietf.org; Wed, 03 Mar 2004 12:14:58 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AyZwn-00079g-00 for manet@ietf.org; Wed, 03 Mar 2004 12:14:17 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i23HEGnp010157; Wed, 3 Mar 2004 18:14:16 +0100 (MET) Subject: Re: [manet] Default Routes From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: Philippe Jacquet Cc: manet In-Reply-To: <006b01c40137$930f50a0$1f175d80@inria.fr> References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> Content-Type: text/plain; charset=UTF-8 Message-Id: <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 03 Mar 2004 18:14:16 +0100 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by aun.it.uu.se id i23HEGnp010157 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Maybe I am missing something (and please point it out), but will not the MPR flooding limit the distribution of (different) prefixes in the network? My concern is that a node far down the (MPR) distribution path rooted at a gateway will not be able to change gateway/prefix unless its upstream neighbor (closer to the gateway) also changes its prefix (of another gateway)?=20 //Erik On Wed, 2004-03-03 at 16:52, Philippe Jacquet wrote: > I don't see any problem with MPR flooding, when last hop is MPR selecto= r > then it will be the upstream neighbor. > I think the algorithm could be an application of the recent MPRF draft = with > the option TTL=3D1. >=20 > Philippe > ----- Original Message ----- > From: Erik Nordstr=C3=B6m > To: Christophe Jelger > Cc: manet > Sent: Wednesday, March 03, 2004 3:13 PM > Subject: Re: [manet] Default Routes >=20 >=20 > Jelger, >=20 > I admit that I am not that familiar with your proposal, and probably > should read it more carefully. However, there are some things I > question... >=20 > For example, why implement a seperate flooding mechanism when this is > already provided by the routing protocol (for example OLSR)? You propos= e > to optionally integrate this with the routing protocol, but I do not se= e > how that is possible with MPR-based flooding? >=20 > I am not convinced that you have maximum flexibility when building your > prefix islands of nodes. How can nodes part of a prefix island > individually choose another gateway? But, I admit, I need to study your > draft in more detail. >=20 > With tunnels you can simply add a flag in ordinary control messages > announcing some nodes as gateways. Nodes can then individually choose a > gateway and tunnel packets to it. The routing protocol takes care of th= e > rest transparently. This also works well with reactive protocols. >=20 > /Erik >=20 >=20 > On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: > > Hi Erik, > > > > Well about handovers everything is in the draft, but I have to admit > > that it's not very clear sometimes. I hope to write a new version soo= n. > > > > To summarise : we propose different algorithms used by each ad hoc no= de > > to choose (and switch between) a gateway. It can either use the close= st > > gateway (whatever prefix it uses), or a gateway that uses the same > > prefix than it currently uses (whatever the distance from the gateway= ). > > We also proposed slight variants. So first answer to your email is th= at > > switching between gateways is controled by each ad hoc node independe= ntly. > > > > Moreover, and because of our particular (but very simple) way of pref= ix > > propagation, we can guarantee that a default route is never diverted = (in > > the steady-state). By steady-state, I mean that of course topological > > changes can cause trouble during a very small amount of time. The mai= n > > idea behind our draft is prefix continuity : we "build" contiguous > > islands of nodes that share the same prefix/gateway. This can be of h= igh > > interest for providers (e.g. management, services, ...). > > > > We have implemented our solution (IPv6) as an independent daemon and = it > > works really well in the presence of multiple gateways and prefixes. = We > > will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI= in > > France). I am also finishing some simulations in which we evaluate ou= r > > solution : I hope I can submit the results for publication very soon. > > > > Well and before everybody says what's best and what's bad, I personal= ly > > think it's very difficult at this stage to say so. If you have done s= ome > > simulations of the tunnel approach you have probably seen that result= s > > can greatly vary across different simulation scenarios. I think all > > solutions have pros and cons, and we should be able to find the best > > parts of all solutions. > > > > Regards, > > Christophe > > > > Erik Nordstr=C3=B6m wrote: > > > > >Hi, > > > > > >I don't see how you can efficiently handle multiple gateways when us= ing > > >default routes? Especially with reactive protocols that do not have = a > > >complete view of the network. Even if you maintain the gateway mappi= ng, > > >how will you deal with hand-overs between gateways? You say that th= e > > >solution is to force nodes to use the "same" default route, but I do= not > > >think that is a good idea. Individual nodes may know best when to sw= itch > > >gateways, and they should be allowed to do so if they wish. How can = you > > >guarantee that a default route is not diverted to another gateway at= an > > >intermediate node if a packet carries no mapping between the (final) > > >destination and the gateway? How do you handle control packets (from > > >different gateways) that want to change the default route --> gatewa= y > > >mapping? > > > > > >My experience with AODV-UU is that gateway tunneling has many proper= ties > > >that are prefered in an ad hoc network. Tunnels easily support multi= ple > > >gateways and are transparent for intermediate nodes that forwards th= e > > >traffic to the gateway. I have a paper pending that clearly shows th= e > > >advantages of tunnels in this context. > > > > > >Before proceeding with a merged draft on Internet connectivity, I th= ink > > >that the proposal should be backed up with serious research showing > > >problems or benefits of different strategies. I have implemented gat= eway > > >connectivity in AODV-UU, and my experience clearly points in the > > >direction of tunnels. > > > > > >Regards, > > > > > >Erik Nordstr=C3=B6m > > > > > > > > > > > >On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: > > > > > > > > >>Actually each node knows what gateway it uses because there is a sp= ecial > > >>field in the packet used to disseminate the prefix information. Thi= s > > >>field contains the IPv6 global address of the gateway (and another = field > > >>gives the prefix length). Moreover, we "almost" don't need a routin= g > > >>protocol (of course don't take this statement too strictly), in the > > >>sense that, when a node wants to send data to some node in the Inte= rnet, > > >>it only uses a default route with next hop being one of its neighbo= rs. > > >>The ad hoc node does not even need to have a /128 route to the gate= way. > > >>Of course on the reverse path this is not the same (i.e. the gatewa= y > > >>must have a /128 route to the ad hoc node). > > >> > > >>Christophe > > >> > > >>Anders Nilsson wrote: > > >> > > >> > > >> > > >>>Hello again, > > >>> > > >>>Christophe Jelger wrote: > > >>> > > >>> > > >>> > > >>>>Of course as one of the authors of a solution that uses default r= oute > > >>>>I don't agree with your statements. ;-) > > >>>> > > >>>>In our draft each MANET node knows which gateway it uses, and (in= the > > >>>>steady-state) it knows that all nodes on the "default route" path= use > > >>>>the same gateway. With our solution gateways don't announce route= s, > > >>>>they just announce prefixes. If two gateways announce the same > > >>>>prefix, an ad hoc node selects the closest gateway (it can be > > >>>>specified that it should from there use the same gateway). The > > >>>>propagation method used to propagate the prefix information ensur= es > > >>>>that the path to the gateway is made of nodes that also use the s= ame > > >>>>gateway : there is no need of a routing header, and default route= s > > >>>>can be used safely. > > >>>> > > >>>> > > >>>> > > >>>That sounds like a good solution, but the node can't control what > > >>>gateway it is currently using. A scenario where this is neeed is w= hen > > >>>the node is moving from gateway to gateway. The node is then unabl= e to > > >>>know what gateway it is currently communicating through. A node ne= ed > > >>>to know this when it switches to a new gateway, and "registers" > > >>>itself. This reason why this needed is because packets from the > > >>>Internet needs to be routed to the correct gateway, which is diffi= cult > > >>>when mobile nodes are unware of its gateway. If a Cellular IP type= of > > >>>solution is used, the routing entries in the access network are > > >>>updated by the actual packets flowing through the gateways. But th= ere > > >>>is problems here as well, because oscillations easily occurs that > > >>>causes a lot of updates, especially when the mobile nodes are mobi= le. > > >>>I have simulated this, and it is harder to maintain than you might > > >>>think. If you rely on proactive gateway discovery, the default rou= ting > > >>>entries have to be maintained during link breaks and mobility, alo= ng > > >>>with sequence number maintainence. I have a paper about this, in a > > >>>slightly different context, but during mobility and several hops t= o > > >>>the gateway, more complex control is needed. > > >>> > > >>>regards, > > >>> > > >>>Anders > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >>_______________________________________________ > > >>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 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Wed Mar 3 12:29:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11991 for ; Wed, 3 Mar 2004 12:29:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaAz-0008Dm-7b for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 12:28:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23HSvOq031588 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 12:28:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaAy-0008DP-TZ for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 12:28:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11982 for ; Wed, 3 Mar 2004 12:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyaAx-00023L-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:28:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aya9y-0001t5-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:27:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aya9T-0001iX-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:27:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aya98-0007iw-2S; Wed, 03 Mar 2004 12:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aya8l-0007hR-5R for manet@optimus.ietf.org; Wed, 03 Mar 2004 12:26:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11884 for ; Wed, 3 Mar 2004 12:26:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aya8j-0001fj-00 for manet@ietf.org; Wed, 03 Mar 2004 12:26:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aya7p-0001Wx-00 for manet@ietf.org; Wed, 03 Mar 2004 12:25:42 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1Aya72-0001OT-00 for manet@ietf.org; Wed, 03 Mar 2004 12:24:52 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i23HRgZr008166 for ; Wed, 3 Mar 2004 18:27:42 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <40462332.9020908@dpt-info.u-strasbg.fr> Date: Wed, 03 Mar 2004 19:25:54 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id i23HRgZr008166 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Erik, You are right ... sometimes a node cannot change its prefix unless its=20 upstream neighbor chooses another one. This is what allows to have=20 prefix continuity. We cannot have all nodes do whatever they want and=20 guarantee the prefix continuity feature ... ;-) Again using MPR is not a problem ... there will be less flexibility and=20 routes might not be "shortest path", but there is no reason why it=20 should not work. And about prefix distribution : prefix distribution is limited "by=20 nature", i.e. a node that is a the limit of two "islands" will not=20 forward control packets received from the island it does not belong to. Christophe Erik Nordstr=C3=B6m wrote: >Maybe I am missing something (and please point it out), but will not the >MPR flooding limit the distribution of (different) prefixes in the >network? My concern is that a node far down the (MPR) distribution path >rooted at a gateway will not be able to change gateway/prefix unless its >upstream neighbor (closer to the gateway) also changes its prefix (of >another gateway)?=20 > >//Erik > >On Wed, 2004-03-03 at 16:52, Philippe Jacquet wrote: > =20 > >>I don't see any problem with MPR flooding, when last hop is MPR selecto= r >>then it will be the upstream neighbor. >>I think the algorithm could be an application of the recent MPRF draft = with >>the option TTL=3D1. >> >>Philippe >>----- Original Message ----- >>From: Erik Nordstr=C3=B6m >>To: Christophe Jelger >>Cc: manet >>Sent: Wednesday, March 03, 2004 3:13 PM >>Subject: Re: [manet] Default Routes >> >> >>Jelger, >> >>I admit that I am not that familiar with your proposal, and probably >>should read it more carefully. However, there are some things I >>question... >> >>For example, why implement a seperate flooding mechanism when this is >>already provided by the routing protocol (for example OLSR)? You propos= e >>to optionally integrate this with the routing protocol, but I do not se= e >>how that is possible with MPR-based flooding? >> >>I am not convinced that you have maximum flexibility when building your >>prefix islands of nodes. How can nodes part of a prefix island >>individually choose another gateway? But, I admit, I need to study your >>draft in more detail. >> >>With tunnels you can simply add a flag in ordinary control messages >>announcing some nodes as gateways. Nodes can then individually choose a >>gateway and tunnel packets to it. The routing protocol takes care of th= e >>rest transparently. This also works well with reactive protocols. >> >>/Erik >> >> >>On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: >> =20 >> >>>Hi Erik, >>> >>>Well about handovers everything is in the draft, but I have to admit >>>that it's not very clear sometimes. I hope to write a new version soon. >>> >>>To summarise : we propose different algorithms used by each ad hoc nod= e >>>to choose (and switch between) a gateway. It can either use the closes= t >>>gateway (whatever prefix it uses), or a gateway that uses the same >>>prefix than it currently uses (whatever the distance from the gateway). >>>We also proposed slight variants. So first answer to your email is tha= t >>>switching between gateways is controled by each ad hoc node independen= tly. >>> >>>Moreover, and because of our particular (but very simple) way of prefi= x >>>propagation, we can guarantee that a default route is never diverted (= in >>>the steady-state). By steady-state, I mean that of course topological >>>changes can cause trouble during a very small amount of time. The main >>>idea behind our draft is prefix continuity : we "build" contiguous >>>islands of nodes that share the same prefix/gateway. This can be of hi= gh >>>interest for providers (e.g. management, services, ...). >>> >>>We have implemented our solution (IPv6) as an independent daemon and i= t >>>works really well in the presence of multiple gateways and prefixes. W= e >>>will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI = in >>>France). I am also finishing some simulations in which we evaluate our >>>solution : I hope I can submit the results for publication very soon. >>> >>>Well and before everybody says what's best and what's bad, I personall= y >>>think it's very difficult at this stage to say so. If you have done so= me >>>simulations of the tunnel approach you have probably seen that results >>>can greatly vary across different simulation scenarios. I think all >>>solutions have pros and cons, and we should be able to find the best >>>parts of all solutions. >>> >>>Regards, >>>Christophe >>> >>>Erik Nordstr=C3=B6m wrote: >>> >>> =20 >>> >>>>Hi, >>>> >>>>I don't see how you can efficiently handle multiple gateways when usi= ng >>>>default routes? Especially with reactive protocols that do not have a >>>>complete view of the network. Even if you maintain the gateway mappin= g, >>>>how will you deal with hand-overs between gateways? You say that the >>>>solution is to force nodes to use the "same" default route, but I do = not >>>>think that is a good idea. Individual nodes may know best when to swi= tch >>>>gateways, and they should be allowed to do so if they wish. How can y= ou >>>>guarantee that a default route is not diverted to another gateway at = an >>>>intermediate node if a packet carries no mapping between the (final) >>>>destination and the gateway? How do you handle control packets (from >>>>different gateways) that want to change the default route --> gateway >>>>mapping? >>>> >>>>My experience with AODV-UU is that gateway tunneling has many propert= ies >>>>that are prefered in an ad hoc network. Tunnels easily support multip= le >>>>gateways and are transparent for intermediate nodes that forwards the >>>>traffic to the gateway. I have a paper pending that clearly shows the >>>>advantages of tunnels in this context. >>>> >>>>Before proceeding with a merged draft on Internet connectivity, I thi= nk >>>>that the proposal should be backed up with serious research showing >>>>problems or benefits of different strategies. I have implemented gate= way >>>>connectivity in AODV-UU, and my experience clearly points in the >>>>direction of tunnels. >>>> >>>>Regards, >>>> >>>>Erik Nordstr=C3=B6m >>>> >>>> >>>> >>>>On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: >>>> >>>> >>>> =20 >>>> >>>>>Actually each node knows what gateway it uses because there is a spe= cial >>>>>field in the packet used to disseminate the prefix information. This >>>>>field contains the IPv6 global address of the gateway (and another f= ield >>>>>gives the prefix length). Moreover, we "almost" don't need a routing >>>>>protocol (of course don't take this statement too strictly), in the >>>>>sense that, when a node wants to send data to some node in the Inter= net, >>>>>it only uses a default route with next hop being one of its neighbor= s. >>>>>The ad hoc node does not even need to have a /128 route to the gatew= ay. >>>>>Of course on the reverse path this is not the same (i.e. the gateway >>>>>must have a /128 route to the ad hoc node). >>>>> >>>>>Christophe >>>>> >>>>>Anders Nilsson wrote: >>>>> >>>>> >>>>> >>>>> =20 >>>>> >>>>>>Hello again, >>>>>> >>>>>>Christophe Jelger wrote: >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>>>Of course as one of the authors of a solution that uses default ro= ute >>>>>>>I don't agree with your statements. ;-) >>>>>>> >>>>>>>In our draft each MANET node knows which gateway it uses, and (in = the >>>>>>>steady-state) it knows that all nodes on the "default route" path = use >>>>>>>the same gateway. With our solution gateways don't announce routes= , >>>>>>>they just announce prefixes. If two gateways announce the same >>>>>>>prefix, an ad hoc node selects the closest gateway (it can be >>>>>>>specified that it should from there use the same gateway). The >>>>>>>propagation method used to propagate the prefix information ensure= s >>>>>>>that the path to the gateway is made of nodes that also use the sa= me >>>>>>>gateway : there is no need of a routing header, and default routes >>>>>>>can be used safely. >>>>>>> >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>> >>>>>>That sounds like a good solution, but the node can't control what >>>>>>gateway it is currently using. A scenario where this is neeed is wh= en >>>>>>the node is moving from gateway to gateway. The node is then unable= to >>>>>>know what gateway it is currently communicating through. A node nee= d >>>>>>to know this when it switches to a new gateway, and "registers" >>>>>>itself. This reason why this needed is because packets from the >>>>>>Internet needs to be routed to the correct gateway, which is diffic= ult >>>>>>when mobile nodes are unware of its gateway. If a Cellular IP type = of >>>>>>solution is used, the routing entries in the access network are >>>>>>updated by the actual packets flowing through the gateways. But the= re >>>>>>is problems here as well, because oscillations easily occurs that >>>>>>causes a lot of updates, especially when the mobile nodes are mobil= e. >>>>>>I have simulated this, and it is harder to maintain than you might >>>>>>think. If you rely on proactive gateway discovery, the default rout= ing >>>>>>entries have to be maintained during link breaks and mobility, alon= g >>>>>>with sequence number maintainence. I have a paper about this, in a >>>>>>slightly different context, but during mobility and several hops to >>>>>>the gateway, more complex control is needed. >>>>>> >>>>>>regards, >>>>>> >>>>>>Anders >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>_______________________________________________ >>>>>manet mailing list >>>>>manet@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/manet >>>>> >>>>> >>>>> =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 >> >> >>_______________________________________________ >>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 > =20 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 12:39:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13062 for ; Wed, 3 Mar 2004 12:39:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaKZ-0000qP-8k for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 12:38:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23Hcprq003244 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 12:38:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaKY-0000qF-V0 for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 12:38:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13015 for ; Wed, 3 Mar 2004 12:38:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyaKX-0004GJ-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:38:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyaJb-000456-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:37:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyaIv-0003v3-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 12:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaIp-0000DH-LX; Wed, 03 Mar 2004 12:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyaIa-0000B6-I0 for manet@optimus.ietf.org; Wed, 03 Mar 2004 12:36:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12663 for ; Wed, 3 Mar 2004 12:36:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyaIZ-0003sf-00 for manet@ietf.org; Wed, 03 Mar 2004 12:36:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyaHf-0003g6-00 for manet@ietf.org; Wed, 03 Mar 2004 12:35:52 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AyaGc-0003NH-00 for manet@ietf.org; Wed, 03 Mar 2004 12:34:46 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i23HYj5Q013681; Wed, 3 Mar 2004 18:34:45 +0100 (MET) Subject: Re: [manet] Default Routes From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: Christophe Jelger Cc: manet In-Reply-To: <40462009.6050900@dpt-info.u-strasbg.fr> References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <40462009.6050900@dpt-info.u-strasbg.fr> Content-Type: text/plain; charset=UTF-8 Message-Id: <1078335284.1364.111.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 03 Mar 2004 18:34:44 +0100 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by aun.it.uu.se id i23HYj5Q013681 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Christophe, Ok, you are proposing a limited scope solution, which is fine. I just didn't realize that was your intention. However, I have another question. How do you handle "contention" between the announcements at the edges of bordering prefix islands? I guess that borderline nodes have the ability to select gateway by themselves, but that could potentially affect many downstream nodes that previously used another prefix. A node could also cut off and isolate islands of nodes if it chooses to change prefix/gateway. What are the convergence times for situations like that? Is it desirable that borderline nodes could have such a big effect on lots of downstream nodes? //Erik On Wed, 2004-03-03 at 19:12, Christophe Jelger wrote: > Erik, >=20 > (please call me Christophe !) >=20 > You are right when you say that a node within an "island" can't change=20 > its prefix. Our objective is to create these islands, so we don't reall= y=20 > want to see a node that breaks this organisation. ;-) >=20 > I also agree with you that the tunnel-based solution is the best one in= =20 > terms of control overhead (less control packets sent). I think our=20 > proposal has a completely different objective. The only point we try to= =20 > defend is the concept of prefix continuity : this feature might be of=20 > real interest for operators who like to have a somehow organised=20 > network. This feature can also allow an operator to do some management=20 > control and stuff like that. >=20 > Regards, > Christophe >=20 > PS : we do not implement a separate flooding mechanism, because this is= =20 > not flooding !!! (I insist on that !) The information disseminates away= =20 > from gateways, it look like flooding but it's not ! ;-) >=20 > Erik Nordstr=C3=B6m wrote: >=20 > >Jelger, > > > >I admit that I am not that familiar with your proposal, and probably > >should read it more carefully. However, there are some things I > >question...=20 > > > >For example, why implement a seperate flooding mechanism when this is > >already provided by the routing protocol (for example OLSR)? You propo= se > >to optionally integrate this with the routing protocol, but I do not s= ee > >how that is possible with MPR-based flooding? > > > >I am not convinced that you have maximum flexibility when building you= r > >prefix islands of nodes. How can nodes part of a prefix island > >individually choose another gateway? But, I admit, I need to study you= r > >draft in more detail. > > > >With tunnels you can simply add a flag in ordinary control messages > >announcing some nodes as gateways. Nodes can then individually choose = a > >gateway and tunnel packets to it. The routing protocol takes care of t= he > >rest transparently. This also works well with reactive protocols. > > > >/Erik > > > > > >On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: > > =20 > > > >>Hi Erik, > >> > >>Well about handovers everything is in the draft, but I have to admit=20 > >>that it's not very clear sometimes. I hope to write a new version soo= n. > >> > >>To summarise : we propose different algorithms used by each ad hoc no= de=20 > >>to choose (and switch between) a gateway. It can either use the close= st=20 > >>gateway (whatever prefix it uses), or a gateway that uses the same=20 > >>prefix than it currently uses (whatever the distance from the gateway= ).=20 > >>We also proposed slight variants. So first answer to your email is th= at=20 > >>switching between gateways is controled by each ad hoc node independe= ntly. > >> > >>Moreover, and because of our particular (but very simple) way of pref= ix=20 > >>propagation, we can guarantee that a default route is never diverted = (in=20 > >>the steady-state). By steady-state, I mean that of course topological= =20 > >>changes can cause trouble during a very small amount of time. The mai= n=20 > >>idea behind our draft is prefix continuity : we "build" contiguous=20 > >>islands of nodes that share the same prefix/gateway. This can be of h= igh=20 > >>interest for providers (e.g. management, services, ...). > >> > >>We have implemented our solution (IPv6) as an independent daemon and = it=20 > >>works really well in the presence of multiple gateways and prefixes. = We=20 > >>will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI= in=20 > >>France). I am also finishing some simulations in which we evaluate ou= r=20 > >>solution : I hope I can submit the results for publication very soon. > >> > >>Well and before everybody says what's best and what's bad, I personal= ly=20 > >>think it's very difficult at this stage to say so. If you have done s= ome=20 > >>simulations of the tunnel approach you have probably seen that result= s=20 > >>can greatly vary across different simulation scenarios. I think all=20 > >>solutions have pros and cons, and we should be able to find the best=20 > >>parts of all solutions. > >> > >>Regards, > >>Christophe > >> > >>Erik Nordstr=C3=B6m wrote: > >> > >> =20 > >> > >>>Hi, > >>> > >>>I don't see how you can efficiently handle multiple gateways when us= ing > >>>default routes? Especially with reactive protocols that do not have = a > >>>complete view of the network. Even if you maintain the gateway mappi= ng, > >>>how will you deal with hand-overs between gateways? You say that th= e > >>>solution is to force nodes to use the "same" default route, but I do= not > >>>think that is a good idea. Individual nodes may know best when to sw= itch > >>>gateways, and they should be allowed to do so if they wish. How can = you > >>>guarantee that a default route is not diverted to another gateway at= an > >>>intermediate node if a packet carries no mapping between the (final) > >>>destination and the gateway? How do you handle control packets (from > >>>different gateways) that want to change the default route --> gatewa= y > >>>mapping? > >>> > >>>My experience with AODV-UU is that gateway tunneling has many proper= ties > >>>that are prefered in an ad hoc network. Tunnels easily support multi= ple > >>>gateways and are transparent for intermediate nodes that forwards th= e > >>>traffic to the gateway. I have a paper pending that clearly shows th= e > >>>advantages of tunnels in this context. > >>> > >>>Before proceeding with a merged draft on Internet connectivity, I th= ink > >>>that the proposal should be backed up with serious research showing > >>>problems or benefits of different strategies. I have implemented gat= eway > >>>connectivity in AODV-UU, and my experience clearly points in the > >>>direction of tunnels. > >>> > >>>Regards, > >>> > >>>Erik Nordstr=C3=B6m > >>> > >>> > >>> > >>>On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: > >>>=20 > >>> > >>> =20 > >>> > >>>>Actually each node knows what gateway it uses because there is a sp= ecial=20 > >>>>field in the packet used to disseminate the prefix information. Thi= s=20 > >>>>field contains the IPv6 global address of the gateway (and another = field=20 > >>>>gives the prefix length). Moreover, we "almost" don't need a routin= g=20 > >>>>protocol (of course don't take this statement too strictly), in the= =20 > >>>>sense that, when a node wants to send data to some node in the Inte= rnet,=20 > >>>>it only uses a default route with next hop being one of its neighbo= rs.=20 > >>>>The ad hoc node does not even need to have a /128 route to the gate= way.=20 > >>>>Of course on the reverse path this is not the same (i.e. the gatewa= y=20 > >>>>must have a /128 route to the ad hoc node). > >>>> > >>>>Christophe > >>>> > >>>>Anders Nilsson wrote: > >>>> > >>>> =20 > >>>> > >>>> =20 > >>>> > >>>>>Hello again, > >>>>> > >>>>>Christophe Jelger wrote: > >>>>> > >>>>> =20 > >>>>> > >>>>> =20 > >>>>> > >>>>>>Of course as one of the authors of a solution that uses default r= oute=20 > >>>>>>I don't agree with your statements. ;-) > >>>>>> > >>>>>>In our draft each MANET node knows which gateway it uses, and (in= the=20 > >>>>>>steady-state) it knows that all nodes on the "default route" path= use=20 > >>>>>>the same gateway. With our solution gateways don't announce route= s,=20 > >>>>>>they just announce prefixes. If two gateways announce the same=20 > >>>>>>prefix, an ad hoc node selects the closest gateway (it can be=20 > >>>>>>specified that it should from there use the same gateway). The=20 > >>>>>>propagation method used to propagate the prefix information ensur= es=20 > >>>>>>that the path to the gateway is made of nodes that also use the s= ame=20 > >>>>>>gateway : there is no need of a routing header, and default route= s=20 > >>>>>>can be used safely. > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>> =20 > >>>>>> > >>>>>That sounds like a good solution, but the node can't control what=20 > >>>>>gateway it is currently using. A scenario where this is neeed is w= hen=20 > >>>>>the node is moving from gateway to gateway. The node is then unabl= e to=20 > >>>>>know what gateway it is currently communicating through. A node ne= ed=20 > >>>>>to know this when it switches to a new gateway, and "registers"=20 > >>>>>itself. This reason why this needed is because packets from the=20 > >>>>>Internet needs to be routed to the correct gateway, which is diffi= cult=20 > >>>>>when mobile nodes are unware of its gateway. If a Cellular IP type= of=20 > >>>>>solution is used, the routing entries in the access network are=20 > >>>>>updated by the actual packets flowing through the gateways. But th= ere=20 > >>>>>is problems here as well, because oscillations easily occurs that=20 > >>>>>causes a lot of updates, especially when the mobile nodes are mobi= le.=20 > >>>>>I have simulated this, and it is harder to maintain than you might= =20 > >>>>>think. If you rely on proactive gateway discovery, the default rou= ting=20 > >>>>>entries have to be maintained during link breaks and mobility, alo= ng=20 > >>>>>with sequence number maintainence. I have a paper about this, in a= =20 > >>>>>slightly different context, but during mobility and several hops t= o=20 > >>>>>the gateway, more complex control is needed. > >>>>> > >>>>>regards, > >>>>> > >>>>>Anders > >>>>> > >>>>> > >>>>> > >>>>> =20 > >>>>> > >>>>> =20 > >>>>> > >>>>_______________________________________________ > >>>>manet mailing list > >>>>manet@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/manet > >>>> =20 > >>>> > >>>> =20 > >>>> > >>>=20 > >>> > >>> =20 > >>> > >> > >>_______________________________________________ > >>manet mailing list > >>manet@ietf.org > >>https://www1.ietf.org/mailman/listinfo/manet > >> =20 > >> > > > > =20 > > >=20 >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Wed Mar 3 13:56:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17636 for ; Wed, 3 Mar 2004 13:56:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AybXE-0007Gr-32 for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 13:56:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23Iu0Wx027943 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 13:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AybXD-0007Gc-Dz for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 13:55:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17526 for ; Wed, 3 Mar 2004 13:55:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AybXB-0003RI-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 13:55:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AybVY-0002v1-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 13:54:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AybTy-0002Ve-01 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 13:52:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AybJs-00038o-1l for manet-web-archive@ietf.org; Wed, 03 Mar 2004 13:42:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AybJg-0006S8-L8; Wed, 03 Mar 2004 13:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AybIk-0006QU-M1 for manet@optimus.ietf.org; Wed, 03 Mar 2004 13:41:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16964 for ; Wed, 3 Mar 2004 13:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AybIi-0000uL-00 for manet@ietf.org; Wed, 03 Mar 2004 13:41:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AybI2-0000if-00 for manet@ietf.org; Wed, 03 Mar 2004 13:40:20 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1AybHA-0000PL-00 for manet@ietf.org; Wed, 03 Mar 2004 13:39:24 -0500 Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i23IcrUM008473 for ; Wed, 3 Mar 2004 19:38:53 +0100 Message-ID: <00c701c4014f$052b8980$1f175d80@inria.fr> From: "Philippe Jacquet" To: "manet" References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> Subject: Re: [manet] Default Routes Date: Wed, 3 Mar 2004 19:40:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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 X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id i23IcrUM008473 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Christophe, This is property of MPR flooding: the path may be shorter than with blind flooding, of course not necessarily the shortest path since transmissions may be desequenced. Philippe ----- Original Message ----- From: Christophe Jelger To: manet Sent: Wednesday, March 03, 2004 7:25 PM Subject: Re: [manet] Default Routes Erik, You are right ... sometimes a node cannot change its prefix unless its upstream neighbor chooses another one. This is what allows to have prefix continuity. We cannot have all nodes do whatever they want and guarantee the prefix continuity feature ... ;-) Again using MPR is not a problem ... there will be less flexibility and routes might not be "shortest path", but there is no reason why it should not work. And about prefix distribution : prefix distribution is limited "by nature", i.e. a node that is a the limit of two "islands" will not forward control packets received from the island it does not belong to. Christophe Erik Nordstr=C3=B6m wrote: >Maybe I am missing something (and please point it out), but will not the >MPR flooding limit the distribution of (different) prefixes in the >network? My concern is that a node far down the (MPR) distribution path >rooted at a gateway will not be able to change gateway/prefix unless its >upstream neighbor (closer to the gateway) also changes its prefix (of >another gateway)? > >//Erik > >On Wed, 2004-03-03 at 16:52, Philippe Jacquet wrote: > > >>I don't see any problem with MPR flooding, when last hop is MPR selecto= r >>then it will be the upstream neighbor. >>I think the algorithm could be an application of the recent MPRF draft with >>the option TTL=3D1. >> >>Philippe >>----- Original Message ----- >>From: Erik Nordstr=C3=B6m >>To: Christophe Jelger >>Cc: manet >>Sent: Wednesday, March 03, 2004 3:13 PM >>Subject: Re: [manet] Default Routes >> >> >>Jelger, >> >>I admit that I am not that familiar with your proposal, and probably >>should read it more carefully. However, there are some things I >>question... >> >>For example, why implement a seperate flooding mechanism when this is >>already provided by the routing protocol (for example OLSR)? You propos= e >>to optionally integrate this with the routing protocol, but I do not se= e >>how that is possible with MPR-based flooding? >> >>I am not convinced that you have maximum flexibility when building your >>prefix islands of nodes. How can nodes part of a prefix island >>individually choose another gateway? But, I admit, I need to study your >>draft in more detail. >> >>With tunnels you can simply add a flag in ordinary control messages >>announcing some nodes as gateways. Nodes can then individually choose a >>gateway and tunnel packets to it. The routing protocol takes care of th= e >>rest transparently. This also works well with reactive protocols. >> >>/Erik >> >> >>On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: >> >> >>>Hi Erik, >>> >>>Well about handovers everything is in the draft, but I have to admit >>>that it's not very clear sometimes. I hope to write a new version soon. >>> >>>To summarise : we propose different algorithms used by each ad hoc nod= e >>>to choose (and switch between) a gateway. It can either use the closes= t >>>gateway (whatever prefix it uses), or a gateway that uses the same >>>prefix than it currently uses (whatever the distance from the gateway). >>>We also proposed slight variants. So first answer to your email is tha= t >>>switching between gateways is controled by each ad hoc node independently. >>> >>>Moreover, and because of our particular (but very simple) way of prefi= x >>>propagation, we can guarantee that a default route is never diverted (= in >>>the steady-state). By steady-state, I mean that of course topological >>>changes can cause trouble during a very small amount of time. The main >>>idea behind our draft is prefix continuity : we "build" contiguous >>>islands of nodes that share the same prefix/gateway. This can be of hi= gh >>>interest for providers (e.g. management, services, ...). >>> >>>We have implemented our solution (IPv6) as an independent daemon and i= t >>>works really well in the presence of multiple gateways and prefixes. W= e >>>will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI = in >>>France). I am also finishing some simulations in which we evaluate our >>>solution : I hope I can submit the results for publication very soon. >>> >>>Well and before everybody says what's best and what's bad, I personall= y >>>think it's very difficult at this stage to say so. If you have done so= me >>>simulations of the tunnel approach you have probably seen that results >>>can greatly vary across different simulation scenarios. I think all >>>solutions have pros and cons, and we should be able to find the best >>>parts of all solutions. >>> >>>Regards, >>>Christophe >>> >>>Erik Nordstr=C3=B6m wrote: >>> >>> >>> >>>>Hi, >>>> >>>>I don't see how you can efficiently handle multiple gateways when usi= ng >>>>default routes? Especially with reactive protocols that do not have a >>>>complete view of the network. Even if you maintain the gateway mappin= g, >>>>how will you deal with hand-overs between gateways? You say that the >>>>solution is to force nodes to use the "same" default route, but I do = not >>>>think that is a good idea. Individual nodes may know best when to swi= tch >>>>gateways, and they should be allowed to do so if they wish. How can y= ou >>>>guarantee that a default route is not diverted to another gateway at = an >>>>intermediate node if a packet carries no mapping between the (final) >>>>destination and the gateway? How do you handle control packets (from >>>>different gateways) that want to change the default route --> gateway >>>>mapping? >>>> >>>>My experience with AODV-UU is that gateway tunneling has many propert= ies >>>>that are prefered in an ad hoc network. Tunnels easily support multip= le >>>>gateways and are transparent for intermediate nodes that forwards the >>>>traffic to the gateway. I have a paper pending that clearly shows the >>>>advantages of tunnels in this context. >>>> >>>>Before proceeding with a merged draft on Internet connectivity, I thi= nk >>>>that the proposal should be backed up with serious research showing >>>>problems or benefits of different strategies. I have implemented gate= way >>>>connectivity in AODV-UU, and my experience clearly points in the >>>>direction of tunnels. >>>> >>>>Regards, >>>> >>>>Erik Nordstr=C3=B6m >>>> >>>> >>>> >>>>On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: >>>> >>>> >>>> >>>> >>>>>Actually each node knows what gateway it uses because there is a special >>>>>field in the packet used to disseminate the prefix information. This >>>>>field contains the IPv6 global address of the gateway (and another field >>>>>gives the prefix length). Moreover, we "almost" don't need a routing >>>>>protocol (of course don't take this statement too strictly), in the >>>>>sense that, when a node wants to send data to some node in the Internet, >>>>>it only uses a default route with next hop being one of its neighbor= s. >>>>>The ad hoc node does not even need to have a /128 route to the gatew= ay. >>>>>Of course on the reverse path this is not the same (i.e. the gateway >>>>>must have a /128 route to the ad hoc node). >>>>> >>>>>Christophe >>>>> >>>>>Anders Nilsson wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hello again, >>>>>> >>>>>>Christophe Jelger wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Of course as one of the authors of a solution that uses default ro= ute >>>>>>>I don't agree with your statements. ;-) >>>>>>> >>>>>>>In our draft each MANET node knows which gateway it uses, and (in = the >>>>>>>steady-state) it knows that all nodes on the "default route" path = use >>>>>>>the same gateway. With our solution gateways don't announce routes= , >>>>>>>they just announce prefixes. If two gateways announce the same >>>>>>>prefix, an ad hoc node selects the closest gateway (it can be >>>>>>>specified that it should from there use the same gateway). The >>>>>>>propagation method used to propagate the prefix information ensure= s >>>>>>>that the path to the gateway is made of nodes that also use the sa= me >>>>>>>gateway : there is no need of a routing header, and default routes >>>>>>>can be used safely. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>That sounds like a good solution, but the node can't control what >>>>>>gateway it is currently using. A scenario where this is neeed is wh= en >>>>>>the node is moving from gateway to gateway. The node is then unable= to >>>>>>know what gateway it is currently communicating through. A node nee= d >>>>>>to know this when it switches to a new gateway, and "registers" >>>>>>itself. This reason why this needed is because packets from the >>>>>>Internet needs to be routed to the correct gateway, which is diffic= ult >>>>>>when mobile nodes are unware of its gateway. If a Cellular IP type = of >>>>>>solution is used, the routing entries in the access network are >>>>>>updated by the actual packets flowing through the gateways. But the= re >>>>>>is problems here as well, because oscillations easily occurs that >>>>>>causes a lot of updates, especially when the mobile nodes are mobil= e. >>>>>>I have simulated this, and it is harder to maintain than you might >>>>>>think. If you rely on proactive gateway discovery, the default rout= ing >>>>>>entries have to be maintained during link breaks and mobility, alon= g >>>>>>with sequence number maintainence. I have a paper about this, in a >>>>>>slightly different context, but during mobility and several hops to >>>>>>the gateway, more complex control is needed. >>>>>> >>>>>>regards, >>>>>> >>>>>>Anders >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>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 >> >> > > >_______________________________________________ >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 exim@www1.ietf.org Wed Mar 3 14:15:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19107 for ; Wed, 3 Mar 2004 14:15:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybpn-0001KZ-Fv for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 14:15:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23JFBg9005109 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 14:15:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybpn-0001KK-5H for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 14:15:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19051 for ; Wed, 3 Mar 2004 14:15:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aybpk-0007iE-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 14:15:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aybog-0007Sy-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 14:14:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aybnx-0007Ft-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 14:13:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybni-0000p7-2G; Wed, 03 Mar 2004 14:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AybnN-0000nS-VH for manet@optimus.ietf.org; Wed, 03 Mar 2004 14:12:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18912 for ; Wed, 3 Mar 2004 14:12:39 -0500 (EST) From: andersn@telecom.lth.se Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AybnL-0007A9-00 for manet@ietf.org; Wed, 03 Mar 2004 14:12:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AybmN-0006vo-00 for manet@ietf.org; Wed, 03 Mar 2004 14:11:40 -0500 Received: from anyida.tts.lth.se ([130.235.18.10]) by ietf-mx with esmtp (Exim 4.12) id 1AyblO-0006jg-00 for manet@ietf.org; Wed, 03 Mar 2004 14:10:38 -0500 Received: from ww2.telecom.lth.se (lina36.tts.lth.se [130.235.18.156]) by anyida.tts.lth.se (8.9.3/8.9.3) with SMTP id UAA26617; Wed, 3 Mar 2004 20:11:49 +0100 (MET) Received: from 217.208.138.149 (SquirrelMail authenticated user andersn) by ww2.telecom.lth.se with HTTP; Wed, 3 Mar 2004 20:11:10 +0100 (CET) Message-ID: <61384.217.208.138.149.1078341070.squirrel@ww2.telecom.lth.se> Date: Wed, 3 Mar 2004 20:11:10 +0100 (CET) Subject: Re: [manet] Default Routes To: Erik =?iso-8859-1?Q?Nordstr=F6m?= Cc: manet@ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by anyida.tts.lth.se id UAA26617 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, Let me see if I understood the draft correctly. > However, I have another question. How do you handle "contention" betwee= n > the announcements at the edges of bordering prefix islands? An upstream node chooses a new or different gateway if it is 1 hop closer than the one it is currently using. > I guess that > borderline nodes have the ability to select gateway by themselves, but > that could potentially affect many downstream nodes that previously use= d > another prefix. A node could also cut off and isolate islands of nodes > if it chooses to change prefix/gateway. I think that depends on whether the network is using a reactive or proactive protocol. If a reactive protocol is used, the routing protocol is still responsisble for establishing a route to the gateway. In that case the downstream node would at least not be isolated, it can continue to use the old gateway. The question is whether the downstream have to configure a new address when the prefix announced by the upstream node changes. If that is the case, we might have some problems. As the network can be very mobile, borderline nodes receiveing announcements about two different gateways, from two different neighbors, might choose two to switch back forth between the two gateways. This easily happens when a node chooses a new gateway when it is 1 hop closer than its current one, and the network have mobility that causes frequent topology changes. > What are the convergence times > for situations like that? Is it desirable that borderline nodes could > have such a big effect on lots of downstream nodes? > I do not think the convergence time is that big, as nodes "almost immediately" rebroadcasts the message. Before updating it. However, if nodes have to configure a new address upon receipt of the announcement, the result can be very bad. I have simulated this, and it helps a lot if the condition to switch is increased to 2 hops, but that would of course create non optimal routes. I am not sure if the draft actually says that nodes should reconfigure a new address when your upstream tells you to. If that is so, I am not so sure that is a wise thing to do. Christophe, please correct me if anythin= g I say here is wrong. /Anders > //Erik > > On Wed, 2004-03-03 at 19:12, Christophe Jelger wrote: >> Erik, >> >> (please call me Christophe !) >> >> You are right when you say that a node within an "island" can't change >> its prefix. Our objective is to create these islands, so we don't real= ly >> want to see a node that breaks this organisation. ;-) >> >> I also agree with you that the tunnel-based solution is the best one i= n >> terms of control overhead (less control packets sent). I think our >> proposal has a completely different objective. The only point we try t= o >> defend is the concept of prefix continuity : this feature might be of >> real interest for operators who like to have a somehow organised >> network. This feature can also allow an operator to do some management >> control and stuff like that. >> >> Regards, >> Christophe >> >> PS : we do not implement a separate flooding mechanism, because this i= s >> not flooding !!! (I insist on that !) The information disseminates awa= y >> from gateways, it look like flooding but it's not ! ;-) >> >> Erik Nordstr=C3=B6m wrote: >> >> >Jelger, >> > >> >I admit that I am not that familiar with your proposal, and probably >> >should read it more carefully. However, there are some things I >> >question... >> > >> >For example, why implement a seperate flooding mechanism when this is >> >already provided by the routing protocol (for example OLSR)? You >> propose >> >to optionally integrate this with the routing protocol, but I do not >> see >> >how that is possible with MPR-based flooding? >> > >> >I am not convinced that you have maximum flexibility when building yo= ur >> >prefix islands of nodes. How can nodes part of a prefix island >> >individually choose another gateway? But, I admit, I need to study yo= ur >> >draft in more detail. >> > >> >With tunnels you can simply add a flag in ordinary control messages >> >announcing some nodes as gateways. Nodes can then individually choose= a >> >gateway and tunnel packets to it. The routing protocol takes care of >> the >> >rest transparently. This also works well with reactive protocols. >> > >> >/Erik >> > >> > >> >On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: >> > >> > >> >>Hi Erik, >> >> >> >>Well about handovers everything is in the draft, but I have to admit >> >>that it's not very clear sometimes. I hope to write a new version >> soon. >> >> >> >>To summarise : we propose different algorithms used by each ad hoc >> node >> >>to choose (and switch between) a gateway. It can either use the >> closest >> >>gateway (whatever prefix it uses), or a gateway that uses the same >> >>prefix than it currently uses (whatever the distance from the >> gateway). >> >>We also proposed slight variants. So first answer to your email is >> that >> >>switching between gateways is controled by each ad hoc node >> independently. >> >> >> >>Moreover, and because of our particular (but very simple) way of >> prefix >> >>propagation, we can guarantee that a default route is never diverted >> (in >> >>the steady-state). By steady-state, I mean that of course topologica= l >> >>changes can cause trouble during a very small amount of time. The ma= in >> >>idea behind our draft is prefix continuity : we "build" contiguous >> >>islands of nodes that share the same prefix/gateway. This can be of >> high >> >>interest for providers (e.g. management, services, ...). >> >> >> >>We have implemented our solution (IPv6) as an independent daemon and >> it >> >>works really well in the presence of multiple gateways and prefixes. >> We >> >>will soon integrate it in an IPv6 version of OLSR (Qolyester from LR= I >> in >> >>France). I am also finishing some simulations in which we evaluate o= ur >> >>solution : I hope I can submit the results for publication very soon. >> >> >> >>Well and before everybody says what's best and what's bad, I >> personally >> >>think it's very difficult at this stage to say so. If you have done >> some >> >>simulations of the tunnel approach you have probably seen that resul= ts >> >>can greatly vary across different simulation scenarios. I think all >> >>solutions have pros and cons, and we should be able to find the best >> >>parts of all solutions. >> >> >> >>Regards, >> >>Christophe >> >> >> >>Erik Nordstr=C3=B6m wrote: >> >> >> >> >> >> >> >>>Hi, >> >>> >> >>>I don't see how you can efficiently handle multiple gateways when >> using >> >>>default routes? Especially with reactive protocols that do not have= a >> >>>complete view of the network. Even if you maintain the gateway >> mapping, >> >>>how will you deal with hand-overs between gateways? You say that t= he >> >>>solution is to force nodes to use the "same" default route, but I d= o >> not >> >>>think that is a good idea. Individual nodes may know best when to >> switch >> >>>gateways, and they should be allowed to do so if they wish. How can >> you >> >>>guarantee that a default route is not diverted to another gateway a= t >> an >> >>>intermediate node if a packet carries no mapping between the (final= ) >> >>>destination and the gateway? How do you handle control packets (fro= m >> >>>different gateways) that want to change the default route --> gatew= ay >> >>>mapping? >> >>> >> >>>My experience with AODV-UU is that gateway tunneling has many >> properties >> >>>that are prefered in an ad hoc network. Tunnels easily support >> multiple >> >>>gateways and are transparent for intermediate nodes that forwards t= he >> >>>traffic to the gateway. I have a paper pending that clearly shows t= he >> >>>advantages of tunnels in this context. >> >>> >> >>>Before proceeding with a merged draft on Internet connectivity, I >> think >> >>>that the proposal should be backed up with serious research showing >> >>>problems or benefits of different strategies. I have implemented >> gateway >> >>>connectivity in AODV-UU, and my experience clearly points in the >> >>>direction of tunnels. >> >>> >> >>>Regards, >> >>> >> >>>Erik Nordstr=C3=B6m >> >>> >> >>> >> >>> >> >>>On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: >> >>> >> >>> >> >>> >> >>> >> >>>>Actually each node knows what gateway it uses because there is a >> special >> >>>>field in the packet used to disseminate the prefix information. Th= is >> >>>>field contains the IPv6 global address of the gateway (and another >> field >> >>>>gives the prefix length). Moreover, we "almost" don't need a routi= ng >> >>>>protocol (of course don't take this statement too strictly), in th= e >> >>>>sense that, when a node wants to send data to some node in the >> Internet, >> >>>>it only uses a default route with next hop being one of its >> neighbors. >> >>>>The ad hoc node does not even need to have a /128 route to the >> gateway. >> >>>>Of course on the reverse path this is not the same (i.e. the gatew= ay >> >>>>must have a /128 route to the ad hoc node). >> >>>> >> >>>>Christophe >> >>>> >> >>>>Anders Nilsson wrote: >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>>Hello again, >> >>>>> >> >>>>>Christophe Jelger wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>>>Of course as one of the authors of a solution that uses default >> route >> >>>>>>I don't agree with your statements. ;-) >> >>>>>> >> >>>>>>In our draft each MANET node knows which gateway it uses, and (i= n >> the >> >>>>>>steady-state) it knows that all nodes on the "default route" pat= h >> use >> >>>>>>the same gateway. With our solution gateways don't announce >> routes, >> >>>>>>they just announce prefixes. If two gateways announce the same >> >>>>>>prefix, an ad hoc node selects the closest gateway (it can be >> >>>>>>specified that it should from there use the same gateway). The >> >>>>>>propagation method used to propagate the prefix information >> ensures >> >>>>>>that the path to the gateway is made of nodes that also use the >> same >> >>>>>>gateway : there is no need of a routing header, and default rout= es >> >>>>>>can be used safely. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>That sounds like a good solution, but the node can't control what >> >>>>>gateway it is currently using. A scenario where this is neeed is >> when >> >>>>>the node is moving from gateway to gateway. The node is then unab= le >> to >> >>>>>know what gateway it is currently communicating through. A node >> need >> >>>>>to know this when it switches to a new gateway, and "registers" >> >>>>>itself. This reason why this needed is because packets from the >> >>>>>Internet needs to be routed to the correct gateway, which is >> difficult >> >>>>>when mobile nodes are unware of its gateway. If a Cellular IP typ= e >> of >> >>>>>solution is used, the routing entries in the access network are >> >>>>>updated by the actual packets flowing through the gateways. But >> there >> >>>>>is problems here as well, because oscillations easily occurs that >> >>>>>causes a lot of updates, especially when the mobile nodes are >> mobile. >> >>>>>I have simulated this, and it is harder to maintain than you migh= t >> >>>>>think. If you rely on proactive gateway discovery, the default >> routing >> >>>>>entries have to be maintained during link breaks and mobility, >> along >> >>>>>with sequence number maintainence. I have a paper about this, in = a >> >>>>>slightly different context, but during mobility and several hops = to >> >>>>>the gateway, more complex control is needed. >> >>>>> >> >>>>>regards, >> >>>>> >> >>>>>Anders >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>_______________________________________________ >> >>>>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 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 14:35:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20368 for ; Wed, 3 Mar 2004 14:35:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayc97-00030x-Pj for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 14:35:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23JZ9JJ011583 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 14:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayc97-00030k-K5 for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 14:35:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20338 for ; Wed, 3 Mar 2004 14:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayc95-0003hS-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 14:35:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayc8E-0003VO-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 14:34:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayc7O-0003JA-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 14:33:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayc73-0002ge-DJ; Wed, 03 Mar 2004 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayc6O-0002ex-62 for manet@optimus.ietf.org; Wed, 03 Mar 2004 14:32:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20103 for ; Wed, 3 Mar 2004 14:32:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayc6L-00035v-00 for manet@ietf.org; Wed, 03 Mar 2004 14:32:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayc5M-0002sC-00 for manet@ietf.org; Wed, 03 Mar 2004 14:31:17 -0500 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1Ayc4a-0002fJ-00 for manet@ietf.org; Wed, 03 Mar 2004 14:30:28 -0500 Received: from user-2ivfnta.dialup.mindspring.com ([165.247.223.170] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ayc4Q-0007eF-00; Wed, 03 Mar 2004 11:30:19 -0800 Message-ID: <40463249.3060100@earthlink.net> Date: Wed, 03 Mar 2004 11:30:17 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Christophe Jelger CC: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA20104 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Christophe Jelger wrote: > Erik, > > You are right ... sometimes a node cannot change its prefix unless its=20 > upstream neighbor chooses another one. This is what allows to have=20 > prefix continuity. We cannot have all nodes do whatever they want and=20 > guarantee the prefix continuity feature ... ;-) > > Again using MPR is not a problem ... there will be less flexibility=20 > and routes might not be "shortest path", but there is no reason why it=20 > should not work.=20 Routes *will* be the min-hop, since the gateway info message contains=20 the distance in hops to the gateway, so a node can always choose a neighbor with fewer hops=20 as the next hop to the gateway. But the MPR forwarding rule should be that a node=20 relays a gateway info message if the *next hop* is an MPR selector. Thus, the path to the=20 gateway will be a sequence of MPR selectors. Philippe, is this correct? Richard > > > And about prefix distribution : prefix distribution is limited "by=20 > nature", i.e. a node that is a the limit of two "islands" will not=20 > forward control packets received from the island it does not belong to. > > Christophe > > Erik Nordstr=C3=B6m wrote: > >> Maybe I am missing something (and please point it out), but will not t= he >> MPR flooding limit the distribution of (different) prefixes in the >> network? My concern is that a node far down the (MPR) distribution pat= h >> rooted at a gateway will not be able to change gateway/prefix unless i= ts >> upstream neighbor (closer to the gateway) also changes its prefix (of >> another gateway)? >> //Erik >> >> On Wed, 2004-03-03 at 16:52, Philippe Jacquet wrote: >> =20 >> >>> I don't see any problem with MPR flooding, when last hop is MPR=20 >>> selector >>> then it will be the upstream neighbor. >>> I think the algorithm could be an application of the recent MPRF=20 >>> draft with >>> the option TTL=3D1. >>> >>> Philippe >>> ----- Original Message ----- >>> From: Erik Nordstr=C3=B6m >>> To: Christophe Jelger >>> Cc: manet >>> Sent: Wednesday, March 03, 2004 3:13 PM >>> Subject: Re: [manet] Default Routes >>> >>> >>> Jelger, >>> >>> I admit that I am not that familiar with your proposal, and probably >>> should read it more carefully. However, there are some things I >>> question... >>> >>> For example, why implement a seperate flooding mechanism when this is >>> already provided by the routing protocol (for example OLSR)? You=20 >>> propose >>> to optionally integrate this with the routing protocol, but I do not=20 >>> see >>> how that is possible with MPR-based flooding? >>> >>> I am not convinced that you have maximum flexibility when building yo= ur >>> prefix islands of nodes. How can nodes part of a prefix island >>> individually choose another gateway? But, I admit, I need to study yo= ur >>> draft in more detail. >>> >>> With tunnels you can simply add a flag in ordinary control messages >>> announcing some nodes as gateways. Nodes can then individually choose= a >>> gateway and tunnel packets to it. The routing protocol takes care of=20 >>> the >>> rest transparently. This also works well with reactive protocols. >>> >>> /Erik >>> >>> >>> On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: >>> =20 >>> >>>> Hi Erik, >>>> >>>> Well about handovers everything is in the draft, but I have to admit >>>> that it's not very clear sometimes. I hope to write a new version=20 >>>> soon. >>>> >>>> To summarise : we propose different algorithms used by each ad hoc=20 >>>> node >>>> to choose (and switch between) a gateway. It can either use the=20 >>>> closest >>>> gateway (whatever prefix it uses), or a gateway that uses the same >>>> prefix than it currently uses (whatever the distance from the=20 >>>> gateway). >>>> We also proposed slight variants. So first answer to your email is=20 >>>> that >>>> switching between gateways is controled by each ad hoc node=20 >>>> independently. >>>> >>>> Moreover, and because of our particular (but very simple) way of=20 >>>> prefix >>>> propagation, we can guarantee that a default route is never=20 >>>> diverted (in >>>> the steady-state). By steady-state, I mean that of course topologica= l >>>> changes can cause trouble during a very small amount of time. The ma= in >>>> idea behind our draft is prefix continuity : we "build" contiguous >>>> islands of nodes that share the same prefix/gateway. This can be of=20 >>>> high >>>> interest for providers (e.g. management, services, ...). >>>> >>>> We have implemented our solution (IPv6) as an independent daemon=20 >>>> and it >>>> works really well in the presence of multiple gateways and=20 >>>> prefixes. We >>>> will soon integrate it in an IPv6 version of OLSR (Qolyester from=20 >>>> LRI in >>>> France). I am also finishing some simulations in which we evaluate o= ur >>>> solution : I hope I can submit the results for publication very soon. >>>> >>>> Well and before everybody says what's best and what's bad, I=20 >>>> personally >>>> think it's very difficult at this stage to say so. If you have done=20 >>>> some >>>> simulations of the tunnel approach you have probably seen that resul= ts >>>> can greatly vary across different simulation scenarios. I think all >>>> solutions have pros and cons, and we should be able to find the best >>>> parts of all solutions. >>>> >>>> Regards, >>>> Christophe >>>> >>>> Erik Nordstr=C3=B6m wrote: >>>> >>>> =20 >>>> >>>>> Hi, >>>>> >>>>> I don't see how you can efficiently handle multiple gateways when=20 >>>>> using >>>>> default routes? Especially with reactive protocols that do not have= a >>>>> complete view of the network. Even if you maintain the gateway=20 >>>>> mapping, >>>>> how will you deal with hand-overs between gateways? You say that t= he >>>>> solution is to force nodes to use the "same" default route, but I=20 >>>>> do not >>>>> think that is a good idea. Individual nodes may know best when to=20 >>>>> switch >>>>> gateways, and they should be allowed to do so if they wish. How=20 >>>>> can you >>>>> guarantee that a default route is not diverted to another gateway=20 >>>>> at an >>>>> intermediate node if a packet carries no mapping between the (final= ) >>>>> destination and the gateway? How do you handle control packets (fro= m >>>>> different gateways) that want to change the default route --> gatew= ay >>>>> mapping? >>>>> >>>>> My experience with AODV-UU is that gateway tunneling has many=20 >>>>> properties >>>>> that are prefered in an ad hoc network. Tunnels easily support=20 >>>>> multiple >>>>> gateways and are transparent for intermediate nodes that forwards t= he >>>>> traffic to the gateway. I have a paper pending that clearly shows t= he >>>>> advantages of tunnels in this context. >>>>> >>>>> Before proceeding with a merged draft on Internet connectivity, I=20 >>>>> think >>>>> that the proposal should be backed up with serious research showing >>>>> problems or benefits of different strategies. I have implemented=20 >>>>> gateway >>>>> connectivity in AODV-UU, and my experience clearly points in the >>>>> direction of tunnels. >>>>> >>>>> Regards, >>>>> >>>>> Erik Nordstr=C3=B6m >>>>> >>>>> >>>>> >>>>> On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: >>>>> >>>>> >>>>> =20 >>>>> >>>>>> Actually each node knows what gateway it uses because there is a=20 >>>>>> special >>>>>> field in the packet used to disseminate the prefix information. Th= is >>>>>> field contains the IPv6 global address of the gateway (and=20 >>>>>> another field >>>>>> gives the prefix length). Moreover, we "almost" don't need a routi= ng >>>>>> protocol (of course don't take this statement too strictly), in th= e >>>>>> sense that, when a node wants to send data to some node in the=20 >>>>>> Internet, >>>>>> it only uses a default route with next hop being one of its=20 >>>>>> neighbors. >>>>>> The ad hoc node does not even need to have a /128 route to the=20 >>>>>> gateway. >>>>>> Of course on the reverse path this is not the same (i.e. the gatew= ay >>>>>> must have a /128 route to the ad hoc node). >>>>>> >>>>>> Christophe >>>>>> >>>>>> Anders Nilsson wrote: >>>>>> >>>>>> >>>>>> >>>>>> =20 >>>>>> >>>>>>> Hello again, >>>>>>> >>>>>>> Christophe Jelger wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> =20 >>>>>>> >>>>>>>> Of course as one of the authors of a solution that uses default=20 >>>>>>>> route >>>>>>>> I don't agree with your statements. ;-) >>>>>>>> >>>>>>>> In our draft each MANET node knows which gateway it uses, and=20 >>>>>>>> (in the >>>>>>>> steady-state) it knows that all nodes on the "default route"=20 >>>>>>>> path use >>>>>>>> the same gateway. With our solution gateways don't announce=20 >>>>>>>> routes, >>>>>>>> they just announce prefixes. If two gateways announce the same >>>>>>>> prefix, an ad hoc node selects the closest gateway (it can be >>>>>>>> specified that it should from there use the same gateway). The >>>>>>>> propagation method used to propagate the prefix information=20 >>>>>>>> ensures >>>>>>>> that the path to the gateway is made of nodes that also use the=20 >>>>>>>> same >>>>>>>> gateway : there is no need of a routing header, and default rout= es >>>>>>>> can be used safely. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>>>> >>>>>>> That sounds like a good solution, but the node can't control what >>>>>>> gateway it is currently using. A scenario where this is neeed is=20 >>>>>>> when >>>>>>> the node is moving from gateway to gateway. The node is then=20 >>>>>>> unable to >>>>>>> know what gateway it is currently communicating through. A node=20 >>>>>>> need >>>>>>> to know this when it switches to a new gateway, and "registers" >>>>>>> itself. This reason why this needed is because packets from the >>>>>>> Internet needs to be routed to the correct gateway, which is=20 >>>>>>> difficult >>>>>>> when mobile nodes are unware of its gateway. If a Cellular IP=20 >>>>>>> type of >>>>>>> solution is used, the routing entries in the access network are >>>>>>> updated by the actual packets flowing through the gateways. But=20 >>>>>>> there >>>>>>> is problems here as well, because oscillations easily occurs that >>>>>>> causes a lot of updates, especially when the mobile nodes are=20 >>>>>>> mobile. >>>>>>> I have simulated this, and it is harder to maintain than you migh= t >>>>>>> think. If you rely on proactive gateway discovery, the default=20 >>>>>>> routing >>>>>>> entries have to be maintained during link breaks and mobility,=20 >>>>>>> along >>>>>>> with sequence number maintainence. I have a paper about this, in = a >>>>>>> slightly different context, but during mobility and several hops = to >>>>>>> the gateway, more complex control is needed. >>>>>>> >>>>>>> regards, >>>>>>> >>>>>>> Anders >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> =20 >>>>>> >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> >>>>>> =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 >>> >>> >>> _______________________________________________ >>> 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 >> =20 >> > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Mar 3 15:10:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23023 for ; Wed, 3 Mar 2004 15:10:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AychD-0004b8-NT for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 15:10:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23KAN4E017668 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 15:10:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AychD-0004at-Co for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 15:10:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22916 for ; Wed, 3 Mar 2004 15:10:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AychA-0002eo-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 15:10:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aycey-00021E-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 15:08:06 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayccs-0001M0-03 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 15:05:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AycQl-0004Yy-2V for manet-web-archive@ietf.org; Wed, 03 Mar 2004 14:53:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AycQP-0004ib-BE; Wed, 03 Mar 2004 14:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AycQ7-0004i2-KY for manet@optimus.ietf.org; Wed, 03 Mar 2004 14:52:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21460 for ; Wed, 3 Mar 2004 14:52:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AycQ4-0006yN-00 for manet@ietf.org; Wed, 03 Mar 2004 14:52:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AycP8-0006pb-00 for manet@ietf.org; Wed, 03 Mar 2004 14:51:43 -0500 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1AycOC-0006ci-00 for manet@ietf.org; Wed, 03 Mar 2004 14:50:44 -0500 Received: from user-2ivfnta.dialup.mindspring.com ([165.247.223.170] helo=earthlink.net) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AycO5-0003qq-00; Wed, 03 Mar 2004 11:50:38 -0800 Message-ID: <4046370C.1000309@earthlink.net> Date: Wed, 03 Mar 2004 11:50:36 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Philippe Jacquet CC: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <00c701c4014f$052b8980$1f175d80@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA21461 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I need to make a minor correction for my suggestion to work (i.e., to guarantee min-hop paths to the gateway). The next hop to the gateway must be selected uniquely among all neighbors that report the minimum number of hops to the gateway. One way to do this is to select the *first* neighbor that reported the gateway info with a given sequence number. However, as was discussed last week, this is a probem with the MPRF draft, since different nodes may not agree on which neighbor was the first one to transmit a given=20 packet. To fix this, a node should relay the gateway info message if the minimum ID neighbor that reports the minimum number of hops to the gateway is an MPR selector. Richard > Routes *will* be the min-hop, since the gateway info message contains=20 > the distance in hops > to the gateway, so a node can always choose a neighbor with fewer hops=20 > as the next hop > to the gateway. But the MPR forwarding rule should be that a node=20 > relays a gateway info > message if the *next hop* is an MPR selector. Thus, the path to the=20 > gateway will be > a sequence of MPR selectors. Philippe, is this correct? > > Richard Philippe Jacquet wrote: >Christophe, > >This is property of MPR flooding: the path may be shorter than with blin= d >flooding, of course not necessarily the shortest path since transmission= s >may be desequenced. > >Philippe >----- Original Message ----- >From: Christophe Jelger >To: manet >Sent: Wednesday, March 03, 2004 7:25 PM >Subject: Re: [manet] Default Routes > > >Erik, > >You are right ... sometimes a node cannot change its prefix unless its >upstream neighbor chooses another one. This is what allows to have >prefix continuity. We cannot have all nodes do whatever they want and >guarantee the prefix continuity feature ... ;-) > >Again using MPR is not a problem ... there will be less flexibility and >routes might not be "shortest path", but there is no reason why it >should not work. > >And about prefix distribution : prefix distribution is limited "by >nature", i.e. a node that is a the limit of two "islands" will not >forward control packets received from the island it does not belong to. > >Christophe > >Erik Nordstr=C3=B6m wrote: > >>Maybe I am missing something (and please point it out), but will not th= e >>MPR flooding limit the distribution of (different) prefixes in the >>network? My concern is that a node far down the (MPR) distribution path >>rooted at a gateway will not be able to change gateway/prefix unless it= s >>upstream neighbor (closer to the gateway) also changes its prefix (of >>another gateway)? >> >>//Erik >> >>On Wed, 2004-03-03 at 16:52, Philippe Jacquet wrote: >> >> >>>I don't see any problem with MPR flooding, when last hop is MPR select= or >>>then it will be the upstream neighbor. >>>I think the algorithm could be an application of the recent MPRF draft >>> >with > >>>the option TTL=3D1. >>> >>>Philippe >>>----- Original Message ----- >>>From: Erik Nordstr=C3=B6m >>>To: Christophe Jelger >>>Cc: manet >>>Sent: Wednesday, March 03, 2004 3:13 PM >>>Subject: Re: [manet] Default Routes >>> >>> >>>Jelger, >>> >>>I admit that I am not that familiar with your proposal, and probably >>>should read it more carefully. However, there are some things I >>>question... >>> >>>For example, why implement a seperate flooding mechanism when this is >>>already provided by the routing protocol (for example OLSR)? You propo= se >>>to optionally integrate this with the routing protocol, but I do not s= ee >>>how that is possible with MPR-based flooding? >>> >>>I am not convinced that you have maximum flexibility when building you= r >>>prefix islands of nodes. How can nodes part of a prefix island >>>individually choose another gateway? But, I admit, I need to study you= r >>>draft in more detail. >>> >>>With tunnels you can simply add a flag in ordinary control messages >>>announcing some nodes as gateways. Nodes can then individually choose = a >>>gateway and tunnel packets to it. The routing protocol takes care of t= he >>>rest transparently. This also works well with reactive protocols. >>> >>>/Erik >>> >>> >>>On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: >>> >>> >>>>Hi Erik, >>>> >>>>Well about handovers everything is in the draft, but I have to admit >>>>that it's not very clear sometimes. I hope to write a new version soo= n. >>>> >>>>To summarise : we propose different algorithms used by each ad hoc no= de >>>>to choose (and switch between) a gateway. It can either use the close= st >>>>gateway (whatever prefix it uses), or a gateway that uses the same >>>>prefix than it currently uses (whatever the distance from the gateway= ). >>>>We also proposed slight variants. So first answer to your email is th= at >>>>switching between gateways is controled by each ad hoc node >>>> >independently. > >>>>Moreover, and because of our particular (but very simple) way of pref= ix >>>>propagation, we can guarantee that a default route is never diverted = (in >>>>the steady-state). By steady-state, I mean that of course topological >>>>changes can cause trouble during a very small amount of time. The mai= n >>>>idea behind our draft is prefix continuity : we "build" contiguous >>>>islands of nodes that share the same prefix/gateway. This can be of h= igh >>>>interest for providers (e.g. management, services, ...). >>>> >>>>We have implemented our solution (IPv6) as an independent daemon and = it >>>>works really well in the presence of multiple gateways and prefixes. = We >>>>will soon integrate it in an IPv6 version of OLSR (Qolyester from LRI= in >>>>France). I am also finishing some simulations in which we evaluate ou= r >>>>solution : I hope I can submit the results for publication very soon. >>>> >>>>Well and before everybody says what's best and what's bad, I personal= ly >>>>think it's very difficult at this stage to say so. If you have done s= ome >>>>simulations of the tunnel approach you have probably seen that result= s >>>>can greatly vary across different simulation scenarios. I think all >>>>solutions have pros and cons, and we should be able to find the best >>>>parts of all solutions. >>>> >>>>Regards, >>>>Christophe >>>> >>>>Erik Nordstr=C3=B6m wrote: >>>> >>>> >>>> >>>>>Hi, >>>>> >>>>>I don't see how you can efficiently handle multiple gateways when us= ing >>>>>default routes? Especially with reactive protocols that do not have = a >>>>>complete view of the network. Even if you maintain the gateway mappi= ng, >>>>>how will you deal with hand-overs between gateways? You say that th= e >>>>>solution is to force nodes to use the "same" default route, but I do= not >>>>>think that is a good idea. Individual nodes may know best when to sw= itch >>>>>gateways, and they should be allowed to do so if they wish. How can = you >>>>>guarantee that a default route is not diverted to another gateway at= an >>>>>intermediate node if a packet carries no mapping between the (final) >>>>>destination and the gateway? How do you handle control packets (from >>>>>different gateways) that want to change the default route --> gatewa= y >>>>>mapping? >>>>> >>>>>My experience with AODV-UU is that gateway tunneling has many proper= ties >>>>>that are prefered in an ad hoc network. Tunnels easily support multi= ple >>>>>gateways and are transparent for intermediate nodes that forwards th= e >>>>>traffic to the gateway. I have a paper pending that clearly shows th= e >>>>>advantages of tunnels in this context. >>>>> >>>>>Before proceeding with a merged draft on Internet connectivity, I th= ink >>>>>that the proposal should be backed up with serious research showing >>>>>problems or benefits of different strategies. I have implemented gat= eway >>>>>connectivity in AODV-UU, and my experience clearly points in the >>>>>direction of tunnels. >>>>> >>>>>Regards, >>>>> >>>>>Erik Nordstr=C3=B6m >>>>> >>>>> >>>>> >>>>>On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Actually each node knows what gateway it uses because there is a >>>>>> >special > >>>>>>field in the packet used to disseminate the prefix information. Thi= s >>>>>>field contains the IPv6 global address of the gateway (and another >>>>>> >field > >>>>>>gives the prefix length). Moreover, we "almost" don't need a routin= g >>>>>>protocol (of course don't take this statement too strictly), in the >>>>>>sense that, when a node wants to send data to some node in the >>>>>> >Internet, > >>>>>>it only uses a default route with next hop being one of its neighbo= rs. >>>>>>The ad hoc node does not even need to have a /128 route to the gate= way. >>>>>>Of course on the reverse path this is not the same (i.e. the gatewa= y >>>>>>must have a /128 route to the ad hoc node). >>>>>> >>>>>>Christophe >>>>>> >>>>>>Anders Nilsson wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hello again, >>>>>>> >>>>>>>Christophe Jelger wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Of course as one of the authors of a solution that uses default r= oute >>>>>>>>I don't agree with your statements. ;-) >>>>>>>> >>>>>>>>In our draft each MANET node knows which gateway it uses, and (in= the >>>>>>>>steady-state) it knows that all nodes on the "default route" path= use >>>>>>>>the same gateway. With our solution gateways don't announce route= s, >>>>>>>>they just announce prefixes. If two gateways announce the same >>>>>>>>prefix, an ad hoc node selects the closest gateway (it can be >>>>>>>>specified that it should from there use the same gateway). The >>>>>>>>propagation method used to propagate the prefix information ensur= es >>>>>>>>that the path to the gateway is made of nodes that also use the s= ame >>>>>>>>gateway : there is no need of a routing header, and default route= s >>>>>>>>can be used safely. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>That sounds like a good solution, but the node can't control what >>>>>>>gateway it is currently using. A scenario where this is neeed is w= hen >>>>>>>the node is moving from gateway to gateway. The node is then unabl= e to >>>>>>>know what gateway it is currently communicating through. A node ne= ed >>>>>>>to know this when it switches to a new gateway, and "registers" >>>>>>>itself. This reason why this needed is because packets from the >>>>>>>Internet needs to be routed to the correct gateway, which is diffi= cult >>>>>>>when mobile nodes are unware of its gateway. If a Cellular IP type= of >>>>>>>solution is used, the routing entries in the access network are >>>>>>>updated by the actual packets flowing through the gateways. But th= ere >>>>>>>is problems here as well, because oscillations easily occurs that >>>>>>>causes a lot of updates, especially when the mobile nodes are mobi= le. >>>>>>>I have simulated this, and it is harder to maintain than you might >>>>>>>think. If you rely on proactive gateway discovery, the default rou= ting >>>>>>>entries have to be maintained during link breaks and mobility, alo= ng >>>>>>>with sequence number maintainence. I have a paper about this, in a >>>>>>>slightly different context, but during mobility and several hops t= o >>>>>>>the gateway, more complex control is needed. >>>>>>> >>>>>>>regards, >>>>>>> >>>>>>>Anders >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>_______________________________________________ >>>>>>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 >>> >>> >> >>_______________________________________________ >>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 exim@www1.ietf.org Wed Mar 3 16:15:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26740 for ; Wed, 3 Mar 2004 16:15:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AydhX-0003ck-Lp for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 16:14:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23LElBb013922 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 16:14:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AydhX-0003cT-GZ for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 16:14:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26731 for ; Wed, 3 Mar 2004 16:14:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AydhV-0006XG-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 16:14:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aydgd-0006Ol-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 16:13:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aydg1-0006G8-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 16:13:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aydfq-0003HO-BV; Wed, 03 Mar 2004 16:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aydfc-0003Ga-Cz for manet@optimus.ietf.org; Wed, 03 Mar 2004 16:12:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26677 for ; Wed, 3 Mar 2004 16:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aydfa-0006ES-00 for manet@ietf.org; Wed, 03 Mar 2004 16:12:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aydel-000666-00 for manet@ietf.org; Wed, 03 Mar 2004 16:11:55 -0500 Received: from mx.laposte.net ([81.255.54.11]) by ietf-mx with esmtp (Exim 4.12) id 1AydeN-0005xG-00 for manet@ietf.org; Wed, 03 Mar 2004 16:11:31 -0500 Received: from loria.fr (82.67.42.119) by mx.laposte.net (7.0.024) (authenticated as fleury.fleury) id 4036D31A003DC13F; Wed, 3 Mar 2004 22:10:56 +0100 Message-ID: <404649D3.1050208@loria.fr> Date: Wed, 03 Mar 2004 22:10:43 +0100 From: Eric Fleury ARES--INRIA Organization: ARES - CITI / INSA de Lyon User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Jelger CC: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> In-Reply-To: <40462332.9020908@dpt-info.u-strasbg.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Christophe Jelger wrote: > Again using MPR is not a problem ... there will be less flexibility and > routes might not be "shortest path", but there is no reason why it > should not work. I think that the great property inside OLSR is that MPR offers shortest path as opposed to a of pure flooding process that may generate non optimal routes... but my point is not to enter in this polemical details right know. I do not really understand the aim of this debate since each one tries to push one solution with a implementation point of view. I'll prefer to try to model / formalize the problem and try to design general classes of solutions but without all implementation constrains in a first time. Some works do exist on proactive/reactive compromise for routing. I'm sure that we can also have and show the same behavior on GW discovery processes. Trying to maintain contiguous areas is a potential candidate but the argument to support such proposal should not be "it avoids to set up source routing which is hardest to setup on current kernel...". Note that IP was modified to support multicast (-; This discussion on GW discovery appeared several months/years ago in the MANET mailing list and in fine, one conclusion was that we need a more general service discovery protocol. More precisely, trying to focus only on prefix delegation and developing a independent protocol is a so so answer since it will always be redundant with the underlying routing protocol used (cf OLSR flooding discussion!). Thus either we try to set up a more generic discovery protocol and a GW/prefix is one service (and we can try to compare here large classes of philosophies : pro actively announce services, reactively reclaim services...) or we can try to develop MANET routing protocol extension in order to corporate prefix delegation. IN OLSR, using MPRs + TC packets will be more efficient than re designing a flooding like prefix delegation... I'm ok to set up the skeleton of an initial draft requirement for a generic service discovery (even if I do not like this term of service since it is used 1000 times in several contexts...) Regards Eric _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 16:50:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28531 for ; Wed, 3 Mar 2004 16:50:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeFk-0006F7-3A for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 16:50:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23Lo8Dc023993 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 16:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeFj-0006Eu-Tq for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 16:50:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28508 for ; Wed, 3 Mar 2004 16:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyeFh-00053s-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 16:50:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyeEg-0004rZ-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 16:49:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyeDu-0004gh-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 16:48:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeDi-0005rn-5W; Wed, 03 Mar 2004 16:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyeDS-0005qy-En for manet@optimus.ietf.org; Wed, 03 Mar 2004 16:47:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28396 for ; Wed, 3 Mar 2004 16:47:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyeDQ-0004ct-00 for manet@ietf.org; Wed, 03 Mar 2004 16:47:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyeCR-0004R8-00 for manet@ietf.org; Wed, 03 Mar 2004 16:46:44 -0500 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1AyeBT-0004CX-00 for manet@ietf.org; Wed, 03 Mar 2004 16:45:43 -0500 Received: from user-2ivfnta.dialup.mindspring.com ([165.247.223.170] helo=earthlink.net) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AyeBR-0001hQ-00 for manet@ietf.org; Wed, 03 Mar 2004 13:45:42 -0800 Message-ID: <40465203.6020407@earthlink.net> Date: Wed, 03 Mar 2004 13:45:39 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Eric Fleury wrote: > This discussion on GW discovery appeared several months/years ago in > the MANET mailing list and in fine, one conclusion was that we need a > more general service discovery protocol. More precisely, trying to > focus only on prefix delegation and developing a independent protocol > is a so so answer since it will always be redundant with the > underlying routing protocol used (cf OLSR flooding discussion!). > > Thus either we try to set up a more generic discovery protocol and a > GW/prefix is one service (and we can try to compare here large classes > of philosophies : pro actively announce services, reactively reclaim > services...) or we can try to develop MANET routing protocol extension > in order to corporate prefix delegation. IN OLSR, using MPRs + TC > packets will be more efficient than re designing a flooding like > prefix delegation... I agree with your point that it is redundant to have a separate protocol to advertise gateways (which is really a distance-vector routing protocol), when gateway information can and should be provided by the underlying routing protocol (without promoting a particular routing protocol at this time). In fact, I made a similar point last September, which I will repeat here: On 22 July 2002 Guillaume Chelius wrote: > My opinion is that we should not split the gateway advertisement mechanism from > the routing protocol. It is the protocol responsability to propose a mechanism > which allows a node to discover gateways and to manage routes between nodes to > gateways. I completely agree with this. For example, assuming that a proactive routing protocol is used, there is no need to introduce a DSDV-like mechanism to provide gateway information to the manet nodes, when the routing protocol can provide this information to the manet nodes. If prefix continuity is desired, the routing protocol can be modified to achieve this (e.g., by computing a source tree for each known prefix). Similarly, a multi-hop extension of NDP as described in draft-wakikawa-manet-globalv6-02.txt should not be necessary since the routing protocol can and should provide the required information to the manet nodes in a timely, efficient manner. (If it doesn't, then the routing protocol needs to be improved.) The only reason to have a separate mechanism to advertise gateway information is if one wanted to do this proactively, even though the underlying routing protocol is reactive. In this case, I think that either (a) the separate mechanism would be used ONLY with the reactive protocol, or (b) the mechanism would really be a reduced version of the proactive protocol, which maintains routes only to and from each gateway. Regards, Richard _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 17:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00373 for ; Wed, 3 Mar 2004 17:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayelc-0000Pi-NS for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 17:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23MN4bf001584 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 17:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayelc-0000PT-IG for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 17:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00350 for ; Wed, 3 Mar 2004 17:23:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayela-0003J3-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 17:23:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayekd-00037o-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 17:22:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayejo-0002wv-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 17:21:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayejg-0008Vr-6i; Wed, 03 Mar 2004 17:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyejW-0008Uo-7g for manet@optimus.ietf.org; Wed, 03 Mar 2004 17:20:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00258 for ; Wed, 3 Mar 2004 17:20:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyejT-0002uv-00 for manet@ietf.org; Wed, 03 Mar 2004 17:20:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyeiX-0002kG-00 for manet@ietf.org; Wed, 03 Mar 2004 17:19:54 -0500 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1Ayehh-0002Pg-00 for manet@ietf.org; Wed, 03 Mar 2004 17:19:01 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F2B76FA639; Wed, 3 Mar 2004 23:18:30 +0100 (CET) Received: from correo.um.es (zape.um.es [155.54.212.102]) by smtp.um.es (Postfix) with ESMTP id D570BFA62F; Wed, 3 Mar 2004 23:18:30 +0100 (CET) Received: from correo.um.es (myotis.um.es [155.54.212.92]) by localhost (Postfix) with ESMTP id 3A83918EA3; Wed, 3 Mar 2004 23:18:11 +0100 (MET) Received: from dif.um.es (dibulibu.um.es [155.54.1.250]) by correo.um.es (Postfix) with ESMTP id ECBE018F47; Wed, 3 Mar 2004 23:08:38 +0100 (MET) Message-ID: <404654E0.3070007@dif.um.es> Date: Wed, 03 Mar 2004 22:57:52 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Fleury ARES--INRIA Cc: Christophe Jelger , manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> In-Reply-To: <404649D3.1050208@loria.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, > I do not really understand the aim of this debate since each one tries > to push one solution with a implementation point of view. > I'll prefer to try to model / formalize the problem and try to design > general classes of solutions but without all implementation > constrains in a first time. Some works do exist on > proactive/reactive compromise for routing. I'm sure that we can also > have and show the same behavior on GW discovery processes. I think this evidences once more the need for an WG-agreed requirements document. I think this is somethink we need to start working on as a WG. Comparing the prefix continuity approach against the tunnelling approaches does not make any sense if we do not agree firstly on what are our requirements. For example, in an "opperator centric" approach, prefix continuity would be very interesting. Is that one of our requirements?. I think those are the things we have to state in such a document. As I mentioned some e-mails ago, I'd be willing work on such a draft. But, it needs definetly to be agreed within the WG. > Thus either we try to set up a more generic discovery protocol and a > GW/prefix is one service (and we can try to compare here large classes > of philosophies : pro actively announce services, reactively reclaim > services...) or we can try to develop MANET routing protocol extension > in order to corporate prefix delegation. IN OLSR, using MPRs + TC > packets will be more efficient than re designing a flooding like > prefix delegation... I also think that Internet conectivity is a basic service to discover inside a MANET. In fact, a prefix does not convey enough information about the network to which the GW is connected. Should GW provide further information, MANET nodes can take more intelligent decissions. However, I think that working towards a general service discovery could actually add much more complexity. I think we can concentrate at the moment on Internet connectivity whereas this general service discovery (including Internet) may fall into the ANS charter?? In any case, I have no objection if the WG dicides to go that way. Regards, Pedro _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 17:50:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02649 for ; Wed, 3 Mar 2004 17:50:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfBq-0002i3-R1 for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 17:50:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23MoAQq010399 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 17:50:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfBq-0002hX-LQ for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 17:50:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02618 for ; Wed, 3 Mar 2004 17:50:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyfBn-00019l-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 17:50:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyfAw-0000yV-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 17:49:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyfA8-0000mX-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 17:48:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayf9m-0002Ju-NR; Wed, 03 Mar 2004 17:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayf8n-0002H8-Bb for manet@optimus.ietf.org; Wed, 03 Mar 2004 17:47:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02341 for ; Wed, 3 Mar 2004 17:46:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayf8k-0000UI-00 for manet@ietf.org; Wed, 03 Mar 2004 17:46:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayf7r-0000FK-00 for manet@ietf.org; Wed, 03 Mar 2004 17:46:04 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx with esmtp (Exim 4.12) id 1Ayf6V-0007T4-00 for manet@ietf.org; Wed, 03 Mar 2004 17:44:39 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id i23Mi2s3011720; Wed, 3 Mar 2004 17:44:02 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.3.37) with SMTP id M2004030317440103238 ; Wed, 03 Mar 2004 17:44:01 -0500 Message-Id: <6.0.3.0.2.20040303173506.02a99ec0@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 03 Mar 2004 17:44:19 -0500 To: Richard Ogier , manet From: Joe Macker Subject: Re: [manet] Default Routes In-Reply-To: <40465203.6020407@earthlink.net> References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 07:54 PM 3/3/2004, Richard Ogier wrote: >Eric Fleury wrote: > >>This discussion on GW discovery appeared several months/years ago in the MANET mailing list and in fine, one conclusion was that we need a more general service discovery protocol. More precisely, trying to focus only on prefix delegation and developing a independent protocol is a so so answer since it will always be redundant with the underlying routing protocol used (cf OLSR flooding discussion!). >> >>Thus either we try to set up a more generic discovery protocol and a GW/prefix is one service (and we can try to compare here large classes of philosophies : pro actively announce services, reactively reclaim services...) or we can try to develop MANET routing protocol extension in order to corporate prefix delegation. IN OLSR, using MPRs + TC packets will be more efficient than re designing a flooding like prefix delegation... > > >I agree with your point that it is redundant to have a separate protocol >to advertise gateways (which is really a distance-vector routing protocol), >when gateway information can and should be provided by the underlying >routing protocol (without promoting a particular routing protocol at this time). > >In fact, I made a similar point last September, which I will repeat here: > >On 22 July 2002 Guillaume Chelius wrote: > >> My opinion is that we should not split the gateway advertisement mechanism from >> the routing protocol. It is the protocol responsability to propose a mechanism >> which allows a node to discover gateways and to manage routes between nodes to >> gateways. > >I completely agree with this. For example, assuming that a proactive >routing protocol is used, there is no need to introduce a DSDV-like >mechanism to provide gateway information to the manet nodes, when the >routing protocol can provide this information to the manet nodes. If prefix continuity is desired, the routing protocol can be modified to >achieve this (e.g., by computing a source tree for each known prefix). > >Similarly, a multi-hop extension of NDP as described in >draft-wakikawa-manet-globalv6-02.txt should not be necessary since the >routing protocol can and should provide the required information to the >manet nodes in a timely, efficient manner. (If it doesn't, then the routing protocol needs to be improved.) > >The only reason to have a separate mechanism to advertise gateway >information is if one wanted to do this proactively, even though the >underlying routing protocol is reactive. In this case, I think that >either > >(a) the separate mechanism would be used ONLY with the reactive protocol, or > >(b) the mechanism would really be a reduced version of the proactive > protocol, which maintains routes only to and from each gateway. I agree with this also. Gateway advertisement has been straightforward for the proactive routing approaches. This is applied in practice today. A problem statement should not require a separate mechanism for that case. -Joe >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 exim@www1.ietf.org Wed Mar 3 18:00:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03186 for ; Wed, 3 Mar 2004 18:00:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfLQ-0003uC-JB for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 18:00:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23N048R015005 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 18:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfLP-0003tv-Gl for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 18:00:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03131 for ; Wed, 3 Mar 2004 17:59:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyfLM-0002oU-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 18:00:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyfKM-0002e3-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 17:58:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyfJl-0002Ua-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 17:58:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfJR-0003NH-Ib; Wed, 03 Mar 2004 17:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfJG-0003Md-GR for manet@optimus.ietf.org; Wed, 03 Mar 2004 17:57:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03049 for ; Wed, 3 Mar 2004 17:57:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyfJD-0002T6-00 for manet@ietf.org; Wed, 03 Mar 2004 17:57:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyfIH-0002Jg-00 for manet@ietf.org; Wed, 03 Mar 2004 17:56:49 -0500 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1AyfHL-00021c-00 for manet@ietf.org; Wed, 03 Mar 2004 17:55:52 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 1420CFA619; Wed, 3 Mar 2004 23:55:21 +0100 (CET) Received: from correo.um.es (zape.um.es [155.54.212.102]) by smtp.um.es (Postfix) with ESMTP id EEE04FA554; Wed, 3 Mar 2004 23:55:20 +0100 (CET) Received: from correo.um.es (myotis.um.es [155.54.212.92]) by localhost (Postfix) with ESMTP id 57FF818E1B; Wed, 3 Mar 2004 23:55:20 +0100 (MET) Received: from dif.um.es (dibulibu.um.es [155.54.1.250]) by correo.um.es (Postfix) with ESMTP id 8022A18E0A; Wed, 3 Mar 2004 23:55:12 +0100 (MET) Message-ID: <40465FCA.2080105@dif.um.es> Date: Wed, 03 Mar 2004 23:44:26 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Macker Cc: Richard Ogier , manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <6.0.3.0.2.20040303173506.02a99ec0@pop.itd.nrl.navy.mil> In-Reply-To: <6.0.3.0.2.20040303173506.02a99ec0@pop.itd.nrl.navy.mil> Content-Type: text/html; 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY,MIME_HTML_ONLY autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe Macker wrote:
At 07:54 PM 3/3/2004, Richard Ogier wrote:
  
Eric Fleury wrote:

    
This discussion on GW discovery appeared several months/years ago in the MANET mailing list and in fine, one conclusion was that we need a more general service discovery protocol. More precisely, trying to focus only on prefix delegation and developing a independent protocol is a so so answer since it will always be redundant with the underlying routing protocol used (cf OLSR flooding discussion!).

Thus either we try to set up a more generic discovery protocol and a GW/prefix is one service (and we can try to compare here large classes of philosophies : pro actively announce services, reactively reclaim services...) or we can try to develop MANET routing protocol extension in order to corporate prefix delegation. IN OLSR, using MPRs + TC packets will be more efficient than re designing a flooding like prefix delegation...
      
I agree with your point that it is redundant to have a separate protocol
to advertise gateways (which is really a distance-vector routing protocol),
when gateway information can and should be provided by the underlying
routing protocol (without promoting a particular routing protocol at this time).

In fact, I made a similar point last September, which I will repeat here:

On 22 July 2002 Guillaume Chelius wrote:

    
My opinion is that we should not split the gateway advertisement mechanism from
the routing protocol. It is the protocol responsability to propose a mechanism
which allows a node to discover gateways and to manage routes between nodes to
gateways.
      
I completely agree with this. For example, assuming that a proactive
routing protocol is used, there is no need to introduce a DSDV-like
mechanism to provide gateway information to the manet nodes, when the
routing protocol can provide this information to the manet nodes. If prefix continuity is desired, the routing protocol can be modified to
achieve this (e.g., by computing a source tree for each known prefix).

Similarly, a multi-hop extension of NDP as described in
draft-wakikawa-manet-globalv6-02.txt should not be necessary since the
routing protocol can and should provide the required information to the
manet nodes in a timely, efficient manner. (If it doesn't, then the routing protocol needs to be improved.)

The only reason to have a separate mechanism to advertise gateway
information is if one wanted to do this proactively, even though the
underlying routing protocol is reactive. In this case, I think that
either

(a) the separate mechanism would be used ONLY with the reactive protocol, or

(b) the mechanism would really be a reduced version of the proactive
  protocol, which maintains routes only to and from each gateway. 
    

I agree with this also.
Gateway advertisement has been straightforward for the proactive routing approaches.
This is applied in practice today.

A problem statement should not require a separate mechanism for that case.
I tend to agree with both of you. But I would also consider the to extend a reactive protocol with a proactive gateway discovery mechanism. So, you can call this enhanced protocol to be hybrid. But I think there is no point in having the mechanism separate from the routing protocol.

However, I think is a good practice to focus now on defining such a mechanism regardless of the routing protocol, and then try to incorporate the agreed mechanism into any of the MANET routing protocols (either proactive or reactive).

Regards, Pedro
 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 19:13:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08996 for ; Wed, 3 Mar 2004 19:13:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygUG-0008Mb-6s for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 19:13:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240DG28032145 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 19:13:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygUG-0008MO-1c for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:13:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08900 for ; Wed, 3 Mar 2004 19:13:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygUE-0000xp-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 19:13:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygT7-0000gg-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 19:12:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AygSC-0000Pm-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 19:11:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygS6-0007sc-Ry; Wed, 03 Mar 2004 19:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygRs-0007ps-D3 for manet@optimus.ietf.org; Wed, 03 Mar 2004 19:10:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08508 for ; Wed, 3 Mar 2004 19:10:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygRp-0000E0-00 for manet@ietf.org; Wed, 03 Mar 2004 19:10:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygQF-0007h6-00 for manet@ietf.org; Wed, 03 Mar 2004 19:09:08 -0500 Received: from dcs-server2.cs.uiuc.edu ([128.174.252.3]) by ietf-mx with esmtp (Exim 4.12) id 1AygPX-0007WQ-00 for manet@ietf.org; Wed, 03 Mar 2004 19:08:23 -0500 Received: from brooklyn (brooklyn.cs.uiuc.edu [128.174.244.80]) (authenticated bits=0) by dcs-server2.cs.uiuc.edu (8.12.10/8.12.10) with ESMTP id i2408BW8026563 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 3 Mar 2004 18:08:18 -0600 (CST) From: "Robin Kravets" To: Date: Wed, 3 Mar 2004 18:07:51 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [manet] ACM MobiCom 2004 CFP - Paper registrations due March 8 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- =20 CALL FOR PAPERS =20 MobiCom 2004 The Tenth Annual International Conference on Mobile Computing and Networking =20 September 26 - October 1, 2004 Philadelphia, PA, USA (dates and location are subject to final approval) http://www.sigmobile.org/mobicom/2004/ Sponsored by ACM SIGMOBILE IMPORTANT DATES: Paper registrations due: March 8, 2004 Paper submissions due: March 15, 2004 Notification of acceptance: June 21, 2004 Camera-ready versions due: July 25, 2004 =20 ACM MobiCom 2004, the Tenth Annual International Conference on Mobile Computing and Networking, is the tenth in the series of annual = conferences sponsored by ACM SIGMOBILE and dedicated to addressing the challenges in = the areas of mobile computing and wireless and mobile networking. The = MobiCom conference series serves as the premier international forum addressing networks, systems, algorithms, and applications that support the = symbiosis of mobile computers and wireless networks. MobiCom is a highly = selective, single-track conference focusing on all issues in mobile computing and wireless and mobile networking at the link layer and above. =20 PAPERS: Authors are invited to submit full papers presenting new = research related to the theory or practice of mobile computing and networking. = All submissions must describe original research that is not published or currently under review by another conference or journal. Areas of = interest include, but are not limited to: - Applications and computing services supporting mobile users - Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity - Database and data management issues in mobile computing - Operating system and middleware support for mobile computing and=20 networking - Distributed systems aspects of mobile computing - New mobile and wireless applications - Integration and interworking of wired and wireless networks=09 - Performance of mobile and wireless networks and systems=20 - Location-dependent applications and protocols - Security and privacy of mobile/wireless systems - Mobile ad hoc and sensor networks - Wireless multimedia systems - Algorithms and protocols for power management and control - Service creation and management environments for mobile/wireless systems =20 The program committee will referee all papers, and accepted papers will = be published in the conference proceedings. Selected papers will appear in = a special issue of the ACM/Kluwer Wireless Networks (WINET) journal. =20 CHALLENGES PAPERS: The conference also solicits short papers (maximum of = 8 pages) that challenge the mobile computing community with revolutionary = new approaches, new technologies, or visionary applications. Such papers = should provide stimulating ideas or grand visions that may open up exciting = avenues of far-reaching future research. Descriptions of new products or simple evolution of existing work are not appropriate as Challenges Papers. Challenges Papers will be reviewed and should be submitted using the = normal submission procedure. The title of such papers must start with the word "Challenges," i.e., "Challenges: ... `rest of the title'." =20 SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PDF or a PostScript version of their full paper. Papers must be no longer than 15 pages (8 pages for Challenges submissions), font size not smaller than 10 points, and must = fit properly on U.S. "letter"-sized paper (8.5x11 inches) with reasonable margins. Detailed instructions for the paper submission procedure and = format will be available on the conference web pages. The deadline for = registering the title and the abstract of the paper with our electronic submission system is March 8, 2004 and the deadline for submitting the actual paper = is March 15, 2004. All deadlines are 11:59PM EST. All submitted papers will be judged based on their quality through double-blind review process, where the identities of the authors are withheld from the reviewers. Authors should not be identifiable by any = means from the paper or from the PDF or the Postscript file. Guidelines for preparing the paper for blind reviewing, as well as electronic paper submission instructions, will be available on the conference web pages. Submitted or substantially similar papers must not be currently under = review for any other publication. Please direct any questions regarding paper submission to the Program Co-Chairs, Samir Das and Ravi Jain at mobicom_pcchairs@acm.org. =20 TUTORIALS: Proposals for tutorials are solicited. Evaluation of tutorial proposals will be based on the expertise and experience of the = instructors and on the relevance of the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Co-Chairs, Andrew Campbell (campbell@ee.columbia.edu) and Taieb Znati (tznati@nsf.gov). The = deadline for tutorial proposals is April 05, 2004. =20 PANELS: Panel proposals are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel = proposals should not exceed 3 pages, including biographical sketches of the = panelists. Potential panel organizers should contact the Panel Co-Chairs, Prathima Agrawal (pagrawal@eng.auburn.edu) and Tao Zhang (tao@research.telcordia.com). The deadline for panel proposals is April = 26, 2004. =20 RESEARCH DEMOS AND EXHIBITS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of = the demo and equipment to be used. Send proposals to the Research Demo = Chair, Elizabeth Belding-Royer (ebelding@cs.ucsb.edu). The deadline for demo proposals is July 12, 2004. We are also planning an Expo featuring = exhibits of the latest mobile computing products and services. STUDENT POSTER SESSION: Student posters are solicited that present = recent and on-going research by students on mobile computing and mobile and wireless networking topics. Student posters should not exceed 2 pages = and should include a description of the student's research. See above for = paper formatting requirements. Accepted posters will be put on the conference = web page; however, they will not be printed in the conference proceedings. = Send poster submissions to the Student Poster Co-Chairs, Chiara Petrioli (petrioli@di.uniroma1.it) and Stefano Basagni (basagni@ece.neu.edu). The deadline for student posters is July 12, 2004. BEST STUDENT PAPER AWARD: Papers with a student as a primary author will = be considered for the Best Student Paper Award, with a cash award of 1000 = USD. Students must indicate with their submission that they would like to be considered for this award. The student author of the awarded paper is expected to present the paper at the conference. =20 GENERAL CHAIR Zygmunt Haas Cornell University =20 PROGRAM CO-CHAIRS Samir R. Das Stony Brook University, SUNY =20 Ravi Jain DoCoMo USA Labs STEERING COMMITTEE CHAIR Imrich Chlamtac University of Texas at Dallas ACM PROGRAM DIRECTOR Ginger Ignatoff Additional committee members will be announced on the conference web = page. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 21:28:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17551 for ; Wed, 3 Mar 2004 21:28:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayiap-0006x0-8M for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 21:28:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242SBEa026712 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 21:28:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayiap-0006wl-3R for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:28:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17502 for ; Wed, 3 Mar 2004 21:28:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayiam-0002mf-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 21:28:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiZo-0002ZH-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 21:27:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyiYu-0002Lu-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 21:26:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiYl-0006JV-MN; Wed, 03 Mar 2004 21:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiYO-0006Ho-4P for manet@optimus.ietf.org; Wed, 03 Mar 2004 21:25:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17312 for ; Wed, 3 Mar 2004 21:25:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiYL-0002AA-00 for manet@ietf.org; Wed, 03 Mar 2004 21:25:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiXK-0001vd-00 for manet@ietf.org; Wed, 03 Mar 2004 21:24:35 -0500 Received: from mbox1.ntu.edu.sg ([155.69.5.171]) by ietf-mx with esmtp (Exim 4.12) id 1AyiW8-0001Sz-00 for manet@ietf.org; Wed, 03 Mar 2004 21:23:20 -0500 Received: from mail04.ntu.edu.sg ([155.69.5.168]) by mbox1.ntu.edu.sg with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Mar 2004 10:22:42 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 4 Mar 2004 10:22:42 +0800 Message-ID: <4454557EC101FC47A1DC5DB2C70F0DDEF98D02@mail04.student.main.ntu.edu.sg> Thread-Topic: ZRP simulation Thread-Index: AcQBj5K8wIzCqQB/RYmH+95mOYXKAQ== From: "#ZHOU XIAOFENG#" To: X-OriginalArrivalTime: 04 Mar 2004 02:22:42.0932 (UTC) FILETIME=[92DFFB40:01C4018F] Content-Transfer-Encoding: quoted-printable Subject: [manet] ZRP simulation 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi,all I have download the source code of ZRP in Glomosim from = http://wnl.ece.cornell.edu/wnlprojects.html=20 and I untar the compressed package release the zrp.h and zrp.pc then copy these two files into the /glomosim-2.03/glomosim/network to = overwrite the existed files with same name. then delete the files zrp.o = and zrp.pi the next step is compile zrp.pc to produce .pi and .o files, but when I = compile the zrp.pc, there are some errors: such as all of the include files in the source code of zrp.pc. =20 Could anybody tell me the reason? and how to tackle it. or could you tell me how to perform the simulation of zrp Thank you very much! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 3 23:09:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24234 for ; Wed, 3 Mar 2004 23:09:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykAI-0002Gm-Cy for manet-archive@odin.ietf.org; Wed, 03 Mar 2004 23:08:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2448sRH008713 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 23:08:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykAE-0002GI-K1 for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 23:08:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24205 for ; Wed, 3 Mar 2004 23:08:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AykA8-00077N-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 23:08:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayk5x-0006Ew-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 23:04:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayk45-0005md-03 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 23:02:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyjnJ-0005Di-6b for manet-web-archive@ietf.org; Wed, 03 Mar 2004 22:45:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjnC-0007ha-9u; Wed, 03 Mar 2004 22:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyjmO-0007gn-J2 for manet@optimus.ietf.org; Wed, 03 Mar 2004 22:44:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22335 for ; Wed, 3 Mar 2004 22:44:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyjmL-0002Nd-00 for manet@ietf.org; Wed, 03 Mar 2004 22:44:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyjlV-0002BY-00 for manet@ietf.org; Wed, 03 Mar 2004 22:43:18 -0500 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 1Ayjkt-00021J-00 for manet@ietf.org; Wed, 03 Mar 2004 22:42:39 -0500 Received: From 192.168.0.100 ([129.94.173.78] == sitcrc.cse.unsw.EDU.AU) (for ) (for ) By note With Smtp ; Thu, 4 Mar 2004 14:42:27 +1100 From: Justin Lipman To: "#ZHOU XIAOFENG#" , Date: Thu, 4 Mar 2004 14:42:26 +1100 Reply-To: justin@titr.uow.edu.au Organization: CRC-SIT Subject: Re: [manet] ZRP simulation User-Agent: KMail/1.5.4 References: <4454557EC101FC47A1DC5DB2C70F0DDEF98D02@mail04.student.main.ntu.edu.sg> In-Reply-To: <4454557EC101FC47A1DC5DB2C70F0DDEF98D02@mail04.student.main.ntu.edu.sg> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403041442.26446.justin@titr.uow.edu.au> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Zhou, Sounds like you have a problem with the version of gcc that is being used. I havent tried compiling ZRP in GlomoSim, but your description of the errors sounds familiar to the problem I had when using the incorrect version of gcc. at your unix prompt type gcc -v if you have any other version of gcc other than gcc-2.95 then you will have this problem. You might also want to limit these types of questions to the GlomoSim mailing lists... if they still exist... hope this helps, Justin On Thu, 4 Mar 2004 01:22 pm, #ZHOU XIAOFENG# wrote: > Hi,all > I have download the source code of ZRP in Glomosim from > http://wnl.ece.cornell.edu/wnlprojects.html and I untar the compressed > package release the zrp.h and zrp.pc > then copy these two files into the /glomosim-2.03/glomosim/network to > overwrite the existed files with same name. then delete the files zrp.o and > zrp.pi the next step is compile zrp.pc to produce .pi and .o files, but > when I compile the zrp.pc, there are some errors: such as all of the > include files in the source code of zrp.pc. > > Could anybody tell me the reason? and how to tackle it. > or could you tell me how to perform the simulation of zrp > Thank you very much! > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- Research Associate Smart Internet Technology Cooperative Research Centre http://www.titr.uow.edu.au/~justin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 00:26:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29546 for ; Thu, 4 Mar 2004 00:26:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylN4-0003Dp-Nm for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 00:26:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i245QAIg012378 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 00:26:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylN4-0003DC-9D for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 00:26:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29502 for ; Thu, 4 Mar 2004 00:26:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AylN1-0006oI-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 00:26:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylM3-0006aE-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 00:25:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AylL5-0006KD-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 00:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylKz-0002rZ-IJ; Thu, 04 Mar 2004 00:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylKH-0002jS-Qs for manet@optimus.ietf.org; Thu, 04 Mar 2004 00:23:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29222 for ; Thu, 4 Mar 2004 00:23:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AylKF-00067G-00 for manet@ietf.org; Thu, 04 Mar 2004 00:23:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylJB-0005vB-00 for manet@ietf.org; Thu, 04 Mar 2004 00:22:10 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1AylIL-0005bo-00 for manet@ietf.org; Thu, 04 Mar 2004 00:21:18 -0500 Received: from jafymobile (6ants5.etri.re.kr [129.254.112.239]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW2AQH; Thu, 4 Mar 2004 14:20:47 +0900 Reply-To: From: "HyunWook Cha" To: "'Christophe Jelger'" , "'manet'" Subject: RE: [manet] Default Routes Date: Thu, 4 Mar 2004 14:20:49 +0900 Organization: ETRI Message-ID: <000201c401a8$74d0c8f0$ef70fe81@jafymobile> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <4045DB5F.6020807@dpt-info.u-strasbg.fr> Importance: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Christophe. Please see my inline comments. > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Christophe Jelger > Sent: Wednesday, March 03, 2004 10:19 PM > To: manet > Subject: Re: [manet] Default Routes > > > > Anders, > > The difference with pure flooding is that an ad hoc does not > forward the > information if it does not use it. With this very simple rule prefix > continuity is possible. > > We did not want to add a default route for reactive protocols > because : > 1. If there is a default route, how can the protocol be reactive ? > (there is always a match in the routing table for any destination) Why not? It depends on the condition on which route discovery should be triggered based. We can give more stric constraint like this to reactive routing protocol. If a valid route entry which is not a default route is not found, peform route discovery. Otherwise, another way is presented in my draft(and somewhere in other draft). If default route is available according to source address, do not "route discovery" and just forward using the default route. And later, prefix route(/n) entry from solicited/unsolicited gateway advertisement is found, packets are forwarded using the prefix route and perform route discovery. -> "route optimization". I think that this approach is also reacive(on-demand). > 2. If there is no default route, the gateway can reply to REQ for > destinations that are outside the Internet. Of course if we want to > guarantee that all nodes on the path to the gateway share the same > prefix, we cannot use the route obtained via the reactive > protol. Each node must send the packet to the neighbor from which it got > its prefix. I'm sure how this could be specified within the operation of > a reactive protocol. > > Christophe > I remember that we have discussed about this. Could you elaborate on this? More question. When current default route(path) which share same prefix breaks, how can this fact is informed to downstream nodes immediately? By RERR for the corresponding gateway? As I mentioned several times before, it is not guaranteed that route informaition(next hop of the gw) obtained by routing protocol is same as upstream neighbor of the default route. Thus, RERR for the gateway may not be issued. If different neighbor node advertising same prefix is available, you can switch this node as new upstream node. However, If not, (It may take a few seconds to recognize this.) the node should change its address with one with different prefix. In recuresively, all downstream nodes will change their addresses if they are arranged in a line. Total delays are incremented node by node until leaf node will recognize breakage of the default route. I have a question which has not been asked before. In your draft, how can a gateway determine that a global address affiliated to its prefix is owned by a MANET node or not? A gateway can do this because it should issue ICMP destination unreachable for addresses which are not used any more by MANET nodes and perform route discovery for addresses which are used by MANET nodes. In other drafts including Wakikawa's, Pekka's, and mine, a node updates its address lifetime as well as reachability from a gateway through periodic RREQ/RREP exchange. Regards, HyunWook _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 01:49:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06428 for ; Thu, 4 Mar 2004 01:49:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymez-0006n9-NQ for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 01:48:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i246mjYZ026106 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 01:48:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymez-0006mz-I8 for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:48:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06321 for ; Thu, 4 Mar 2004 01:48:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aymew-0000vo-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 01:48:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aymdl-0000cI-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 01:47:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AymcQ-00009t-01 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 01:46:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AymWo-0007uJ-8O for manet-web-archive@ietf.org; Thu, 04 Mar 2004 01:40:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymWc-0005fj-0s; Thu, 04 Mar 2004 01:40:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymVi-0005dI-Pt for manet@optimus.ietf.org; Thu, 04 Mar 2004 01:39:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05606 for ; Thu, 4 Mar 2004 01:39:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymVf-0006jW-00 for manet@ietf.org; Thu, 04 Mar 2004 01:39:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymUn-0006aE-00 for manet@ietf.org; Thu, 04 Mar 2004 01:38:14 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1AymTz-0006HF-00 for manet@ietf.org; Thu, 04 Mar 2004 01:37:23 -0500 Received: from jafymobile (6ants5.etri.re.kr [129.254.112.239]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW2AW9; Thu, 4 Mar 2004 15:36:53 +0900 Reply-To: From: "HyunWook Cha" To: "'Christophe Jelger'" , "'manet'" Subject: RE: [manet] Default Routes Date: Thu, 4 Mar 2004 15:36:55 +0900 Organization: ETRI Message-ID: <000601c401b3$162b80a0$ef70fe81@jafymobile> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.1165 In-Reply-To: <4045E2ED.2050704@dpt-info.u-strasbg.fr> Importance: Normal Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, Chiristophe and Eric. Please see my inline comments.=20 > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On=20 > Behalf Of Christophe Jelger > Sent: Wednesday, March 03, 2004 10:52 PM > To: manet > Subject: Re: [manet] Default Routes >=20 >=20 >=20 > Hi Erik, >=20 > Well about handovers everything is in the draft, but I have to admit=20 > that it's not very clear sometimes. I hope to write a new=20 > version soon. >=20 > To summarise : we propose different algorithms used by each=20 > ad hoc node=20 > to choose (and switch between) a gateway. It can either use=20 > the closest=20 > gateway (whatever prefix it uses), or a gateway that uses the same=20 > prefix than it currently uses (whatever the distance from the=20 > gateway).=20 > We also proposed slight variants. So first answer to your=20 > email is that=20 > switching between gateways is controled by each ad hoc node=20 > independently. >=20 As long as I understand, what Eric means is that "switching decision between gateways" in a node should not be affected by neighbors' prefix/address and each node can decide independently its best gateway. In case of second algorithm, this is not provided. [from Eric's mail] =20 > > > >My experience with AODV-UU is that gateway tunneling has=20 > many properties > >that are prefered in an ad hoc network. Tunnels easily=20 > support multiple > >gateways and are transparent for intermediate nodes that forwards the > >traffic to the gateway. I have a paper pending that clearly shows the > >advantages of tunnels in this context. Could you elaborate on this? What are tunnel end points? What about inbound traffic? =20 > > > >Before proceeding with a merged draft on Internet=20 > connectivity, I think > >that the proposal should be backed up with serious research showing > >problems or benefits of different strategies. I have=20 > implemented gateway > >connectivity in AODV-UU, and my experience clearly points in the > >direction of tunnels. > > > >Regards, > > > >Erik Nordstr=F6m > > > > I think that tunneling, source based forwarding, routing header those kind of stuff are not research issues but engineering issues. Though, performance does matter on either side.=20 Regards, HyunWook=20 =20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 03:55:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01039 for ; Thu, 4 Mar 2004 03:55:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyodU-0005oc-04 for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 03:55:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248tJjV022353 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 03:55:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyodT-0005oQ-RF for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:55:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00810 for ; Thu, 4 Mar 2004 03:55:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyodR-0005x2-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:55:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayoc5-0005WA-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:53:54 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyobJ-0005HD-03 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:53:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyoWc-0001j4-NM for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:48:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoWP-0004x5-OO; Thu, 04 Mar 2004 03:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoVz-0004s4-Lj for manet@optimus.ietf.org; Thu, 04 Mar 2004 03:47:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00135 for ; Thu, 4 Mar 2004 03:47:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoVx-0004Au-00 for manet@ietf.org; Thu, 04 Mar 2004 03:47:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoUg-0003jo-00 for manet@ietf.org; Thu, 04 Mar 2004 03:46:15 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyoTW-0003Qu-00 for manet@ietf.org; Thu, 04 Mar 2004 03:45:02 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i248lqZr023865 for ; Thu, 4 Mar 2004 09:47:52 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <4046FAE0.1080409@dpt-info.u-strasbg.fr> Date: Thu, 04 Mar 2004 10:46:08 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <6.0.3.0.2.20040303173506.02a99ec0@pop.itd.nrl.navy.mil> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Can you please elaborate on that ? While I agree with your statement, I don't fully agree with the way that it is "straighforward". Advertising a prefix is obviously very easy, and using it is also easy with the tunnel approach. I think the complexity (relatively speaking) is in the maintenance due to nodes mobility. Even with the tunnel approach, a node must check that the gateway is always reachable in order to be able to switch to a new gateway. Each node should also always use (for example) the closest gateway. We can also consider load balancing between gateways. Christophe >I agree with this also. >Gateway advertisement has been straightforward for the proactive routing approaches. >This is applied in practice today. > >A problem statement should not require a separate mechanism for that case. > >-Joe > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 03:59:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01158 for ; Thu, 4 Mar 2004 03:59:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayogr-0006Ff-Lp for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 03:58:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248wng1024026 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 03:58:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayogr-0006FR-11 for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:58:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01151 for ; Thu, 4 Mar 2004 03:58:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayogo-0006iH-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:58:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayofk-0006VH-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:57:40 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyofE-0006If-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:57:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyofG-00020t-9v for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:57:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayof8-0005u5-M1; Thu, 04 Mar 2004 03:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoeC-0005rZ-81 for manet@optimus.ietf.org; Thu, 04 Mar 2004 03:56:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01076 for ; Thu, 4 Mar 2004 03:56:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayoe9-00065a-00 for manet@ietf.org; Thu, 04 Mar 2004 03:56:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyodI-0005pF-00 for manet@ietf.org; Thu, 04 Mar 2004 03:55:08 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1Ayobv-0005UN-00 for manet@ietf.org; Thu, 04 Mar 2004 03:53:43 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i248uXZr024085 for ; Thu, 4 Mar 2004 09:56:33 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <4046FCE9.8050905@dpt-info.u-strasbg.fr> Date: Thu, 04 Mar 2004 10:54:49 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <6.0.3.0.2.20040303173506.02a99ec0@pop.itd.nrl.navy.mil> <40465FCA.2080105@dif.um.es> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pedro, I agree with you when you say that the gateway discovery mechanism should not be separated from the routing protocol. As stated in the draft, our approach could easily be integrated into OLSR. That's what we plan to do with the LRI version (Qolyester). We could therefore use the neighbors table of OLSR and use TC packets to send the gateway information (the operation has to be slightly modified but I won't go into the details). There might be some more complicated issues with reactive protocols, but I haven't gone into implementation details so far. Christophe Pedro M. Ruiz wrote: >> > I tend to agree with both of you. But I would also consider the to > extend a reactive protocol with a proactive gateway discovery > mechanism. So, you can call this enhanced protocol to be hybrid. But I > think there is no point in having the mechanism separate from the > routing protocol. > > However, I think is a good practice to focus now on defining such a > mechanism regardless of the routing protocol, and then try to > incorporate the agreed mechanism into any of the MANET routing > protocols (either proactive or reactive). > > Regards, Pedro > _______________________________________________ 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 exim@www1.ietf.org Thu Mar 4 04:19:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02352 for ; Thu, 4 Mar 2004 04:19:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayp0g-0000Ey-CJ for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 04:19:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i249JIEn000922 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 04:19:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayp0f-0000En-Tf for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 04:19:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02283 for ; Thu, 4 Mar 2004 04:19:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayp0d-0003Fh-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:19:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayozd-00032K-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:18:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayoyc-0002jP-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:17:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoyV-0008K7-C1; Thu, 04 Mar 2004 04:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayoxw-0008JM-6x for manet@optimus.ietf.org; Thu, 04 Mar 2004 04:16:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02230 for ; Thu, 4 Mar 2004 04:16:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayoxt-0002iB-00 for manet@ietf.org; Thu, 04 Mar 2004 04:16:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayox5-0002Xq-00 for manet@ietf.org; Thu, 04 Mar 2004 04:15:35 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyowI-0002Lu-00 for manet@ietf.org; Thu, 04 Mar 2004 04:14:46 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i249HaZr024862 for ; Thu, 4 Mar 2004 10:17:36 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <404701D8.80404@dpt-info.u-strasbg.fr> Date: Thu, 04 Mar 2004 11:15:52 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <6.0.3.0.2.20040303173506.02a99ec0@pop.itd.nrl.navy.mil> <40465FCA.2080105@dif.um.es> <4046FCE9.8050905@dpt-info.u-strasbg.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Gateway Discovery : are we going forward ? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, Well I obviously appreciate the discussions we have on gateway discovery, but as Eric Fleury said, we had similar discussions in the past. This time I hope it won't be for nothing, and I hope there could be some constructive consequences. It seems that many MANET members are willing to work on that, so maybe we could summarize the discussions we had and try to go ahead, maybe with a problem statement draft. So (maybe this is a very direct question) are the chairs willing to add this issues in the WG charter ? I think we could start to discuss on how we could collaborate ... Christophe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 04:32:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03146 for ; Thu, 4 Mar 2004 04:32:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypCa-0001Hh-8y for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 04:31:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i249Vax7004931 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 04:31:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypCZ-0001HS-Pk for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 04:31:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03081 for ; Thu, 4 Mar 2004 04:31:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypCW-0005yZ-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:31:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypBI-0005Y8-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:30:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AypAB-0005Ez-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:29:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypA5-0000sl-3L; Thu, 04 Mar 2004 04:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayp9P-0000qP-Sy for manet@optimus.ietf.org; Thu, 04 Mar 2004 04:28:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02741 for ; Thu, 4 Mar 2004 04:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayp9N-0005A7-00 for manet@ietf.org; Thu, 04 Mar 2004 04:28:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayp8N-0004xT-00 for manet@ietf.org; Thu, 04 Mar 2004 04:27:15 -0500 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1Ayp7M-0004bz-00 for manet@ietf.org; Thu, 04 Mar 2004 04:26:12 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 935A3FA85F; Thu, 4 Mar 2004 10:25:32 +0100 (CET) Received: from correo.um.es (zape.um.es [155.54.212.102]) by smtp.um.es (Postfix) with ESMTP id 2327AFA88E; Thu, 4 Mar 2004 10:25:27 +0100 (CET) Received: from correo.um.es (myotis.um.es [155.54.212.92]) by localhost (Postfix) with ESMTP id 90F2118E2D; Thu, 4 Mar 2004 10:25:24 +0100 (MET) Received: from dif.um.es (dibulibu.um.es [155.54.1.250]) by correo.um.es (Postfix) with ESMTP id 0178F18E27; Thu, 4 Mar 2004 10:25:23 +0100 (MET) Message-ID: <4046F37C.4000708@dif.um.es> Date: Thu, 04 Mar 2004 10:14:36 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Jelger Cc: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <6.0.3.0.2.20040303173506.02a99ec0@pop.itd.nrl.navy.mil> <40465FCA.2080105@dif.um.es> <4046FCE9.8050905@dpt-info.u-strasbg.fr> In-Reply-To: <4046FCE9.8050905@dpt-info.u-strasbg.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Christophe, I completely agree with your approach. First you define how to do the Internet interworking, then once it is proven to be correct, it will be integrated within the routing protocols (e.g. OLSR), Of course, some problems may happen to appear when integrating with the protocol. But, I think those are solvable once you know exactly how do you want to perform the Interworking. So, I think we have the same view on this. Regards, Pedro Christophe Jelger wrote: > Hi Pedro, > > I agree with you when you say that the gateway discovery mechanism > should not be separated from the routing protocol. > > As stated in the draft, our approach could easily be integrated into > OLSR. That's what we plan to do with the LRI version (Qolyester). We > could therefore use the neighbors table of OLSR and use TC packets to > send the gateway information (the operation has to be slightly > modified but I won't go into the details). > > There might be some more complicated issues with reactive protocols, > but I haven't gone into implementation details so far. > > Christophe > > Pedro M. Ruiz wrote: > >>> >> I tend to agree with both of you. But I would also consider the to >> extend a reactive protocol with a proactive gateway discovery >> mechanism. So, you can call this enhanced protocol to be hybrid. But >> I think there is no point in having the mechanism separate from the >> routing protocol. >> >> However, I think is a good practice to focus now on defining such a >> mechanism regardless of the routing protocol, and then try to >> incorporate the agreed mechanism into any of the MANET routing >> protocols (either proactive or reactive). >> >> Regards, Pedro >> _______________________________________________ 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 exim@www1.ietf.org Thu Mar 4 04:38:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03604 for ; Thu, 4 Mar 2004 04:38:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypJ8-0002ON-DO for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 04:38:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i249cLgD009193 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 04:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypJ6-0002OC-W9 for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 04:38:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03537 for ; Thu, 4 Mar 2004 04:38:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypJ4-0007Y6-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:38:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypI2-0007IU-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:37:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AypH4-0006xc-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:36:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypGu-0001rR-R0; Thu, 04 Mar 2004 04:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypGV-0001py-On for manet@optimus.ietf.org; Thu, 04 Mar 2004 04:35:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03434 for ; Thu, 4 Mar 2004 04:35:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypGS-0006wH-00 for manet@ietf.org; Thu, 04 Mar 2004 04:35:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypFe-0006jU-00 for manet@ietf.org; Thu, 04 Mar 2004 04:34:47 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1AypEk-0006Rh-00 for manet@ietf.org; Thu, 04 Mar 2004 04:33:50 -0500 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW2BHJ; Thu, 4 Mar 2004 18:33:17 +0900 Reply-To: From: "HyunWook Cha" To: "'Christophe Jelger'" , "'manet'" Subject: RE: [manet] Gateway Discovery : are we going forward ? Date: Thu, 4 Mar 2004 18:33:17 +0900 Message-ID: <000001c401cb$b9d269e0$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <404701D8.80404@dpt-info.u-strasbg.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, all. I agree with Christophe, though "Gateway Discovery" seems to be narrow. This is important issue since it is not an optional service, and basic framework to enable communication through Internet as well as incorporation with MIPv6 and multi-homing issues can be addressed in this category. HyunWook -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Christophe Jelger Sent: Thursday, March 04, 2004 7:16 PM To: manet Subject: [manet] Gateway Discovery : are we going forward ? Hi all, Well I obviously appreciate the discussions we have on gateway discovery, but as Eric Fleury said, we had similar discussions in the past. This time I hope it won't be for nothing, and I hope there could be some constructive consequences. It seems that many MANET members are willing to work on that, so maybe we could summarize the discussions we had and try to go ahead, maybe with a problem statement draft. So (maybe this is a very direct question) are the chairs willing to add this issues in the WG charter ? I think we could start to discuss on how we could collaborate ... Christophe _______________________________________________ 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 exim@www1.ietf.org Thu Mar 4 04:51:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04415 for ; Thu, 4 Mar 2004 04:51:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypVh-0004H2-KK for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 04:51:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i249pLTw016419 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 04:51:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypVg-0004Gk-06 for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 04:51:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04335 for ; Thu, 4 Mar 2004 04:51:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypVc-0002Uu-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:51:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypUd-0002Hc-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:50:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AypTc-000205-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:49:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypTT-0003to-CK; Thu, 04 Mar 2004 04:49:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypT2-0003sj-7r for manet@optimus.ietf.org; Thu, 04 Mar 2004 04:48:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04246 for ; Thu, 4 Mar 2004 04:48:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypSz-0001wy-00 for manet@ietf.org; Thu, 04 Mar 2004 04:48:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypSA-0001lg-00 for manet@ietf.org; Thu, 04 Mar 2004 04:47:43 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1AypRY-0001W1-00 for manet@ietf.org; Thu, 04 Mar 2004 04:47:04 -0500 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW2B2A; Thu, 4 Mar 2004 18:46:34 +0900 Reply-To: From: "HyunWook Cha" To: "'manet'" Date: Thu, 4 Mar 2004 18:46:35 +0900 Message-ID: <000a01c401cd$94f6c420$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <40465203.6020407@earthlink.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [manet] Why GW discovery should not be separated from reactive 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, all. Could you tell me why GW discovery should not be separated from reactive routing protocols? IMO, periodic gw solication/advertisement seems to be proactive. Thanks in advance. HyunWook -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Richard Ogier Sent: Thursday, March 04, 2004 6:46 AM To: manet Subject: Re: [manet] Default Routes Eric Fleury wrote: > This discussion on GW discovery appeared several months/years ago in > the MANET mailing list and in fine, one conclusion was that we need a > more general service discovery protocol. More precisely, trying to > focus only on prefix delegation and developing a independent protocol > is a so so answer since it will always be redundant with the > underlying routing protocol used (cf OLSR flooding discussion!). > > Thus either we try to set up a more generic discovery protocol and a > GW/prefix is one service (and we can try to compare here large classes > of philosophies : pro actively announce services, reactively reclaim > services...) or we can try to develop MANET routing protocol extension > in order to corporate prefix delegation. IN OLSR, using MPRs + TC > packets will be more efficient than re designing a flooding like > prefix delegation... I agree with your point that it is redundant to have a separate protocol to advertise gateways (which is really a distance-vector routing protocol), when gateway information can and should be provided by the underlying routing protocol (without promoting a particular routing protocol at this time). In fact, I made a similar point last September, which I will repeat here: On 22 July 2002 Guillaume Chelius wrote: > My opinion is that we should not split the gateway advertisement mechanism from > the routing protocol. It is the protocol responsability to propose a mechanism > which allows a node to discover gateways and to manage routes between nodes to > gateways. I completely agree with this. For example, assuming that a proactive routing protocol is used, there is no need to introduce a DSDV-like mechanism to provide gateway information to the manet nodes, when the routing protocol can provide this information to the manet nodes. If prefix continuity is desired, the routing protocol can be modified to achieve this (e.g., by computing a source tree for each known prefix). Similarly, a multi-hop extension of NDP as described in draft-wakikawa-manet-globalv6-02.txt should not be necessary since the routing protocol can and should provide the required information to the manet nodes in a timely, efficient manner. (If it doesn't, then the routing protocol needs to be improved.) The only reason to have a separate mechanism to advertise gateway information is if one wanted to do this proactively, even though the underlying routing protocol is reactive. In this case, I think that either (a) the separate mechanism would be used ONLY with the reactive protocol, or (b) the mechanism would really be a reduced version of the proactive protocol, which maintains routes only to and from each gateway. 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 exim@www1.ietf.org Thu Mar 4 05:45:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07608 for ; Thu, 4 Mar 2004 05:45:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqM0-0000Ns-6G for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 05:45:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24AjOLS001473 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 05:45:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqLz-0000Ng-Bf for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 05:45:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07498 for ; Thu, 4 Mar 2004 05:45:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyqLv-0006V8-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 05:45:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyqKw-0006FU-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 05:44:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyqJv-0005u2-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 05:43:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqJj-0008Md-9L; Thu, 04 Mar 2004 05:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqIu-0008H7-R7 for manet@optimus.ietf.org; Thu, 04 Mar 2004 05:42:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07150 for ; Thu, 4 Mar 2004 05:42:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyqIr-0005ZU-00 for manet@ietf.org; Thu, 04 Mar 2004 05:42:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyqHq-0005I2-00 for manet@ietf.org; Thu, 04 Mar 2004 05:41:06 -0500 Received: from csiges9.insa-lyon.fr ([134.214.79.200] helo=mail.insa-lyon.fr) by ietf-mx with esmtp (Exim 4.12) id 1AyqGs-0004yz-00 for manet@ietf.org; Thu, 04 Mar 2004 05:40:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.insa-lyon.fr (Postfix) with ESMTP id ECFFA4B790; Thu, 4 Mar 2004 11:39:17 +0100 (CET) Received: from insa-lyon.fr (ares-chelius-1.insa-lyon.fr [134.214.144.146]) by mail.insa-lyon.fr (Postfix) with ESMTP id 721454B733; Thu, 4 Mar 2004 11:39:15 +0100 (CET) Message-ID: <40470762.9060805@insa-lyon.fr> Date: Thu, 04 Mar 2004 11:39:30 +0100 From: Guillaume Chelius Reply-To: guillaume.chelius@insa-lyon.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jafy@etri.re.kr Cc: "'manet'" Subject: Re: [manet] Why GW discovery should not be separated from reactive routing protocols? References: <000a01c401cd$94f6c420$ae70fe81@jafywinxp> In-Reply-To: <000a01c401cd$94f6c420$ae70fe81@jafywinxp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd 0.1 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, > Could you tell me why GW discovery should not be separated from reactive > routing protocols? IMO, periodic gw solication/advertisement seems to be > proactive. A periodic solicitation/advertisement scheme is indeed proactive. As for a periodic unsolicited advertisement one. But on-demand solicitation/advertisement (route-request to the gateway) is reactive. This clearly shows that for reactive protocols, the gateway/prefix advertizement may be either integrated to the routing protocol (for reactive) or may be performed by a separate protocol if a proactive scheme is preferred. For a proactive protocol, the question does not hold as proactive advertizement can be performed at almost 0 cost. Regards, Guillaume. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 06:25:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10298 for ; Thu, 4 Mar 2004 06:25:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayqxx-0007cp-4I for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 06:24:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24BObKM029305 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 06:24:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayqxw-0007ca-VJ for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 06:24:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10222 for ; Thu, 4 Mar 2004 06:24:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayqxt-000021-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 06:24:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayqwh-0007W6-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 06:23:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayqvg-00077R-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 06:22:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayqve-0004rI-NH for manet-web-archive@ietf.org; Thu, 04 Mar 2004 06:22:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqvR-00075K-Pb; Thu, 04 Mar 2004 06:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayqud-00071v-0S for manet@optimus.ietf.org; Thu, 04 Mar 2004 06:21:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09959 for ; Thu, 4 Mar 2004 06:21:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyquZ-0006n6-00 for manet@ietf.org; Thu, 04 Mar 2004 06:21:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyqtH-0006Rn-00 for manet@ietf.org; Thu, 04 Mar 2004 06:19:48 -0500 Received: from bareed3.maktoob.net ([195.172.126.104] helo=maktoobchat.net) by ietf-mx with esmtp (Exim 4.12) id 1Ayqrk-0005uB-00 for manet@ietf.org; Thu, 04 Mar 2004 06:18:12 -0500 Received: from [195.172.126.106] (HELO maktoobchat.net) by maktoobchat.net (CommuniGate Pro SMTP 4.1.6) with ESMTP id 12013974 for manet@ietf.org; Thu, 04 Mar 2004 11:21:06 +0000 Received: from [195.172.126.104] (HELO maktoob.com) by maktoobchat.net (CommuniGate Pro SMTP 4.1.6) with ESMTP id 12988828 for manet@ietf.org; Thu, 04 Mar 2004 11:04:43 +0000 From: "yazeed al-sbou" To: manet@ietf.org Comment: Maktoob By BOC X-Mailer: Maktoob 2.0 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)] X-Originating-IP: [143.52.2.80] MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 7bit Date: Thu, 04 Mar 2004 11:04:43 +0000 Message-ID: Content-Transfer-Encoding: 7bit Subject: [manet] Variable Bit Rate 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=AWL,FORGED_MUA_MOZILLA autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all.... Could anyone please tell me how to send a variable bit rate traffic using NS... Yazeed Ahamd Al-Sbou, Research Student School of Engineering Sheaf Building - Room 4311, Sheffield Hallam University,City Campus Sheiffield, S1 1WB Tel(university):+441142253254 Mobile 00447813402741 Yazeed.A.Al-Sbou@student.shu.ac.uk _________________________________________________ Make someone's day! Send a friend a special Arabic card from Maktoob Cards NOW. http://www.maktoob.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 06:44:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12465 for ; Thu, 4 Mar 2004 06:44:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyrGv-0001ag-6G for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 06:44:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24BiDEx006102 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 06:44:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyrGu-0001aJ-Pq for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 06:44:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12403 for ; Thu, 4 Mar 2004 06:44:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyrGq-00055G-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 06:44:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyrFr-0004pW-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 06:43:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyrF1-0004Zj-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 06:42:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyrF3-0005HY-Iq for manet-web-archive@ietf.org; Thu, 04 Mar 2004 06:42:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyrEn-0001EZ-9r; Thu, 04 Mar 2004 06:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyrEg-0001E0-DR for manet@optimus.ietf.org; Thu, 04 Mar 2004 06:41:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12259 for ; Thu, 4 Mar 2004 06:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyrEc-0004YW-00 for manet@ietf.org; Thu, 04 Mar 2004 06:41:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyrDj-0004LP-00 for manet@ietf.org; Thu, 04 Mar 2004 06:40:55 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AyrD2-00046c-00 for manet@ietf.org; Thu, 04 Mar 2004 06:40:13 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i24Be7Y7024100; Thu, 4 Mar 2004 12:40:07 +0100 (MET) Subject: RE: [manet] Default Routes From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: jafy@etri.re.kr Cc: "'manet'" In-Reply-To: <000601c401b3$162b80a0$ef70fe81@jafymobile> References: <000601c401b3$162b80a0$ef70fe81@jafymobile> Content-Type: text/plain Message-Id: <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 04 Mar 2004 12:40:07 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-03-04 at 07:36, HyunWook Cha wrote: > [from Eric's mail] > > > > > >My experience with AODV-UU is that gateway tunneling has > > many properties > > >that are prefered in an ad hoc network. Tunnels easily > > support multiple > > >gateways and are transparent for intermediate nodes that forwards the > > >traffic to the gateway. I have a paper pending that clearly shows the > > >advantages of tunnels in this context. > > Could you elaborate on this? What are tunnel end points? What about > inbound traffic? > Tunnel end points would be the source node in the ad hoc network and the gateway. Between these end points packets are encapsulated/tunneled (through ip-in-ip, or similar). Intermediate nodes (between the source and the gateway) can then forward the packets without knowledge of the external (Internet) address. In fact they need no extra state, except a route to the gateway, which is provided by the ad hoc routing protocol. Inbound traffic (i.e., traffic from the Internet to the ad hoc network) does not need to be tunneled inside the ad hoc network since the return address is routable there (in case you run Mobile IP, NAT or have address conf). /Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 07:40:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16108 for ; Thu, 4 Mar 2004 07:40:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ays8T-00005F-B3 for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 07:39:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24CdXlU000315 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 07:39:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ays8T-000050-3a for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 07:39:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16099 for ; Thu, 4 Mar 2004 07:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ays8S-00020J-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 07:39:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ays7Y-0001px-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 07:38:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ays79-0001fB-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 07:38:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ays71-0008Be-2d; Thu, 04 Mar 2004 07:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ays6c-0007yw-DI for manet@optimus.ietf.org; Thu, 04 Mar 2004 07:37:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16043 for ; Thu, 4 Mar 2004 07:37:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ays6b-0001e1-00 for manet@ietf.org; Thu, 04 Mar 2004 07:37:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ays5n-0001TI-00 for manet@ietf.org; Thu, 04 Mar 2004 07:36:48 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1Ays5K-0001H4-00 for manet@ietf.org; Thu, 04 Mar 2004 07:36:18 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i24CaGS1005415; Thu, 4 Mar 2004 13:36:16 +0100 (MET) Subject: Re: [manet] Gateway Discovery : are we going forward ? From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: Christophe Jelger Cc: manet In-Reply-To: <404701D8.80404@dpt-info.u-strasbg.fr> References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <6.0.3.0.2.20040303173506.02a99ec0@pop.itd.nrl.navy.mil> <40465FCA.2080105@dif.um.es> <4046FCE9.8050905@dpt-info.u-strasbg.fr> <404701D8.80404@dpt-info.u-strasbg.fr> Content-Type: text/plain Message-Id: <1078403776.5224.36.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 04 Mar 2004 13:36:16 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-03-04 at 11:15, Christophe Jelger wrote: > Hi all, > > Well I obviously appreciate the discussions we have on gateway > discovery, but as Eric Fleury said, we had similar discussions in the > past. This time I hope it won't be for nothing, and I hope there could > be some constructive consequences. It seems that many MANET members are > willing to work on that, so maybe we could summarize the discussions we > had and try to go ahead, maybe with a problem statement draft. > I agree that a "problem statement" draft is needed. The problem I have with the current drafts is that they try to cover _all_ grounds by including several ways to do forwarding, address conf etc. Speaking from experience (by trying to implement Internet connectivity in AODV-UU), it is hard to extract something useful from these documents. A problem statement draft would explore all issues, scenario focus, gateway discovery, gateway forwarding, address conf etc. Hopefully, this would lead to one draft describing a simple and efficient way to provide Internet connectivity. After that, there would be an opening for limited scope solutions, extensions and optimizations, etc. //Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 07:47:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16353 for ; Thu, 4 Mar 2004 07:47:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysFU-00019m-3D for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 07:46:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24CkmWn004440 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 07:46:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysFT-00019X-TK for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 07:46:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16347 for ; Thu, 4 Mar 2004 07:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AysFT-0003MG-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 07:46:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AysEZ-0003Aa-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 07:45:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AysDx-0002xj-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 07:45:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysDn-0000dX-Mp; Thu, 04 Mar 2004 07:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AysDJ-0000bv-Sc for manet@optimus.ietf.org; Thu, 04 Mar 2004 07:44:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16299 for ; Thu, 4 Mar 2004 07:44:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AysDJ-0002wl-00 for manet@ietf.org; Thu, 04 Mar 2004 07:44:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AysCM-0002me-00 for manet@ietf.org; Thu, 04 Mar 2004 07:43:36 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1AysBq-0002b3-00 for manet@ietf.org; Thu, 04 Mar 2004 07:43:02 -0500 Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i24CgUUM029834 for ; Thu, 4 Mar 2004 13:42:30 +0100 Message-ID: <016e01c401e6$6f44c420$1f175d80@inria.fr> From: "Philippe Jacquet" To: "manet" References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <40463249.3060100@earthlink.net> Subject: Re: [manet] Default Routes Date: Thu, 4 Mar 2004 13:44:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" 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 X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id i24CgUUM029834 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable ----- Original Message ----- From: Richard Ogier To: Christophe Jelger Cc: manet Sent: Wednesday, March 03, 2004 8:30 PM Subject: Re: [manet] Default Routes > > > Routes *will* be the min-hop, since the gateway info message contains > the distance in hops > to the gateway, so a node can always choose a neighbor with fewer hops > as the next hop > to the gateway. But the MPR forwarding rule should be that a node > relays a gateway info > message if the *next hop* is an MPR selector. Thus, the path to the > gateway will be > a sequence of MPR selectors. Philippe, is this correct? > Yes you are correct, excepted the minor point that there is no guarantee that blind flooding or MPR flooding forward information on min-hop path e= ven in presence of error free transmissions. The reason is that retransmissio= ns on optimal path could be re-empted by retransmissions on non-optimal path= s. However MPR flooding will be statistically done on shorter paths than bli= nd flooding. In order to get shortest path for sure we would have either to allow node= s to retransmit the information several times, everytime they receive it on shorter hop number (see our paper on superflooding), or to wait long enou= gth between retransmission in order to collect the shortest path before retransmission. There is also the possibility to explicitly compute the shortest path to the gateway but this will only work with proactive protocols. I agree that if gateway advertizement were included in routing protocols,= as it is done in proactive protocols, the problem would be much simpler. OLS= R has already an embedded mechanism called HNA. It can be easily extended t= o several gateways information if one uses the rule of selecting the gatewa= y with the shortest path. Philippe > Richard > > > > > > > And about prefix distribution : prefix distribution is limited "by > > nature", i.e. a node that is a the limit of two "islands" will not > > forward control packets received from the island it does not belong t= o. > > > > Christophe > > > > Erik Nordstr=C3=B6m wrote: > > > >> Maybe I am missing something (and please point it out), but will not the > >> MPR flooding limit the distribution of (different) prefixes in the > >> network? My concern is that a node far down the (MPR) distribution p= ath > >> rooted at a gateway will not be able to change gateway/prefix unless its > >> upstream neighbor (closer to the gateway) also changes its prefix (o= f > >> another gateway)? > >> file://Erik > >> > >> On Wed, 2004-03-03 at 16:52, Philippe Jacquet wrote: > >> > >> > >>> I don't see any problem with MPR flooding, when last hop is MPR > >>> selector > >>> then it will be the upstream neighbor. > >>> I think the algorithm could be an application of the recent MPRF > >>> draft with > >>> the option TTL=3D1. > >>> > >>> Philippe > >>> ----- Original Message ----- > >>> From: Erik Nordstr=C3=B6m > >>> To: Christophe Jelger > >>> Cc: manet > >>> Sent: Wednesday, March 03, 2004 3:13 PM > >>> Subject: Re: [manet] Default Routes > >>> > >>> > >>> Jelger, > >>> > >>> I admit that I am not that familiar with your proposal, and probabl= y > >>> should read it more carefully. However, there are some things I > >>> question... > >>> > >>> For example, why implement a seperate flooding mechanism when this = is > >>> already provided by the routing protocol (for example OLSR)? You > >>> propose > >>> to optionally integrate this with the routing protocol, but I do no= t > >>> see > >>> how that is possible with MPR-based flooding? > >>> > >>> I am not convinced that you have maximum flexibility when building your > >>> prefix islands of nodes. How can nodes part of a prefix island > >>> individually choose another gateway? But, I admit, I need to study your > >>> draft in more detail. > >>> > >>> With tunnels you can simply add a flag in ordinary control messages > >>> announcing some nodes as gateways. Nodes can then individually choo= se a > >>> gateway and tunnel packets to it. The routing protocol takes care o= f > >>> the > >>> rest transparently. This also works well with reactive protocols. > >>> > >>> /Erik > >>> > >>> > >>> On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: > >>> > >>> > >>>> Hi Erik, > >>>> > >>>> Well about handovers everything is in the draft, but I have to adm= it > >>>> that it's not very clear sometimes. I hope to write a new version > >>>> soon. > >>>> > >>>> To summarise : we propose different algorithms used by each ad hoc > >>>> node > >>>> to choose (and switch between) a gateway. It can either use the > >>>> closest > >>>> gateway (whatever prefix it uses), or a gateway that uses the same > >>>> prefix than it currently uses (whatever the distance from the > >>>> gateway). > >>>> We also proposed slight variants. So first answer to your email is > >>>> that > >>>> switching between gateways is controled by each ad hoc node > >>>> independently. > >>>> > >>>> Moreover, and because of our particular (but very simple) way of > >>>> prefix > >>>> propagation, we can guarantee that a default route is never > >>>> diverted (in > >>>> the steady-state). By steady-state, I mean that of course topologi= cal > >>>> changes can cause trouble during a very small amount of time. The main > >>>> idea behind our draft is prefix continuity : we "build" contiguous > >>>> islands of nodes that share the same prefix/gateway. This can be o= f > >>>> high > >>>> interest for providers (e.g. management, services, ...). > >>>> > >>>> We have implemented our solution (IPv6) as an independent daemon > >>>> and it > >>>> works really well in the presence of multiple gateways and > >>>> prefixes. We > >>>> will soon integrate it in an IPv6 version of OLSR (Qolyester from > >>>> LRI in > >>>> France). I am also finishing some simulations in which we evaluate our > >>>> solution : I hope I can submit the results for publication very so= on. > >>>> > >>>> Well and before everybody says what's best and what's bad, I > >>>> personally > >>>> think it's very difficult at this stage to say so. If you have don= e > >>>> some > >>>> simulations of the tunnel approach you have probably seen that results > >>>> can greatly vary across different simulation scenarios. I think al= l > >>>> solutions have pros and cons, and we should be able to find the be= st > >>>> parts of all solutions. > >>>> > >>>> Regards, > >>>> Christophe > >>>> > >>>> Erik Nordstr=C3=B6m wrote: > >>>> > >>>> > >>>> > >>>>> Hi, > >>>>> > >>>>> I don't see how you can efficiently handle multiple gateways when > >>>>> using > >>>>> default routes? Especially with reactive protocols that do not ha= ve a > >>>>> complete view of the network. Even if you maintain the gateway > >>>>> mapping, > >>>>> how will you deal with hand-overs between gateways? You say that the > >>>>> solution is to force nodes to use the "same" default route, but I > >>>>> do not > >>>>> think that is a good idea. Individual nodes may know best when to > >>>>> switch > >>>>> gateways, and they should be allowed to do so if they wish. How > >>>>> can you > >>>>> guarantee that a default route is not diverted to another gateway > >>>>> at an > >>>>> intermediate node if a packet carries no mapping between the (fin= al) > >>>>> destination and the gateway? How do you handle control packets (f= rom > >>>>> different gateways) that want to change the default route --> gateway > >>>>> mapping? > >>>>> > >>>>> My experience with AODV-UU is that gateway tunneling has many > >>>>> properties > >>>>> that are prefered in an ad hoc network. Tunnels easily support > >>>>> multiple > >>>>> gateways and are transparent for intermediate nodes that forwards the > >>>>> traffic to the gateway. I have a paper pending that clearly shows the > >>>>> advantages of tunnels in this context. > >>>>> > >>>>> Before proceeding with a merged draft on Internet connectivity, I > >>>>> think > >>>>> that the proposal should be backed up with serious research showi= ng > >>>>> problems or benefits of different strategies. I have implemented > >>>>> gateway > >>>>> connectivity in AODV-UU, and my experience clearly points in the > >>>>> direction of tunnels. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Erik Nordstr=C3=B6m > >>>>> > >>>>> > >>>>> > >>>>> On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Actually each node knows what gateway it uses because there is a > >>>>>> special > >>>>>> field in the packet used to disseminate the prefix information. This > >>>>>> field contains the IPv6 global address of the gateway (and > >>>>>> another field > >>>>>> gives the prefix length). Moreover, we "almost" don't need a routing > >>>>>> protocol (of course don't take this statement too strictly), in = the > >>>>>> sense that, when a node wants to send data to some node in the > >>>>>> Internet, > >>>>>> it only uses a default route with next hop being one of its > >>>>>> neighbors. > >>>>>> The ad hoc node does not even need to have a /128 route to the > >>>>>> gateway. > >>>>>> Of course on the reverse path this is not the same (i.e. the gateway > >>>>>> must have a /128 route to the ad hoc node). > >>>>>> > >>>>>> Christophe > >>>>>> > >>>>>> Anders Nilsson wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Hello again, > >>>>>>> > >>>>>>> Christophe Jelger wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> Of course as one of the authors of a solution that uses defaul= t > >>>>>>>> route > >>>>>>>> I don't agree with your statements. ;-) > >>>>>>>> > >>>>>>>> In our draft each MANET node knows which gateway it uses, and > >>>>>>>> (in the > >>>>>>>> steady-state) it knows that all nodes on the "default route" > >>>>>>>> path use > >>>>>>>> the same gateway. With our solution gateways don't announce > >>>>>>>> routes, > >>>>>>>> they just announce prefixes. If two gateways announce the same > >>>>>>>> prefix, an ad hoc node selects the closest gateway (it can be > >>>>>>>> specified that it should from there use the same gateway). The > >>>>>>>> propagation method used to propagate the prefix information > >>>>>>>> ensures > >>>>>>>> that the path to the gateway is made of nodes that also use th= e > >>>>>>>> same > >>>>>>>> gateway : there is no need of a routing header, and default routes > >>>>>>>> can be used safely. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> That sounds like a good solution, but the node can't control wh= at > >>>>>>> gateway it is currently using. A scenario where this is neeed i= s > >>>>>>> when > >>>>>>> the node is moving from gateway to gateway. The node is then > >>>>>>> unable to > >>>>>>> know what gateway it is currently communicating through. A node > >>>>>>> need > >>>>>>> to know this when it switches to a new gateway, and "registers" > >>>>>>> itself. This reason why this needed is because packets from the > >>>>>>> Internet needs to be routed to the correct gateway, which is > >>>>>>> difficult > >>>>>>> when mobile nodes are unware of its gateway. If a Cellular IP > >>>>>>> type of > >>>>>>> solution is used, the routing entries in the access network are > >>>>>>> updated by the actual packets flowing through the gateways. But > >>>>>>> there > >>>>>>> is problems here as well, because oscillations easily occurs th= at > >>>>>>> causes a lot of updates, especially when the mobile nodes are > >>>>>>> mobile. > >>>>>>> I have simulated this, and it is harder to maintain than you mi= ght > >>>>>>> think. If you rely on proactive gateway discovery, the default > >>>>>>> routing > >>>>>>> entries have to be maintained during link breaks and mobility, > >>>>>>> along > >>>>>>> with sequence number maintainence. I have a paper about this, i= n a > >>>>>>> slightly different context, but during mobility and several hop= s to > >>>>>>> the gateway, more complex control is needed. > >>>>>>> > >>>>>>> regards, > >>>>>>> > >>>>>>> Anders > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>> > >> > >> > >> > >> _______________________________________________ > >> 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 exim@www1.ietf.org Thu Mar 4 09:42:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22158 for ; Thu, 4 Mar 2004 09:42:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayu3K-00033w-JJ for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 09:42:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24EgM4M011771 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 09:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayu3K-00033m-Aj for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 09:42:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22104 for ; Thu, 4 Mar 2004 09:42:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayu3I-0004JP-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 09:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayu1m-0003su-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 09:40:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayu0M-0003ON-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 09:39:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayu06-0002Wj-3p; Thu, 04 Mar 2004 09:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aytzl-0002VE-Ns for manet@optimus.ietf.org; Thu, 04 Mar 2004 09:38:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21732 for ; Thu, 4 Mar 2004 09:38:38 -0500 (EST) From: Paal.Engelstad@telenor.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aytzj-0003Cc-00 for manet@ietf.org; Thu, 04 Mar 2004 09:38:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aytxn-0002fu-00 for manet@ietf.org; Thu, 04 Mar 2004 09:36:39 -0500 Received: from virus-out.ttyl.com ([193.212.240.200] helo=virus-out-st.online.no) by ietf-mx with esmtp (Exim 4.12) id 1Aytx2-0002Ja-00 for manet@ietf.org; Thu, 04 Mar 2004 09:35:52 -0500 Received: from tns-fbu-22-208.corp.telenor.no ([134.47.162.90] [134.47.162.90]) by scan.telenor.net with ESMTP; Thu, 4 Mar 2004 15:35:19 +0100 Received: from moffice3.nsc.no ([10.122.115.83]) by tns-fbu-22-208.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Mar 2004 15:35:18 +0100 Message-Id: <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> To: =?iso-8859-1?Q?Erik_Nordstr=F6m?= To: Subject: SV: RE: [manet] Default Routes (Intern) Cc: "'manet'" In-Reply-To: <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> X-Priority: 3 (Normal) X-Mailer: Mobile Office v1.0 (Telenor Business Solutions) References: <000601c401b3$162b80a0$ef70fe81@jafymobile> <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> X-OriginalArrivalTime: 04 Mar 2004 14:35:18.0718 (UTC) FILETIME=[EA90A5E0:01C401F5] Date: 4 Mar 2004 15:35:18 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1258_2653016.1078410918480" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ------=_Part_1258_2653016.1078410918480 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Erik, On a side note: I am just wondering if your solution really is fully transparent as you claimed? Does not AODV also use the source IP addresses of data packets to keep routes up to date... and without tunneling from GW...? Comments? Paal > > Could you elaborate on this? What are tunnel end points? What about > > inbound traffic? > > > > Tunnel end points would be the source node in the ad hoc network and the > gateway. Between these end points packets are encapsulated/tunneled > (through ip-in-ip, or similar). Intermediate nodes (between the source > and the gateway) can then forward the packets without knowledge of the > external (Internet) address. In fact they need no extra state, except a > route to the gateway, which is provided by the ad hoc routing protocol. > Inbound traffic (i.e., traffic from the Internet to the ad hoc network) > does not need to be tunneled inside the ad hoc network since the return > address is routable there (in case you run Mobile IP, NAT or have > address conf). > > /Erik > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet ------=_Part_1258_2653016.1078410918480-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 09:50:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23004 for ; Thu, 4 Mar 2004 09:50:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyuAj-0003wH-E1 for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 09:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Eo1qS015135 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 09:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyuAj-0003vz-0y for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 09:50:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22982 for ; Thu, 4 Mar 2004 09:49:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyuAh-0006Iu-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 09:49:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayu9Z-00063M-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 09:48:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayu8u-0005qv-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 09:48:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayu8p-0003Uj-Ou; Thu, 04 Mar 2004 09:48:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayu8h-0003Tz-Uf for manet@optimus.ietf.org; Thu, 04 Mar 2004 09:47:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22765 for ; Thu, 4 Mar 2004 09:47:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayu8f-0005pj-00 for manet@ietf.org; Thu, 04 Mar 2004 09:47:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayu7v-0005b7-00 for manet@ietf.org; Thu, 04 Mar 2004 09:47:08 -0500 Received: from csiges9.insa-lyon.fr ([134.214.79.200] helo=mail.insa-lyon.fr) by ietf-mx with esmtp (Exim 4.12) id 1Ayu6p-0005Dc-00 for manet@ietf.org; Thu, 04 Mar 2004 09:45:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.insa-lyon.fr (Postfix) with ESMTP id BCC364B7BA; Thu, 4 Mar 2004 15:45:25 +0100 (CET) Received: from insa-lyon.fr (ares-chelius-1.insa-lyon.fr [134.214.144.146]) by mail.insa-lyon.fr (Postfix) with ESMTP id 75BC44B605; Thu, 4 Mar 2004 15:45:24 +0100 (CET) Message-ID: <40474104.7010106@insa-lyon.fr> Date: Thu, 04 Mar 2004 15:45:24 +0100 From: Guillaume Chelius Reply-To: guillaume.chelius@insa-lyon.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paal.Engelstad@telenor.com Cc: =?ISO-8859-1?Q?Erik_Nordstr=F6m?= , jafy@etri.re.kr, "'manet'" Subject: Re: SV: RE: [manet] Default Routes (Intern) References: <000601c401b3$162b80a0$ef70fe81@jafymobile> <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> In-Reply-To: <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd 0.1 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Paal, You could also use source routing instead tunneling. However, if a tunnel is used, the source address of the tunnel is identical to the one of the original packet. Between the tunnel header and the packet header, only the destination address changes (gateway address instead of destination address). Regards, Guillaume Cheluis. Paal.Engelstad@telenor.com wrote: > Erik, > > On a side note: I am just wondering if your solution really is fully transparent as you claimed? Does not AODV also use the source IP addresses of data packets to keep routes up to date... and without tunneling from GW...? Comments? > > Paal > > >>>Could you elaborate on this? What are tunnel end points? What about >>>inbound traffic? >>> >> >>Tunnel end points would be the source node in the ad hoc network and the >>gateway. Between these end points packets are encapsulated/tunneled >>(through ip-in-ip, or similar). Intermediate nodes (between the source >>and the gateway) can then forward the packets without knowledge of the >>external (Internet) address. In fact they need no extra state, except a >>route to the gateway, which is provided by the ad hoc routing protocol. >>Inbound traffic (i.e., traffic from the Internet to the ad hoc network) >>does not need to be tunneled inside the ad hoc network since the return >>address is routable there (in case you run Mobile IP, NAT or have >>address conf). >> >>/Erik >> >> >>_______________________________________________ >>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 exim@www1.ietf.org Thu Mar 4 10:07:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24333 for ; Thu, 4 Mar 2004 10:07:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyuRX-0000Uj-PZ for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 10:07:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24F7M5m001870 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 10:07:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyuRW-0000U0-H7 for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 10:07:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24235 for ; Thu, 4 Mar 2004 10:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyuRU-0002Hf-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 10:07:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyuQM-0001zy-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 10:06:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyuPX-0001kL-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 10:05:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyuPI-000814-Ez; Thu, 04 Mar 2004 10:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyuOt-0007uR-IH for manet@optimus.ietf.org; Thu, 04 Mar 2004 10:04:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23942 for ; Thu, 4 Mar 2004 10:04:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyuOr-0001j5-00 for manet@ietf.org; Thu, 04 Mar 2004 10:04:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyuOB-0001Z1-00 for manet@ietf.org; Thu, 04 Mar 2004 10:03:55 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AyuNa-0001Nd-00 for manet@ietf.org; Thu, 04 Mar 2004 10:03:18 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i24F3Git003820; Thu, 4 Mar 2004 16:03:16 +0100 (MET) Subject: Re: SV: RE: [manet] Default Routes (Intern) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: Paal.Engelstad@telenor.com Cc: "'manet'" In-Reply-To: <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> References: <000601c401b3$162b80a0$ef70fe81@jafymobile> <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> Content-Type: text/plain Message-Id: <1078412596.5224.80.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 04 Mar 2004 16:03:16 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-03-04 at 15:35, Paal.Engelstad@telenor.com wrote: > Erik, > > On a side note: I am just wondering if your solution really is fully transparent as you claimed? Does not AODV also use the source IP addresses of data packets to keep routes up to date... and without tunneling from GW...? Comments? > The source address is not changed in the encapsulated packet... Only the destination is "rewritten" to be the gateway. Therefore it is fully transparent in the sense that intermediate nodes only have to run a standards compliant AODV implementation. If Mobile IP is used the source address is the node's home address and will by MIP be tunneled to the correct gateway (FA) where the node is registered. Since this home address is routable in the ad hoc network there is no need for a tunnel from the gateway to the ad hoc node. Does this answer your question? /Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 10:34:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26801 for ; Thu, 4 Mar 2004 10:34:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyurI-0006LL-0b for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 10:34:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24FXxPp024382 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 10:33:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyurH-0006LA-PW for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 10:33:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26790 for ; Thu, 4 Mar 2004 10:33:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyurF-00005r-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 10:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyuqP-0007g3-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 10:33:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayupe-0007Rm-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 10:32:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyupO-00060X-2G; Thu, 04 Mar 2004 10:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyupJ-00060B-9g for manet@optimus.ietf.org; Thu, 04 Mar 2004 10:31:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26487 for ; Thu, 4 Mar 2004 10:31:53 -0500 (EST) From: Paal.Engelstad@telenor.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyupG-0007OI-00 for manet@ietf.org; Thu, 04 Mar 2004 10:31:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyuoL-00078h-00 for manet@ietf.org; Thu, 04 Mar 2004 10:30:58 -0500 Received: from virus-out.ttyl.com ([193.212.240.200] helo=virus-out-st.online.no) by ietf-mx with esmtp (Exim 4.12) id 1AyunM-0006gB-00 for manet@ietf.org; Thu, 04 Mar 2004 10:29:57 -0500 Received: from tns-fbu-22-208.corp.telenor.no ([134.47.162.90] [134.47.162.90]) by scan.telenor.net with ESMTP; Thu, 4 Mar 2004 16:28:38 +0100 Received: from moffice3.nsc.no ([10.122.115.83]) by tns-fbu-22-208.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Mar 2004 16:28:37 +0100 Message-Id: <22188493.1078414117309.JavaMail.adm-moff@moffice3.nsc.no> To: =?iso-8859-1?Q?Erik_Nordstr=F6m?= To: Subject: SV: Re: SV: RE: [manet] Default Routes (Intern) Cc: "'manet'" In-Reply-To: <1078412596.5224.80.camel@dhcp-8-241.it.uu.se> X-Priority: 3 (Normal) X-Mailer: Mobile Office v1.0 (Telenor Business Solutions) References: <000601c401b3$162b80a0$ef70fe81@jafymobile> <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> <1078412596.5224.80.camel@dhcp-8-241.it.uu.se> X-OriginalArrivalTime: 04 Mar 2004 15:28:37.0618 (UTC) FILETIME=[5D420D20:01C401FD] Date: 4 Mar 2004 16:28:37 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1289_10384886.1078414117307" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ------=_Part_1289_10384886.1078414117307 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Erik and Guilliaume,=20 You both misunderstood the question and what the potensial problem is about= , so I take that as evidence that I need to express myself more clearly. - First, to address Guilliaumes comment: "Tunneling" is not a clear word: i= s CN->MN communication in MIP6 tunneling or not? So let us use the word "En= capsulation" and "Source Routing" instead. - Encapsulation from Manet Node to Gw is straightforward (and probably a sa= tisfactory IPv4 solution). Source routing is also an option (and preferable= with IPv6). This is not the question! Let us not discuss that. - Here is the question: If you do not do "encapsulation" (thanks, Guilliaum= e, for clarifying that source routing does NOT work in this case) of the re= turn/inbound packets from GW to the MANET node, you import external address= es into the routing system. Normally, AODV would update the outgoing route = (to the gateway) based on the source address of the incoming (un-encapsulat= ed!) traffic. However, this incoming un-encapsulated traffic use external a= ddresses as source addresses. This is why I believe your solution is not fully transparent. And this is w= hat I asked your comment on.=20 Got it? Paal > From: Erik Nordstr=F6m [erik.nordstrom@it.uu.se] > Sent: 2004-03-04 16:03:16 CET > To: Paal.Engelstad@telenor.com > Cc: 'manet' [manet@ietf.org] > Subject: Re: SV: RE: [manet] Default Routes (Intern) >=20 > On Thu, 2004-03-04 at 15:35, Paal.Engelstad@telenor.com wrote: > > Erik, > >=20 > > On a side note: I am just wondering if your solution really is fully tr= ansparent as you claimed? Does not AODV also use the source IP addresses of= data packets to keep routes up to date... and without tunneling from GW...= ? Comments? > >=20 >=20 > The source address is not changed in the encapsulated packet... Only the > destination is "rewritten" to be the gateway. Therefore it is fully > transparent in the sense that intermediate nodes only have to run a > standards compliant AODV implementation. If Mobile IP is used the source > address is the node's home address and will by MIP be tunneled to the > correct gateway (FA) where the node is registered. Since this home > address is routable in the ad hoc network there is no need for a tunnel > from the gateway to the ad hoc node. >=20 > Does this answer your question? >=20 > /Erik >=20 >=20 ------=_Part_1289_10384886.1078414117307-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 10:46:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27642 for ; Thu, 4 Mar 2004 10:46:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv3K-0007r1-AO for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 10:46:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24FkQWm030185 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 10:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv3K-0007qm-6y for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 10:46:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27595 for ; Thu, 4 Mar 2004 10:46:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv3H-0002dD-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 10:46:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayv25-0002N4-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 10:45:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv1L-000280-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 10:44:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv0z-0007SK-F6; Thu, 04 Mar 2004 10:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv0f-0007R3-2k for manet@optimus.ietf.org; Thu, 04 Mar 2004 10:43:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27353 for ; Thu, 4 Mar 2004 10:43:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv0c-000246-00 for manet@ietf.org; Thu, 04 Mar 2004 10:43:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayuze-0001rb-00 for manet@ietf.org; Thu, 04 Mar 2004 10:42:39 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1Ayuyk-0001fx-00 for manet@ietf.org; Thu, 04 Mar 2004 10:41:42 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i24FfeXn011210; Thu, 4 Mar 2004 16:41:40 +0100 (MET) Subject: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: Paal.Engelstad@telenor.com Cc: "'manet'" In-Reply-To: <22188493.1078414117309.JavaMail.adm-moff@moffice3.nsc.no> References: <000601c401b3$162b80a0$ef70fe81@jafymobile> <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> <1078412596.5224.80.camel@dhcp-8-241.it.uu.se> <22188493.1078414117309.JavaMail.adm-moff@moffice3.nsc.no> Content-Type: text/plain; charset=UTF-8 Message-Id: <1078414900.5224.92.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 04 Mar 2004 16:41:40 +0100 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by aun.it.uu.se id i24FfeXn011210 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Paal, Ok, I understand what you mean. This might be an issue for specific protocols and I guess for transperency you have to make tradeoffs. In the AODV case this is not such a big issue, the gateway route will be refreshed by the outgoing traffic (if using TCP), and I think that is sufficient. If outgoing traffic is one way (UDP) there is no issue. The only problem is incoming UDP traffic which is one way. In that case, it does not really matter if the (reverse) gateway route times out, since no traffic goes in that direction anyway. If transparency is important, it is possible to encapsulate traffic (by rewriting the source address) from the gateway to the source node too, but increases complexity and overhead a bit. However, because of the above mentioned reasons, I do not think that this matters for AODV. Or do you think differently? //Erik Thu, 2004-03-04 at 16:28, Paal.Engelstad@telenor.com wrote: > Erik and Guilliaume,=20 >=20 > You both misunderstood the question and what the potensial problem is a= bout, so I take that as evidence that I need to express myself more clear= ly. >=20 > - First, to address Guilliaumes comment: "Tunneling" is not a clear wor= d: is CN->MN communication in MIP6 tunneling or not? So let us use the wo= rd "Encapsulation" and "Source Routing" instead. >=20 > - Encapsulation from Manet Node to Gw is straightforward (and probably = a satisfactory IPv4 solution). Source routing is also an option (and pref= erable with IPv6). This is not the question! Let us not discuss that. >=20 > - Here is the question: If you do not do "encapsulation" (thanks, Guill= iaume, for clarifying that source routing does NOT work in this case) of = the return/inbound packets from GW to the MANET node, you import external= addresses into the routing system. Normally, AODV would update the outgo= ing route (to the gateway) based on the source address of the incoming (u= n-encapsulated!) traffic. However, this incoming un-encapsulated traffic = use external addresses as source addresses. >=20 > This is why I believe your solution is not fully transparent. And this = is what I asked your comment on.=20 >=20 > Got it? >=20 > Paal >=20 >=20 >=20 >=20 > > From: Erik Nordstr=C3=B6m [erik.nordstrom@it.uu.se] > > Sent: 2004-03-04 16:03:16 CET > > To: Paal.Engelstad@telenor.com > > Cc: 'manet' [manet@ietf.org] > > Subject: Re: SV: RE: [manet] Default Routes (Intern) > >=20 > > On Thu, 2004-03-04 at 15:35, Paal.Engelstad@telenor.com wrote: > > > Erik, > > >=20 > > > On a side note: I am just wondering if your solution really is full= y transparent as you claimed? Does not AODV also use the source IP addres= ses of data packets to keep routes up to date... and without tunneling fr= om GW...? Comments? > > >=20 > >=20 > > The source address is not changed in the encapsulated packet... Only = the > > destination is "rewritten" to be the gateway. Therefore it is fully > > transparent in the sense that intermediate nodes only have to run a > > standards compliant AODV implementation. If Mobile IP is used the sou= rce > > address is the node's home address and will by MIP be tunneled to the > > correct gateway (FA) where the node is registered. Since this home > > address is routable in the ad hoc network there is no need for a tunn= el > > from the gateway to the ad hoc node. > >=20 > > Does this answer your question? > >=20 > > /Erik > >=20 > >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 11:36:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00825 for ; Thu, 4 Mar 2004 11:36:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyvpL-0004ZR-51 for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 11:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Ga3Ug017568 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 11:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyvpK-0004ZH-W7 for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 11:36:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00799 for ; Thu, 4 Mar 2004 11:35:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyvpJ-0005oI-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:36:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyvoI-0005Xk-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:34:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyvnR-0005KS-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:34:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyvmP-0004GR-Hs; Thu, 04 Mar 2004 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayvm5-0004Fs-8M for manet@optimus.ietf.org; Thu, 04 Mar 2004 11:32:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00624 for ; Thu, 4 Mar 2004 11:32:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayvm4-000548-00 for manet@ietf.org; Thu, 04 Mar 2004 11:32:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyvlF-0004tV-00 for manet@ietf.org; Thu, 04 Mar 2004 11:31:49 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27] helo=i2r.a-star.edu.sg) by ietf-mx with esmtp (Exim 4.12) id 1Ayvku-0004ie-00 for manet@ietf.org; Thu, 04 Mar 2004 11:31:29 -0500 Received: from newmailhost (localhost [127.0.0.1]) by i2r.a-star.edu.sg (8.12.10/8.12.10) with ESMTP id i24GUHF1007022 for ; Fri, 5 Mar 2004 00:30:17 +0800 (SGT) Received: from localhost.localdomain ([192.168.152.135]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HU200KFR8IN8J@mailhost.lit.org.sg> for manet@ietf.org; Fri, 05 Mar 2004 00:30:25 +0800 (SGT) Received: by localhost.localdomain (Postfix, from userid 1000) id 9D30F4331E; Fri, 05 Mar 2004 00:31:16 +0800 (SGT) Date: Fri, 05 Mar 2004 00:31:16 +0800 From: "Sukanta K. Hazra" Subject: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) In-reply-to: <1078414900.5224.92.camel@dhcp-8-241.it.uu.se> To: "'manet'" Mail-followup-to: 'manet' Message-id: <20040304163116.GA13339@i2r.a-star.edu.sg> Organization: Institute for Infocomm Research MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 User-Agent: Mutt/1.5.4i References: <000601c401b3$162b80a0$ef70fe81@jafymobile> <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> <1078412596.5224.80.camel@dhcp-8-241.it.uu.se> <22188493.1078414117309.JavaMail.adm-moff@moffice3.nsc.no> <1078414900.5224.92.camel@dhcp-8-241.it.uu.se> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Erik, A short comment inline. > Paal, > > Ok, I understand what you mean. This might be an issue for specific > protocols and I guess for transperency you have to make tradeoffs. In > the AODV case this is not such a big issue, the gateway route will be > refreshed by the outgoing traffic (if using TCP), and I think that is > sufficient. If outgoing traffic is one way (UDP) there is no issue. The > only problem is incoming UDP traffic which is one way. In that case, it > does not really matter if the (reverse) gateway route times out, since > no traffic goes in that direction anyway. This is not strictly true. Even if the incoming UDP traffic is predominantly one way, there are often control messages sent in the reverse direction, and thus may need a route to the gateway. > > If transparency is important, it is possible to encapsulate traffic (by > rewriting the source address) from the gateway to the source node too, > but increases complexity and overhead a bit. > > However, because of the above mentioned reasons, I do not think that > this matters for AODV. Or do you think differently? > > //Erik > > > > Thu, 2004-03-04 at 16:28, Paal.Engelstad@telenor.com wrote: > > Erik and Guilliaume, > > > > You both misunderstood the question and what the potensial problem is about, so I take that as evidence that I need to express myself more clearly. > > > > - First, to address Guilliaumes comment: "Tunneling" is not a clear word: is CN->MN communication in MIP6 tunneling or not? So let us use the word "Encapsulation" and "Source Routing" instead. > > > > - Encapsulation from Manet Node to Gw is straightforward (and probably a satisfactory IPv4 solution). Source routing is also an option (and preferable with IPv6). This is not the question! Let us not discuss that. > > > > - Here is the question: If you do not do "encapsulation" (thanks, Guilliaume, for clarifying that source routing does NOT work in this case) of the return/inbound packets from GW to the MANET node, you import external addresses into the routing system. Normally, AODV would update the outgoing route (to the gateway) based on the source address of the incoming (un-encapsulated!) traffic. However, this incoming un-encapsulated traffic use external addresses as source addresses. > > > > This is why I believe your solution is not fully transparent. And this is what I asked your comment on. > > > > Got it? > > > > Paal > > > > > > > > > > > From: Erik Nordstr??m [erik.nordstrom@it.uu.se] > > > Sent: 2004-03-04 16:03:16 CET > > > To: Paal.Engelstad@telenor.com > > > Cc: 'manet' [manet@ietf.org] > > > Subject: Re: SV: RE: [manet] Default Routes (Intern) > > > > > > On Thu, 2004-03-04 at 15:35, Paal.Engelstad@telenor.com wrote: > > > > Erik, > > > > > > > > On a side note: I am just wondering if your solution really is fully transparent as you claimed? Does not AODV also use the source IP addresses of data packets to keep routes up to date... and without tunneling from GW...? Comments? > > > > > > > > > > The source address is not changed in the encapsulated packet... Only the > > > destination is "rewritten" to be the gateway. Therefore it is fully > > > transparent in the sense that intermediate nodes only have to run a > > > standards compliant AODV implementation. If Mobile IP is used the source > > > address is the node's home address and will by MIP be tunneled to the > > > correct gateway (FA) where the node is registered. Since this home > > > address is routable in the ad hoc network there is no need for a tunnel > > > from the gateway to the ad hoc node. > > > > > > Does this answer your question? > > > > > > /Erik > > > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- Sukanta K. Hazra (Mr.) Institute for Infocomm Research Tel: +65 6874-1953 Fax: +65 6776-8109 Homepage: http://www1.i2r.a-star.edu.sg/~sukanta/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 11:50:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01668 for ; Thu, 4 Mar 2004 11:50:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayw37-0007SJ-Sb for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 11:50:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24GoHHg028653 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 11:50:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayw37-0007S4-Nk for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 11:50:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01644 for ; Thu, 4 Mar 2004 11:50:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayw36-0001BU-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:50:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayw29-0000wD-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:49:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayw1N-0000gf-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:48:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayw1N-0002XO-LB for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:48:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayw0v-0007CT-TC; Thu, 04 Mar 2004 11:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayvzy-0006nh-TN for manet@optimus.ietf.org; Thu, 04 Mar 2004 11:47:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01447 for ; Thu, 4 Mar 2004 11:46:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayvzx-0000R0-00 for manet@ietf.org; Thu, 04 Mar 2004 11:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayvyz-0000DA-00 for manet@ietf.org; Thu, 04 Mar 2004 11:46:02 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27] helo=i2r.a-star.edu.sg) by ietf-mx with esmtp (Exim 4.12) id 1AyvyO-0007nW-00 for manet@ietf.org; Thu, 04 Mar 2004 11:45:24 -0500 Received: from newmailhost (localhost [127.0.0.1]) by i2r.a-star.edu.sg (8.12.10/8.12.10) with ESMTP id i24GiKF1007252 for ; Fri, 5 Mar 2004 00:44:20 +0800 (SGT) Received: from localhost.localdomain ([192.168.152.135]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HU200KO29648J@mailhost.lit.org.sg> for manet@ietf.org; Fri, 05 Mar 2004 00:44:28 +0800 (SGT) Received: by localhost.localdomain (Postfix, from userid 1000) id 359044331E; Fri, 05 Mar 2004 00:45:22 +0800 (SGT) Date: Fri, 05 Mar 2004 00:45:22 +0800 From: "Sukanta K. Hazra" Subject: Re: [manet] Will there be a collision??? In-reply-to: <20040302150513.84408.qmail@web60907.mail.yahoo.com> To: manet@ietf.org Mail-followup-to: manet@ietf.org Message-id: <20040304164522.GC13339@i2r.a-star.edu.sg> Organization: Institute for Infocomm Research MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 User-Agent: Mutt/1.5.4i References: <20040302150513.84408.qmail@web60907.mail.yahoo.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi! I once read a paper title something like "Interference is in the ears of the receiver" (can't recall the exact title), and it made a lot of things clear. Yes, it depends on the radio design and the mac. Google for the paper, and it might be of help. - Sukanta ----- Original Message ----- From: "Jas C " Date: Tue, 02 Mar, 2004 23:05 SGT Subject: [manet] Will there be a collision??? > Hello everyone, > > This is related to a doubt raised on "strong interfering signals". > > I need clarification on the following scenario based on a string topology where any node can only hear its immediate neighbors and a nodes interference range and transmission range are equal. > > If there are four nodes placed as A ---- B ---- C ----D , can B transmit to A and C to D at the same time without there being a collision between B and C ? > > I understand that this is a typical exposed node problem and parallel transmissions are possible depending on the type of MAC protocol being used. > > My concern is if B and C are within each other's ranges wouldn't their transmissions collide whereby A and D would not receive anything ?? > > I would appreciate any suggestions/pointers to help me clear this doubt. > > Thanks a lot in advance, > Jasmina > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Search - Find what you?re looking for faster. -- Sukanta K. Hazra (Mr.) Institute for Infocomm Research Tel: +65 6874-1953 Fax: +65 6776-8109 Homepage: http://www1.i2r.a-star.edu.sg/~sukanta/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 12:54:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04221 for ; Thu, 4 Mar 2004 12:54:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayx2i-0004wI-Oi for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 12:53:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Hru8E018980 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 12:53:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayx2i-0004w3-I7 for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 12:53:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04211 for ; Thu, 4 Mar 2004 12:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayx2g-00066r-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 12:53:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayx1m-0005uK-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 12:52:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayx11-0005hW-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 12:52:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayx0s-0004Z2-0y; Thu, 04 Mar 2004 12:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayx0V-0004YK-UD for manet@optimus.ietf.org; Thu, 04 Mar 2004 12:51:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04097 for ; Thu, 4 Mar 2004 12:51:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayx0T-0005cq-00 for manet@ietf.org; Thu, 04 Mar 2004 12:51:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AywzV-0005PH-00 for manet@ietf.org; Thu, 04 Mar 2004 12:50:38 -0500 Received: from ims21.stu.nus.edu.sg ([137.132.14.228]) by ietf-mx with esmtp (Exim 4.12) id 1AywyU-00052b-00 for manet@ietf.org; Thu, 04 Mar 2004 12:49:34 -0500 Received: from MBXSRV23.stu.nus.edu.sg ([137.132.14.233]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Fri, 5 Mar 2004 01:49:25 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: Default Routes (WAS: Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt) Date: Fri, 5 Mar 2004 01:49:21 +0800 Message-ID: <97B6AED9BBAE4845B2559DA63E6ECDC250F0A9@MBXSRV23.stu.nus.edu.sg> Thread-Topic: [manet] Re: Default Routes (WAS: Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt) Thread-Index: AcQBB0P+sJY3pXoHR+yHJEGCAvGBSgBCRwWg From: "Sheena Lizen Barbosa" To: "Anders Nilsson" , , "manet" , X-OriginalArrivalTime: 04 Mar 2004 17:49:25.0258 (UTC) FILETIME=[08719EA0:01C40211] Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Anders, I just wanted to know if the implementation Nico Bayer presented at = EW2004 was with AODV6 or DSR? It's because we are working on a similar = implementation for DSR. Thanks and Regards, Sheena Final Year Student (B.Eng. Computer Engineering) National University of Singapore -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of = Anders Nilsson Sent: Wednesday, March 03, 2004 6:05 PM To: jafy@etri.re.kr; manet; Paal.Engelstad@telenor.com Subject: [manet] Re: Default Routes (WAS: Request of Comments on the i-d = ietf-cha-manet-aodv-internet-00.txt) Hello, I must say that I agree with all the comments about trying to coordinate = our efforts. (I am a co-author with Ryuji). It doesn't make any sense at all to have several drafts that say=20 basically the same thing, with some minor modifications. This is really=20 the case right now. But the fact that we have so similiar drafts tells=20 us that we are close to consensus, so making a common requirement=20 document shouldn't be too hard. Having several drafts is really bad, and = makes things bad for the implementors. There are implementors out there=20 trying to implement these features, and they are clearly confused by all = the different drafts. Nico Bayer have an implementation that he=20 presented last week at EW2004, that closely follows the globalv6 draft.=20 This is great, and although the imp. seems to follow the draft closely,=20 there are some major differences to the draft. This could be explained=20 by the confusion created by the different drafts, but may also=20 implementation choices. Either way, a consensus is needed. >Although I admit that I was inspired and motivated by your draft, I do=20 >not think that your draft does address all related issues and propose=20 >all possilbe solutions. If you are interested in my suggestion, we can=20 >have good chance to share ideas and make productive work in this topic. > =20 > Please point out what you think is wrong. > =20 >As for your comment on my draft, please take it easy. > >[The draft says] >one including [1 globalv6], [2], [3] which use next hop forwarding for=20 >default routes and the other including [1 globalv6] which do not use=20 >next hop forwarding and require that a sender specifies a gateway in=20 >routing header. > > =20 > What do you mean here? This is from Paals mail: > If you have two gateways announcing the same default route, the > MANET node has no control of which gateway the packet is routed=20 > out through. You might get problems with: > - Stateless firewalls: E.g. The first packet of your (TCP-) session=20 > might go out through another gateway than the one corresponding to=20 > the selected source IP address. Thus, the return inbound packets will=20 > not reach the gateway corresponding to the MANET node's source IP = address=20 > if the gateway is behind i firewall because no state is set in the = firewall. > - Ingress filtering: Outbound packets escaping out through "wrong" = gateways=20 > are filtered out. As pointed out earlier, this problem can solved by letting intermediate=20 forwarding nodes search their gateway list for the source prefix. If the = source prefix matches an entry in the gateway list, the packet is=20 forwarded to the indicated gateway. I think this solves the problem=20 stated above. However, there is an other problem here. If the node is=20 moving inside the network, it will probably want to switch to different=20 gateways as they become closer. The only way for this to work in the=20 mentioned solution is to onfigure a new address, which is not really a=20 good solution. If the different gateways belong to the same domain, it=20 might not even be possible, and routing header might be to prefer in=20 that case. I discuss this problem among other things in a paper to be=20 presented at WWC04, the main focus of the paper is performance though. regards, Anders _______________________________________________ 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 exim@www1.ietf.org Thu Mar 4 13:12:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05275 for ; Thu, 4 Mar 2004 13:12:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxKA-0007JV-Jq for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 13:11:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24IBw1h028107 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 13:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxKA-0007JG-Ci for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 13:11:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05264 for ; Thu, 4 Mar 2004 13:11:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxK8-0001zy-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:11:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxJ8-0001nt-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:10:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyxIP-0001c9-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:10:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxII-0006zj-V2; Thu, 04 Mar 2004 13:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxHP-0006y6-9B for manet@optimus.ietf.org; Thu, 04 Mar 2004 13:09:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05077 for ; Thu, 4 Mar 2004 13:09:02 -0500 (EST) From: Paal.Engelstad@telenor.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxHN-0001OE-00 for manet@ietf.org; Thu, 04 Mar 2004 13:09:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxGY-0001B1-00 for manet@ietf.org; Thu, 04 Mar 2004 13:08:15 -0500 Received: from virus-out.ttyl.com ([193.212.240.200] helo=virus-out-st.online.no) by ietf-mx with esmtp (Exim 4.12) id 1AyxFk-0000r6-00 for manet@ietf.org; Thu, 04 Mar 2004 13:07:24 -0500 Received: from tns-fbu-22-209.corp.telenor.no ([134.47.162.190] [134.47.162.190]) by scan.telenor.net with ESMTP; Thu, 4 Mar 2004 19:06:50 +0100 Received: from moffice3.nsc.no ([10.122.115.83]) by tns-fbu-22-209.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Mar 2004 19:06:50 +0100 Message-Id: <33346562.1078423610035.JavaMail.adm-moff@moffice3.nsc.no> To: =?iso-8859-1?Q?Erik_Nordstr=F6m?= To: Subject: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) Cc: "'manet'" In-Reply-To: <1078414900.5224.92.camel@dhcp-8-241.it.uu.se> X-Priority: 3 (Normal) X-Mailer: Mobile Office v1.0 (Telenor Business Solutions) References: <000601c401b3$162b80a0$ef70fe81@jafymobile> <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> <1078412596.5224.80.camel@dhcp-8-241.it.uu.se> <22188493.1078414117309.JavaMail.adm-moff@moffice3.nsc.no> <1078414900.5224.92.camel@dhcp-8-241.it.uu.se> X-OriginalArrivalTime: 04 Mar 2004 18:06:50.0077 (UTC) FILETIME=[773458D0:01C40213] Date: 4 Mar 2004 19:06:50 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1347_373324.1078423610033" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ------=_Part_1347_373324.1078423610033 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Erik, No, I am very much in line with your thinking here.=20 By simple reasoning, I drew more or less the same conclusions as you did. B= ut I am not 100% sure, since we have not tested the differences between the= "ideal" to-way-tunneling and one-way-tunneling. (In fact, we tested both, = based on your AODV-UU code, thanks!, but we have not made any proper compar= izons.)=20 My current standing is that the "ideal" Internet access mechanism, as far a= s routing is concerned, is tunneling in both directions: source routing (IP= v6) or encapsulation (IPv4) of outbound traffic via the gateway and encapsu= lation of inbound traffic from gateway to MANET node (IPv4 and IPv6). From = there you start to make optimizations to save bandwidth etc., and each opti= mization resembles a "hack", i.e. it undermines the ideal model. =20 - The first step is to go from two-way to one-way tunneling, as we have jus= t discussed.=20 - The next is perhaps your proposal to "rewrite" destination addresses at t= he GW, as you seem to propose (It does not sound good, IMHO. I think we hav= e to accespt that we might need NAT for outgoing IPv4 traffic, but I hope y= ou do not need it for incoming traffic as well.) - Another alternative is to use source-address-based routing. This "hack" m= eans that all outgoing traffic MUST have a souce IP addres under the gatewa= ys prefix. I.e. it will not work for IPv4, where you use private/IPv4-link-= local address with NATs or home-address with a MIP-FA based gateway. It wil= l also exclude every future IPv6 protocol that might need to use a source a= ddress that is not topologically correct for any gateway - i.e. this soluti= on is also a "hack". - The next step is perhaps to introduce Proxy RREPs (AODV, i.e. gateway imp= ersonates external hosts when sending RREP, see the old globalv4/MIPv4 draf= t) or to use default routes (e.g. OLSR). Here you might introduce routing r= ace conditions, and also race conditions between MANET nodes that have pref= erence for using different gateways but who are communicating with the same= external host. - And so on... What I have yet to understand (and this is why I initiated this discussion = on "default routes") is the reason for default routes: i) Is it necesary ii= ) can it enhance routing performance of external traffic iii) or is it simp= ly an optimization (or "hack") to save bandwidth. Due to radio/link dynamics and mobility, the routing protocols are providin= g a service that is inherently not robust. What is my concern is that the d= efault routes, and the route selection mechansims necessary, are also not r= ebust and prone to malfunctioning due to network dynamics. Intuitively, def= ault routes adds an additional unpredictable element, in addition to the un= predictability of the routing. With tunneling, on the contrary, we have only one single problem: How to ma= ke the routing protocol robust. Thoughts? Paal > Paal, >=20 > Ok, I understand what you mean. This might be an issue for specific > proto cols and I guess for transperency you have to make tradeoffs. In > the AODV case this is not such a big issue, the gateway route will be > refreshed by the outgoing traffic (if using TCP), and I think that is > sufficient. If outgoing traffic is one way (UDP) there is no issue. The > only problem is incoming UDP traffic which is one way. In that case, it > does not really matter if the (reverse) gateway route times out, since > no traffic goes in that direction anyway. >=20 > If transparency is important, it is possible to encapsulate traffic (by > rewriting the source address) from the gateway to the source node too, > but increases complexity and overhead a bit. >=20 > However, because of the above mentioned reasons, I do not think that > this matters for AODV. Or do you think differently? >=20 > //Erik >=20 >=20 >=20 > Thu, 2004-03-04 at 16:28, Paal.Engelstad@telenor.com wrote: > > Erik and Guilliaume,=20 > >=20 > > You both misunderstood the question and what the potensial problem is a= bout, so I take that as evidence that I need to express myself more clearly= . > >=20 > > - First, to address Guilliaumes comment: "Tunneling" is not a clear wor= d: is CN->MN communication in MIP6 tunneling or not? So let us use the word= "Encapsulation" and "Source Routing" instead. > >=20 > > - Encapsulation from Manet Node to Gw is straightforward (and probably = a satisfactory IPv4 solution). Source routing is also an option (and prefer= able with IPv6). This is not the question! Let us not discuss that. > >=20 > > - Here is the question: If you do not do "encapsulation" (thanks, Guill= iaume, for clarifying that source routing does NOT work in this case) of th= e return/inbound packets from GW to the MANET node, you import external add= resses into the routing system. Normally, AODV would update the outgoing ro= ute (to the gateway) based on the source address of the incoming (un-encaps= ulated!) traffic. However, this incoming un-encapsulated traffic use extern= al addresses as source addresses. > >=20 > > This is why I believe your solution is not fully transparent. And this = is what I asked your comment on.=20 > >=20 > > Got it? > >=20 > > Paal > >=20 > >=20 > >=20 > >=20 > > > From: Erik Nordstr=F6m [erik.nordstrom@it.uu.se] > > > Sent: 2004-03-04 16:03:16 CET > > > To: Paal.Engelstad@telenor.com > > > Cc: 'manet' [manet@ietf.org] > > > Subject: Re: SV: RE: [manet] Default Routes (Intern) > > >=20 > > > On Thu, 2004-03-04 at 15:35, Paal.Engelstad@telenor.com wrote: > > > > Erik, > > > >=20 > > > > On a side note: I am just wondering if your solution really is full= y transparent as you claimed? Does not AODV also use the source IP addresse= s of data packets to keep routes up to date... and without tunneling from G= W...? Comments? > > > >=20 > > >=20 > > > The source address is not changed in the encapsulated packet... Only = the > > > destination is "rewritten" to be the gateway. Therefore it is fully > > > transparent in the sense that intermediate nodes only have to run a > > > standards compliant AODV implementation. If Mobile IP is used the sou= rce > > > address is the node's home address and will by MIP be tunneled to the > > > correct gateway (FA) where the node is registered. Since this home > > > address is routable in the ad hoc network there is no need for a tunn= el > > > from the gateway to the ad hoc node. > > >=20 > > > Does this answer your question? > > >=20 > > > /Erik > > >=20 > > >=20 >=20 ------=_Part_1347_373324.1078423610033-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 13:20:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05812 for ; Thu, 4 Mar 2004 13:20:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxRs-0007qF-Dg for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 13:19:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24IJuca030138 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 13:19:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxRr-0007q1-Qy for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 13:19:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05762 for ; Thu, 4 Mar 2004 13:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxRp-0003aP-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:19:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxQr-0003NR-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:18:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyxQO-0003C2-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:18:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxQ1-0007Xp-As; Thu, 04 Mar 2004 13:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxPg-0007Wm-Vr for manet@optimus.ietf.org; Thu, 04 Mar 2004 13:17:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05667 for ; Thu, 4 Mar 2004 13:17:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxPf-0003A2-00 for manet@ietf.org; Thu, 04 Mar 2004 13:17:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxOk-0002zA-00 for manet@ietf.org; Thu, 04 Mar 2004 13:16:42 -0500 Received: from mail.ece.gatech.edu ([199.77.227.200]) by ietf-mx with esmtp (Exim 4.12) id 1AyxNm-0002nc-00 for manet@ietf.org; Thu, 04 Mar 2004 13:15:42 -0500 Received: from yamsrv2.ece.gatech.edu (yamsrv2.ece.gatech.edu [130.207.232.10]) by mail.ece.gatech.edu (8.12.10/8.12.9) with ESMTP id i24IFgPH004964 for ; Thu, 4 Mar 2004 13:15:42 -0500 (EST) Received: from localhost (jau@localhost) by yamsrv2.ece.gatech.edu (8.12.0.Beta19/8.12.0.Beta19/Submit) with ESMTP id i24IFfnh006768 for ; Thu, 4 Mar 2004 13:15:41 -0500 (EST) Date: Thu, 4 Mar 2004 13:15:41 -0500 (EST) From: Jaudelice Cavalcante de Oliveira To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-SPAM: NO Subject: [manet] Med-Hoc-Net 2004 - Deadline approaching: March 12 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 We apologize if you receive multiple copies of this message. ------------------------------------------------------------------------------ ANNOUNCEMENTS: - PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004. - PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM ------------------------------------------------------------------------------ Med-Hoc-Net 2004 The Third Annual Mediterranean Ad Hoc Networking Workshop June 27-30, 2004, Bodrum, Turkey http://www.medhoc04/diit/unict.it Call for Papers ------------------------------------------------------------------------------ Scope: Ad hoc network applications are emerging continuously imposing their own stringent constraints which cannot be fulfilled by generic approaches and thus spur new research efforts. Therefore, ad hoc networks attract growing attention from the research community. The aim of Med-Hoc-Net 2004 is to serve as a platform for researchers and visionaries from academia, research labs, and industry from all over the globe to share their ideas, views, results, and experiences in the field of ad-hoc networking and communications. Med-Hoc-Net 2004 will include presentations of theoretical and experimental achievements, innovative ad-hoc systems, prototyping efforts, case studies, and advancements in technology directly affecting ad-hoc networking and communications infrastructures. The papers solicited in Med-Hoc-Net 2004 cover a variety of topics including but not limited to: - Novel ad-hoc network architectures and applications, - Sensor network applications and protocols, - Implementations, testbeds, and prototypes, - Interfacing ad-hoc systems with different networks, - Resource discovery and management, - Power management and control, - Call admission and traffic shaping policies for ad-hoc networks, - Multimedia location services, - Self organization and network reconfiguration, - Protocols for QoS support in ad-hoc networks, - QoS support in Bluetooth, HIPERLAN, IEEE 802.11 etc., - MAC protocols, scheduling, and radio resource sharing in ad hoc networks, - Unicast and multicast routing algorithms and protocols, - Transport layer protocols for multi-hop networks, - Congestion control, - Performance evaluation of ad-hoc network protocols through simulations, analysis, and measurements, - Security in ad-hoc networks, - Fault tolerance and error recovery - Signal processing algorithms (coding, compression) for ad-hoc networks The program committee will referee all papers, and accepted papers will be published in the conference proceedings. Papers of particular merit will be published in the Elsevier Ad Hoc Networks Journal. Manuscripts must be formatted according to the IEEE double-column standard format, except the font size, which must be 11pt. Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or their equivalent. The maximum length of the manuscript is 12 pages. NEW: THE PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004 PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM Papers should be submitted in pdf or ps format through EDAS system (http://edas.info) according to the following timetable: Important Dates: Full Paper Electronic Submission: March 12, 2004 Tutorial proposal submission: April 15, 2004 Notification of Acceptance/Rejection: May 3, 2004 Camera ready submission of full papers: May 17, 2004 Tutorial date: June 27, 2004 Conference dates: June 28-30, 2004 Organization Committee: General Chair: Ian F. Akyildiz, Georgia Institute of Technology, USA General Vice Chair: Erdal Cayirci, Istanbul Technical University, TURKEY Technical Program Chairs: Giacomo Morabito, University of Catania, ITALY Eylem Ekici, Ohio State University, USA Tutorial Chairs: Francesca Cuomo, University of Rome - La Sapienza, ITALY Christos Douligeris, University of Piraeus, GREECE Publicity Chairs: Buyurman Baykal, Middle East Technical University, TURKEY Jaudelice Cavalcante de Oliveira, Drexel University, USA Registration Chair: Sebnem Baydere, Yeditepe University, TURKEY Technical Program Committee: Khaldoun Al Agha, Laboratoire de Recherche en Informatique, FRANCE Hamid Aghvami, King's College London, UK Eitan Altman, INRIA, FRANCE Roberto Battiti, University of Trento, ITALY Raouf Boutaba, University of Waterloo, CANADA Walid Dabbous, INRIA, FRANCE Magda El Zarki, University of California at Irvine, USA Luigi Fratta, Politecnico di Milano, ITALY Mario Gerla, UCLA, USA Paul J. M. Havinga, University of Twente, NETHERLANDS Ahmed Helmy, University of Southern California, USA Farouk Kamoun, ENSI, TUNISIA Holger Karl, Technical University of Berlin, GERMANY Ulf Korner, Lund Institute of Technology, SWEDEN Bhaskar Krishnamachari, University of Southern California, USA Marwan Krunz, University of Arizona, USA Albert Levi, Sabanci University, TURKEY Janise McNair, University of Florida, USA Lazaros Merakos, University of Athens, GREECE Ioanis Nikolaidis, University of Alberta, CANADA Ariel Orda, Technion, ISRAEL Sergio Palazzo, University of Catania, ITALY Giovanni Pau, UCLA, USA Chiara Petrioli, University of Rome "La Sapienza", ITALY Andreas Pitsillides, University of Cyprus, CYPRUS Guy Pujolle, LIP6, FRANCE Paolo Santi, CNR, ITALY Adrian Segall, Technion, ISRAEL Ness Shroff, Purdue University, USA Moshe Sidi, Technion, ISRAEL Raghupathy Sivakumar, Georgia Institute of Technology, USA Ioannis Stavrakakis, University of Athens, GREECE Ivan Stojmenovic, University of Ottawa, CANADA Violet R. Syrotiuk, Arizona State University, USA Leandros Tassiulas, University of Thessaly, GREECE Damla Turgut, University of Central Florida, USA Bernhard H. Walke, Aachen University of Technology, GERMANY Wenye Wang, North Carolina State University, USA Michele Zorzi, University of Ferrara, ITALY _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 13:36:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06546 for ; Thu, 4 Mar 2004 13:36:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxhL-00010o-Rt for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 13:35:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24IZtmH003891 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 13:35:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxhL-00010g-Ib for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 13:35:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06512 for ; Thu, 4 Mar 2004 13:35:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxhI-0006dT-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:35:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxgJ-0006Rf-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:34:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayxfh-0006Gj-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:34:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxfV-0000cl-VV; Thu, 04 Mar 2004 13:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxfH-0000bg-4f for manet@optimus.ietf.org; Thu, 04 Mar 2004 13:33:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06450 for ; Thu, 4 Mar 2004 13:33:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxfE-0006Fa-00 for manet@ietf.org; Thu, 04 Mar 2004 13:33:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxeJ-00065h-00 for manet@ietf.org; Thu, 04 Mar 2004 13:32:47 -0500 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1Ayxdv-0005vp-00 for manet@ietf.org; Thu, 04 Mar 2004 13:32:24 -0500 Received: from user-2ivfms1.dialup.mindspring.com ([165.247.219.129] helo=earthlink.net) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Ayxdp-0007cK-00; Thu, 04 Mar 2004 10:32:17 -0800 Message-ID: <4047762E.1080401@earthlink.net> Date: Thu, 04 Mar 2004 10:32:14 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Christophe Jelger CC: guillaume.chelius@insa-lyon.fr, manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <40470344.3070202@insa-lyon.fr> <404714FE.2010207@dpt-info.u-strasbg.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christophe Jelger wrote: > Guillaume, > > Just on point, see inline my comment. In general I agree that gateway > discovery should not be separated, as stated in the draft. We first > implemented it as a stand-alone process to check the operation. As you > know, we plan to integrate it into OLSR. (see below for a last comment) > > With prefix continuity, routes are optimal if we use the "distance" > algorithm : always choose closest gateway. In that case the route is a > shortest route, but it can be different than the shortest route > computed by the routing protocol. On the other hand, if we use the > algorithm "prefix stability", then the route might not be optimal (I'm > currently simulating this and it appears that routes are not much > longer on average). > So, the gateway discovery protocol (which uses distance vectors) computes a route to some gateway, and the link-state routing protocol (e.g., OLSR or TBRPF or OSPF) computes a route to each gateway, which may be different from the one computed by the gateway discovery protocol. Also, it is possible that the link-state protocol reacts to topology changes faster or slower than the gateway protocol. Wouldn't it be nice if the two protocols could *agree* on the route to each gateway? I would prefer to remove this redundancy, and just have one routing protocol that computes the routes to all nodes, including routes to gateways and default routes. Several people (including Joe Macker, Chelius Guillaume, Pedro Ruiz, Eric Fleury) have agreed that it would be better to avoid redundancy between the proactive routing protocol and gateway discovery. Can we agree that we have consensus on this Now, you may say that the proactive routing protocol still needs some mechanism to achieve prefix continuity. IF we decide we need to ensure prefix continuity (and I have doubts about this), then the link-state routing protocol can be modified to achieve this, using link-state routing (instead of distance vectors). Regards, Richard > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 13:39:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06679 for ; Thu, 4 Mar 2004 13:39:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxkF-0001st-AP for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 13:38:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24IctoV007237 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 13:38:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxkE-0001se-Vu for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 13:38:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06649 for ; Thu, 4 Mar 2004 13:38:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxkC-0007Fg-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:38:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxjH-00073M-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:37:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyxiT-0006ro-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 13:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxiR-00016Z-Nt; Thu, 04 Mar 2004 13:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyxiI-00013h-Qs for manet@optimus.ietf.org; Thu, 04 Mar 2004 13:36:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06596 for ; Thu, 4 Mar 2004 13:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyxiG-0006ps-00 for manet@ietf.org; Thu, 04 Mar 2004 13:36:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyxhR-0006ed-00 for manet@ietf.org; Thu, 04 Mar 2004 13:36:01 -0500 Received: from gateway.scalable-networks.com ([63.205.33.202] helo=mithrandir.scalable-networks.com) by ietf-mx with smtp (Exim 4.12) id 1AyxgU-0006SW-00 for manet@ietf.org; Thu, 04 Mar 2004 13:35:02 -0500 Received: (qmail 13509 invoked from network); 4 Mar 2004 18:34:36 -0000 Received: from web.lan.scalable-solutions.com (HELO cs.ucla.edu) (sssmail@192.168.0.1) by mithrandir.lan.scalable.networks.com with SMTP; 4 Mar 2004 18:34:36 -0000 Message-ID: <404776AB.2040900@cs.ucla.edu> Date: Thu, 04 Mar 2004 10:34:19 -0800 From: Mineo Takai User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] MobiHoc 2004 Call for Posters 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=LINES_OF_YELLING, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Our apologies if you receive multiple copies of this message. ---------- CALL FOR POSTERS The Fifth ACM International Symposium on Mobile Ad Hoc Networking and Computing MobiHoc 2004 http://www.sigmobile.org/mobihoc/2004/ May 24-26, 2004 Tokyo, Japan MobiHoc 2004 is the fifth of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 at Long Beach, California, in 2002 at Lausanne, Switzerland, in 2003 at Annapolis, Maryland, and now in 2004 at Tokyo, Japan, on Monday through Wednesday, May 24-26, 2004. The symposium will include a poster session that highlights recent and on-going research that has not been published elsewhere. Poster submissions will be reviewed and the summaries of accepted posters will appear in the SIGMOBILE's Mobile Computing Communications Review (MC2R). Submissions should consist of a 2-page summary as well as a rough draft of the poster in PDF. Please see the website for further details or contact the Poster Co-Chairs, Mineo Takai and Srikanth V. Krishnamurthy . SUBMISSION INSTRUCTIONS: Submissions for posters should be unpublished and must not be currently under review for any other publication, conference or workshop. Authors of accepted posters will need to sign an ACM copyright release form and present their poster at the conference. All poster submissions will be reviewed and their summaries will appear in the SIGMOBILE's Mobile Computing & Communications Review (MC2R). Poster submissions consist of two parts -- a two-page summary, and a draft of the poster layout. Both parts of the submission must be in PDF. The summary must be formatted for US Letter (8.5" x 11") paper with 1" margins all around, 10 point font (minimum), and single line spacing (minimum) for the main text. The purpose of the summary is to evaluate the quality, interest and depth of the work to be presented. The summary is the primary item for review consideration. The poster draft may be either a single sheet or multiple sheets (all 8.5" x 11"). The draft is meant to provide an initial impression of the organization and presentation of the work. It does not need to be a completed poster but needs to at least convey the flow and presentation of what will be the final poster. The final posters will be 1 x 1.25 meters. We must be able to print your summary and draft once they are submitted. Due to the large variety of systems available for formatting papers and producing PDF, this is not always possible for some systems. To maximize the chances that your paper will print correctly, please use only standard printer fonts (e.g., Times Roman, Helvetica, etc.); other fonts may be used but must be included in the PDF file. IMPORTANT: The two-page summary of the poster and the poster draft will be submitted to DIFFERENT places. The summary will be submitted over the web at http://edas.info (please select the MobiHoc Poster as the conference). The poster submission link will be enabled 10 days prior to the poster deadline. After you have successfully uploaded your summary, the poster draft should be mailed to the Poster Co-Chairs Mineo Takai and Srikanth V. Krishnamurthy indicating the Paper ID that was assigned to the poster summary by EDAS. IMPORTANT DATES: Poster Submission Deadline March 24, 2004 Notification of Acceptance April 19, 2004 Please see the website for further details or contact For further details or any questions about the poster session, please contact the Poster Co-Chairs, Mineo Takai and Srikanth V. Krishnamurthy . For more information about the symposium, please visit the MobiHoc 2004 Home Page at http://www.sigmobile.org/mobihoc/2004/, or send email to the General Chair, Jun Murai , or to . _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 14:34:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09747 for ; Thu, 4 Mar 2004 14:34:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyybU-0006Om-SQ for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 14:33:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24JXuDW024588 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 14:33:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyybU-0006OV-My for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 14:33:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09692 for ; Thu, 4 Mar 2004 14:33:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyybR-0002v2-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 14:33:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyyaR-0002iq-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 14:32:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyyZu-0002Y7-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 14:32:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyyZf-0005vE-N3; Thu, 04 Mar 2004 14:32:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyyZQ-0005uP-1K for manet@optimus.ietf.org; Thu, 04 Mar 2004 14:31:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09581 for ; Thu, 4 Mar 2004 14:31:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyyZN-0002Vc-00 for manet@ietf.org; Thu, 04 Mar 2004 14:31:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyyYR-0002JQ-00 for manet@ietf.org; Thu, 04 Mar 2004 14:30:47 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AyyXU-00025p-00 for manet@ietf.org; Thu, 04 Mar 2004 14:29:48 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i24JTkom017025; Thu, 4 Mar 2004 20:29:46 +0100 (MET) Subject: Re: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: Paal.Engelstad@telenor.com Cc: "'manet'" In-Reply-To: <33346562.1078423610035.JavaMail.adm-moff@moffice3.nsc.no> References: <000601c401b3$162b80a0$ef70fe81@jafymobile> <1078400407.5224.24.camel@dhcp-8-241.it.uu.se> <28965003.1078410918482.JavaMail.adm-moff@moffice3.nsc.no> <1078412596.5224.80.camel@dhcp-8-241.it.uu.se> <22188493.1078414117309.JavaMail.adm-moff@moffice3.nsc.no> <1078414900.5224.92.camel@dhcp-8-241.it.uu.se> <33346562.1078423610035.JavaMail.adm-moff@moffice3.nsc.no> Content-Type: text/plain Message-Id: <1078428586.6734.15.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 04 Mar 2004 20:29:46 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2004-03-04 at 19:06, Paal.Engelstad@telenor.com wrote: > Erik, > > No, I am very much in line with your thinking here. > good ;-) > By simple reasoning, I drew more or less the same conclusions as you did. But I am not 100% sure, since we have not tested the differences between the "ideal" to-way-tunneling and one-way-tunneling. (In fact, we tested both, based on your AODV-UU code, thanks!, but we have not made any proper comparizons.) > > My current standing is that the "ideal" Internet access mechanism, as far as routing is concerned, is tunneling in both directions: source routing (IPv6) or encapsulation (IPv4) of outbound traffic via the gateway and encapsulation of inbound traffic from gateway to MANET node (IPv4 and IPv6). From there you start to make optimizations to save bandwidth etc., and each optimization resembles a "hack", i.e. it undermines the ideal model. > Tunneling in both directions is OK, but I am not sure I would call it "ideal". It is just one solution, and I believe one-way is enough. But it is not such a big deal I think. > - The first step is to go from two-way to one-way tunneling, as we have just discussed. > - The next is perhaps your proposal to "rewrite" destination addresses at the GW, as you seem to propose (It does not sound good, IMHO. I think we have to accespt that we might need NAT for outgoing IPv4 traffic, but I hope you do not need it for incoming traffic as well.) I am not sure what you mean here... I did not propose to rewrite the destination address except for the src->gateway encapsulation (depending on what encapsulation method you choose). I agree that NAT is a good target, but can be problematic with multiple gateways (i.e., keeping consistent NAT states). Mobile IP is the best solution for seamless migration between gateways I think. > - Another alternative is to use source-address-based routing. This "hack" means that all outgoing traffic MUST have a souce IP addres under the gateways prefix. I.e. it will not work for IPv4, where you use private/IPv4-link-local address with NATs or home-address with a MIP-FA based gateway. It will also exclude every future IPv6 protocol that might need to use a source address that is not topologically correct for any gateway - i.e. this solution is also a "hack". Yes, this solution is very much a hack... I do not think it is needed. > - The next step is perhaps to introduce Proxy RREPs (AODV, i.e. gateway impersonates external hosts when sending RREP, see the old globalv4/MIPv4 draft) or to use default routes (e.g. OLSR). Here you might introduce routing race conditions, and also race conditions between MANET nodes that have preference for using different gateways but who are communicating with the same external host. I agree. This is a separate issue from the forwarding and there are several ways to do it. However, I think a proxy RREP solution is very attractive. > - And so on... > > What I have yet to understand (and this is why I initiated this discussion on "default routes") is the reason for default routes: i) Is it necesary ii) can it enhance routing performance of external traffic iii) or is it simply an optimization (or "hack") to save bandwidth. > I think it is neither. I have played around with default routes. With reactive protocols it is my strong belief that they give more problems than they solve. It is clear that you can't use a generic routing entry with a reactive protocol and multiple gateways without adding extra state. It quickly becomes a mess... > Due to radio/link dynamics and mobility, the routing protocols are providing a service that is inherently not robust. What is my concern is that the default routes, and the route selection mechansims necessary, are also not rebust and prone to malfunctioning due to network dynamics. Intuitively, default routes adds an additional unpredictable element, in addition to the unpredictability of the routing. > > With tunneling, on the contrary, we have only one single problem: How to make the routing protocol robust. > agreed. /Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 18:49:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22068 for ; Thu, 4 Mar 2004 18:49:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az2aT-00020G-1q for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 18:49:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Nn882007694 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 18:49:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az2aS-000201-KL for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 18:49:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21974 for ; Thu, 4 Mar 2004 18:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az2aP-0002uH-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 18:49:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az2ZT-0002eh-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 18:48:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az2Ya-0002RC-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 18:47:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az2YP-0001mb-Nr; Thu, 04 Mar 2004 18:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az2XS-0001lW-6I for manet@optimus.ietf.org; Thu, 04 Mar 2004 18:46:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21796 for ; Thu, 4 Mar 2004 18:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az2XP-0002D8-00 for manet@ietf.org; Thu, 04 Mar 2004 18:45:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az2WT-00023P-00 for manet@ietf.org; Thu, 04 Mar 2004 18:45:02 -0500 Received: from bittern.mail.pas.earthlink.net ([207.217.120.119]) by ietf-mx with esmtp (Exim 4.12) id 1Az2Vd-0001tI-00 for manet@ietf.org; Thu, 04 Mar 2004 18:44:09 -0500 Received: from user-2ivfn2t.dialup.mindspring.com ([165.247.220.93] helo=earthlink.net) by bittern.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Az2Wd-0000OM-00; Thu, 04 Mar 2004 15:45:12 -0800 Message-ID: <4047BF40.6080803@earthlink.net> Date: Thu, 04 Mar 2004 15:44:00 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Philippe Jacquet CC: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <40463249.3060100@earthlink.net> <016e01c401e6$6f44c420$1f175d80@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA21797 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Philippe Jacquet wrote: >----- Original Message ----- >From: Richard Ogier >To: Christophe Jelger >Cc: manet >Sent: Wednesday, March 03, 2004 8:30 PM >Subject: Re: [manet] Default Routes > >>Routes *will* be the min-hop, since the gateway info message contains >>the distance in hops >>to the gateway, so a node can always choose a neighbor with fewer hops >>as the next hop >>to the gateway. But the MPR forwarding rule should be that a node >>relays a gateway info >>message if the *next hop* is an MPR selector. Thus, the path to the >>gateway will be >>a sequence of MPR selectors. Philippe, is this correct? >> >Yes you are correct, excepted the minor point that there is no guarantee >that blind flooding or MPR flooding forward information on min-hop path = even >in presence of error free transmissions. The reason is that retransmissi= ons >on optimal path could be re-empted by retransmissions on non-optimal pat= hs. >However MPR flooding will be statistically done on shorter paths than bl= ind >flooding. > >In order to get shortest path for sure we would have either to allow nod= es >to retransmit the information several times, everytime they receive it o= n >shorter hop number (see our paper on superflooding), or to wait long eno= ugth >between retransmission in order to collect the shortest path before >retransmission. There is also the possibility to explicitly compute the >shortest path to the gateway but this will only work with proactive >protocols. > Philippe, You and I are not talking about exactly the same solution. What I am proposing does not require multiple retransmissions or waiting long enough to collect the shortest path. The proposed gateway discovery protocol computes the min-hop route to the gateway using distance vectors. I.e., it computes an "upstream neighbor", which should stay the same as long as the topology does not change. Thus, there is no need for retransmitting the info several times or waiting long enough to collect the shortest path. Instead, a node periodically sends its GW_INFO message if and only if its "upstream neighbor" is an MPR selector. This guarantees min-hop paths. As I noted before, for this to work, the "upstream neighbor" must be chosen consistently, e.g., by using node ID to break a tie when there are multiple possible upstream neighbors. Regards, Richard > > >I agree that if gateway advertizement were included in routing protocols= , as >it is done in proactive protocols, the problem would be much simpler. OL= SR >has already an embedded mechanism called HNA. It can be easily extended = to >several gateways information if one uses the rule of selecting the gatew= ay >with the shortest path. > >Philippe > >>Richard >> >>> >>>And about prefix distribution : prefix distribution is limited "by >>>nature", i.e. a node that is a the limit of two "islands" will not >>>forward control packets received from the island it does not belong to. >>> >>>Christophe >>> >>>Erik Nordstr=C3=B6m wrote: >>> >>>>Maybe I am missing something (and please point it out), but will not >>>> >the > >>>>MPR flooding limit the distribution of (different) prefixes in the >>>>network? My concern is that a node far down the (MPR) distribution pa= th >>>>rooted at a gateway will not be able to change gateway/prefix unless >>>> >its > >>>>upstream neighbor (closer to the gateway) also changes its prefix (of >>>>another gateway)? >>>>file://Erik >>>> >>>>On Wed, 2004-03-03 at 16:52, Philippe Jacquet wrote: >>>> >>>> >>>>>I don't see any problem with MPR flooding, when last hop is MPR >>>>>selector >>>>>then it will be the upstream neighbor. >>>>>I think the algorithm could be an application of the recent MPRF >>>>>draft with >>>>>the option TTL=3D1. >>>>> >>>>>Philippe >>>>>----- Original Message ----- >>>>>From: Erik Nordstr=C3=B6m >>>>>To: Christophe Jelger >>>>>Cc: manet >>>>>Sent: Wednesday, March 03, 2004 3:13 PM >>>>>Subject: Re: [manet] Default Routes >>>>> >>>>> >>>>>Jelger, >>>>> >>>>>I admit that I am not that familiar with your proposal, and probably >>>>>should read it more carefully. However, there are some things I >>>>>question... >>>>> >>>>>For example, why implement a seperate flooding mechanism when this i= s >>>>>already provided by the routing protocol (for example OLSR)? You >>>>>propose >>>>>to optionally integrate this with the routing protocol, but I do not >>>>>see >>>>>how that is possible with MPR-based flooding? >>>>> >>>>>I am not convinced that you have maximum flexibility when building >>>>> >your > >>>>>prefix islands of nodes. How can nodes part of a prefix island >>>>>individually choose another gateway? But, I admit, I need to study >>>>> >your > >>>>>draft in more detail. >>>>> >>>>>With tunnels you can simply add a flag in ordinary control messages >>>>>announcing some nodes as gateways. Nodes can then individually choos= e >>>>> >a > >>>>>gateway and tunnel packets to it. The routing protocol takes care of >>>>>the >>>>>rest transparently. This also works well with reactive protocols. >>>>> >>>>>/Erik >>>>> >>>>> >>>>>On Wed, 2004-03-03 at 14:51, Christophe Jelger wrote: >>>>> >>>>> >>>>>>Hi Erik, >>>>>> >>>>>>Well about handovers everything is in the draft, but I have to admi= t >>>>>>that it's not very clear sometimes. I hope to write a new version >>>>>>soon. >>>>>> >>>>>>To summarise : we propose different algorithms used by each ad hoc >>>>>>node >>>>>>to choose (and switch between) a gateway. It can either use the >>>>>>closest >>>>>>gateway (whatever prefix it uses), or a gateway that uses the same >>>>>>prefix than it currently uses (whatever the distance from the >>>>>>gateway). >>>>>>We also proposed slight variants. So first answer to your email is >>>>>>that >>>>>>switching between gateways is controled by each ad hoc node >>>>>>independently. >>>>>> >>>>>>Moreover, and because of our particular (but very simple) way of >>>>>>prefix >>>>>>propagation, we can guarantee that a default route is never >>>>>>diverted (in >>>>>>the steady-state). By steady-state, I mean that of course topologic= al >>>>>>changes can cause trouble during a very small amount of time. The >>>>>> >main > >>>>>>idea behind our draft is prefix continuity : we "build" contiguous >>>>>>islands of nodes that share the same prefix/gateway. This can be of >>>>>>high >>>>>>interest for providers (e.g. management, services, ...). >>>>>> >>>>>>We have implemented our solution (IPv6) as an independent daemon >>>>>>and it >>>>>>works really well in the presence of multiple gateways and >>>>>>prefixes. We >>>>>>will soon integrate it in an IPv6 version of OLSR (Qolyester from >>>>>>LRI in >>>>>>France). I am also finishing some simulations in which we evaluate >>>>>> >our > >>>>>>solution : I hope I can submit the results for publication very soo= n. >>>>>> >>>>>>Well and before everybody says what's best and what's bad, I >>>>>>personally >>>>>>think it's very difficult at this stage to say so. If you have done >>>>>>some >>>>>>simulations of the tunnel approach you have probably seen that >>>>>> >results > >>>>>>can greatly vary across different simulation scenarios. I think all >>>>>>solutions have pros and cons, and we should be able to find the bes= t >>>>>>parts of all solutions. >>>>>> >>>>>>Regards, >>>>>>Christophe >>>>>> >>>>>>Erik Nordstr=C3=B6m wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>I don't see how you can efficiently handle multiple gateways when >>>>>>>using >>>>>>>default routes? Especially with reactive protocols that do not hav= e >>>>>>> >a > >>>>>>>complete view of the network. Even if you maintain the gateway >>>>>>>mapping, >>>>>>>how will you deal with hand-overs between gateways? You say that >>>>>>> >the > >>>>>>>solution is to force nodes to use the "same" default route, but I >>>>>>>do not >>>>>>>think that is a good idea. Individual nodes may know best when to >>>>>>>switch >>>>>>>gateways, and they should be allowed to do so if they wish. How >>>>>>>can you >>>>>>>guarantee that a default route is not diverted to another gateway >>>>>>>at an >>>>>>>intermediate node if a packet carries no mapping between the (fina= l) >>>>>>>destination and the gateway? How do you handle control packets (fr= om >>>>>>>different gateways) that want to change the default route --> >>>>>>> >gateway > >>>>>>>mapping? >>>>>>> >>>>>>>My experience with AODV-UU is that gateway tunneling has many >>>>>>>properties >>>>>>>that are prefered in an ad hoc network. Tunnels easily support >>>>>>>multiple >>>>>>>gateways and are transparent for intermediate nodes that forwards >>>>>>> >the > >>>>>>>traffic to the gateway. I have a paper pending that clearly shows >>>>>>> >the > >>>>>>>advantages of tunnels in this context. >>>>>>> >>>>>>>Before proceeding with a merged draft on Internet connectivity, I >>>>>>>think >>>>>>>that the proposal should be backed up with serious research showin= g >>>>>>>problems or benefits of different strategies. I have implemented >>>>>>>gateway >>>>>>>connectivity in AODV-UU, and my experience clearly points in the >>>>>>>direction of tunnels. >>>>>>> >>>>>>>Regards, >>>>>>> >>>>>>>Erik Nordstr=C3=B6m >>>>>>> >>>>>>> >>>>>>> >>>>>>>On Wed, 2004-03-03 at 12:46, Christophe Jelger wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Actually each node knows what gateway it uses because there is a >>>>>>>>special >>>>>>>>field in the packet used to disseminate the prefix information. >>>>>>>> >This > >>>>>>>>field contains the IPv6 global address of the gateway (and >>>>>>>>another field >>>>>>>>gives the prefix length). Moreover, we "almost" don't need a >>>>>>>> >routing > >>>>>>>>protocol (of course don't take this statement too strictly), in t= he >>>>>>>>sense that, when a node wants to send data to some node in the >>>>>>>>Internet, >>>>>>>>it only uses a default route with next hop being one of its >>>>>>>>neighbors. >>>>>>>>The ad hoc node does not even need to have a /128 route to the >>>>>>>>gateway. >>>>>>>>Of course on the reverse path this is not the same (i.e. the >>>>>>>> >gateway > >>>>>>>>must have a /128 route to the ad hoc node). >>>>>>>> >>>>>>>>Christophe >>>>>>>> >>>>>>>>Anders Nilsson wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Hello again, >>>>>>>>> >>>>>>>>>Christophe Jelger wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>Of course as one of the authors of a solution that uses default >>>>>>>>>>route >>>>>>>>>>I don't agree with your statements. ;-) >>>>>>>>>> >>>>>>>>>>In our draft each MANET node knows which gateway it uses, and >>>>>>>>>>(in the >>>>>>>>>>steady-state) it knows that all nodes on the "default route" >>>>>>>>>>path use >>>>>>>>>>the same gateway. With our solution gateways don't announce >>>>>>>>>>routes, >>>>>>>>>>they just announce prefixes. If two gateways announce the same >>>>>>>>>>prefix, an ad hoc node selects the closest gateway (it can be >>>>>>>>>>specified that it should from there use the same gateway). The >>>>>>>>>>propagation method used to propagate the prefix information >>>>>>>>>>ensures >>>>>>>>>>that the path to the gateway is made of nodes that also use the >>>>>>>>>>same >>>>>>>>>>gateway : there is no need of a routing header, and default >>>>>>>>>> >routes > >>>>>>>>>>can be used safely. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>That sounds like a good solution, but the node can't control wha= t >>>>>>>>>gateway it is currently using. A scenario where this is neeed is >>>>>>>>>when >>>>>>>>>the node is moving from gateway to gateway. The node is then >>>>>>>>>unable to >>>>>>>>>know what gateway it is currently communicating through. A node >>>>>>>>>need >>>>>>>>>to know this when it switches to a new gateway, and "registers" >>>>>>>>>itself. This reason why this needed is because packets from the >>>>>>>>>Internet needs to be routed to the correct gateway, which is >>>>>>>>>difficult >>>>>>>>>when mobile nodes are unware of its gateway. If a Cellular IP >>>>>>>>>type of >>>>>>>>>solution is used, the routing entries in the access network are >>>>>>>>>updated by the actual packets flowing through the gateways. But >>>>>>>>>there >>>>>>>>>is problems here as well, because oscillations easily occurs tha= t >>>>>>>>>causes a lot of updates, especially when the mobile nodes are >>>>>>>>>mobile. >>>>>>>>>I have simulated this, and it is harder to maintain than you mig= ht >>>>>>>>>think. If you rely on proactive gateway discovery, the default >>>>>>>>>routing >>>>>>>>>entries have to be maintained during link breaks and mobility, >>>>>>>>>along >>>>>>>>>with sequence number maintainence. I have a paper about this, in= a >>>>>>>>>slightly different context, but during mobility and several hops >>>>>>>>> >to > >>>>>>>>>the gateway, more complex control is needed. >>>>>>>>> >>>>>>>>>regards, >>>>>>>>> >>>>>>>>>Anders >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>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 >>>>> >>>> >>>> >>>>_______________________________________________ >>>>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 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 21:46:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29433 for ; Thu, 4 Mar 2004 21:46:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5Lj-0005lM-LS for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 21:46:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i252k7L2022148 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 21:46:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5Lj-0005l9-Ah for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 21:46:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29427 for ; Thu, 4 Mar 2004 21:46:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az5Lg-0004v4-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 21:46:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az5Kp-0004kn-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 21:45:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az5KI-0004aA-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 21:44:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5Jh-0005Ti-MS; Thu, 04 Mar 2004 21:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5In-0005Sk-7i for manet@optimus.ietf.org; Thu, 04 Mar 2004 21:43:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29354 for ; Thu, 4 Mar 2004 21:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az5Ik-0004OH-00 for manet@ietf.org; Thu, 04 Mar 2004 21:43:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az5Hn-0004Dm-00 for manet@ietf.org; Thu, 04 Mar 2004 21:42:03 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1Az5Gt-0003sH-00 for manet@ietf.org; Thu, 04 Mar 2004 21:41:07 -0500 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW2D80; Fri, 5 Mar 2004 11:40:35 +0900 Reply-To: From: "HyunWook Cha" To: Cc: "'manet'" Subject: RE: [manet] Why GW discovery should not be separated from reactive routing protocols? Date: Fri, 5 Mar 2004 11:40:39 +0900 Message-ID: <000001c4025b$3f131070$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <40470762.9060805@insa-lyon.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Guilaume. On-demand solicitation/advertisement should be performed periodically to extend address lifetime and update bidirectional reachability whether packets to be forwarded toward Internet exist or not. IMHO, reactive routing protocol is reactive because it perform route discovery only when valid route entry needed for forwarding does not exist. In this sense, I think that separate protocols can be more adequate for reactive routing protocols since routing protocols can still behave for its original purpose. If I am wrong, please enlighten me. Regards, HyunWook -----Original Message----- From: Guillaume Chelius [mailto:guillaume.chelius@insa-lyon.fr] Sent: Thursday, March 04, 2004 7:40 PM To: jafy@etri.re.kr Cc: 'manet' Subject: Re: [manet] Why GW discovery should not be separated from reactive routing protocols? Hello, > Could you tell me why GW discovery should not be separated from > reactive routing protocols? IMO, periodic gw solication/advertisement > seems to be proactive. A periodic solicitation/advertisement scheme is indeed proactive. As for a periodic unsolicited advertisement one. But on-demand solicitation/advertisement (route-request to the gateway) is reactive. This clearly shows that for reactive protocols, the gateway/prefix advertizement may be either integrated to the routing protocol (for reactive) or may be performed by a separate protocol if a proactive scheme is preferred. For a proactive protocol, the question does not hold as proactive advertizement can be performed at almost 0 cost. Regards, Guillaume. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 4 22:06:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00285 for ; Thu, 4 Mar 2004 22:06:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5f8-0007pe-5Z for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 22:06:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2536A2j030103 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 22:06:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5f7-0007pS-Pv for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 22:06:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00247 for ; Thu, 4 Mar 2004 22:06:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az5f4-0000fZ-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 22:06:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az5e4-0000Ta-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 22:05:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az5dA-0000JC-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 22:04:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5d4-00075y-2d; Thu, 04 Mar 2004 22:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5c7-0006rh-It for manet@optimus.ietf.org; Thu, 04 Mar 2004 22:03:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00126 for ; Thu, 4 Mar 2004 22:02:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az5c4-00006M-00 for manet@ietf.org; Thu, 04 Mar 2004 22:03:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az5b5-0007hO-00 for manet@ietf.org; Thu, 04 Mar 2004 22:02:00 -0500 Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx with smtp (Exim 4.12) id 1Az5a3-0007Mo-00 for manet@ietf.org; Thu, 04 Mar 2004 22:00:55 -0500 Received: From 192.168.0.100 ([129.94.173.78] == sitcrc.cse.unsw.EDU.AU) (for ) (for ) (for ) By note With Smtp ; Fri, 5 Mar 2004 14:00:43 +1100 From: Justin Lipman To: , Date: Fri, 5 Mar 2004 14:00:42 +1100 Reply-To: justin@titr.uow.edu.au Organization: CRC-SIT Subject: Re: [manet] Why GW discovery should not be separated from reactive routing protocols? User-Agent: KMail/1.5.4 Cc: "'manet'" References: <000001c4025b$3f131070$ae70fe81@jafywinxp> In-Reply-To: <000001c4025b$3f131070$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200403051400.42745.justin@titr.uow.edu.au> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi HyunWook, I agree. I think from the reactive approach, there is plenty of existing approaches sensor network and information collection literature which can be used to build reactive approaches to determining the existence of gateways, determining the best gateways to be used and necessary paths... Kind regards, Justin -- Research Associate Smart Internet Technology Cooperative Research Centre http://www.titr.uow.edu.au/~justin On Fri, 5 Mar 2004 01:40 pm, HyunWook Cha wrote: > Hello, Guilaume. > > On-demand solicitation/advertisement should be performed periodically to > extend address lifetime and update bidirectional reachability whether > packets to be forwarded toward Internet exist or not. IMHO, reactive > routing protocol is reactive because it perform route discovery only > when valid route entry needed for forwarding does not exist. In this > sense, I think that separate protocols can be more adequate for reactive > routing protocols since routing protocols can still behave for its > original purpose. If I am wrong, please enlighten me. > > Regards, > > HyunWook > > -----Original Message----- > From: Guillaume Chelius [mailto:guillaume.chelius@insa-lyon.fr] > Sent: Thursday, March 04, 2004 7:40 PM > To: jafy@etri.re.kr > Cc: 'manet' > Subject: Re: [manet] Why GW discovery should not be separated from > reactive routing protocols? > > > > Hello, > > > Could you tell me why GW discovery should not be separated from > > reactive routing protocols? IMO, periodic gw solication/advertisement > > seems to be proactive. > > A periodic solicitation/advertisement scheme is indeed proactive. As for > > a periodic unsolicited advertisement one. But on-demand > solicitation/advertisement (route-request to the gateway) is reactive. > This clearly shows that for reactive protocols, the gateway/prefix > advertizement may be either integrated to the routing protocol (for > reactive) or may be performed by a separate protocol if a proactive > scheme is preferred. > > For a proactive protocol, the question does not hold as proactive > advertizement can be performed at almost 0 cost. > > > Regards, > Guillaume. > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Mar 4 22:29:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01562 for ; Thu, 4 Mar 2004 22:29:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az61P-0001FK-Fo for manet-archive@odin.ietf.org; Thu, 04 Mar 2004 22:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i253TBcj004784 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 22:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az61P-0001F5-6P for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 22:29:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01522 for ; Thu, 4 Mar 2004 22:29:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az61L-0005K8-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 22:29:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az60J-00057T-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 22:28:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az5zO-0004wN-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 22:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5zK-0000uA-VZ; Thu, 04 Mar 2004 22:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az5yh-0000rN-2g for manet@optimus.ietf.org; Thu, 04 Mar 2004 22:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01430 for ; Thu, 4 Mar 2004 22:26:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az5yd-0004m0-00 for manet@ietf.org; Thu, 04 Mar 2004 22:26:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az5xj-0004a4-00 for manet@ietf.org; Thu, 04 Mar 2004 22:25:23 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1Az5xG-0004Np-00 for manet@ietf.org; Thu, 04 Mar 2004 22:24:54 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Az5xH-0000a2-66; Fri, 05 Mar 2004 03:24:55 +0000 Date: Fri, 5 Mar 2004 12:23:49 +0900 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <21261456464.20040305122349@psg.com> To: OSPF@PEACH.EASE.LSOFT.COM, manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] On MANET extensions to OSPF 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- I'd like to inform the OSPF and MANET WGs that ADs and WG chairs are discussing organization of the work on MANET extensions to OSPF and will be consulting WG participants in the following few weeks. We intend to get back to the community with further directions on this topic. Please feel free to send us any feedback you believe would be important. Thank you. -- Alex Zinin IETF RTG Area co-Director _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 5 01:32:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08610 for ; Fri, 5 Mar 2004 01:32:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8sb-0008Nl-1j for manet-archive@odin.ietf.org; Fri, 05 Mar 2004 01:32:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i256WHeP032220 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 01:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8sa-0008Nb-Sc for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 01:32:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08586 for ; Fri, 5 Mar 2004 01:32:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az8sX-00005r-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 01:32:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az8rX-0007i2-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 01:31:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az8qX-0007X3-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 01:30:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8qR-00080Z-J1; Fri, 05 Mar 2004 01:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az8pi-0007yG-7w for manet@optimus.ietf.org; Fri, 05 Mar 2004 01:29:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08494 for ; Fri, 5 Mar 2004 01:29:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az8pf-0007MG-00 for manet@ietf.org; Fri, 05 Mar 2004 01:29:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az8op-0007Bm-00 for manet@ietf.org; Fri, 05 Mar 2004 01:28:24 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1Az8oA-0006xu-00 for manet@ietf.org; Fri, 05 Mar 2004 01:27:42 -0500 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW21Q7; Fri, 5 Mar 2004 15:27:09 +0900 Reply-To: From: "HyunWook Cha" To: "'Erik Nordstr?'" , Cc: "'manet'" Subject: RE: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) Date: Fri, 5 Mar 2004 15:27:14 +0900 Message-ID: <000001c4027a$e6157c90$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <1078428586.6734.15.camel@dhcp-8-241.it.uu.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Please find my inline comments. > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Erik Nordstr? > Sent: Friday, March 05, 2004 4:30 AM > To: Paal.Engelstad@telenor.com > Cc: 'manet' > Subject: Re: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) > > > > On Thu, 2004-03-04 at 19:06, Paal.Engelstad@telenor.com wrote: > > Erik, > > > > No, I am very much in line with your thinking here. > > > good ;-) > > > By simple reasoning, I drew more or less the same > conclusions as you > > did. But I am not 100% sure, since we have not tested the > differences between the "ideal" to-way-tunneling and > one-way-tunneling. (In fact, we tested both, based on your > AODV-UU code, thanks!, but we have not made any proper comparizons.) > > > > My current standing is that the "ideal" Internet access > mechanism, as > > far as routing is concerned, is tunneling in both > directions: source routing (IPv6) or encapsulation (IPv4) of > outbound traffic via the gateway and encapsulation of inbound > traffic from gateway to MANET node (IPv4 and IPv6). From > there you start to make optimizations to save bandwidth etc., > and each optimization resembles a "hack", i.e. it undermines > the ideal model. > > What is ideal and what is hack? It depends on your thought? > > Tunneling in both directions is OK, but I am not sure I would > call it "ideal". It is just one solution, and I believe > one-way is enough. But it is not such a big deal I think. > IMO, to enforce all inbound traffics to be encapsulated is hack !!! What makes you think that route entries for global addresses assigned to MANET nodes should not be maintained inside the MANET? I do not see any reason. If gateway obtains valid route entry for a destination node's global address, it can forward packets as they are. Unnecessary encapsulation is useless, wastful and it can cause packets to be dropped when size of encapulated packets are greater thatn MTU in case of IPv6. I believe that encapsulation should be used only when valid route entry for global address does not exsit and valid route entry for MANET local address is available and it is guaranteed that two addreeses point the same node. > > - The first step is to go from two-way to one-way tunneling, as we > > have just discussed. > > - The next is perhaps your proposal to "rewrite" > destination addresses at the GW, as you seem to propose (It > does not sound good, IMHO. I think we have to accespt that we > might need NAT for outgoing IPv4 traffic, but I hope you do > not need it for incoming traffic as well.) > If you want to use NAT for only outbound traffic(but not for inbound traffic) and encapsulation for inbound traffic, communication is not possilbe. The reason is that a node does not know its external address which is used as destination address in inbound traffic and even if it knows, existing upper layer (TCP/UDP) can not recognize that inbound traffics belong to the session bound to internal address. > I am not sure what you mean here... I did not propose to > rewrite the destination address except for the src->gateway > encapsulation (depending on what encapsulation method you > choose). I agree that NAT is a good target, but can be > problematic with multiple gateways (i.e., keeping consistent > NAT states). Mobile IP is the best solution for seamless > migration between gateways I think. > Right. Could you handle gateway handover using NATs? > > - Another alternative is to use source-address-based routing. This > > "hack" means that all outgoing traffic MUST have a souce IP addres > > under the gateways prefix. I.e. it will not work for IPv4, where you > > use private/IPv4-link-local address with NATs or home-address with a > > MIP-FA based gateway. It will also exclude every future IPv6 protocol > > that might need to use a source address that is not topologically > > correct for any gateway - i.e. this solution is also a "hack". > > Yes, this solution is very much a hack... I do not think it is needed. > Soure address based forwarding assumes that source address is globally routable and configured dinamically from a gateway. Just forget private/ipv4 link local with NATs!!! Corporation with MIPv4 has never been considered by me. In this case, sender node has no choice but encapsulation from it to FA gateway because it knows that source address based default routing is not available because of absence of gateway advertisement from HA gateway. As you know, all global addresses configured statefully/statelssly from routers are alway topological correct. I think that we have same goal. Packets should be forwarded to right exit gateway according to source address. Right? > > - The next step is perhaps to introduce Proxy RREPs (AODV, i.e. > > gateway impersonates external hosts when sending RREP, see the old > > globalv4/MIPv4 draft) or to use default routes (e.g. OLSR). Here you > > might introduce routing race conditions, and also race conditions > > between MANET nodes that have preference for using > different gateways but who are communicating with the same external host. > > I agree. This is a separate issue from the forwarding and > there are several ways to do it. However, I think a proxy > RREP solution is very attractive. > Whe source address based forwarding is used, MANET nodes that have preference for using different gateways but who are communicating with the same external host can do what they want. Actually intermediate nodes does not have to maintain default route entry(/0) but gateway information list as well as route entry(/128) for gateways. I am not familiar with globalv4/MIPv4 draft. However I want to know that proxy RREPs works well under multiple gateways or not, and how to configure global addresses. > > - And so on... > > > > What I have yet to understand (and this is why I initiated this > > discussion on "default routes") is the reason for default > routes: i) > > Is it necesary ii) can it enhance routing performance of external > > traffic iii) or is it simply an optimization (or "hack") to save > > bandwidth. > > > > I think it is neither. I have played around with default > routes. With reactive protocols it is my strong belief that > they give more problems than they solve. It is clear that you > can't use a generic routing entry with a reactive protocol > and multiple gateways without adding extra state. It quickly > becomes a mess... > This depends on implementation of default route forwarding. I can not understand why you are considering default route forwarding using prefix continuity or source address based forwading. Please give careful comments on two drafts.(Do not say "hack" before you can prove that clearly.) HyunWook Cha _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 5 05:31:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00514 for ; Fri, 5 Mar 2004 05:31:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzCbB-0005Pp-Pk for manet-archive@odin.ietf.org; Fri, 05 Mar 2004 05:30:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25AUX7J020814 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 05:30:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzCW4-00050A-Jr for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 05:25:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27892 for ; Fri, 5 Mar 2004 04:26:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzBbd-0001Ur-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 04:26:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzBaf-0001G1-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 04:25:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzBZb-0000zY-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 04:24:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBZa-0007IY-LG; Fri, 05 Mar 2004 04:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzAyp-0003O2-AU for manet@optimus.ietf.org; Fri, 05 Mar 2004 03:46:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26616 for ; Fri, 5 Mar 2004 03:46:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzAym-0001C0-00 for manet@ietf.org; Fri, 05 Mar 2004 03:46:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzAxq-0000xv-00 for manet@ietf.org; Fri, 05 Mar 2004 03:45:51 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AzAx7-0000iW-00 for manet@ietf.org; Fri, 05 Mar 2004 03:45:05 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i258lpZr052317; Fri, 5 Mar 2004 09:47:51 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <40483E65.2000102@dpt-info.u-strasbg.fr> Date: Fri, 05 Mar 2004 09:46:29 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: Richard Ogier CC: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <40470344.3070202@insa-lyon.fr> <404714FE.2010207@dpt-info.u-strasbg.fr> <4047762E.1080401@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Richard, I think we all agree that gateway discovery and prefix announcement can be integrated into a proactive routing protocol. Again I'd like to re-state that we clearly say that in the draft ... ;-) At least that seems to be a first consensus. I also just want to re-state that we first decided to propose the idea without integrating the concept in any routing protocol ... this is (in its current state) why we can have different routes between our standalone process and the routing protocol. Of course the final objective when we integrate it in OLSR is to "merge" everything (e.g. unique neighbors table and neighbor discovery mechanisms). Finally, I know that there has already been a lot of discussions on "should we have something like prefix continuity, or can we just mix nodes and don't bother about that ?". I'm not sure that's something we should decide, because it will mainly be a matter of deployment. If an operator (at a large sense) wants to deploy an ad hoc network, it should be able to choose whether it wants prefix continuity or not (as it can choose between different types of routing protocol). I think our task is to propose solutions, and people just decide (or not) to use them. Of course I like prefix continuity, but not just because we (sort of) proposed that. I really think it's something people will like in their deployment, it can be really useful in a number of situations (management, accounting, load balancing). Regards, Christophe Richard Ogier wrote: > Christophe Jelger wrote: > >> Guillaume, >> >> Just on point, see inline my comment. In general I agree that gateway >> discovery should not be separated, as stated in the draft. We first >> implemented it as a stand-alone process to check the operation. As >> you know, we plan to integrate it into OLSR. (see below for a last >> comment) > > > > >> >> With prefix continuity, routes are optimal if we use the "distance" >> algorithm : always choose closest gateway. In that case the route is >> a shortest route, but it can be different than the shortest route >> computed by the routing protocol. On the other hand, if we use the >> algorithm "prefix stability", then the route might not be optimal >> (I'm currently simulating this and it appears that routes are not >> much longer on average). >> > So, the gateway discovery protocol (which uses distance vectors) > computes a route to some gateway, and the link-state routing protocol > (e.g., OLSR or TBRPF or OSPF) computes a route to each gateway, which > may be different from the one computed by the gateway discovery protocol. > Also, it is possible that the link-state protocol reacts to topology > changes faster or slower than the gateway protocol. > Wouldn't it be nice if the two protocols could *agree* on the route to > each gateway? I would prefer to remove this redundancy, and just have > one routing protocol that computes the routes to all nodes, including > routes to gateways and default routes. > Several people (including Joe Macker, Chelius Guillaume, Pedro Ruiz, > Eric Fleury) have agreed that it would be better to avoid redundancy > between the proactive routing protocol and gateway discovery. > Can we agree that we have consensus on this > Now, you may say that the proactive routing protocol still needs some > mechanism to achieve prefix continuity. IF we decide we need > to ensure prefix continuity (and I have doubts about this), > then the link-state routing protocol can be modified to achieve this, > using link-state routing (instead of distance vectors). > > Regards, > Richard > >> > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 5 05:45:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00926 for ; Fri, 5 Mar 2004 05:45:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzCop-0006lg-10 for manet-archive@odin.ietf.org; Fri, 05 Mar 2004 05:44:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25Aic7T026010 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 05:44:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzCoo-0006lR-OW for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 05:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00906 for ; Fri, 5 Mar 2004 05:44:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzCol-0001eC-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 05:44:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzCmv-00014n-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 05:42:41 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzCmM-0000rz-03 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 05:42:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzCcq-0004vp-Uw for manet-web-archive@ietf.org; Fri, 05 Mar 2004 05:32:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzCcc-0005Z0-OH; Fri, 05 Mar 2004 05:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzCcB-0005Vl-RS for manet@optimus.ietf.org; Fri, 05 Mar 2004 05:31:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00552 for ; Fri, 5 Mar 2004 05:31:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzCc8-00073j-00 for manet@ietf.org; Fri, 05 Mar 2004 05:31:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzCbO-0006t2-00 for manet@ietf.org; Fri, 05 Mar 2004 05:30:47 -0500 Received: from reserv6.univ-lille1.fr ([193.49.225.20] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AzCa7-0006h5-00 for manet@ietf.org; Fri, 05 Mar 2004 05:29:27 -0500 Received: from 0 (popeye.univ-lille1.fr [193.49.225.6]) by reserv6.univ-lille1.fr (8.12.10/jtpda-5.3.1) with ESMTP id i25ATPsk011174 for ; Fri, 5 Mar 2004 11:29:25 +0100 Message-Id: <200403051029.i25ATPsk011174@reserv6.univ-lille1.fr> X-Originating-IP: [62.147.108.86] User-Agent: IMHO/0.98 (Webmail for Roxen) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=iso-8859-1 From: NICOLAS LOUIS Content-Transfer-Encoding: 8bit Date: Fri, 05 Mar 2004 11:29:24 +0100 Subject: [manet] Routing algorithm in OPNET 8.1 X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi I'm a student in the university of Lille, France I'm working on a MAC protocol for my degree and I'm searching for a routing algotithm for wireless networks 802.11 to make simulations. Does anyone know if a AODV or OLSR model for OPNET 8.1 exists and where can I find it ? Thank you for your help. Regards Nicolas LOUIS _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 5 06:40:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03529 for ; Fri, 5 Mar 2004 06:40:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzDgn-0002bK-Ni for manet-archive@odin.ietf.org; Fri, 05 Mar 2004 06:40:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25BeP9r009992 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 06:40:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzDgn-0002b5-Gr for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 06:40:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03484 for ; Fri, 5 Mar 2004 06:40:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzDgj-00052A-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 06:40:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzDfk-0004qT-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 06:39:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzDej-0004YM-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 06:38:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzDeU-0002Ip-Qg; Fri, 05 Mar 2004 06:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzDdt-00028J-W0 for manet@optimus.ietf.org; Fri, 05 Mar 2004 06:37:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03421 for ; Fri, 5 Mar 2004 06:37:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzDdp-0004Vx-00 for manet@ietf.org; Fri, 05 Mar 2004 06:37:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzDct-0004Kj-00 for manet@ietf.org; Fri, 05 Mar 2004 06:36:24 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AzDby-00047E-00 for manet@ietf.org; Fri, 05 Mar 2004 06:35:26 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i25BZItV025123; Fri, 5 Mar 2004 12:35:20 +0100 (MET) Subject: RE: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: jafy@etri.re.kr Cc: Paal.Engelstad@telenor.com, "'manet'" In-Reply-To: <000001c4027a$e6157c90$ae70fe81@jafywinxp> References: <000001c4027a$e6157c90$ae70fe81@jafywinxp> Content-Type: text/plain Message-Id: <1078486185.9485.35.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 05 Mar 2004 12:35:18 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-03-05 at 07:27, HyunWook Cha wrote: > > > My current standing is that the "ideal" Internet access > > mechanism, as > > > far as routing is concerned, is tunneling in both > > directions: source routing (IPv6) or encapsulation (IPv4) of > > outbound traffic via the gateway and encapsulation of inbound > > traffic from gateway to MANET node (IPv4 and IPv6). From > > there you start to make optimizations to save bandwidth etc., > > and each optimization resembles a "hack", i.e. it undermines > > the ideal model. > > > > > What is ideal and what is hack? It depends on your thought? > > > > > Tunneling in both directions is OK, but I am not sure I would > > call it "ideal". It is just one solution, and I believe > > one-way is enough. But it is not such a big deal I think. > > > > IMO, to enforce all inbound traffics to be encapsulated is hack !!! Why would this be a hack? Tunneling is an established mechanism. Do you have a good argument for this? > What makes you think that route entries for global addresses assigned to > MANET nodes should not be maintained inside the MANET? I do not see any > reason. If gateway obtains valid route entry for a destination node's Tunneling does not totally exclude global (non-adhoc) addresses in the MANET. Routing entries for global addresses still have to be maintained at end nodes. It just simplifies the routing, and you achieves route aggregation since you can share a tunnel among many addresses. In the AODV case, there is also no need to maintain sequence numbers for routes to global destinations since it maps to the gateway route. This would not be the case if you "import" global addresses/routes into the ad hoc network. > global address, it can forward packets as they are. Unnecessary > encapsulation is useless, wastful and it can cause packets to be dropped > when size of encapulated packets are greater thatn MTU in case of IPv6. > I believe that encapsulation should be used only when valid route entry > for global address does not exsit and valid route entry for MANET local > address is available and it is guaranteed that two addreeses point the > same node. > > > - The first step is to go from two-way to one-way tunneling, as we > > > have just discussed. > > > - The next is perhaps your proposal to "rewrite" > > destination addresses at the GW, as you seem to propose (It > > does not sound good, IMHO. I think we have to accespt that we > > might need NAT for outgoing IPv4 traffic, but I hope you do > > not need it for incoming traffic as well.) > > > > I am not sure what you mean here... I did not propose to > > rewrite the destination address except for the src->gateway > > encapsulation (depending on what encapsulation method you > > choose). I agree that NAT is a good target, but can be > > problematic with multiple gateways (i.e., keeping consistent > > NAT states). Mobile IP is the best solution for seamless > > migration between gateways I think. > > > > Right. Could you handle gateway handover using NATs? > I guess, if you tunneled traffic from your "old" gateway to the new one. Of course, there would have to be some extra signaling between the gateways. > > > > - The next step is perhaps to introduce Proxy RREPs (AODV, i.e. > > > gateway impersonates external hosts when sending RREP, see the old > > > globalv4/MIPv4 draft) or to use default routes (e.g. OLSR). Here you > > > > might introduce routing race conditions, and also race conditions > > > between MANET nodes that have preference for using > > different gateways but who are communicating with the same external > host. > > > > I agree. This is a separate issue from the forwarding and > > there are several ways to do it. However, I think a proxy > > RREP solution is very attractive. > > > > Whe source address based forwarding is used, MANET nodes that have > preference for using different gateways but who are communicating with > the same external host can do what they want. Actually intermediate > nodes does not have to maintain default route entry(/0) but gateway > information list as well as route entry(/128) for gateways. > > I am not familiar with globalv4/MIPv4 draft. However I want to know that > proxy RREPs works well under multiple gateways or not, and how to > configure global addresses. > Proxy RREPs works with multiple gateways. A source node gets multiple replies and can chose the best route (i.e., based on hop count or something else). As for the global address, why would you need to configure one? In the NAT case you can use your home address or a link local. With MIP you would use your home address in the ad hoc network and the gateway/FA would just rewrite the packet with the care-of-address. No address configuration is necessary as long as you have a unique home address. For those that don't have a valid home address, you can just configure a link local address. > > > > I think it is neither. I have played around with default > > routes. With reactive protocols it is my strong belief that > > they give more problems than they solve. It is clear that you > > can't use a generic routing entry with a reactive protocol > > and multiple gateways without adding extra state. It quickly > > becomes a mess... > > > > This depends on implementation of default route forwarding. I can not > understand why you are considering default route forwarding using prefix > continuity or source address based forwading. Please give careful > comments on two drafts.(Do not say "hack" before you can prove that > clearly.) > Prefix continuity is fine but clearly has limitations, since (all) nodes can't chose gateways by themselves. I am not sure what you mean with source address based forwarding. Do you select your default route based on source address? In that case you need to maintain a lot of extra state and you have no route aggregation which is mainly what default routes are for. Correct me if I am wrong. /Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 5 07:06:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04376 for ; Fri, 5 Mar 2004 07:06:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzE63-0005RY-Vk for manet-archive@odin.ietf.org; Fri, 05 Mar 2004 07:06:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25C6Vmu020924 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 07:06:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzE63-0005RJ-CQ for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 07:06:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04373 for ; Fri, 5 Mar 2004 07:06:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzE5y-000217-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 07:06:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzE52-0001r9-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 07:05:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzE4o-0001hV-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 07:05:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzE4f-00058i-Ov; Fri, 05 Mar 2004 07:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzE43-0004RD-8U for manet@optimus.ietf.org; Fri, 05 Mar 2004 07:04:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04326 for ; Fri, 5 Mar 2004 07:04:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzE3y-0001g6-00 for manet@ietf.org; Fri, 05 Mar 2004 07:04:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzE31-0001Vu-00 for manet@ietf.org; Fri, 05 Mar 2004 07:03:25 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AzE25-0001La-00 for manet@ietf.org; Fri, 05 Mar 2004 07:02:25 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i25C5DZr056821; Fri, 5 Mar 2004 13:05:13 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <40486CA8.3040507@dpt-info.u-strasbg.fr> Date: Fri, 05 Mar 2004 13:03:52 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Erik_Nordstr=F6m?= CC: "'manet'" Subject: Re: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) References: <000001c4027a$e6157c90$ae70fe81@jafywinxp> <1078486185.9485.35.camel@dhcp-8-241.it.uu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by dpt-info.u-strasbg.fr id i25C5DZr056821 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Erik, Just a few comments: see below in the text ... CHristophe Erik Nordstr=F6m wrote: >On Fri, 2004-03-05 at 07:27, HyunWook Cha wrote: > > =20 > >>>>My current standing is that the "ideal" Internet access=20 >>>> =20 >>>> >>>mechanism, as=20 >>> =20 >>> >>>>far as routing is concerned, is tunneling in both=20 >>>> =20 >>>> >>>directions: source routing (IPv6) or encapsulation (IPv4) of=20 >>>outbound traffic via the gateway and encapsulation of inbound=20 >>>traffic from gateway to MANET node (IPv4 and IPv6). From=20 >>>there you start to make optimizations to save bandwidth etc.,=20 >>>and each optimization resembles a "hack", i.e. it undermines=20 >>>the ideal model. >>> =20 >>> >>>>=20 >>>> =20 >>>> >>What is ideal and what is hack? It depends on your thought?=20 >> >> =20 >> >>>Tunneling in both directions is OK, but I am not sure I would=20 >>>call it "ideal". It is just one solution, and I believe=20 >>>one-way is enough. But it is not such a big deal I think. >>> >>> =20 >>> >>IMO, to enforce all inbound traffics to be encapsulated is hack !!! >> =20 >> > >Why would this be a hack? Tunneling is an established mechanism. Do you >have a good argument for this? > > =20 > >>What makes you think that route entries for global addresses assigned t= o >>MANET nodes should not be maintained inside the MANET? I do not see any >>reason. If gateway obtains valid route entry for a destination node's >> =20 >> > >Tunneling does not totally exclude global (non-adhoc) addresses in the >MANET. Routing entries for global addresses still have to be maintained >at end nodes. It just simplifies the routing, and you achieves route >aggregation since you can share a tunnel among many addresses. In the >AODV case, there is also no need to maintain sequence numbers for routes >to global destinations since it maps to the gateway route. This would >not be the case if you "import" global addresses/routes into the ad hoc >network. > > =20 > Route aggregation ? Well usually route aggregation is for the routing=20 table ... and if you don't use a default route it means you will still=20 have a routing entry for each destination. The "next hop" entry will be=20 the same tunnel, but still you have one entry per destination. This=20 doesn't really look like route aggregation ... but maybe did you mean=20 something else ? >>global address, it can forward packets as they are. Unnecessary >>encapsulation is useless, wastful and it can cause packets to be droppe= d >>when size of encapulated packets are greater thatn MTU in case of IPv6. >>I believe that encapsulation should be used only when valid route entry >>for global address does not exsit and valid route entry for MANET local >>address is available and it is guaranteed that two addreeses point the >>same node. >> =20 >> > > > =20 > >>>>- The first step is to go from two-way to one-way tunneling, as we=20 >>>>have just discussed. >>>>- The next is perhaps your proposal to "rewrite"=20 >>>> =20 >>>> >>>destination addresses at the GW, as you seem to propose (It=20 >>>does not sound good, IMHO. I think we have to accespt that we=20 >>>might need NAT for outgoing IPv4 traffic, but I hope you do=20 >>>not need it for incoming traffic as well.) >>> >>>I am not sure what you mean here... I did not propose to=20 >>>rewrite the destination address except for the src->gateway=20 >>>encapsulation (depending on what encapsulation method you=20 >>>choose). I agree that NAT is a good target, but can be=20 >>>problematic with multiple gateways (i.e., keeping consistent=20 >>>NAT states). Mobile IP is the best solution for seamless=20 >>>migration between gateways I think. >>> >>> =20 >>> >>Right. Could you handle gateway handover using NATs? =20 >> >> =20 >> > >I guess, if you tunneled traffic from your "old" gateway to the new one. >Of course, there would have to be some extra signaling between the >gateways. > > > =20 > >>>>- The next step is perhaps to introduce Proxy RREPs (AODV, i.e.=20 >>>>gateway impersonates external hosts when sending RREP, see the old=20 >>>>globalv4/MIPv4 draft) or to use default routes (e.g. OLSR). Here you >>>> =20 >>>> >>>>might introduce routing race conditions, and also race conditions=20 >>>>between MANET nodes that have preference for using=20 >>>> =20 >>>> >>>different gateways but who are communicating with the same external >>> =20 >>> >>host. >> =20 >> >>>I agree. This is a separate issue from the forwarding and=20 >>>there are several ways to do it. However, I think a proxy=20 >>>RREP solution is very attractive. >>> >>> =20 >>> >>Whe source address based forwarding is used, MANET nodes that have >>preference for using different gateways but who are communicating with >>the same external host can do what they want. Actually intermediate >>nodes does not have to maintain default route entry(/0) but gateway >>information list as well as route entry(/128) for gateways.=20 >> >>I am not familiar with globalv4/MIPv4 draft. However I want to know tha= t >>proxy RREPs works well under multiple gateways or not, and how to >>configure global addresses.=20 >> >> =20 >> > >Proxy RREPs works with multiple gateways. A source node gets multiple >replies and can chose the best route (i.e., based on hop count or >something else). > >As for the global address, why would you need to configure one? In the >NAT case you can use your home address or a link local. With MIP you >would use your home address in the ad hoc network and the gateway/FA >would just rewrite the packet with the care-of-address. No address >configuration is necessary as long as you have a unique home address. >For those that don't have a valid home address, you can just configure a >link local address. > > =20 > With IPv6 each MANET node will need a global address, unless you allow=20 to route and forward link local addresses (fe80::/64). That's why there=20 was once a proposal to use a site-local MANET prefix ... there is also a=20 proposal from Guillaume Chelius and Eric Fleury (ANA6) that tries to=20 solve this issue (routing without a global address). In general when you=20 want Internet connectivity you'll need a global address. > =20 > >>>I think it is neither. I have played around with default=20 >>>routes. With reactive protocols it is my strong belief that=20 >>>they give more problems than they solve. It is clear that you=20 >>>can't use a generic routing entry with a reactive protocol=20 >>>and multiple gateways without adding extra state. It quickly=20 >>>becomes a mess... >>> >>> =20 >>> >>This depends on implementation of default route forwarding. I can not >>understand why you are considering default route forwarding using prefi= x >>continuity or source address based forwading. Please give careful >>comments on two drafts.(Do not say "hack" before you can prove that >>clearly.) =20 >> >> =20 >> > >Prefix continuity is fine but clearly has limitations, since (all) nodes >can't chose gateways by themselves. I am not sure what you mean with >source address based forwarding. Do you select your default route based >on source address? In that case you need to maintain a lot of extra >state and you have no route aggregation which is mainly what default >routes are for. Correct me if I am wrong. > =20 > I won't call that a limitation ... the objective is to maintain prefix=20 continuity, not to allows nodes to choose whatever prefix they want. In=20 the later case it's best to use a solution that uses tunnels (or routing=20 header with IPv6). Would you call IPv6 stateless autoconf "a limitation"=20 because it gives the same prefix to all nodes of a subnet ? To me it's=20 just doing fine what it has been designed for ... ;-) >/Erik > > >_______________________________________________ >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 From exim@www1.ietf.org Fri Mar 5 07:21:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04953 for ; Fri, 5 Mar 2004 07:21:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzEJo-00076k-JL for manet-archive@odin.ietf.org; Fri, 05 Mar 2004 07:20:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25CKi24027314 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 07:20:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzEJn-00076T-W7 for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 07:20:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04944 for ; Fri, 5 Mar 2004 07:20:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzEJn-0004qI-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 07:20:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzEIo-0004eC-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 07:19:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzEIN-0004SX-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 07:19:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzEI9-0006r6-JU; Fri, 05 Mar 2004 07:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzEHg-0006pT-85 for manet@optimus.ietf.org; Fri, 05 Mar 2004 07:18:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04885 for ; Fri, 5 Mar 2004 07:18:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzEHf-0004Pt-00 for manet@ietf.org; Fri, 05 Mar 2004 07:18:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzEGd-0004EU-00 for manet@ietf.org; Fri, 05 Mar 2004 07:17:28 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AzEFl-00044A-00 for manet@ietf.org; Fri, 05 Mar 2004 07:16:34 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i25CGWdi003491; Fri, 5 Mar 2004 13:16:32 +0100 (MET) Subject: Re: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: Christophe Jelger Cc: "'manet'" In-Reply-To: <40486CA8.3040507@dpt-info.u-strasbg.fr> References: <000001c4027a$e6157c90$ae70fe81@jafywinxp> <1078486185.9485.35.camel@dhcp-8-241.it.uu.se> <40486CA8.3040507@dpt-info.u-strasbg.fr> Content-Type: text/plain Message-Id: <1078488992.9485.47.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Fri, 05 Mar 2004 13:16:32 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2004-03-05 at 13:03, Christophe Jelger wrote: > >> > > > >Prefix continuity is fine but clearly has limitations, since (all) nodes > >can't chose gateways by themselves. I am not sure what you mean with > >source address based forwarding. Do you select your default route based > >on source address? In that case you need to maintain a lot of extra > >state and you have no route aggregation which is mainly what default > >routes are for. Correct me if I am wrong. > > > > > I won't call that a limitation ... the objective is to maintain prefix > continuity, not to allows nodes to choose whatever prefix they want. In > the later case it's best to use a solution that uses tunnels (or routing > header with IPv6). Would you call IPv6 stateless autoconf "a limitation" > because it gives the same prefix to all nodes of a subnet ? To me it's > just doing fine what it has been designed for ... ;-) > Ok, limited applicability? I agree that if prefix continuity is fine if that's what you want. And yes, stateless autoconf can be a limitation since it does not allow you to easily switch between gateways (and maintain your connections). MIP would be better for that (or a combination). But it does not mean it is not useful for what it was design for. Which I do not believe were ad hoc networks and multiple gateway scenarios. Rather as an alternative to DHCP? /Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 5 10:49:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14032 for ; Fri, 5 Mar 2004 10:49:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHZA-0005Xs-BM for manet-archive@odin.ietf.org; Fri, 05 Mar 2004 10:48:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25FmmTP021312 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 10:48:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHZA-0005Xf-1z for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 10:48:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14025 for ; Fri, 5 Mar 2004 10:48:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzHZ7-0005fC-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 10:48:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzHYG-0005UG-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 10:47:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzHXk-0005Ij-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 10:47:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHXR-0005Fi-O9; Fri, 05 Mar 2004 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzHX3-0005EV-Bu for manet@optimus.ietf.org; Fri, 05 Mar 2004 10:46:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13925 for ; Fri, 5 Mar 2004 10:46:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzHX0-0005EX-00 for manet@ietf.org; Fri, 05 Mar 2004 10:46:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzHW4-000529-00 for manet@ietf.org; Fri, 05 Mar 2004 10:45:37 -0500 Received: from nestor.nmsu.edu ([128.123.34.146] helo=mail.nmsu.edu) by ietf-mx with esmtp (Exim 4.12) id 1AzHV7-0004oO-00 for manet@ietf.org; Fri, 05 Mar 2004 10:44:38 -0500 Received: from PCMullen2 (pc-mullen-2.NMSU.Edu [128.123.245.103]) by mail.nmsu.edu (Postfix) with ESMTP id 0FC792006; Fri, 5 Mar 2004 08:44:37 -0700 (MST) From: "John Mullen" To: "'NICOLAS LOUIS'" , Subject: RE: [manet] Routing algorithm in OPNET 8.1 Date: Fri, 5 Mar 2004 08:45:12 -0700 Message-ID: <001a01c402c8$d8b9da70$67f57b80@IEngr.ad.nmsu.edu> 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.2800.1165 In-Reply-To: <200403051029.i25ATPsk011174@reserv6.univ-lille1.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Nicolas, There are some AODV models at: http://www.mil3.com/support/home1.html You need to be a registered user to log in, but you don't need a maintenance agreement. I didn't find any OLSR models there. John Mullen -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of NICOLAS LOUIS Sent: Friday, March 05, 2004 3:29 AM To: manet@ietf.org Subject: [manet] Routing algorithm in OPNET 8.1 Hi I'm a student in the university of Lille, France I'm working on a MAC protocol for my degree and I'm searching for a routing algotithm for wireless networks 802.11 to make simulations. Does anyone know if a AODV or OLSR model for OPNET 8.1 exists and where can I find it ? Thank you for your help. Regards Nicolas LOUIS _______________________________________________ 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 exim@www1.ietf.org Fri Mar 5 12:43:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19350 for ; Fri, 5 Mar 2004 12:43:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzJLW-0000ai-4I for manet-archive@odin.ietf.org; Fri, 05 Mar 2004 12:42:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25HgoWf002271 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 12:42:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzJLV-0000aY-UC for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 12:42:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19266 for ; Fri, 5 Mar 2004 12:42:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzJLS-0004tR-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 12:42:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzJKG-0004Tm-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 12:41:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzJIm-0004C1-03 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 12:40:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzJ6N-0003T3-I3 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 12:27:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzJ6E-0006yE-0Z; Fri, 05 Mar 2004 12:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzJ60-0006x5-M9 for manet@optimus.ietf.org; Fri, 05 Mar 2004 12:26:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18836 for ; Fri, 5 Mar 2004 12:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzJ5x-0001zf-00 for manet@ietf.org; Fri, 05 Mar 2004 12:26:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzJ5D-0001nt-00 for manet@ietf.org; Fri, 05 Mar 2004 12:26:00 -0500 Received: from grouse.mail.pas.earthlink.net ([207.217.120.116]) by ietf-mx with esmtp (Exim 4.12) id 1AzJ4L-0001Zb-00 for manet@ietf.org; Fri, 05 Mar 2004 12:25:05 -0500 Received: from user-2ivfmi4.dialup.mindspring.com ([165.247.218.68] helo=earthlink.net) by grouse.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AzJ4F-0001KG-00; Fri, 05 Mar 2004 09:25:00 -0800 Message-ID: <4048B7E8.3090804@earthlink.net> Date: Fri, 05 Mar 2004 09:24:56 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Christophe Jelger CC: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <40470344.3070202@insa-lyon.fr> <404714FE.2010207@dpt-info.u-strasbg.fr> <4047762E.1080401@earthlink.net> <40483E65.2000102@dpt-info.u-strasbg.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christophe Jelger wrote: > Richard, > > I think we all agree that gateway discovery and prefix announcement > can be integrated into a proactive routing protocol. Again I'd like to > re-state that we clearly say that in the draft ... ;-) At least that > seems to be a first consensus. > > I also just want to re-state that we first decided to propose the idea > without integrating the concept in any routing protocol ... this is > (in its current state) why we can have different routes between our > standalone process and the routing protocol. Of course the final > objective when we integrate it in OLSR is to "merge" everything (e.g. > unique neighbors table and neighbor discovery mechanisms). My point is that your draft proposes a specific mechanism based on distance-vector routing to determine the route to a gateway. OLSR uses a different mechanism based on link-state routing to determine the route to every node. You have not said how you plan to "merge" everything, but even if you do, it is still redundant to have these two different mechanisms. If you want prefix continuity, this can be done using link-state routing, by having each node advertise its prefix, and having each node compute a source tree for each prefix. If you are claiming that it is better to use distance vector routing to achieve prefix continuity, that is possible, but it *might* also be better to use distance-vector routing (instead of link-state routing) for proactive routing. But the WG has decided to use link-state routing for proactive routing, so for consistency it would be good to use link-state routing for gateway discovery and prefix continuity, if possible. However, a valid reason for using distance-vector routing is to have a common mechanism that can be used for both proactive and reactive routing. This is because OLSR-style link-state routing is not useful for computing routes to only a *few* nodes (e.g., gateways), but distance-vector routing is ideal for this. (Which is why it is also used for landmark routing.) As a side note, source-tree based routing algorithms (such as TBRPF) are also useful for computing routes to only a few nodes, since each node only needs to advertise links on its shortest path to each such node. BUT, it is not necessary to use the same mechanism for both proactive and reactive routing (and such a mechanism would be redundant for proactive routing). > > > Finally, I know that there has already been a lot of discussions on > "should we have something like prefix continuity, or can we just mix > nodes and don't bother about that ?". I'm not sure that's something we > should decide, because it will mainly be a matter of deployment. If an > operator (at a large sense) wants to deploy an ad hoc network, it > should be able to choose whether it wants prefix continuity or not (as > it can choose between different types of routing protocol). I think > our task is to propose solutions, and people just decide (or not) to > use them. Of course I like prefix continuity, but not just because we > (sort of) proposed that. I really think it's something people will > like in their deployment, it can be really useful in a number of > situations (management, accounting, load balancing). It seems to me that prefix continuity makes load balancing more difficult. (In any case, load balancing does not require prefix continuity.) Correct me if I am wrong, but my understanding is that only nodes on the boundary between two prefix islands can choose between two gateways with different prefixes. Nodes in the interior of a prefix island know only about the gateway(s) with the same prefix, and thus cannot use another gateway for load balancing. Is that correct? Regards, Richard > > > Regards, > Christophe > > Richard Ogier wrote: > >> Christophe Jelger wrote: >> >>> Guillaume, >>> >>> Just on point, see inline my comment. In general I agree that >>> gateway discovery should not be separated, as stated in the draft. >>> We first implemented it as a stand-alone process to check the >>> operation. As you know, we plan to integrate it into OLSR. (see >>> below for a last comment) >> >> >> >> >> >>> >>> With prefix continuity, routes are optimal if we use the "distance" >>> algorithm : always choose closest gateway. In that case the route is >>> a shortest route, but it can be different than the shortest route >>> computed by the routing protocol. On the other hand, if we use the >>> algorithm "prefix stability", then the route might not be optimal >>> (I'm currently simulating this and it appears that routes are not >>> much longer on average). >>> >> So, the gateway discovery protocol (which uses distance vectors) >> computes a route to some gateway, and the link-state routing protocol >> (e.g., OLSR or TBRPF or OSPF) computes a route to each gateway, which >> may be different from the one computed by the gateway discovery >> protocol. >> Also, it is possible that the link-state protocol reacts to topology >> changes faster or slower than the gateway protocol. >> Wouldn't it be nice if the two protocols could *agree* on the route to >> each gateway? I would prefer to remove this redundancy, and just have >> one routing protocol that computes the routes to all nodes, including >> routes to gateways and default routes. >> Several people (including Joe Macker, Chelius Guillaume, Pedro Ruiz, >> Eric Fleury) have agreed that it would be better to avoid redundancy >> between the proactive routing protocol and gateway discovery. >> Can we agree that we have consensus on this >> Now, you may say that the proactive routing protocol still needs some >> mechanism to achieve prefix continuity. IF we decide we need >> to ensure prefix continuity (and I have doubts about this), >> then the link-state routing protocol can be modified to achieve this, >> using link-state routing (instead of distance vectors). >> >> Regards, >> Richard >> >>> >> > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 5 13:00:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20306 for ; Fri, 5 Mar 2004 13:00:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzJc8-0001wx-FZ for manet-archive@odin.ietf.org; Fri, 05 Mar 2004 13:00:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25I00bS007493 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 13:00:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzJc8-0001wm-CW for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 13:00:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20260 for ; Fri, 5 Mar 2004 12:59:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzJc4-0000nt-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 12:59:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzJb6-0000bG-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 12:58:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzJaP-0000PW-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 12:58:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzJaE-0001YB-Jx; Fri, 05 Mar 2004 12:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzJa6-0001Xk-LV for manet@optimus.ietf.org; Fri, 05 Mar 2004 12:57:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20123 for ; Fri, 5 Mar 2004 12:57:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzJa2-0000NY-00 for manet@ietf.org; Fri, 05 Mar 2004 12:57:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzJZC-0000CX-00 for manet@ietf.org; Fri, 05 Mar 2004 12:56:59 -0500 Received: from mail.tns.net ([216.86.143.7] helo=remail.tns.net) by ietf-mx with esmtp (Exim 4.12) id 1AzJYW-00000b-00 for manet@ietf.org; Fri, 05 Mar 2004 12:56:16 -0500 Received: from SDRCZZ (66-146-170-74.skyriver.net [66.146.170.74]) by remail.tns.net (8.12.8p1/9.4.4) with ESMTP id i25Hu8Rd098264 for ; Fri, 5 Mar 2004 09:56:09 -0800 (PST) (envelope-from zzhang@ieee.org) Message-Id: <200403051756.i25Hu8Rd098264@remail.tns.net> From: "Zhensheng Zhang" To: "'manet'" Date: Fri, 5 Mar 2004 09:56:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQBRj8HRGfPJ1z2ReKXpKvt0zy6DABlFSRQ In-Reply-To: <1078335284.1364.111.camel@dhcp-8-241.it.uu.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Milter: Spamilter Content-Transfer-Encoding: quoted-printable Subject: [manet] CFP: Broadband wireless networking symposium 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 CALL FOR PAPERS BroadNets 2004 Broadband Wireless Networking Symposium October 25-29, 2004, San Jose, California, USA http://www.broadnets.org BroadNets 2004 is a new conference focusing on broadband networking and covers the entire gamut of next generation networks with ultra-high bandwidth available all the way from access networks, to regional and metropolitan networks, to wide-area core networks. Broadband Wireless Networking that is defined to cover high-speed wireless networking for access, regional and backhaul networks including backhaul capacity provisioning using wireless, including the WLAN networks and WMAN. .BroadNets 2004 will thus offer a unique forum for researchers from academia, government, and industry to share ideas and disseminate new results in these important areas. We are soliciting full papers in all research, development, and deployment areas on broadband wireless networking. Papers of particular merit will be considered for a special issue of ACM/Kluwer Mobile Networks (MONET) Journal. Topics Full papers are solicited in all research and applied areas related to broadband wireless networking. Topics include, but not limited to: =20 =D8 3G/4G Systems =D8 Fixed Broadband Wireless Access =D8 Wireless Local Area Networks =D8 WLAN Hotspots =D8 Wireless indoor & home networks =D8 Wireless Personal Area Networks including IEEE 802.15 =D8 IEEE 802.16 (WiMax) Standards Activities and Products =D8 Wireless Metropolitan Area Networks =D8 Wireless Wide Area Networks =D8 Free-Space Optics =D8 Ultra Wideband (UWB) Networks =D8 Ad-hoc networks =D8 System architecture =D8 Network Topology management =D8 Neighbor discovery =D8 Unicast and multicast routing =D8 Quality-of-Service support =D8 Security techniques and systems =D8 Resource management =D8 Software-defined radio =D8 Space-time processing, MIMO systems =D8 Digital signal processing =D8 Smart (directional) antennas =D8 Power control =D8 Wireless emergency systems =D8 Standards, Licensing and regulation =D8 Interference mitigation for multiple access =D8 Economics and business cases=20 Important Dates =B7 Submission Deadline: March 15, 2004 =B7 Acceptance Notification: June 7, 2004 =B7 Final Manuscript Due: July 7, 2004 Submission Instructions Authors are invited to submit full papers of up to 20 double-spaced = pages, including references, figures, and tables. All submissions should be submitted electronically in Postscript or Adobe PDF format through the = EDAS submission system at http://edas.info/Conferences.cgi. Proposals for Workshops, Tutorials, and Panels Proposals for workshops, tutorials, and panels on broadband wireless networking and related topics are solicited. Workshop proposals should consist of: 1) title of the workshop, 2) description of potential = audience, 3) description of the workshop topic and justification of why the = proposed topic is interesting and timely and, 4) intended format of the workshop. Tutorial proposals should consist of: 1) title and outline of materials = to be presented, 2) description of potential audience, 3) justification of = why the proposed topic is interesting and timely and, 4) biographical sketch = of the presenter(s). Panel topics should address innovative, controversial, = or otherwise provocative issues of interest related to broadband wireless networking and communications. Workshop proposals should be submitted to = the appropriate chair by March 15, 2004. Tutorial and Panel proposals = should be submitted to the appropriate chairs by May 1, 2004. Exhibits and Sponsorship Opportunities For information on exhibit space or sponsorship opportunities at = BroadNets 2004, please contact the Exhibits and Sponsorships Chairs. Organizing Committee =20 Symposium Chair Zhensheng Zhang, San Diego Research Center=09 zzhang@ieee.org Technical Program Chairs Parameswaran Ramanathan, Univ. of Wisconsin-Madison, = parmesh@ece.wisc.edu=20 Thomas Hou, Virginia Tech, thou@vt.edu=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Mar 6 15:24:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03520 for ; Sat, 6 Mar 2004 15:24:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AziLA-00018V-68 for manet-archive@odin.ietf.org; Sat, 06 Mar 2004 15:24:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26KO8jp004356 for manet-archive@odin.ietf.org; Sat, 6 Mar 2004 15:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AziL9-000188-M2 for manet-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 15:24:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03514 for ; Sat, 6 Mar 2004 15:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AziL8-0001c3-00 for manet-web-archive@ietf.org; Sat, 06 Mar 2004 15:24:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AziKB-0001SK-00 for manet-web-archive@ietf.org; Sat, 06 Mar 2004 15:23:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AziJL-0001Ht-00 for manet-web-archive@ietf.org; Sat, 06 Mar 2004 15:22:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AziJ6-0000uc-Jy; Sat, 06 Mar 2004 15:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AziIt-0000u6-MC for manet@optimus.ietf.org; Sat, 06 Mar 2004 15:21:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03485 for ; Sat, 6 Mar 2004 15:21:45 -0500 (EST) From: Paal.Engelstad@telenor.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AziIs-0001Gi-00 for manet@ietf.org; Sat, 06 Mar 2004 15:21:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AziHx-00019J-00 for manet@ietf.org; Sat, 06 Mar 2004 15:20:50 -0500 Received: from virus-out.ttyl.com ([193.212.240.200] helo=scan.telenor.net) by ietf-mx with esmtp (Exim 4.12) id 1AziGz-0000u7-00 for manet@ietf.org; Sat, 06 Mar 2004 15:19:49 -0500 Received: from tns-fbu-22-209.corp.telenor.no ([134.47.162.190] [134.47.162.190]) by scan.telenor.net with ESMTP; Sat, 6 Mar 2004 21:19:16 +0100 Received: from moffice3.nsc.no ([10.122.115.83]) by tns-fbu-22-209.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Mar 2004 21:19:16 +0100 Message-Id: <32569599.1078604356215.JavaMail.adm-moff@moffice3.nsc.no> To: To: Christophe Jelger To: =?iso-8859-1?Q?Erik_Nordstr=F6m?= Subject: Re: SV: RE: [manet] Default Routes (Intern) Cc: "'manet'" In-Reply-To: <40486CA8.3040507@dpt-info.u-strasbg.fr> X-Priority: 3 (Normal) X-Mailer: Mobile Office v1.0 (Telenor Business Solutions) References: <000001c4027a$e6157c90$ae70fe81@jafywinxp> <1078486185.9485.35.camel@dhcp-8-241.it.uu.se> <40486CA8.3040507@dpt-info.u-strasbg.fr> X-OriginalArrivalTime: 06 Mar 2004 20:19:16.0490 (UTC) FILETIME=[4C763EA0:01C403B8] Date: 6 Mar 2004 21:19:16 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2012_17832284.1078604356213" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ------=_Part_2012_17832284.1078604356213 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi HyunWook Cha, Comments inline: On 2004-03-05 13:03:52 CET Christophe Jelger wrote >Erik Nordstr=F6m wrote: >>On Fri, 2004-03-05 at 07:27, HyunWook Cha wrote: >> >>>>>My current standing is that the "ideal" Internet access=20 >>>>mechanism, as=20 >>>>>far as routing is concerned, is tunneling in both=20 >>>>directions: source routing (IPv6) or encapsulation (IPv4) of=20 >>>>outbound traffic via the gateway and encapsulation of inbound=20 >>>>traffic from gateway to MANET node (IPv4 and IPv6). From=20 >>>>there you start to make optimizations to save bandwidth etc.,=20 >>>>and each optimization resembles a "hack", i.e. it undermines=20 >>>>the ideal model. >>>> =20 >>>What is ideal and what is hack? It depends on your thought?=20 >>> I agree with you that it is difficult to draw a clear line, so let's not ar= gue over words... (However, if you want to know my thought: According to my= terminology, a "hack" is a solution that imposes additional requirements o= n the network that *significantly* narrows the room for improving technolog= y in the future. E.g. NAT is a hack that changes the rules of the networkin= g, by requiring all traffic be initaited from one side, and IP-layers proto= cols (e.g. IPSec and MIP) be transparent to changes in IP-addresses (and po= rtnumbers - for NAPT). The result of a "hack" is normally new "hacks", e.g= . MIP-over-UDP-tunnels or IPSec-over-UDP, to circumvent the additional requ= irements imposed by the previous hack.) >>> =20 >>>>Tunneling in both directions is OK, but I am not sure I would=20 >>>>call it "ideal". It is just one solution, and I believe=20 >>>>one-way is enough. But it is not such a big deal I think.=20 >>>> >>>IMO, to enforce all inbound traffics to be encapsulated is hack !!! >>> =20 According to how I defined a "hack" above, it is probably not...but again l= et's not argue over words. It was stupid of me to use a negatively loaded w= ord. I am not saying that encapsulating inbound traffic is a good solution.= I only say that it is the "cleanest" solution. Probably we will need to do= optimisations to make things more efficient. There is a tradeoff between m= aking it clean and making it efficient, and I am not sure exactly where to = draw the line. That is what I intend to find out. >> >>Why would this be a hack? Tunneling is an established mechanism. Do you >>have a good argument for this? >> Agree with Erik. >> =20 >>>What makes you think that route entries for global addresses assigned to >>>MANET nodes should not be maintained inside the MANET? I do not see any >>>reason. If gateway obtains valid route entry for a destination node's >>> Take AODV as an example, how does gateways maintain destination sequence nu= mbers on behalf of external nodes? And how does the gateways cooperate to m= aintain sequence numbers. I remember that some version of the AODV-draft (m= aybe the RFC) proposed co-operation between gateways, but in my opinion thi= s is not a desireable way to go. Besides, I also tend to agree with Erik's comment, here: >> >>Tunneling does not totally exclude global (non-adhoc) addresses in the >>MANET. Routing entries for global addresses still have to be maintained >>at end nodes. It just simplifies the routing, and you achieves route >>aggregation since you can share a tunnel among many addresses. In the >>AODV case, there is also no need to maintain sequence numbers for routes >>to global destinations since it maps to the gateway route. This would >>not be the case if you "import" global addresses/routes into the ad hoc >>network. >> >> =20 <...> >>>> >>>Right. Could you handle gateway handover using NATs? =20 >>> Using MIP with NAT-traversal is probably the most straightforward solution,= but the additional overhead of 28bytes only for the NAT-traversal part is = not insignificant on a MANET. (In fact, we have discussed implementing this= , just to see how it works.) The upside is that you could probably use off-= the-self MIPv4 code in co-located mode and with NAT-traversal, and I assume= it would work without major changes. I believe that other MIP-for-MANET so= lutions proposed, on the contrary, would need special-purpose code that wou= ld differ significantly from regular off-the-shelf MIPv4.=20 >> >>I guess, if you tunneled traffic from your "old" gateway to the new one. >>Of course, there would have to be some extra signaling between the >>gateways. >> Yes, Erik, that might be another option... None of them seems ideal, though= ... > > <...> Paal ------=_Part_2012_17832284.1078604356213-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Mar 6 16:19:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05398 for ; Sat, 6 Mar 2004 16:19:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzjCJ-0004wC-TN for manet-archive@odin.ietf.org; Sat, 06 Mar 2004 16:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26LJ3YQ018974 for manet-archive@odin.ietf.org; Sat, 6 Mar 2004 16:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzjCJ-0004vv-N1 for manet-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 16:19:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05371 for ; Sat, 6 Mar 2004 16:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzjCH-0001zG-00 for manet-web-archive@ietf.org; Sat, 06 Mar 2004 16:19:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzjBD-0001of-00 for manet-web-archive@ietf.org; Sat, 06 Mar 2004 16:17:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzjAZ-0001fb-00 for manet-web-archive@ietf.org; Sat, 06 Mar 2004 16:17:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzjAM-0004dS-8J; Sat, 06 Mar 2004 16:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzjAG-0004d3-43 for manet@optimus.ietf.org; Sat, 06 Mar 2004 16:16:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05331 for ; Sat, 6 Mar 2004 16:16:53 -0500 (EST) From: Paal.Engelstad@telenor.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzjAE-0001eT-00 for manet@ietf.org; Sat, 06 Mar 2004 16:16:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azj9D-0001WG-00 for manet@ietf.org; Sat, 06 Mar 2004 16:15:52 -0500 Received: from virus-out.ttyl.com ([193.212.240.200] helo=scan.telenor.net) by ietf-mx with esmtp (Exim 4.12) id 1Azj8P-0001Gg-00 for manet@ietf.org; Sat, 06 Mar 2004 16:15:01 -0500 Received: from tns-fbu-22-208.corp.telenor.no ([134.47.162.90] [134.47.162.90]) by scan.telenor.net with ESMTP; Sat, 6 Mar 2004 22:14:28 +0100 Received: from moffice2.nsc.no ([10.122.115.82]) by tns-fbu-22-208.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Mar 2004 22:14:27 +0100 Message-Id: <24635060.1078607667373.JavaMail.adm-moff@moffice2.nsc.no> To: =?iso-8859-1?Q?Erik_Nordstr=F6m?= To: Subject: Re: SV: RE: [manet] Default Routes (Intern) Cc: Cc: "'manet'" In-Reply-To: <1078486185.9485.35.camel@dhcp-8-241.it.uu.se> X-Priority: 3 (Normal) X-Mailer: Mobile Office v1.0 (Telenor Business Solutions) References: <000001c4027a$e6157c90$ae70fe81@jafywinxp> <1078486185.9485.35.camel@dhcp-8-241.it.uu.se> X-OriginalArrivalTime: 06 Mar 2004 21:14:27.0781 (UTC) FILETIME=[02252750:01C403C0] Date: 6 Mar 2004 22:14:27 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2373_4725080.1078607667371" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ------=_Part_2373_4725080.1078607667371 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Erik, > Proxy RREPs works with multiple gateways. A source node gets multiple > replies and can chose the best route (i.e., based on hop count or > something else). It works, but whether it works "fine"or not is probably a matter of definition ;-) The problem is that it easily leads to routing race conditions. For example, if you have two gateways that are located an equal number of hops away from the MANET node, both gateways will return the same Proxy RREP (assuming that both gateways use the same gateway-independent rules for setting the sequence number, and thus return the same sequence number.) Every time the outgoing route needs to be re-discovered due to link breaks or route-timeouts, the outgoing route is determined by the first Proxy RREPs that reaches the MANET node or the intermediate node where the return routes of the two Proxy RREPs meet. The outgoing route may shift between the two gateways in a non-deterministic way. If there are NATs present, the performance can be discouraging. We have both done tests and simulations on this issue, and the results so far does not yet convince me that Proxy RREP is a solution without significant problems. You might have different experiences? Paal ------=_Part_2373_4725080.1078607667371-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Mar 7 00:41:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20529 for ; Sun, 7 Mar 2004 00:41:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azr2M-0006v9-Uu for manet-archive@odin.ietf.org; Sun, 07 Mar 2004 00:41:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i275fICC026597 for manet-archive@odin.ietf.org; Sun, 7 Mar 2004 00:41:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azr2M-0006uu-Ql for manet-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 00:41:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20488 for ; Sun, 7 Mar 2004 00:41:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azr2K-0002f2-00 for manet-web-archive@ietf.org; Sun, 07 Mar 2004 00:41:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azr1J-0002U7-00 for manet-web-archive@ietf.org; Sun, 07 Mar 2004 00:40:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Azr0J-0002K1-00 for manet-web-archive@ietf.org; Sun, 07 Mar 2004 00:39:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azr0A-0006UR-73; Sun, 07 Mar 2004 00:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzqzM-0006PJ-Ei for manet@optimus.ietf.org; Sun, 07 Mar 2004 00:38:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20373 for ; Sun, 7 Mar 2004 00:38:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzqzJ-00028P-00 for manet@ietf.org; Sun, 07 Mar 2004 00:38:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzqyP-0001x1-00 for manet@ietf.org; Sun, 07 Mar 2004 00:37:14 -0500 Received: from [203.199.83.147] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1AzqxV-0001m6-00 for manet@ietf.org; Sun, 07 Mar 2004 00:36:18 -0500 Received: (qmail 31906 invoked by uid 510); 7 Mar 2004 05:36:14 -0000 Date: 7 Mar 2004 05:36:14 -0000 Message-ID: <20040307053614.31905.qmail@webmail25.rediffmail.com> Received: from unknown (61.11.44.89) by rediffmail.com via HTTP; 07 mar 2004 05:36:14 -0000 MIME-Version: 1.0 From: "kani mozhi" Reply-To: "kani mozhi" To: manet@ietf.org Content-type: multipart/alternative; boundary="Next_1078637774---0-203.199.83.147-31903" Subject: [manet] security in adhoc 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_IMAGE_ONLY_06,HTML_MESSAGE,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 This is a multipart mime message --Next_1078637774---0-203.199.83.147-31903 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

=0A
=0Ahi everybody
=0Aiam doing  a project related to securi= ty in adhoc networks.
=0A    i want to know what would be the = processing time taken my a node during data transmission.
=0A  wha= t are the parameters that decide the processing time?
=0A
=0Aplease d= o reply=0A

=0A

=0A=0A --Next_1078637774---0-203.199.83.147-31903 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =0Ahi everybody=0Aiam doing a project related to security in adhoc network= s.=0A i want to know what would be the processing time taken my a node d= uring data transmission.=0A what are the parameters that decide the proce= ssing time?=0A=0Aplease do reply --Next_1078637774---0-203.199.83.147-31903-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Mar 7 13:47:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00312 for ; Sun, 7 Mar 2004 13:47:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B03Ie-0000sX-Fu for manet-archive@odin.ietf.org; Sun, 07 Mar 2004 13:46:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i27Ikus8003378 for manet-archive@odin.ietf.org; Sun, 7 Mar 2004 13:46:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B03Ie-0000sP-9I for manet-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 13:46:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00304 for ; Sun, 7 Mar 2004 13:46:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B03Ib-0004Ie-00 for manet-web-archive@ietf.org; Sun, 07 Mar 2004 13:46:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B03Hg-00049v-00 for manet-web-archive@ietf.org; Sun, 07 Mar 2004 13:45:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B03H2-000429-00 for manet-web-archive@ietf.org; Sun, 07 Mar 2004 13:45:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B03Gq-0000e0-Ei; Sun, 07 Mar 2004 13:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B03Fq-0000Vu-KG for manet@optimus.ietf.org; Sun, 07 Mar 2004 13:44:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00229 for ; Sun, 7 Mar 2004 13:44:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B03Fo-0003s8-00 for manet@ietf.org; Sun, 07 Mar 2004 13:44:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B03Ex-0003j2-00 for manet@ietf.org; Sun, 07 Mar 2004 13:43:08 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1B03EN-0003Vm-00 for manet@ietf.org; Sun, 07 Mar 2004 13:42:31 -0500 Received: from etri7fodix6mw4 (61.81.79.242 [61.81.79.242]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW2LQ4; Mon, 8 Mar 2004 03:41:44 +0900 Message-ID: <004501c40473$db873d40$f24f513d@etri7fodix6mw4> Reply-To: "HyunWook Cha" From: "HyunWook Cha" To: , "Christophe Jelger" , =?ISO-8859-1?Q?Erik_Nordstr=F6m?= Cc: "'manet'" References: <000001c4027a$e6157c90$ae70fe81@jafywinxp> <1078486185.9485.35.camel@dhcp-8-241.it.uu.se> <40486CA8.3040507@dpt-info.u-strasbg.fr> <32569599.1078604356215.JavaMail.adm-moff@moffice3.nsc.no> Subject: Re: SV: RE: [manet] Default Routes (Intern) Date: Mon, 8 Mar 2004 03:40:28 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA00230 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, Paal and all. My comments below. ----- Original Message ----- From: To: ; "Christophe Jelger" = ; "Erik Nordstr=F6m" Cc: "'manet'" Sent: Sunday, March 07, 2004 5:19 AM Subject: Re: SV: RE: [manet] Default Routes (Intern) Hi HyunWook Cha, Comments inline: On 2004-03-05 13:03:52 CET Christophe Jelger wrote >Erik Nordstr=F6m wrote: >>On Fri, 2004-03-05 at 07:27, HyunWook Cha wrote: >> >>>>>My current standing is that the "ideal" Internet access >>>>mechanism, as >>>>>far as routing is concerned, is tunneling in both >>>>directions: source routing (IPv6) or encapsulation (IPv4) of >>>>outbound traffic via the gateway and encapsulation of inbound >>>>traffic from gateway to MANET node (IPv4 and IPv6). From >>>>there you start to make optimizations to save bandwidth etc., >>>>and each optimization resembles a "hack", i.e. it undermines >>>>the ideal model. >>>> >>>What is ideal and what is hack? It depends on your thought? >>> I agree with you that it is difficult to draw a clear line, so let's not argue over words... (However, if you want to know my thought: According t= o my terminology, a "hack" is a solution that imposes additional requiremen= ts on the network that *significantly* narrows the room for improving technology in the future. E.g. NAT is a hack that changes the rules of th= e networking, by requiring all traffic be initaited from one side, and IP-layers protocols (e.g. IPSec and MIP) be transparent to changes in IP-addresses (and portnumbers - for NAPT). The result of a "hack" is normally new "hacks", e.g. MIP-over-UDP-tunnels or IPSec-over-UDP, to circumvent the additional requirements imposed by the previous hack.) [HW] Ok, I understand what you mean by "hack". However, IMO, we have not analy= zed existing solutions fully until now, so it is not suitable time to say wha= t is ideal or hack. I agree that tunneling in both directions are simple an= d do not cause any problem, but I do not think that that is efficient and h= as no room to optimize and any effort to do that are just hack. I do not wan= t to argue over words, either. >>> >>>>Tunneling in both directions is OK, but I am not sure I would >>>>call it "ideal". It is just one solution, and I believe >>>>one-way is enough. But it is not such a big deal I think. >>>> >>>IMO, to enforce all inbound traffics to be encapsulated is hack !!! >>> According to how I defined a "hack" above, it is probably not...but again let's not argue over words. It was stupid of me to use a negatively loade= d word. I am not saying that encapsulating inbound traffic is a good soluti= on. I only say that it is the "cleanest" solution. Probably we will need to d= o optimisations to make things more efficient. There is a tradeoff between making it clean and making it efficient, and I am not sure exactly where = to draw the line. That is what I intend to find out. [HW] >From your definition about "hack", you are right. Tunneling itself is not hack, but the strict requirement that inbound traffics should be encapsulated is not desirable as I mentioned before. >> >>Why would this be a hack? Tunneling is an established mechanism. Do you >>have a good argument for this? >> Agree with Erik. >> >>>What makes you think that route entries for global addresses assigned = to >>>MANET nodes should not be maintained inside the MANET? I do not see an= y >>>reason. If gateway obtains valid route entry for a destination node's >>> Take AODV as an example, how does gateways maintain destination sequence numbers on behalf of external nodes? And how does the gateways cooperate = to maintain sequence numbers. I remember that some version of the AODV-draft (maybe the RFC) proposed co-operation between gateways, but in my opinion this is not a desireable way to go. [HW] Why gateways care about seq no for external nodes? Are you considering about proxy RREP based solution? In the most of existing drafts including globalv6 related this issue, route entries for external nodes are not nee= ded for outbound traffics and only ones for gateways to be passed are demande= d whether default routes are used for forwarding or not. Do you concern abo= ut updating route entry for gateways by inbound traffics? Right, unencapsula= ted inbound traffics can not do that. However, periodic gateway solicitation/advertisement exchanges between MANET nodes and gateways and unsolicited gateway advertisements from gateways can prevent from degradi= ng performance of bidirectional communications like TCP sessions. Other thoughts? Regards, HyunWook >>>> >>>Right. Could you handle gateway handover using NATs? >>> Using MIP with NAT-traversal is probably the most straightforward solutio= n, but the additional overhead of 28bytes only for the NAT-traversal part is not insignificant on a MANET. (In fact, we have discussed implementing th= is, just to see how it works.) The upside is that you could probably use off-the-self MIPv4 code in co-located mode and with NAT-traversal, and I assume it would work without major changes. I believe that other MIP-for-MANET solutions proposed, on the contrary, would need special-purpose code that would differ significantly from regular off-the-shelf MIPv4. >> >>I guess, if you tunneled traffic from your "old" gateway to the new one. >>Of course, there would have to be some extra signaling between the >>gateways. >> Yes, Erik, that might be another option... None of them seems ideal, though... > > <...> Paal _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Mar 7 14:30:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01598 for ; Sun, 7 Mar 2004 14:30:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B03yP-0003KD-TL for manet-archive@odin.ietf.org; Sun, 07 Mar 2004 14:30:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i27JU5Ro012780 for manet-archive@odin.ietf.org; Sun, 7 Mar 2004 14:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B03yP-0003K3-PH for manet-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 14:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01551 for ; Sun, 7 Mar 2004 14:30:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B03yN-0002We-00 for manet-web-archive@ietf.org; Sun, 07 Mar 2004 14:30:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B03xJ-0002Mo-00 for manet-web-archive@ietf.org; Sun, 07 Mar 2004 14:28:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B03wS-0002ED-00 for manet-web-archive@ietf.org; Sun, 07 Mar 2004 14:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B03wP-0002zs-Lr; Sun, 07 Mar 2004 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B03wG-0002xG-RK for manet@optimus.ietf.org; Sun, 07 Mar 2004 14:27:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01493 for ; Sun, 7 Mar 2004 14:27:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B03wE-0002DX-00 for manet@ietf.org; Sun, 07 Mar 2004 14:27:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B03vI-00025r-00 for manet@ietf.org; Sun, 07 Mar 2004 14:26:53 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1B03ue-0001w8-00 for manet@ietf.org; Sun, 07 Mar 2004 14:26:13 -0500 Received: from etri7fodix6mw4 (61.81.79.242 [61.81.79.242]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW2L43; Mon, 8 Mar 2004 04:25:32 +0900 Message-ID: <006a01c40479$f9e45060$f24f513d@etri7fodix6mw4> Reply-To: "HyunWook Cha" From: "HyunWook Cha" To: "Erik Nordstr?" , "Christophe Jelger" Cc: "'manet'" References: <000001c4027a$e6157c90$ae70fe81@jafywinxp> <1078486185.9485.35.camel@dhcp-8-241.it.uu.se> <40486CA8.3040507@dpt-info.u-strasbg.fr> <1078488992.9485.47.camel@dhcp-8-241.it.uu.se> Subject: Re: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) Date: Mon, 8 Mar 2004 04:25:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Eric and Christophe. My comments below; ----- Original Message ----- From: "Erik Nordstr?" To: "Christophe Jelger" Cc: "'manet'" Sent: Friday, March 05, 2004 9:16 PM Subject: Re: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) > > On Fri, 2004-03-05 at 13:03, Christophe Jelger wrote: > > > > >> > > > > > >Prefix continuity is fine but clearly has limitations, since (all) nodes > > >can't chose gateways by themselves. I am not sure what you mean with > > >source address based forwarding. Do you select your default route based > > >on source address? In that case you need to maintain a lot of extra > > >state and you have no route aggregation which is mainly what default > > >routes are for. Correct me if I am wrong. > > > Right. A sender node select a default route to send a packet according to its global source address. The node already maintain default gateway list to configure and maintain its global addresses. It does not require additional state. Also, additional route entries for Internet nodes (=external nodes) are not needed since this approach has same effect as default route forwarding execpt that actual forwarding is based on route entry for corresponding gateway with source address. > > > > > I won't call that a limitation ... the objective is to maintain prefix > > continuity, not to allows nodes to choose whatever prefix they want. In > > the later case it's best to use a solution that uses tunnels (or routing > > header with IPv6). Would you call IPv6 stateless autoconf "a limitation" > > because it gives the same prefix to all nodes of a subnet ? To me it's > > just doing fine what it has been designed for ... ;-) > > Christophe, IPv6 stateless autoconf does not prohibit that multiple global addresses are configured and used by a node. When two addresses are available, one address can be used as HoA and the other as CoA to preserve transport session or load balancing. When multiple addresses are allowed, source address based forwarding is a solution which has same effect as "prefix continutity" since it can demultiplex corresponding gateway with source address without routing header/tunneling. Regards, HyunWook > > Ok, limited applicability? I agree that if prefix continuity is fine if > that's what you want. > > And yes, stateless autoconf can be a limitation since it does not allow > you to easily switch between gateways (and maintain your connections). > MIP would be better for that (or a combination). But it does not mean it > is not useful for what it was design for. Which I do not believe were ad > hoc networks and multiple gateway scenarios. Rather as an alternative to > DHCP? > > > /Erik > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Mar 8 03:02:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15043 for ; Mon, 8 Mar 2004 03:02:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FiP-0003uy-UG for manet-archive@odin.ietf.org; Mon, 08 Mar 2004 03:02:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2882LNh015053 for manet-archive@odin.ietf.org; Mon, 8 Mar 2004 03:02:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FiP-0003ui-4W for manet-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 03:02:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14982 for ; Mon, 8 Mar 2004 03:02:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0FiL-00015F-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 03:02:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0FhR-0000tl-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 03:01:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0FgZ-0000fi-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 03:00:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FgB-0003fc-WE; Mon, 08 Mar 2004 03:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FfP-0003d4-RS for manet@optimus.ietf.org; Mon, 08 Mar 2004 02:59:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14726 for ; Mon, 8 Mar 2004 02:59:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0FfL-0000Lz-00 for manet@ietf.org; Mon, 08 Mar 2004 02:59:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0FeP-0000EP-00 for manet@ietf.org; Mon, 08 Mar 2004 02:58:13 -0500 Received: from in02-fes2.whowhere.com ([209.202.220.219] helo=whowhere.com) by ietf-mx with smtp (Exim 4.12) id 1B0FdS-0007nO-00 for manet@ietf.org; Mon, 08 Mar 2004 02:57:14 -0500 Received: from Unknown/Local ([?.?.?.?]) by whowhere.com; Mon, 08 Mar 2004 07:56:39 -0000 To: manet@ietf.org Date: Mon, 08 Mar 2004 08:56:39 +0100 From: "wafa ber" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: oifa@eudoramail.com X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 193.95.33.18 Organization: Lycos Mail (http://www.mail.eudoramail.com) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Draft IEEE 802.11e 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello; I am working on IEE 802.11e, I have the version 6.0 on the corresponding draft. I ask me, if some one knows a recent version, and could forward it to me. Thank you very much and have a good day wafa Berrayana Need a new email address that people can remember Check out the new EudoraMail at http://www.eudoramail.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 8 03:18:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15632 for ; Mon, 8 Mar 2004 03:18:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FxA-0005hn-CL for manet-archive@odin.ietf.org; Mon, 08 Mar 2004 03:17:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i288HaKR021926 for manet-archive@odin.ietf.org; Mon, 8 Mar 2004 03:17:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FxA-0005hZ-2C for manet-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 03:17:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15619 for ; Mon, 8 Mar 2004 03:17:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Fx7-0003RI-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 03:17:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0FwA-0003Gb-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 03:16:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Fvk-00036Z-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 03:16:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Fvf-0005KG-PP; Mon, 08 Mar 2004 03:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0FvA-0005Iy-VX for manet@optimus.ietf.org; Mon, 08 Mar 2004 03:15:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15546 for ; Mon, 8 Mar 2004 03:15:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Fv8-00035g-00 for manet@ietf.org; Mon, 08 Mar 2004 03:15:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0FuB-0002wK-00 for manet@ietf.org; Mon, 08 Mar 2004 03:14:32 -0500 Received: from web40803.mail.yahoo.com ([66.218.78.180]) by ietf-mx with smtp (Exim 4.12) id 1B0FtW-0002mS-00 for manet@ietf.org; Mon, 08 Mar 2004 03:13:51 -0500 Message-ID: <20040308081321.58488.qmail@web40803.mail.yahoo.com> Received: from [155.69.5.236] by web40803.mail.yahoo.com via HTTP; Mon, 08 Mar 2004 00:13:21 PST Date: Mon, 8 Mar 2004 00:13:21 -0800 (PST) From: Gayathri To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-52366246-1078733601=:57785" Subject: [manet] ZRP implementation 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 --0-52366246-1078733601=:57785 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA15547 Content-Transfer-Encoding: quoted-printable Hi all =20 I am working on hybrid protocols . I came across the implementation of zr= p from the site=20 =20 http://wnl.ece.cornell.edu/wnlprojects.html =20 ZRP Implementation in Glomosim: Glomosim Code (tar file) by Kaixin Xu (UC= LA/CSD)=20 =20 I experience a problem. The function "Networkipsetmaclayerstatushandler "= function is part of the old glomosim 2.0 and we now have the new version= . The new version says that it has been made obsolete by explicit packet = handling function (nwip.pc) . I am unable to replace that function. Could= one one help me wiht it . Has anyone implemented it successfully using t= his code. Please help me with this=20 =20 Thanks in advance=20 Gayathri --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster. --0-52366246-1078733601=:57785 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA15547 Content-Transfer-Encoding: quoted-printable
Hi all
 
I am working on hybrid protocols . I came across the implementat= ion of zrp from the site
 
 
  • ZRP Implementation in Glomosim: Glomosim C= ode (tar file) by Kaixin Xu (UCLA/CSD)
    •  
    I experience a problem. The = function "Networkipsetmaclayerstatushandler " function is part of the old= glomosim 2.0 and we now have the new version. The new version says that = it has been made obsolete by explicit packet handling function (nwip.pc) = . I am unable to replace that function. Could one one help me wiht it . H= as anyone implemented it successfully using this code. Please help me wit= h this
     
    Thanks in advance
    Gayathri

    Do you Yahoo!?
    Yahoo! Search - Find what you=92re looking for faster. --0-52366246-1078733601=:57785-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 8 11:47:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13133 for ; Mon, 8 Mar 2004 11:47:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Nto-0005FE-Ox for manet-archive@odin.ietf.org; Mon, 08 Mar 2004 11:46:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28GkeBb020154 for manet-archive@odin.ietf.org; Mon, 8 Mar 2004 11:46:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Nto-0005Ez-Jj for manet-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 11:46:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13044 for ; Mon, 8 Mar 2004 11:46:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Ntn-0004Qu-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 11:46:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0NsB-0003z0-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 11:45:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0Nqe-0003W6-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 11:43:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0Nqf-0003tE-Gd for manet-web-archive@ietf.org; Mon, 08 Mar 2004 11:43:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0NqI-0004cb-BU; Mon, 08 Mar 2004 11:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Nq1-0004bj-Hb for manet@optimus.ietf.org; Mon, 08 Mar 2004 11:42:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12794 for ; Mon, 8 Mar 2004 11:42:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Nq0-0003Le-00 for manet@ietf.org; Mon, 08 Mar 2004 11:42:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0NoN-0002v2-00 for manet@ietf.org; Mon, 08 Mar 2004 11:41:03 -0500 Received: from web13423.mail.yahoo.com ([216.136.175.154]) by ietf-mx with smtp (Exim 4.12) id 1B0NnP-0002er-00 for manet@ietf.org; Mon, 08 Mar 2004 11:40:03 -0500 Message-ID: <20040308164001.14638.qmail@web13423.mail.yahoo.com> Received: from [193.95.33.18] by web13423.mail.yahoo.com via HTTP; Mon, 08 Mar 2004 17:40:01 CET Date: Mon, 8 Mar 2004 17:40:01 +0100 (CET) From: =?iso-8859-1?q?Fehmi?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA12795 Subject: [manet] Retrieving the Path found by DSR or other 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable How to retrieve and interact with the wireless card in adhoc mod ,for exemple to retrieve paths found by the routing protocol DSR. I'm a beginning in searching in this field, and i'm going to code a tool on linux to manage path diversity in adhoc networks. Thanks a lot! =09 =09 =09 Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !=20 Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger !T=E9l=E9c= hargez Yahoo! Messenger sur http://fr.messenger.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 8 12:58:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16899 for ; Mon, 8 Mar 2004 12:58:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0P0p-0002tG-Jv for manet-archive@odin.ietf.org; Mon, 08 Mar 2004 12:57:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28Hvx4Q011109 for manet-archive@odin.ietf.org; Mon, 8 Mar 2004 12:57:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0P0p-0002t6-8u for manet-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 12:57:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16875 for ; Mon, 8 Mar 2004 12:57:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0P0n-0002O7-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 12:57:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Ozp-0002Ch-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 12:56:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Oz7-00022J-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 12:56:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Oyy-0002Zq-5T; Mon, 08 Mar 2004 12:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Oye-0002UF-KT for manet@optimus.ietf.org; Mon, 08 Mar 2004 12:55:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16752 for ; Mon, 8 Mar 2004 12:55:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Oyc-0001yd-00 for manet@ietf.org; Mon, 08 Mar 2004 12:55:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Oxi-0001nZ-00 for manet@ietf.org; Mon, 08 Mar 2004 12:54:47 -0500 Received: from web21408.mail.yahoo.com ([216.136.232.78]) by ietf-mx with smtp (Exim 4.12) id 1B0Own-0001c1-00 for manet@ietf.org; Mon, 08 Mar 2004 12:53:49 -0500 Message-ID: <20040308175348.31835.qmail@web21408.mail.yahoo.com> Received: from [128.4.130.33] by web21408.mail.yahoo.com via HTTP; Mon, 08 Mar 2004 09:53:48 PST Date: Mon, 8 Mar 2004 09:53:48 -0800 (PST) From: Leon Martin To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA16753 Subject: [manet] Questions about 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Just want to know the answers of: 1. Does 802.11 do RTS/CTS/DATA/ACK on a per packet basis? 2. For the ACK in the RTS/CTS/DATA/ACK, what is the value for its retransmission timeout? Thanks! - Leon=20 __________________________________ Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster http://search.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 8 14:32:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22612 for ; Mon, 8 Mar 2004 14:32:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QTv-0002KA-3B for manet-archive@odin.ietf.org; Mon, 08 Mar 2004 14:32:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28JW7fZ008928 for manet-archive@odin.ietf.org; Mon, 8 Mar 2004 14:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QTu-0002Jv-TS for manet-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 14:32:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22559 for ; Mon, 8 Mar 2004 14:32:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0QTr-0004fa-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 14:32:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0QSr-0004RG-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 14:31:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0QS9-0004EF-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 14:30:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0QS8-0006Xt-WA for manet-web-archive@ietf.org; Mon, 08 Mar 2004 14:30:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QRw-0001pM-Hl; Mon, 08 Mar 2004 14:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0QR8-0001me-GD for manet@optimus.ietf.org; Mon, 08 Mar 2004 14:29:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22409 for ; Mon, 8 Mar 2004 14:29:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0QR5-0003yt-00 for manet@ietf.org; Mon, 08 Mar 2004 14:29:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0QQI-0003kU-00 for manet@ietf.org; Mon, 08 Mar 2004 14:28:23 -0500 Received: from taurus.cs.albany.edu ([169.226.2.109] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B0QPJ-0003To-00 for manet@ietf.org; Mon, 08 Mar 2004 14:27:21 -0500 Received: from broomstick.cs.albany.edu (ravi@broomstick.cs.albany.edu [169.226.2.89]) by taurus.cs.albany.edu (8.12.8p1-20030918/8.12.8) with ESMTP id i28JRDox025318 for ; Mon, 8 Mar 2004 14:27:14 -0500 (EST) Received: (from ravi@localhost) by broomstick.cs.albany.edu (8.12.8p1-20030918/8.12.8/Submit) id i28JRD6x024946 for manet@ietf.org; Mon, 8 Mar 2004 14:27:13 -0500 (EST) Date: Mon, 8 Mar 2004 14:27:13 -0500 (EST) From: "S.S.Ravi" Message-Id: <200403081927.i28JRD6x024946@broomstick.cs.albany.edu> To: manet@ietf.org Subject: [manet] ADHOC-NOW'04 -- Call for papers 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES Call for Papers -- ADHOC-NOW'04 The 3rd Annual International Conference on AD-HOC Networks & Wireless Conference dates: July 22-24, 2004 Location: Vancouver, British Columbia, Canada URL: http://namur.cs.ualberta.ca:8080/adhocnow04/Default.htm Important Dates: Paper Submissions Due: May 1, 2004 Notification of Acceptance: May 14, 2004 Panel/Tutorial Proposals Due: May 31, 2004 Camera Ready Versions Due: June 1, 2004 Topics of Interest: We are interested in work in progress, experimental and theoretical research in Ad-Hoc, Mobile and Wireless Networks. Of interest but are not limited, to research papers in any of the following areas: Access Control Ad Hoc Networks of Autonomous Intelligent Systems Analytic Methods and Modeling for Performance Evaluation Applications for Ad Hoc Networks Architectures of Ad-Hoc Networks Distributed Algorithms for Ad Hoc Networks Location Discovery and Management Low Power and Energy-Efficient Designs Mobile Ad Hoc Computing Platforms, Systems and Testbeds Quality-of-Service Routing Protocols (Unicast, Multicast, etc.) Secure Services and Protocols Sensor Networks Self-Configuration Service Discovery Timing Synchronization Wireless Internet Proceedings: To be published by Springer-Verlag, as part of the Lecture Notes in Computer Science (LNCS) series. Supported by: Carleton University, University of Alberta, Simon Fraser University, PIMS INSTITUTE, MITACS. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 9 10:48:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03171 for ; Tue, 9 Mar 2004 10:48:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jSD-0000lA-Ib for manet-archive@odin.ietf.org; Tue, 09 Mar 2004 10:47:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29FlajP002430 for manet-archive@odin.ietf.org; Tue, 9 Mar 2004 10:47:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jSA-0000Va-LA for manet-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03023 for ; Tue, 9 Mar 2004 10:47:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jS7-0004Dc-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 10:47:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jNv-0002zi-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 10:43:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B0jMJ-0002Ul-01 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 10:41:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B0jI5-0004Al-Cc for manet-web-archive@ietf.org; Tue, 09 Mar 2004 10:37:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jHJ-0003ox-Cm; Tue, 09 Mar 2004 10:36:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0gzE-0001cV-BL for manet@optimus.ietf.org; Tue, 09 Mar 2004 08:09:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25512 for ; Tue, 9 Mar 2004 08:09:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0gzD-0007Fu-00 for manet@ietf.org; Tue, 09 Mar 2004 08:09:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0gyK-00076r-00 for manet@ietf.org; Tue, 09 Mar 2004 08:08:36 -0500 Received: from [202.84.232.68] (helo=mail.aitlbd.net) by ietf-mx with esmtp (Exim 4.12) id 1B0gxV-0006vw-00 for manet@ietf.org; Tue, 09 Mar 2004 08:07:46 -0500 Received: from p217.aitlbd.net (p217.aitlbd.net [202.84.231.217]) by mail.aitlbd.net (8.11.7p1+Sun/8.11.6) with ESMTP id i29CvOd27978 for ; Tue, 9 Mar 2004 18:57:25 +0600 (GMT) From: merajul Organization: BUET To: manet@ietf.org Date: Fri, 15 Aug 2003 19:09:54 +0600 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308151909.54511.merajul@aitlbd.net> AFTAB-IT-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Subject: [manet] NS2 simulation 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,DATE_IN_PAST_96_XX autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi! I tried to implement a new Ping Agent protocol and it ran successfully in NS2. But when I see the trace file, I see the type fields are undefined. How can I set the packet types to 1. ICMP ECHO_REQUEST 2. ICMP ECHO_REPLY I want to distinguish between the two. My next question is, I have done some wireless simulation in ns2. My question is how can I extract various information like 1. Success Rate vs. Speed 2. Collision vs Max Speed etc, etc. from the trace file ? Are there any scripts for this ? Thanks -- Mohammad Merajul Islam Molla Department of Computer Science & Engineering ( Final Year ) Bangladesh University of Engineering & Technology (BUET) Dhaka, Bangladesh. -- This message has been scanned for viruses and dangerous content by AFTAB IT MailScanner, and is believed to be clean. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 9 10:55:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04597 for ; Tue, 9 Mar 2004 10:55:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jZM-0003YE-JN for manet-archive@odin.ietf.org; Tue, 09 Mar 2004 10:55:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29Ft01j013644 for manet-archive@odin.ietf.org; Tue, 9 Mar 2004 10:55:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jZM-0003Xz-FI for manet-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 10:55:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04529 for ; Tue, 9 Mar 2004 10:54:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0jZJ-0006Gy-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 10:54:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0jWj-0005cS-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 10:52:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0jTn-0004lw-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 10:49:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0jIb-0004iF-Ua; Tue, 09 Mar 2004 10:37:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0isN-0008P0-Qe for manet@optimus.ietf.org; Tue, 09 Mar 2004 10:10:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00031 for ; Tue, 9 Mar 2004 10:10:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0isL-00043k-00 for manet@ietf.org; Tue, 09 Mar 2004 10:10:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0irM-0003tU-00 for manet@ietf.org; Tue, 09 Mar 2004 10:09:33 -0500 Received: from mail.ece.gatech.edu ([199.77.227.200]) by ietf-mx with esmtp (Exim 4.12) id 1B0iqO-0003c7-00 for manet@ietf.org; Tue, 09 Mar 2004 10:08:32 -0500 Received: from yamsrv2.ece.gatech.edu (yamsrv2.ece.gatech.edu [130.207.232.10]) by mail.ece.gatech.edu (8.12.10/8.12.9) with ESMTP id i29F8SPH010576 for ; Tue, 9 Mar 2004 10:08:28 -0500 (EST) Received: from localhost (jau@localhost) by yamsrv2.ece.gatech.edu (8.12.0.Beta19/8.12.0.Beta19/Submit) with ESMTP id i29F8SGN006971 for ; Tue, 9 Mar 2004 10:08:28 -0500 (EST) Date: Tue, 9 Mar 2004 10:08:28 -0500 (EST) From: Jaudelice Cavalcante de Oliveira To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-SPAM: NO Subject: [manet] Med-Hoc-Net 2004: Final CFP, Papers due March 12th 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Please note that the deadline for paper submissions, Friday, March 12th, is only a few days away. We look forward to your submissions. See our website for full details. http://www.medhoc04/diit/unict.it We apologize in advance if you receive multiple copies of this CFP. ------------------------------------------------------------------------------ Med-Hoc-Net 2004 The Third Annual Mediterranean Ad Hoc Networking Workshop June 27-30, 2004, Bodrum, Turkey http://www.medhoc04/diit/unict.it Call for Papers ------------------------------------------------------------------------------ Scope: Ad hoc network applications are emerging continuously imposing their own stringent constraints which cannot be fulfilled by generic approaches and thus spur new research efforts. Therefore, ad hoc networks attract growing attention from the research community. The aim of Med-Hoc-Net 2004 is to serve as a platform for researchers and visionaries from academia, research labs, and industry from all over the globe to share their ideas, views, results, and experiences in the field of ad-hoc networking and communications. Med-Hoc-Net 2004 will include presentations of theoretical and experimental achievements, innovative ad-hoc systems, prototyping efforts, case studies, and advancements in technology directly affecting ad-hoc networking and communications infrastructures. The papers solicited in Med-Hoc-Net 2004 cover a variety of topics including but not limited to: - Novel ad-hoc network architectures and applications, - Sensor network applications and protocols, - Implementations, testbeds, and prototypes, - Interfacing ad-hoc systems with different networks, - Resource discovery and management, - Power management and control, - Call admission and traffic shaping policies for ad-hoc networks, - Multimedia location services, - Self organization and network reconfiguration, - Protocols for QoS support in ad-hoc networks, - QoS support in Bluetooth, HIPERLAN, IEEE 802.11 etc., - MAC protocols, scheduling, and radio resource sharing in ad hoc networks, - Unicast and multicast routing algorithms and protocols, - Transport layer protocols for multi-hop networks, - Congestion control, - Performance evaluation of ad-hoc network protocols through simulations, analysis, and measurements, - Security in ad-hoc networks, - Fault tolerance and error recovery - Signal processing algorithms (coding, compression) for ad-hoc networks The program committee will referee all papers, and accepted papers will be published in the conference proceedings. Papers of particular merit will be published in the Elsevier Ad Hoc Networks Journal. Manuscripts must be formatted according to the IEEE double-column standard format, except the font size, which must be 11pt. Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or their equivalent. The maximum length of the manuscript is 12 pages. NEW: THE PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004 PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM Papers should be submitted in pdf or ps format through EDAS system (http://edas.info) according to the following timetable: Important Dates: Full Paper Electronic Submission: March 12, 2004 Tutorial proposal submission: April 15, 2004 Notification of Acceptance/Rejection: May 3, 2004 Camera ready submission of full papers: May 17, 2004 Tutorial date: June 27, 2004 Conference dates: June 28-30, 2004 Organization Committee: General Chair: Ian F. Akyildiz, Georgia Institute of Technology, USA General Vice Chair: Erdal Cayirci, Istanbul Technical University, TURKEY Technical Program Chairs: Giacomo Morabito, University of Catania, ITALY Eylem Ekici, Ohio State University, USA Tutorial Chairs: Francesca Cuomo, University of Rome - La Sapienza, ITALY Christos Douligeris, University of Piraeus, GREECE Publicity Chairs: Buyurman Baykal, Middle East Technical University, TURKEY Jaudelice Cavalcante de Oliveira, Drexel University, USA Registration Chair: Sebnem Baydere, Yeditepe University, TURKEY Technical Program Committee: Khaldoun Al Agha, Laboratoire de Recherche en Informatique, FRANCE Hamid Aghvami, King's College London, UK Eitan Altman, INRIA, FRANCE Roberto Battiti, University of Trento, ITALY Raouf Boutaba, University of Waterloo, CANADA Walid Dabbous, INRIA, FRANCE Magda El Zarki, University of California at Irvine, USA Luigi Fratta, Politecnico di Milano, ITALY Mario Gerla, UCLA, USA Paul J. M. Havinga, University of Twente, NETHERLANDS Ahmed Helmy, University of Southern California, USA Farouk Kamoun, ENSI, TUNISIA Holger Karl, Technical University of Berlin, GERMANY Ulf Korner, Lund Institute of Technology, SWEDEN Bhaskar Krishnamachari, University of Southern California, USA Marwan Krunz, University of Arizona, USA Albert Levi, Sabanci University, TURKEY Janise McNair, University of Florida, USA Lazaros Merakos, University of Athens, GREECE Ioanis Nikolaidis, University of Alberta, CANADA Ariel Orda, Technion, ISRAEL Sergio Palazzo, University of Catania, ITALY Giovanni Pau, UCLA, USA Chiara Petrioli, University of Rome "La Sapienza", ITALY Andreas Pitsillides, University of Cyprus, CYPRUS Guy Pujolle, LIP6, FRANCE Paolo Santi, CNR, ITALY Adrian Segall, Technion, ISRAEL Ness Shroff, Purdue University, USA Moshe Sidi, Technion, ISRAEL Raghupathy Sivakumar, Georgia Institute of Technology, USA Ioannis Stavrakakis, University of Athens, GREECE Ivan Stojmenovic, University of Ottawa, CANADA Violet R. Syrotiuk, Arizona State University, USA Leandros Tassiulas, University of Thessaly, GREECE Damla Turgut, University of Central Florida, USA Bernhard H. Walke, Aachen University of Technology, GERMANY Wenye Wang, North Carolina State University, USA Michele Zorzi, University of Ferrara, ITALY _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 9 11:54:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08149 for ; Tue, 9 Mar 2004 11:54:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kUr-0000Ro-3E for manet-archive@odin.ietf.org; Tue, 09 Mar 2004 11:54:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29GsPEZ001714 for manet-archive@odin.ietf.org; Tue, 9 Mar 2004 11:54:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kUq-0000RZ-U6 for manet-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 11:54:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08019 for ; Tue, 9 Mar 2004 11:54:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kUp-0003bo-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 11:54:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0kTB-000341-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 11:52:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0kQq-0002Hx-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 11:50:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kQd-0007zI-Eo; Tue, 09 Mar 2004 11:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0kQX-0007ya-MI for manet@optimus.ietf.org; Tue, 09 Mar 2004 11:49:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07668 for ; Tue, 9 Mar 2004 11:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0kQW-0002Ct-00 for manet@ietf.org; Tue, 09 Mar 2004 11:49:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0kNa-0001SJ-00 for manet@ietf.org; Tue, 09 Mar 2004 11:46:55 -0500 Received: from web21202.mail.yahoo.com ([216.136.130.18]) by ietf-mx with smtp (Exim 4.12) id 1B0kMh-0001Eh-00 for manet@ietf.org; Tue, 09 Mar 2004 11:45:59 -0500 Message-ID: <20040309164559.40275.qmail@web21202.mail.yahoo.com> Received: from [158.94.254.20] by web21202.mail.yahoo.com via HTTP; Tue, 09 Mar 2004 08:45:59 PST Date: Tue, 9 Mar 2004 08:45:59 -0800 (PST) From: Vishak Srinivasan To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA07669 Subject: [manet] could anybody plz help me in simulating manet using 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hello everybody, i am doing my comp networks and i am doing my thesis in simulation of MANETs using DSR protocol. i want to do a simulation using 3/4 nodes but in tht case how should we set one as a source , one as a destination and the other nodes should act as a routing agent which should route the pkts from source to destination. i am trying very hard to try to find some way out but couldnot. i expect some way out of this problem. as u all know simulating using 2 nodes in quite simple but i want to do it for more than 3 or 3 expecting some quick reply from u experienced people thanx in advance regards vishak srinivasan __________________________________ Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster http://search.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 9 13:25:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13499 for ; Tue, 9 Mar 2004 13:25:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lub-0007KK-Ah for manet-archive@odin.ietf.org; Tue, 09 Mar 2004 13:25:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29IP5ru028158 for manet-archive@odin.ietf.org; Tue, 9 Mar 2004 13:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lua-0007Jw-MI for manet-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 13:25:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13480 for ; Tue, 9 Mar 2004 13:25:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0luY-0006lk-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 13:25:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0lta-0006Zr-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 13:24:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0lsn-0006Of-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 13:23:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lsc-000713-Dm; Tue, 09 Mar 2004 13:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0lsK-0006zV-85 for manet@optimus.ietf.org; Tue, 09 Mar 2004 13:22:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13371 for ; Tue, 9 Mar 2004 13:22:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0lsI-0006LR-00 for manet@ietf.org; Tue, 09 Mar 2004 13:22:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0lrJ-00069K-00 for manet@ietf.org; Tue, 09 Mar 2004 13:21:42 -0500 Received: from web8311.mail.in.yahoo.com ([203.199.122.11]) by ietf-mx with smtp (Exim 4.12) id 1B0lqJ-0005oX-00 for manet@ietf.org; Tue, 09 Mar 2004 13:20:39 -0500 Message-ID: <20040309182007.71996.qmail@web8311.mail.in.yahoo.com> Received: from [203.197.138.167] by web8311.mail.in.yahoo.com via HTTP; Tue, 09 Mar 2004 18:20:07 GMT Date: Tue, 9 Mar 2004 18:20:07 +0000 (GMT) From: =?iso-8859-1?q?sabthagiri=20saravanan?= 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] ns aodv 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit hi guys, i am doing aproject in integration of cellular ip and manets.i am using ns . while simulating aodv in ns i get an error report in line no. 19 .i tried it in other versions of ns as well. but i get the same problem. has anyone encountered this problem .if so plz tell me how to solve it . bye ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 9 19:03:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08276 for ; Tue, 9 Mar 2004 19:03:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rBe-0004Nk-VW for manet-archive@odin.ietf.org; Tue, 09 Mar 2004 19:03:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A032x2016840 for manet-archive@odin.ietf.org; Tue, 9 Mar 2004 19:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rBe-0004NX-Pf for manet-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 19:03:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08244 for ; Tue, 9 Mar 2004 19:02:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0rBb-0000O8-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 19:02:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rAk-0000DC-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 19:02:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0r9r-00001Y-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 19:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0r9j-00043p-EQ; Tue, 09 Mar 2004 19:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0r8u-00042X-Ck for manet@optimus.ietf.org; Tue, 09 Mar 2004 19:00:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08156 for ; Tue, 9 Mar 2004 19:00:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0r8r-0007ds-00 for manet@ietf.org; Tue, 09 Mar 2004 19:00:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0r7p-0007TN-00 for manet@ietf.org; Tue, 09 Mar 2004 18:59:05 -0500 Received: from web61101.mail.yahoo.com ([216.155.196.103]) by ietf-mx with smtp (Exim 4.12) id 1B0r6v-00079X-00 for manet@ietf.org; Tue, 09 Mar 2004 18:58:09 -0500 Message-ID: <20040309235739.77247.qmail@web61101.mail.yahoo.com> Received: from [141.156.71.10] by web61101.mail.yahoo.com via HTTP; Tue, 09 Mar 2004 15:57:39 PST Date: Tue, 9 Mar 2004 15:57:39 -0800 (PST) From: manet user To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-365876440-1078876659=:76528" Subject: [manet] DSR route maintenance issue 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-365876440-1078876659=:76528 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA08157 Content-Transfer-Encoding: quoted-printable Hi, =20 I have a question / concern regarding DSR route maintenance as suggested = in the draft-ietf-manet-dsr-09. If i am using explicit acknowledgments fo= r route maintenance, there are possibilities of receiving multiple duplic= ate packets.=20 =20 For instance, while forwarding data packet to next hop, i enable the bit = in the packet header so that nexthop node should send me explicit ACK aft= er receiving this data packet. If WLAN MAC layer is congested, my packet = is still sitting at MAC to be retransmitted, whereas my ACK timer (50ms a= s suggested in draft) expires. I will retransmit the same data packet. Th= is will lead to duplicate packets at destination. Under heavy traffic sce= narios, this situation will happen frequently. =20 I did not find any measures in the draft for the same. Am i missing somet= hing in implemenation ? Please help. Thanks in advance. =20 -MU --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster. --0-365876440-1078876659=:76528 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA08157 Content-Transfer-Encoding: quoted-printable
    Hi,
     
    I have a question / concern regarding DSR route maintenance as sugge= sted in the draft-ietf-manet-dsr-09. If i am using explicit acknowledgmen= ts for route maintenance, there are possibilities of receiving multiple d= uplicate packets.
     
    For instance, while forwarding data packet to next hop, i enable the= bit in the packet header so that nexthop node should send me explicit AC= K after receiving this data packet. If WLAN MAC layer is congested, my pa= cket is still sitting at MAC to be retransmitted, whereas my ACK tim= er (50ms as suggested in draft) expires. I will retransmit the same = data packet. This will lead to duplicate packets at destination. Under he= avy traffic scenarios, this situation will happen frequently.
     
    I did not find any measures in the draft for the same. Am i missing = something in implemenation ? Please help. Thanks in advance.
     
    -MU

    Do you Yahoo!?
    Yahoo! Search - Find what you=92re looking for faster. --0-365876440-1078876659=:76528-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 10 10:42:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16278 for ; Wed, 10 Mar 2004 10:42:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15qQ-00070W-W4 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 10:42:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AFg6jZ026930 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 10:42:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15qQ-00070H-99 for manet-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 10:42:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16275 for ; Wed, 10 Mar 2004 10:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B15qN-0006wl-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 10:42:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B15pb-0006k3-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 10:41:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B15oe-0006W9-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 10:40:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15oP-0006eM-Rs; Wed, 10 Mar 2004 10:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B15oJ-0006dB-H0 for manet@optimus.ietf.org; Wed, 10 Mar 2004 10:39:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16129 for ; Wed, 10 Mar 2004 10:39:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B15oH-0006SU-00 for manet@ietf.org; Wed, 10 Mar 2004 10:39:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B15nQ-0006DW-00 for manet@ietf.org; Wed, 10 Mar 2004 10:39:01 -0500 Received: from web40605.mail.yahoo.com ([66.218.78.142]) by ietf-mx with smtp (Exim 4.12) id 1B15mc-0005tD-00 for manet@ietf.org; Wed, 10 Mar 2004 10:38:10 -0500 Message-ID: <20040310153733.4912.qmail@web40605.mail.yahoo.com> Received: from [132.204.100.226] by web40605.mail.yahoo.com via HTTP; Wed, 10 Mar 2004 16:37:33 CET Date: Wed, 10 Mar 2004 16:37:33 +0100 (CET) From: =?iso-8859-1?q?redouane?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA16130 Subject: [manet] DSR, route error and ack 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi I ask if it is necessary to add an ack when sendind a route error back to the destination. Packet contains route source and route error no other data. Thanks Redouane =09 =09 =09 Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !=20 Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger !T=E9l=E9c= hargez Yahoo! Messenger sur http://fr.messenger.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 10 11:10:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17648 for ; Wed, 10 Mar 2004 11:10:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B16HC-0001vj-UL for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 11:09:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AG9kbx007418 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 11:09:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B16HC-0001vZ-M6 for manet-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 11:09:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17639 for ; Wed, 10 Mar 2004 11:09:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B16H9-0004OF-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 11:09:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B16GF-0004Eg-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 11:08:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B16Ff-00045V-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 11:08:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B16FX-0001PY-B0; Wed, 10 Mar 2004 11:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B16FA-0001KE-TV for manet@optimus.ietf.org; Wed, 10 Mar 2004 11:07:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17538 for ; Wed, 10 Mar 2004 11:07:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B16F8-00043K-00 for manet@ietf.org; Wed, 10 Mar 2004 11:07:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B16E9-0003u1-00 for manet@ietf.org; Wed, 10 Mar 2004 11:06:37 -0500 Received: from smtp2.andrew.cmu.edu ([128.2.10.82]) by ietf-mx with esmtp (Exim 4.12) id 1B16DA-0003k1-00 for manet@ietf.org; Wed, 10 Mar 2004 11:05:36 -0500 Received: from UNIX50.andrew.cmu.edu (UNIX50.andrew.cmu.edu [128.2.13.180]) (user=dmaltz mech=GSSAPI (0 bits)) by smtp2.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i2AG5cn6025447; Wed, 10 Mar 2004 11:05:38 -0500 Date: Wed, 10 Mar 2004 11:05:36 -0500 (EST) From: Dave Maltz X-X-Sender: dmaltz@unix50.andrew.cmu.edu To: =?iso-8859-1?q?redouane?= cc: manet@ietf.org Subject: Re: [manet] DSR, route error and ack In-Reply-To: <20040310153733.4912.qmail@web40605.mail.yahoo.com> Message-ID: References: <20040310153733.4912.qmail@web40605.mail.yahoo.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, 10 Mar 2004, [iso-8859-1] redouane wrote: > Hi > I ask if it is necessary to add an ack when sendind a > route error back to the destination. > Packet contains route source and route error no other > data. The destination for the Route Error does not need to send an ACK all the way back to the node that generated the Route Error, but I believe Route Maintenance should be performed on the packet carrying the Route Error. Cheers, -dam _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 10 12:18:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20995 for ; Wed, 10 Mar 2004 12:18:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B17LN-0000JS-VH for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 12:18:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AHI9P8001202 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 12:18:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B17LN-0000JJ-Nw for manet-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 12:18:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20905 for ; Wed, 10 Mar 2004 12:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B17LM-0000IJ-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 12:18:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B17Jt-0007dX-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 12:16:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B17Ic-0007Mh-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 12:15:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B17IO-0008Ge-M5; Wed, 10 Mar 2004 12:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B17IC-0008Fj-Ru for manet@optimus.ietf.org; Wed, 10 Mar 2004 12:14:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20697 for ; Wed, 10 Mar 2004 12:14:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B17IB-0007IQ-00 for manet@ietf.org; Wed, 10 Mar 2004 12:14:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B17Gi-0006tS-00 for manet@ietf.org; Wed, 10 Mar 2004 12:13:20 -0500 Received: from pine.cs.tamu.edu ([128.194.138.12]) by ietf-mx with esmtp (Exim 4.12) id 1B17Fa-0006cB-00 for manet@ietf.org; Wed, 10 Mar 2004 12:12:10 -0500 Received: from unix.cs.tamu.edu (unix.cs.tamu.edu [128.194.138.13]) by pine.cs.tamu.edu (8.12.9/8.12.9) with ESMTP id i2AHC9nf029927 for ; Wed, 10 Mar 2004 11:12:09 -0600 (CST) Received: from localhost (b0l4549@localhost) by unix.cs.tamu.edu (8.11.7p1+Sun/8.10.2) with ESMTP id i2AHC9G02707 for ; Wed, 10 Mar 2004 11:12:09 -0600 (CST) X-Authentication-Warning: unix.cs.tamu.edu: b0l4549 owned process doing -bs Date: Wed, 10 Mar 2004 11:12:09 -0600 (CST) From: Bin Lu To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] question about bandwidth reservation 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=FROM_ENDS_IN_NUMS, FROM_HAS_MIXED_NUMS autolearn=no version=2.60 Hi, I have a question on bandwidth reservation in ad hoc networks: Some MAC layer protocol that supports QoS (such as ieee802.11e) is using Traffic Categories (different priority queues) to implement priority differentiation. But this is just at one node, I mean it doesn't consider the case of shared bandwidth, right? Considering the characteristics of wireless networks, the bandwidth at a node is actually shared by its neighboring nodes since the node can not send packets to its neighbor if the neighboring node is also transmitting or receiving from another node. IEEE802.11e doesn't consider this case, right? or it doesn't need to? I'd appreciate it if someone could clarify this to me! Bin Lu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 10 13:15:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24000 for ; Wed, 10 Mar 2004 13:15:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18EC-000771-UL for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 13:14:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AIEmWh027333 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 13:14:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18EC-00076m-Jj for manet-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 13:14:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23994 for ; Wed, 10 Mar 2004 13:14:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18EA-0003GG-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 13:14:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18DC-00037R-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 13:13:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B18Ce-0002zI-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 13:13:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18CU-0006mV-4N; Wed, 10 Mar 2004 13:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18CB-0006m5-M6 for manet@optimus.ietf.org; Wed, 10 Mar 2004 13:12:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23957 for ; Wed, 10 Mar 2004 13:12:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18C9-0002xm-00 for manet@ietf.org; Wed, 10 Mar 2004 13:12:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18BB-0002oi-00 for manet@ietf.org; Wed, 10 Mar 2004 13:11:41 -0500 Received: from ellis.ad.nps.navy.mil ([131.120.18.61]) by ietf-mx with esmtp (Exim 4.12) id 1B18AF-0002Yl-00 for manet@ietf.org; Wed, 10 Mar 2004 13:10:43 -0500 Received: from [131.120.179.249] ([131.120.179.249]) by ellis.ad.nps.navy.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 10:10:33 -0800 Subject: Re: [manet] question about bandwidth reservation From: Rex Buddenberg To: Bin Lu Cc: manet@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1078942232.20863.155.camel@antony> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Mar 2004 10:10:33 -0800 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2004 18:10:33.0950 (UTC) FILETIME=[FB1F27E0:01C406CA] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2004-03-10 at 09:12, Bin Lu wrote: > Hi, > > I have a question on bandwidth reservation in ad hoc networks: First, back up one level of abstraction: - at layer 3, QoS control is primarily a priority queuing issue. - at layer 2, QoS control is a media access issue. How does a station, in a shared media, get priority access (permission to transmit) when it is in possession of urgent packets? > > Some MAC layer protocol that supports QoS (such as ieee802.11e) is using > Traffic Categories (different priority queues) to implement priority > differentiation. But this is just at one node, I mean it > doesn't consider the case of shared bandwidth, right? The Traffic Categories only identify urgent packets; still begs the question of how you get priority access. In contention queues like all the .11 variants, you have no access control that can handle the QoS needs. All stations with traffic to send compete, using a carrier sense algorithm to take turns. This, while better than nothing, has several shortcomings: - no way to handle more-equal pigs, as you pointed out - poorly equipped to handle silent hosts. Wired ethernet (802.3) MAC works on the assumption that everybody can hear everybody else. 802.11 stretches that but lives with the same assumption. In a radio-WAN, we have to trade that assumption in for one where all leaf nodes can hear the base station but not necessarily each other. Which drives you to polling or scheduling MAC algorithms. Both of these approaches can handle priority access if designed properly. - carrier sense algorithms trade off bandwidth efficiency for other qos parameters (interactivity, low latency ... and simplicity of design). > Considering > the characteristics of wireless networks, the bandwidth at a node is > actually shared by its neighboring nodes since the node can not send > packets to its neighbor if the neighboring node is also transmitting > or receiving from another node. IEEE802.11e doesn't consider this case, > right? or it doesn't need to? .11 standards took a very large step forward -- we got vendor interoperability and the prices for the gear went way down compared to pre-802.11 wireless LAN equipment (got some of that in lab and it was comparatively pricey). But we didn't get - bandwidth efficient MAC algorithm - decent security (the MAC addresses remain uncovered with WEP) - QoS controls -- which you cannot with a carrier sense algorithm in any real sense. - layer 2 multicast You might want to look at the 802.16 (aka WiMax) standards which, IMHO, represent the next generation and fix a good deal of these problems. The MAC is a dual-queue reservation protocol and that does afford some QoS control at layer 2. > > I'd appreciate it if someone could clarify this to me! > > Bin Lu > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 10 13:34:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24957 for ; Wed, 10 Mar 2004 13:34:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Ws-0000Mi-E4 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 13:34:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AIY6xI001396 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 13:34:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Ws-0000MQ-87 for manet-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 13:34:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24920 for ; Wed, 10 Mar 2004 13:34:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18Wq-0006RK-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 13:34:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18Vh-0006GE-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 13:32:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B18Uy-000672-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 13:32:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Ur-00087T-2d; Wed, 10 Mar 2004 13:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B18Ug-00086x-Nb for manet@optimus.ietf.org; Wed, 10 Mar 2004 13:31:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24825 for ; Wed, 10 Mar 2004 13:31:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B18Ue-00065D-00 for manet@ietf.org; Wed, 10 Mar 2004 13:31:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B18Tm-0005wD-00 for manet@ietf.org; Wed, 10 Mar 2004 13:30:55 -0500 Received: from itc100.adtran.com ([66.0.238.100] helo=srv-exchange1.adtran.com) by ietf-mx with esmtp (Exim 4.12) id 1B18Sw-0005nD-00 for manet@ietf.org; Wed, 10 Mar 2004 13:30:02 -0500 Received: by srv-exchange1.adtran.com with Internet Mail Service (5.5.2657.72) id <196W4RMS>; Wed, 10 Mar 2004 12:29:59 -0600 Message-ID: <39B01E2189D99F4B8C9612462DB3922A153B8A6E@srv-exchange.adtran.com> From: DANIEL BYRNE To: manet@ietf.org Date: Wed, 10 Mar 2004 12:28:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Since the 802.11 mac header has address fields for sender, transmitter, receiver and destination, why aren't ad-hoc routing protocols based upon this seemingly built-in faciity for multihop routing? Each receving node would simply have to change the rx address to the next hop. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 10 16:19:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06657 for ; Wed, 10 Mar 2004 16:19:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1B6p-0007sb-2m for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 16:19:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ALJNcN030285 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 16:19:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1B6o-0007sO-P6 for manet-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 16:19:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06482 for ; Wed, 10 Mar 2004 16:19:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1B6m-0004Ww-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 16:19:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1B52-0003yv-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 16:17:33 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1B3E-0003XU-03 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 16:15:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1Apv-0001f9-38 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 16:01:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Ap5-0006Ng-Vn; Wed, 10 Mar 2004 16:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Ap0-0006MI-6q for manet@optimus.ietf.org; Wed, 10 Mar 2004 16:00:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04017 for ; Wed, 10 Mar 2004 16:00:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Aoy-0007h9-00 for manet@ietf.org; Wed, 10 Mar 2004 16:00:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Ao1-0007Xx-00 for manet@ietf.org; Wed, 10 Mar 2004 15:59:58 -0500 Received: from smtp2.andrew.cmu.edu ([128.2.10.82]) by ietf-mx with esmtp (Exim 4.12) id 1B1Anh-0007Oq-00 for manet@ietf.org; Wed, 10 Mar 2004 15:59:37 -0500 Received: from UNIX48.andrew.cmu.edu (UNIX48.andrew.cmu.edu [128.2.13.178]) (user=dmaltz mech=GSSAPI (0 bits)) by smtp2.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i2AKvdn6029775; Wed, 10 Mar 2004 15:57:39 -0500 Date: Wed, 10 Mar 2004 15:57:38 -0500 (EST) From: Dave Maltz X-X-Sender: dmaltz@unix48.andrew.cmu.edu To: DANIEL BYRNE cc: manet@ietf.org Subject: Re: [manet] 802.11 In-Reply-To: <39B01E2189D99F4B8C9612462DB3922A153B8A6E@srv-exchange.adtran.com> Message-ID: References: <39B01E2189D99F4B8C9612462DB3922A153B8A6E@srv-exchange.adtran.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 On Wed, 10 Mar 2004, DANIEL BYRNE wrote: > Since the 802.11 mac header has address fields for sender, transmitter, > receiver and destination, why aren't ad-hoc routing protocols based upon > this seemingly built-in faciity for multihop routing? Each receving node > would simply have to change the rx address to the next hop. DSR was originally conceived of as a layer-2 routing protocol that could be implemented directly in the interface card using MAC addresses as you suggest. In that role, the protocol could be used to "transparently" extend the coverage of access points and provide multiple-hop ad hoc connectivity between nodes running any layer 3 protocol. We made the decision to define what's become DSR as a layer-3 protocol so that an ad hoc cloud could extend across multiple types of interfaces and even across the Internet itself. Consider a node with two types of interfaces (say IR and 802.11b). If the multi-hop ad hoc routing is done at layer 3, this node has the potential ability to discover routes and forward packets between a node that only as IR and node that only has 802.11. Building a gateway to efficiently connect an ad hoc cloud to the Internet requires the network layer on the gateway to have knowledge of how routing works in the ad hoc cloud, so fewer layer violations are involved if the ad hoc routing protocol runs at layer 3. Cheers, -dam _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 10 19:43:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16962 for ; Wed, 10 Mar 2004 19:43:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EHu-0001YS-6J for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 19:43:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B0h2ZX005970 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 19:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EHt-0001YD-Em for manet-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 19:43:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16940 for ; Wed, 10 Mar 2004 19:43:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EHr-0005YX-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 19:42:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EGv-0005Pu-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 19:42:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1EG9-0005I0-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 19:41:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EFz-0001Gn-6X; Wed, 10 Mar 2004 19:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EF0-0001FF-CA for manet@optimus.ietf.org; Wed, 10 Mar 2004 19:40:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16881 for ; Wed, 10 Mar 2004 19:40:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EEy-00058Q-00 for manet@ietf.org; Wed, 10 Mar 2004 19:40:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EE2-00050V-00 for manet@ietf.org; Wed, 10 Mar 2004 19:39:03 -0500 Received: from web41801.mail.yahoo.com ([66.218.93.135]) by ietf-mx with smtp (Exim 4.12) id 1B1EDE-0004ki-00 for manet@ietf.org; Wed, 10 Mar 2004 19:38:13 -0500 Message-ID: <20040311003743.48722.qmail@web41801.mail.yahoo.com> Received: from [136.159.15.15] by web41801.mail.yahoo.com via HTTP; Wed, 10 Mar 2004 16:37:43 PST Date: Wed, 10 Mar 2004 16:37:43 -0800 (PST) From: Icy Termite To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA16882 Subject: [manet] Counting the number of TCP packets sent/received in Linux kernel 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Can anyone please give me any pointers to counting the number of tcp packets sent and received for a connection in Linux kernel? Thanks, Icy. __________________________________ Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster http://search.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 10 19:55:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17381 for ; Wed, 10 Mar 2004 19:55:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ETY-0002st-IV for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 19:55:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B0t4WA011085 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 19:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ETY-0002si-EI for manet-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 19:55:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17345 for ; Wed, 10 Mar 2004 19:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ETW-0007Um-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 19:55:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ESZ-0007LP-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 19:54:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ERe-0007CB-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 19:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ERa-00029O-0h; Wed, 10 Mar 2004 19:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EQb-00028d-N7 for manet@optimus.ietf.org; Wed, 10 Mar 2004 19:52:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17281 for ; Wed, 10 Mar 2004 19:52:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EQZ-00071o-00 for manet@ietf.org; Wed, 10 Mar 2004 19:51:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EPb-0006sQ-00 for manet@ietf.org; Wed, 10 Mar 2004 19:51:00 -0500 Received: from smtp005.bizmail.sc5.yahoo.com ([66.163.175.82]) by ietf-mx with smtp (Exim 4.12) id 1B1EOd-0006ih-00 for manet@ietf.org; Wed, 10 Mar 2004 19:49:59 -0500 Received: from unknown (HELO truck1) (akucheria@metricsystems.com@67.89.211.170 with plain) by smtp005.bizmail.sc5.yahoo.com with SMTP; 11 Mar 2004 00:49:59 -0000 Subject: Re: [manet] Counting the number of TCP packets sent/received in Linux kernel From: Amit Kucheria To: Icy Termite Cc: IETF Manet In-Reply-To: <20040311003743.48722.qmail@web41801.mail.yahoo.com> References: <20040311003743.48722.qmail@web41801.mail.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-iJzSTfuvKMSdQeWSmJNT" Organization: Metric Systems Corporation Message-Id: <1078966108.28517.13.camel@amit.metricsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 10 Mar 2004 16:48:29 -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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-iJzSTfuvKMSdQeWSmJNT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Use a protocol analyzer like 'tcpdump' or 'ethereal' /Amit On Wed, 2004-03-10 at 16:37, Icy Termite wrote: > Hi, > Can anyone please give me any pointers to counting the > number of tcp packets sent and received for a > connection in Linux kernel? >=20 > Thanks, > Icy. >=20 > __________________________________ > Do you Yahoo!? > Yahoo! Search - Find what youre looking for faster > http://search.yahoo.com >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet --=20 .| Amit Kucheria |. ...| Wireless Systems Engineer |... .....| Metric Systems Corp., San Diego, CA |..... ......| www.metricsystems.com |...... --=-iJzSTfuvKMSdQeWSmJNT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBAT7dctLg6PvU36DYRArpKAKCnr+tImmHV2DYNXNpv5MftNHFZ/ACeK6Mx efTGvvf3TKmIG3a+NkJeZOQ= =WQQC -----END PGP SIGNATURE----- --=-iJzSTfuvKMSdQeWSmJNT-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 10 20:01:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17633 for ; Wed, 10 Mar 2004 20:01:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EZR-0003Zk-FB for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 20:01:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B119rH013738 for manet-archive@odin.ietf.org; Wed, 10 Mar 2004 20:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EZR-0003ZV-Ad for manet-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 20:01:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17581 for ; Wed, 10 Mar 2004 20:01:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EZP-0000dB-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 20:01:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EYO-0000SY-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 20:00:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1EXQ-0000JM-00 for manet-web-archive@ietf.org; Wed, 10 Mar 2004 19:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EXN-00034p-SV; Wed, 10 Mar 2004 19:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1EWc-00030q-NI for manet@optimus.ietf.org; Wed, 10 Mar 2004 19:58:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17489 for ; Wed, 10 Mar 2004 19:58:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1EWa-0000B4-00 for manet@ietf.org; Wed, 10 Mar 2004 19:58:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1EVc-00001T-00 for manet@ietf.org; Wed, 10 Mar 2004 19:57:13 -0500 Received: from [130.15.22.4] (helo=wasp.ECE.QUEENSU.CA) by ietf-mx with esmtp (Exim 4.12) id 1B1EV9-0007gN-00 for manet@ietf.org; Wed, 10 Mar 2004 19:56:43 -0500 Received: from Acer100 ([24.226.41.71]) by wasp.ECE.QUEENSU.CA with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Mar 2004 19:57:28 -0500 From: "Chi-Hsiang Yeh" To: "'Rex Buddenberg'" , "'Bin Lu'" Cc: Subject: RE: [manet] question about bandwidth reservation Date: Wed, 10 Mar 2004 19:55:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQGy3vliYlqUkXEQS6aFuaEAWfSeQAL6msw In-Reply-To: <1078942232.20863.155.camel@antony> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 11 Mar 2004 00:57:28.0593 (UTC) FILETIME=[D3620810:01C40703] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, At layer 3, QoS control is also a routing issue. IEEE 802.11e employs different persistent factors (PF) for different traffic categories. A higher-priority class has a smaller PF so that its contention window (CW) and thus typical backoff times grow slower. Moreover, a higher-priority class has a smaller AIFS required for sensing the carrier, and thus has a better chance for access of the channel. Based on these two mechanisms, 802.11e can differentiate the delay and bandwidth for different traffic classes among nodes, not just within a node. The problem with IEEE 802.11e for MANET is that its differentiation capability is not effective in multihop wireless networking environments (though 802.11e is fine for QoS provisioning in single-hop wireless LANs). There have been several effective differentiation mechanisms proposed for ad hoc networks though. IEEE 802.16 is not appropriate for MANET. Chihsiang ___________________________________________________________ Chi-Hsiang Yeh (Mr./Dr./Prof.) Dept. of Electrical & Computer Eng. Queen's University Kingston, Ontario, K7L 3N6 Canada phone: +1 613-533-6368 fax: +1 613-533-6615 e-mail: chi-hsiang.yeh@ece.queensu.ca , yeh@ee.queensu.ca URL: http://www.ece.queensu.ca/hpages/faculty/yeh/ ___________________________________________________________ -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Rex Buddenberg Sent: Wednesday, March 10, 2004 1:11 PM To: Bin Lu Cc: manet@ietf.org Subject: Re: [manet] question about bandwidth reservation On Wed, 2004-03-10 at 09:12, Bin Lu wrote: > Hi, > > I have a question on bandwidth reservation in ad hoc networks: First, back up one level of abstraction: - at layer 3, QoS control is primarily a priority queuing issue. - at layer 2, QoS control is a media access issue. How does a station, in a shared media, get priority access (permission to transmit) when it is in possession of urgent packets? > > Some MAC layer protocol that supports QoS (such as ieee802.11e) is using > Traffic Categories (different priority queues) to implement priority > differentiation. But this is just at one node, I mean it > doesn't consider the case of shared bandwidth, right? The Traffic Categories only identify urgent packets; still begs the question of how you get priority access. In contention queues like all the .11 variants, you have no access control that can handle the QoS needs. All stations with traffic to send compete, using a carrier sense algorithm to take turns. This, while better than nothing, has several shortcomings: - no way to handle more-equal pigs, as you pointed out - poorly equipped to handle silent hosts. Wired ethernet (802.3) MAC works on the assumption that everybody can hear everybody else. 802.11 stretches that but lives with the same assumption. In a radio-WAN, we have to trade that assumption in for one where all leaf nodes can hear the base station but not necessarily each other. Which drives you to polling or scheduling MAC algorithms. Both of these approaches can handle priority access if designed properly. - carrier sense algorithms trade off bandwidth efficiency for other qos parameters (interactivity, low latency ... and simplicity of design). > Considering > the characteristics of wireless networks, the bandwidth at a node is > actually shared by its neighboring nodes since the node can not send > packets to its neighbor if the neighboring node is also transmitting > or receiving from another node. IEEE802.11e doesn't consider this case, > right? or it doesn't need to? .11 standards took a very large step forward -- we got vendor interoperability and the prices for the gear went way down compared to pre-802.11 wireless LAN equipment (got some of that in lab and it was comparatively pricey). But we didn't get - bandwidth efficient MAC algorithm - decent security (the MAC addresses remain uncovered with WEP) - QoS controls -- which you cannot with a carrier sense algorithm in any real sense. - layer 2 multicast You might want to look at the 802.16 (aka WiMax) standards which, IMHO, represent the next generation and fix a good deal of these problems. The MAC is a dual-queue reservation protocol and that does afford some QoS control at layer 2. > > I'd appreciate it if someone could clarify this to me! > > Bin Lu > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- b _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 11 01:11:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00347 for ; Thu, 11 Mar 2004 01:11:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JPi-0007vO-8I for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 01:11:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B6BQYQ030456 for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 01:11:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JPi-0007v9-54 for manet-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 01:11:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00182 for ; Thu, 11 Mar 2004 01:11:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1JPf-00014x-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 01:11:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1JNo-0000Yi-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 01:09:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1JMa-0000J3-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 01:08:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JMQ-00072o-GC; Thu, 11 Mar 2004 01:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1JLf-0006pX-84 for manet@optimus.ietf.org; Thu, 11 Mar 2004 01:07:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29893 for ; Thu, 11 Mar 2004 01:07:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1JLc-0000BA-00 for manet@ietf.org; Thu, 11 Mar 2004 01:07:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1JKf-00002v-00 for manet@ietf.org; Thu, 11 Mar 2004 01:06:14 -0500 Received: from ece.iisc.ernet.in ([144.16.64.2]) by ietf-mx with esmtp (Exim 4.12) id 1B1JJp-0007bW-00 for manet@ietf.org; Thu, 11 Mar 2004 01:05:22 -0500 Received: from ece.iisc.ernet.in (localhost.localdomain [127.0.0.1]) by ece.iisc.ernet.in (8.12.6/8.11.6) with ESMTP id i2B6Di9U092278; Thu, 11 Mar 2004 11:43:44 +0530 (IST) Received: from localhost (nandini@localhost) by ece.iisc.ernet.in (8.12.6/8.12.6/Submit) with ESMTP id i2B6Dhls092275; Thu, 11 Mar 2004 11:43:43 +0530 (IST) Date: Thu, 11 Mar 2004 11:43:43 +0530 (IST) From: Nandini To: Icy Termite cc: IETF Manet Subject: Re: [manet] Counting the number of TCP packets sent/received in Linux kernel In-Reply-To: <1078966108.28517.13.camel@amit.metricsystems.com> Message-ID: References: <20040311003743.48722.qmail@web41801.mail.yahoo.com> <1078966108.28517.13.camel@amit.metricsystems.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 You can further analyse the dump file obtained from tcpdump using a utility called tcptrace. Nandini On Thu, 10 Mar 2004, Amit Kucheria wrote: > Use a protocol analyzer like 'tcpdump' or 'ethereal' > > /Amit > On Wed, 2004-03-10 at 16:37, Icy Termite wrote: > > Hi, > > Can anyone please give me any pointers to counting the > > number of tcp packets sent and received for a > > connection in Linux kernel? > > > > Thanks, > > Icy. > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! Search - Find what youre looking for faster > > http://search.yahoo.com > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > -- > .| Amit Kucheria |. > ...| Wireless Systems Engineer |... > .....| Metric Systems Corp., San Diego, CA |..... > ......| www.metricsystems.com |...... > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 11 04:54:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22369 for ; Thu, 11 Mar 2004 04:54:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MtR-0004o1-LG for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 04:54:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B9sIOw018460 for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 04:54:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MtN-0004nf-2i for manet-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 04:54:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22295 for ; Thu, 11 Mar 2004 04:54:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1MtJ-0005Zt-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 04:54:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Ms6-0005Ms-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 04:52:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1MrI-00059z-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 04:52:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MrF-0004ME-NO; Thu, 11 Mar 2004 04:52:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Mqr-0004KN-8r for manet@optimus.ietf.org; Thu, 11 Mar 2004 04:51:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22185 for ; Thu, 11 Mar 2004 04:51:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Mqo-00056P-00 for manet@ietf.org; Thu, 11 Mar 2004 04:51:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Mpw-0004tI-00 for manet@ietf.org; Thu, 11 Mar 2004 04:50:44 -0500 Received: from web21108.mail.yahoo.com ([216.136.227.110]) by ietf-mx with smtp (Exim 4.12) id 1B1Moy-0004h1-00 for manet@ietf.org; Thu, 11 Mar 2004 04:49:44 -0500 Message-ID: <20040311094945.6842.qmail@web21108.mail.yahoo.com> Received: from [193.95.33.18] by web21108.mail.yahoo.com via HTTP; Thu, 11 Mar 2004 10:49:45 CET Date: Thu, 11 Mar 2004 10:49:45 +0100 (CET) From: =?iso-8859-1?q?amine=20elabidi?= To: manet@ietf.org In-Reply-To: <20040310170007.25768.51362.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA22186 Subject: [manet] mesh 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I m looking for some references about wireless channel models (path loss,k factor ..) thank you =09 =09 =09 Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !=20 Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger !T=E9l=E9c= hargez Yahoo! Messenger sur http://fr.messenger.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 11 12:43:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12807 for ; Thu, 11 Mar 2004 12:43:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UCs-0006WS-BP for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 12:42:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BHgsTw025068 for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 12:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UCs-0006WF-77 for manet-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 12:42:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12785 for ; Thu, 11 Mar 2004 12:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1UCq-0004UR-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 12:42:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1UBt-0004M0-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 12:41:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1UBK-0004Dm-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 12:41:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UB6-0006Gi-8S; Thu, 11 Mar 2004 12:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1UAk-0006ET-BR for manet@optimus.ietf.org; Thu, 11 Mar 2004 12:40:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12694 for ; Thu, 11 Mar 2004 12:40:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1UAi-0004BW-00 for manet@ietf.org; Thu, 11 Mar 2004 12:40:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1U9m-00043V-00 for manet@ietf.org; Thu, 11 Mar 2004 12:39:43 -0500 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1B1U8u-0003oA-00 for manet@ietf.org; Thu, 11 Mar 2004 12:38:48 -0500 Received: from [128.89.81.92] (dhcp89-081-092.bbn.com [128.89.81.92]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i2BHN6M8019902; Thu, 11 Mar 2004 12:23:06 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Rex Buddenberg'" , , "'Bin Lu'" From: Ram Ramanathan Subject: Re: [manet] question about bandwidth reservation Date: Thu, 11 Mar 2004 12:24:04 -0500 To: "Chi-Hsiang Yeh" X-Mailer: Apple Mail (2.606) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mar 10, 2004, at 7:55 PM, Chi-Hsiang Yeh wrote: > Hi, > > At layer 3, QoS control is also a routing issue. > > IEEE 802.11e employs different persistent factors (PF) for different > traffic > categories. A higher-priority class has a smaller PF so that its > contention > window (CW) and thus typical backoff times grow slower. Moreover, a > higher-priority class has a smaller AIFS required for sensing the > carrier, > and thus has a better chance for access of the channel. Based on these > two > mechanisms, 802.11e can differentiate the delay and bandwidth for > different > traffic classes among nodes, not just within a node. > > The problem with IEEE 802.11e for MANET is that its differentiation > capability is not effective in multihop wireless networking > environments > (though 802.11e is fine for QoS provisioning in single-hop wireless > LANs). > There have been several effective differentiation mechanisms proposed > for ad > hoc networks though. > Why is it not effective in multihop networking? If the idea is that lower priority packets get to wait longer and higher priority are quick out of the gate, why should it be affected by single/multihop? Not arguing a case, just would be interested in a clarification. Any papers on the subject of 802.11e-like things for ad hoc nets? Any paper that summarizes 802.11e? -Ram. > IEEE 802.16 is not appropriate for MANET. > > Chihsiang > ___________________________________________________________ > Chi-Hsiang Yeh (Mr./Dr./Prof.) > Dept. of Electrical & Computer Eng. > Queen's University > Kingston, Ontario, K7L 3N6 > Canada > > phone: +1 613-533-6368 > fax: +1 613-533-6615 > > e-mail: chi-hsiang.yeh@ece.queensu.ca , yeh@ee.queensu.ca > URL: http://www.ece.queensu.ca/hpages/faculty/yeh/ > ___________________________________________________________ > > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of > Rex > Buddenberg > Sent: Wednesday, March 10, 2004 1:11 PM > To: Bin Lu > Cc: manet@ietf.org > Subject: Re: [manet] question about bandwidth reservation > > On Wed, 2004-03-10 at 09:12, Bin Lu wrote: >> Hi, >> >> I have a question on bandwidth reservation in ad hoc networks: > > First, back up one level of abstraction: > - at layer 3, QoS control is primarily a priority queuing issue. > - at layer 2, QoS control is a media access issue. How does a > station, > in a shared media, get priority access (permission to transmit) when it > is in possession of urgent packets? >> >> Some MAC layer protocol that supports QoS (such as ieee802.11e) is >> using >> Traffic Categories (different priority queues) to implement priority >> differentiation. But this is just at one node, I mean it >> doesn't consider the case of shared bandwidth, right? > > The Traffic Categories only identify urgent packets; still begs the > question of how you get priority access. > > In contention queues like all the .11 variants, you have no access > control that can handle the QoS needs. All stations with traffic to > send compete, using a carrier sense algorithm to take turns. This, > while better than nothing, has several shortcomings: > - no way to handle more-equal pigs, as you pointed out > - poorly equipped to handle silent hosts. Wired ethernet (802.3) > MAC > works on the assumption that everybody can hear everybody else. 802.11 > stretches that but lives with the same assumption. In a radio-WAN, we > have to trade that assumption in for one where all leaf nodes can hear > the base station but not necessarily each other. Which drives you to > polling or scheduling MAC algorithms. Both of these approaches can > handle priority access if designed properly. > - carrier sense algorithms trade off bandwidth efficiency for other > qos > parameters (interactivity, low latency ... and simplicity of design). > >> Considering >> the characteristics of wireless networks, the bandwidth at a node is >> actually shared by its neighboring nodes since the node can not send >> packets to its neighbor if the neighboring node is also transmitting >> or receiving from another node. IEEE802.11e doesn't consider this >> case, >> right? or it doesn't need to? > > .11 standards took a very large step forward -- we got vendor > interoperability and the prices for the gear went way down compared to > pre-802.11 wireless LAN equipment (got some of that in lab and it was > comparatively pricey). But we didn't get > - bandwidth efficient MAC algorithm > - decent security (the MAC addresses remain uncovered with WEP) > - QoS controls -- which you cannot with a carrier sense algorithm in > any real sense. > - layer 2 multicast > > You might want to look at the 802.16 (aka WiMax) standards which, IMHO, > represent the next generation and fix a good deal of these problems. > The MAC is a dual-queue reservation protocol and that does afford some > QoS control at layer 2. >> >> I'd appreciate it if someone could clarify this to me! >> >> Bin Lu >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > -- > b > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > 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 exim@www1.ietf.org Thu Mar 11 19:52:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07124 for ; Thu, 11 Mar 2004 19:52:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1atv-0004AO-Gm for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 19:51:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C0plHU016012 for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 19:51:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1atv-0004AB-9o for manet-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 19:51:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06988 for ; Thu, 11 Mar 2004 19:51:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1att-0003sT-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 19:51:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1apR-0002kZ-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 19:47:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1aob-0002ax-03 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 19:46:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1afr-0005Y6-59 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 19:37:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1afd-0002wB-O0; Thu, 11 Mar 2004 19:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1aer-0002pt-0e for manet@optimus.ietf.org; Thu, 11 Mar 2004 19:36:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06591 for ; Thu, 11 Mar 2004 19:36:11 -0500 (EST) From: richard.r.herron@L-3com.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1aep-0001JW-00 for manet@ietf.org; Thu, 11 Mar 2004 19:36:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1adm-0001B8-00 for manet@ietf.org; Thu, 11 Mar 2004 19:35:06 -0500 Received: from slxcg01.csw.l-3com.com ([128.170.12.150]) by ietf-mx with esmtp (Exim 4.12) id 1B1acv-0000wk-00 for manet@ietf.org; Thu, 11 Mar 2004 19:34:13 -0500 Received: by slxcg01.csw.L-3com.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Mar 2004 17:33:34 -0700 Message-ID: <31892CFAF4097F488320D5FFDC60074001A1C6D7@slxcg01.csw.L-3com.com> To: manet@ietf.org Date: Thu, 11 Mar 2004 17:33:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] OLSR and IP Addresses 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 I have a question about how to assign IP addresses when using OLSR. Section 11.1 of RFC 3626 says: The nodes in the MANET network SHOULD be assigned addresses within a defined address sequence, i.e., the nodes in the MANET SHOULD be addressable through a network address and a netmask. Since the OLSR routing protocol messages contain only IP addresses and not subnet masks, it seems like this is implying that all IP addresses in the OLSR MANET should be on the same IP subnet. Is this the case? If so, this seems like a limitation in OLSR that is not present in other protocols such as AODV. The AODV RFC says it was designed for use by mobile nodes with IP addresses that are not necessarily related to each other. Can someone please provide some clarification on these points? Thanks, Richard Herron L-3 Communications _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 12 03:51:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08884 for ; Fri, 12 Mar 2004 03:51:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1iNx-0004Px-2e for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 03:51:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C8pHCr016982 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 03:51:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1iNw-0004Pp-QC for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 03:51:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08803 for ; Fri, 12 Mar 2004 03:51:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1iNu-0005B3-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 03:51:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1iMv-00051O-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 03:50:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1iLz-0004sP-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 03:49:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1iLl-0003uA-RA; Fri, 12 Mar 2004 03:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1iL4-0003t0-7C for manet@optimus.ietf.org; Fri, 12 Mar 2004 03:48:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08667 for ; Fri, 12 Mar 2004 03:48:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1iL1-0004kM-00 for manet@ietf.org; Fri, 12 Mar 2004 03:48:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1iKA-0004dJ-00 for manet@ietf.org; Fri, 12 Mar 2004 03:47:23 -0500 Received: from mailhost.cs.auc.dk ([130.225.194.6] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B1iJJ-0004W0-00 for manet@ietf.org; Fri, 12 Mar 2004 03:46:29 -0500 Received: from armada (voop@borg.cs.auc.dk [130.225.194.22]) by mailhost.cs.auc.dk (8.12.10/8.12.10) with SMTP id i2C8kSWs021910; Fri, 12 Mar 2004 09:46:28 +0100 (MET) Date: Fri, 12 Mar 2004 09:46:28 +0100 From: Thomas Heide Clausen To: richard.r.herron@L-3com.com Cc: manet@ietf.org Subject: Re: [manet] OLSR and IP Addresses Message-Id: <20040312094628.2403e7ee.ietflists@free.fr> In-Reply-To: <31892CFAF4097F488320D5FFDC60074001A1C6D7@slxcg01.csw.L-3com.com> References: <31892CFAF4097F488320D5FFDC60074001A1C6D7@slxcg01.csw.L-3com.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Richard, Thanks for your interrest in OLSR. On Thu, 11 Mar 2004 17:33:34 -0700 richard.r.herron@L-3com.com wrote: > > I have a question about how to assign IP addresses when using OLSR. > > Section 11.1 of RFC 3626 says: > The nodes in the MANET network SHOULD be assigned addresses within a > defined address sequence, i.e., the nodes in the MANET SHOULD be > addressable through a network address and a netmask. > > Since the OLSR routing protocol messages contain only IP addresses and > not subnet masks, it seems like this is implying that all IP addresses in > the OLSR > MANET should be on the same IP subnet. Is this the case? Nope. Each node must have an IP-address, however there are no requirements as to how these addresses are assigned within the OLSR network. You may have nodes from different "IP subnet" in the same OLSR manet -- it makes no difference as to how the routing protocol routes. For all OLSR is concirned, an IP address is an IP address -- always. The condition from section 11.1 (which is a SHOULD, btw., not a MUST) comes from the simple fact that if you want to advertice routes from the OLSR manet into another routing domain, then it is smart to be able to address the entire manet as a "chunk" -- to aggregate the node addresses by means of a subnet. However this is a real issue only at the time when you want to inject routes to manet nodes into an external network. This is similar to the way aggregation is done by other prevailing internet routing protocols. > > If so, this seems like a limitation in OLSR that is not present in other > protocols > such as AODV. The AODV RFC says it was designed for use by mobile nodes > with IP addresses that are not necessarily related to each other. > AODV and OLSR works identically wrt. requirements address assignment within the manet. There is no difference on this point. I hope this answers your question? Regards, --thomas > Can someone please provide some clarification on these points? > > Thanks, > > Richard Herron > L-3 Communications _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 12 05:27:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12140 for ; Fri, 12 Mar 2004 05:27:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jsx-00017B-Ir for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 05:27:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CARNcX004281 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 05:27:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jsx-00016y-D3 for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 05:27:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12100 for ; Fri, 12 Mar 2004 05:27:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jsu-0001RL-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 05:27:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1jru-0001Hl-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 05:26:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1jqv-00018R-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 05:25:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jqk-0000jB-2a; Fri, 12 Mar 2004 05:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1jpz-0000hX-RN for manet@optimus.ietf.org; Fri, 12 Mar 2004 05:24:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11907 for ; Fri, 12 Mar 2004 05:24:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1jpw-000109-00 for manet@ietf.org; Fri, 12 Mar 2004 05:24:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1joy-0000sL-00 for manet@ietf.org; Fri, 12 Mar 2004 05:23:16 -0500 Received: from gemini.rz.uni-ulm.de ([134.60.246.16] helo=mail.rz.uni-ulm.de) by ietf-mx with esmtp (Exim 4.12) id 1B1jo0-0000jL-00 for manet@ietf.org; Fri, 12 Mar 2004 05:22:16 -0500 Received: from informatik.uni-ulm.de (delphin.informatik.uni-ulm.de [134.60.70.42]) by mail.rz.uni-ulm.de (8.12.10/8.12.10) with ESMTP id i2CAMG3D003031 for ; Fri, 12 Mar 2004 11:22:16 +0100 (MET) Message-ID: <40518F58.7000602@informatik.uni-ulm.de> Date: Fri, 12 Mar 2004 11:22:16 +0100 From: Frank Kargl Organization: University of Ulm User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: manet@ietf.org X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-DCC-RollaNet-Metrics: gemini 1004; Body=1 Fuz1=1 Fuz2=1 Content-Transfer-Encoding: 7bit Subject: [manet] CfP: 2nd German Workshop on 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all ... from 22. to 24. Sept. 2004 we will organize the 2nd German Workshop on Mobile Ad-hoc Networks in Ulm, Germany. You can find all details in the CfP at: http://www.informatik2004.de/fileadmin/dateien_redaktion/CfP-adhoc-de.pdf (german version) http://www.informatik2004.de/fileadmin/dateien_redaktion/CfP-adhoc-en.pdf (english version) Regards ... Frank -- ----------------------------------------------------------------------- Dr.rer.nat. Frank Kargl Dep. of Multimedia Computing, University of Ulm, Germany http://medien.informatik.uni-ulm.de/~frank/ ----------------------------------------------------------------------- Use the SOURCE, Luke ! I feel a great disturbance in the SOURCE. But beware of the Microsoft side of the SOURCE ! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 12 09:13:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22058 for ; Fri, 12 Mar 2004 09:13:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nPN-0000v4-HL for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 09:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CED5iu003530 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 09:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nPN-0000ur-Cg for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 09:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22028 for ; Fri, 12 Mar 2004 09:13:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nPL-0001JP-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 09:13:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nON-00014y-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 09:12:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1nNV-0000tr-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 09:11:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nNO-0000af-5U; Fri, 12 Mar 2004 09:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nN4-0000Zb-Os for manet@optimus.ietf.org; Fri, 12 Mar 2004 09:10:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21871 for ; Fri, 12 Mar 2004 09:10:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nN3-0000ry-00 for manet@ietf.org; Fri, 12 Mar 2004 09:10:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nM5-0000j8-00 for manet@ietf.org; Fri, 12 Mar 2004 09:09:42 -0500 Received: from mail.ict.ac.cn ([159.226.39.4]) by ietf-mx with smtp (Exim 4.12) id 1B1nLH-0000Sl-00 for manet@ietf.org; Fri, 12 Mar 2004 09:08:51 -0500 Received: (qmail 4466 invoked from network); 12 Mar 2004 14:10:11 -0000 Received: from unknown (HELO dream) (159.226.39.104) by mail.ict.ac.cn with SMTP; 12 Mar 2004 14:10:11 -0000 Message-ID: <005601c4083b$792d6f90$0906a8c0@dream> From: "Li Ru" To: Date: Fri, 12 Mar 2004 22:08:19 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01C4087E.86C119C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: [manet] hello message in ns aodv 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0053_01C4087E.86C119C0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGw6DQogQ2FuIGFueWJvZHkgdG9sZCBtZSBob3cgdG8gc3RhcnQgSGVsbG8gbWVzc2Fn ZSBpbiBhb2R2PyBJdCBzZWVtcyB0aGF0IGxpbmsgbGF5ZXIgZmVlZGJhY2sgaXMgdXNlZCBpbiBh b2R2IG9mIG5zMiBieSBkZWZhdWx0LiBUaGFua3MgaW4gYWR2YW5jZS4NCg0KTGVlDQo= ------=_NextPart_000_0053_01C4087E.86C119C0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNzM3LjgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkRlYXIgYWxsOjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwO0NhbiBhbnlib2R5IHRvbGQgbWUgaG93IHRv IHN0YXJ0IEhlbGxvIG1lc3NhZ2UgaW4gYW9kdj8gDQpJdCBzZWVtcyB0aGF0IGxpbmsgbGF5ZXIg ZmVlZGJhY2sgaXMgdXNlZCBpbiBhb2R2IG9mIG5zMiBieSBkZWZhdWx0LiBUaGFua3MgaW4gDQph ZHZhbmNlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPkxlZTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0053_01C4087E.86C119C0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 12 09:36:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23819 for ; Fri, 12 Mar 2004 09:36:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nli-0002wk-A7 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 09:36:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CEaAXh011325 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 09:36:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nli-0002wa-6v for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 09:36:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23724 for ; Fri, 12 Mar 2004 09:36:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nlg-0005GY-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 09:36:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nka-00050A-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 09:35:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1njG-0004gr-02 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 09:33:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nWC-0001cd-CK; Fri, 12 Mar 2004 09:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nVi-0001aV-1y for manet@optimus.ietf.org; Fri, 12 Mar 2004 09:19:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22980 for ; Fri, 12 Mar 2004 09:19:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nVg-0002xQ-00 for manet@ietf.org; Fri, 12 Mar 2004 09:19:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1nV1-0002nx-00 for manet@ietf.org; Fri, 12 Mar 2004 09:18:56 -0500 Received: from tosh.netlab.uky.edu ([204.198.76.200]) by ietf-mx with esmtp (Exim 4.12) id 1B1nTv-0002YB-00 for manet@ietf.org; Fri, 12 Mar 2004 09:17:47 -0500 Received: from willow.netlab.uky.edu (willow.netlab.uky.edu [204.198.76.76]) by tosh.netlab.uky.edu (Postfix) with ESMTP id 5BFDACE81 for ; Fri, 12 Mar 2004 09:17:47 -0500 (EST) Received: by willow.netlab.uky.edu (Postfix, from userid 1109) id 319DF950ED; Fri, 12 Mar 2004 09:17:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by willow.netlab.uky.edu (Postfix) with ESMTP id 2C286FD40 for ; Fri, 12 Mar 2004 09:17:47 -0500 (EST) Date: Fri, 12 Mar 2004 09:17:47 -0500 (EST) From: Krishna Prabhala To: manet@ietf.org Subject: Re: [manet] OLSR and IP Addresses 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Thomas, Still, I am not very clear. If nodes belonging to any subnet can be in a MANET, how is that the MANET prefix for auto-configuration is being fixed at 169.254/16? (for route aggregation?) What about if nodes having an IP address outside this range move into a MANET? Will their old IP addresses be changed to be within 169.254/16? Also, how can route aggregation be guaranteed in a MANET wherein nodes have IP addresses belonging to different subnets? Thanks, Krishna. On Fri, 12 Mar 2004, Thomas Heide Clausen wrote: - Richard, - - Thanks for your interrest in OLSR. - - On Thu, 11 Mar 2004 17:33:34 -0700 - richard.r.herron@L-3com.com wrote: - - > - > I have a question about how to assign IP addresses when using OLSR. - > - > Section 11.1 of RFC 3626 says: - > The nodes in the MANET network SHOULD be assigned addresses within a - > defined address sequence, i.e., the nodes in the MANET SHOULD be - > addressable through a network address and a netmask. - > - > Since the OLSR routing protocol messages contain only IP addresses and - > not subnet masks, it seems like this is implying that all IP addresses in - > the OLSR - > MANET should be on the same IP subnet. Is this the case? - - Nope. Each node must have an IP-address, however there are no requirements - as to how these addresses are assigned within the OLSR network. You may - have nodes from different "IP subnet" in the same OLSR manet -- it makes no - difference as to how the routing protocol routes. For all OLSR is - concirned, an IP address is an IP address -- always. - - The condition from section 11.1 (which is a SHOULD, btw., not a MUST) comes - from the simple fact that if you want to advertice routes from the OLSR - manet into another routing domain, then it is smart to be able to address - the entire manet as a "chunk" -- to aggregate the node addresses by means - of a subnet. However this is a real issue only at the time when you want to - inject routes to manet nodes into an external network. This is similar to - the way aggregation is done by other prevailing internet routing protocols. - - > - > If so, this seems like a limitation in OLSR that is not present in other - > protocols - > such as AODV. The AODV RFC says it was designed for use by mobile nodes - > with IP addresses that are not necessarily related to each other. - > - - AODV and OLSR works identically wrt. requirements address assignment within - the manet. There is no difference on this point. - - I hope this answers your question? - - Regards, - - --thomas - - > Can someone please provide some clarification on these points? - > - > Thanks, - > - > Richard Herron - > L-3 Communications - - _______________________________________________ - 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 exim@www1.ietf.org Fri Mar 12 10:30:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27862 for ; Fri, 12 Mar 2004 10:30:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1obO-00050b-Ra for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 10:29:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CFTYB1019249 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 10:29:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1obO-00050O-Ls for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 10:29:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27826 for ; Fri, 12 Mar 2004 10:29:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1obM-0004pv-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 10:29:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1oaM-0004hi-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 10:28:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1oZR-0004ai-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 10:27:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1oYw-0004aK-De; Fri, 12 Mar 2004 10:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1oYW-0004Wd-NM for manet@optimus.ietf.org; Fri, 12 Mar 2004 10:26:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27557 for ; Fri, 12 Mar 2004 10:26:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1oYU-0004RI-00 for manet@ietf.org; Fri, 12 Mar 2004 10:26:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1oXT-0004H1-00 for manet@ietf.org; Fri, 12 Mar 2004 10:25:32 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1B1oWz-00049O-00 for manet@ietf.org; Fri, 12 Mar 2004 10:25:01 -0500 Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i2CFJOHd021837; Fri, 12 Mar 2004 16:19:24 +0100 Message-ID: <013401c40845$af87e160$1f175d80@inria.fr> From: "Philippe Jacquet" To: "Ram Ramanathan" , "Chi-Hsiang Yeh" Cc: "'Rex Buddenberg'" , , "'Bin Lu'" References: Subject: Re: [manet] question about bandwidth reservation Date: Fri, 12 Mar 2004 16:21:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ram, One problem of multihop networks versus bandwidth reservation is that out of range links interfer (hidden nodes, interference area larger than data reception area, etc). As far as we know this greatly complicates bandwidth reservation since reservation affects links and nodes that are not involved in the path of data. This should fairly reduce the efficiency of local priorities use. In fact it can be proven that finding a good route for bandwidth that does not downgrade the bandwidth of existing connections is NP hard (http://www.inria.fr/rrrt/rr-4876.html ). The result is fairly independent on the MAC layer. Philippe ----- Original Message ----- From: Ram Ramanathan To: Chi-Hsiang Yeh Cc: 'Rex Buddenberg' ; ; 'Bin Lu' Sent: Thursday, March 11, 2004 6:24 PM Subject: Re: [manet] question about bandwidth reservation > > On Mar 10, 2004, at 7:55 PM, Chi-Hsiang Yeh wrote: > > > Hi, > > > > At layer 3, QoS control is also a routing issue. > > > > IEEE 802.11e employs different persistent factors (PF) for different > > traffic > > categories. A higher-priority class has a smaller PF so that its > > contention > > window (CW) and thus typical backoff times grow slower. Moreover, a > > higher-priority class has a smaller AIFS required for sensing the > > carrier, > > and thus has a better chance for access of the channel. Based on these > > two > > mechanisms, 802.11e can differentiate the delay and bandwidth for > > different > > traffic classes among nodes, not just within a node. > > > > The problem with IEEE 802.11e for MANET is that its differentiation > > capability is not effective in multihop wireless networking > > environments > > (though 802.11e is fine for QoS provisioning in single-hop wireless > > LANs). > > There have been several effective differentiation mechanisms proposed > > for ad > > hoc networks though. > > > > Why is it not effective in multihop networking? If the idea is that > lower priority packets get to wait longer and higher priority are quick > out of the gate, why should it be affected by single/multihop? > > Not arguing a case, just would be interested in a clarification. > > Any papers on the subject of 802.11e-like things for ad hoc nets? Any > paper that summarizes 802.11e? > > -Ram. > > > IEEE 802.16 is not appropriate for MANET. > > > > Chihsiang > > ___________________________________________________________ > > Chi-Hsiang Yeh (Mr./Dr./Prof.) > > Dept. of Electrical & Computer Eng. > > Queen's University > > Kingston, Ontario, K7L 3N6 > > Canada > > > > phone: +1 613-533-6368 > > fax: +1 613-533-6615 > > > > e-mail: chi-hsiang.yeh@ece.queensu.ca , yeh@ee.queensu.ca > > URL: http://www.ece.queensu.ca/hpages/faculty/yeh/ > > ___________________________________________________________ > > > > -----Original Message----- > > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of > > Rex > > Buddenberg > > Sent: Wednesday, March 10, 2004 1:11 PM > > To: Bin Lu > > Cc: manet@ietf.org > > Subject: Re: [manet] question about bandwidth reservation > > > > On Wed, 2004-03-10 at 09:12, Bin Lu wrote: > >> Hi, > >> > >> I have a question on bandwidth reservation in ad hoc networks: > > > > First, back up one level of abstraction: > > - at layer 3, QoS control is primarily a priority queuing issue. > > - at layer 2, QoS control is a media access issue. How does a > > station, > > in a shared media, get priority access (permission to transmit) when it > > is in possession of urgent packets? > >> > >> Some MAC layer protocol that supports QoS (such as ieee802.11e) is > >> using > >> Traffic Categories (different priority queues) to implement priority > >> differentiation. But this is just at one node, I mean it > >> doesn't consider the case of shared bandwidth, right? > > > > The Traffic Categories only identify urgent packets; still begs the > > question of how you get priority access. > > > > In contention queues like all the .11 variants, you have no access > > control that can handle the QoS needs. All stations with traffic to > > send compete, using a carrier sense algorithm to take turns. This, > > while better than nothing, has several shortcomings: > > - no way to handle more-equal pigs, as you pointed out > > - poorly equipped to handle silent hosts. Wired ethernet (802.3) > > MAC > > works on the assumption that everybody can hear everybody else. 802.11 > > stretches that but lives with the same assumption. In a radio-WAN, we > > have to trade that assumption in for one where all leaf nodes can hear > > the base station but not necessarily each other. Which drives you to > > polling or scheduling MAC algorithms. Both of these approaches can > > handle priority access if designed properly. > > - carrier sense algorithms trade off bandwidth efficiency for other > > qos > > parameters (interactivity, low latency ... and simplicity of design). > > > >> Considering > >> the characteristics of wireless networks, the bandwidth at a node is > >> actually shared by its neighboring nodes since the node can not send > >> packets to its neighbor if the neighboring node is also transmitting > >> or receiving from another node. IEEE802.11e doesn't consider this > >> case, > >> right? or it doesn't need to? > > > > .11 standards took a very large step forward -- we got vendor > > interoperability and the prices for the gear went way down compared to > > pre-802.11 wireless LAN equipment (got some of that in lab and it was > > comparatively pricey). But we didn't get > > - bandwidth efficient MAC algorithm > > - decent security (the MAC addresses remain uncovered with WEP) > > - QoS controls -- which you cannot with a carrier sense algorithm in > > any real sense. > > - layer 2 multicast > > > > You might want to look at the 802.16 (aka WiMax) standards which, IMHO, > > represent the next generation and fix a good deal of these problems. > > The MAC is a dual-queue reservation protocol and that does afford some > > QoS control at layer 2. > >> > >> I'd appreciate it if someone could clarify this to me! > >> > >> Bin Lu > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www1.ietf.org/mailman/listinfo/manet > > -- > > b > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Fri Mar 12 10:55:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29414 for ; Fri, 12 Mar 2004 10:55:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ozb-00073D-Pr for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 10:54:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CFsZiD027101 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 10:54:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ozb-000732-M3 for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 10:54:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29321 for ; Fri, 12 Mar 2004 10:54:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ozZ-0000T2-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 10:54:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1oyc-0000Jf-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 10:53:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1oxf-0000Az-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 10:52:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ox7-0006Xs-Te; Fri, 12 Mar 2004 10:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1owi-0006XJ-Kk for manet@optimus.ietf.org; Fri, 12 Mar 2004 10:51:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29120 for ; Fri, 12 Mar 2004 10:51:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1owg-00002m-00 for manet@ietf.org; Fri, 12 Mar 2004 10:51:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ovn-0007jc-00 for manet@ietf.org; Fri, 12 Mar 2004 10:50:40 -0500 Received: from mailhost.cs.auc.dk ([130.225.194.6] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B1ovC-0007ct-00 for manet@ietf.org; Fri, 12 Mar 2004 10:50:02 -0500 Received: from armada (voop@borg.cs.auc.dk [130.225.194.22]) by mailhost.cs.auc.dk (8.12.10/8.12.10) with SMTP id i2CFnvWs009634; Fri, 12 Mar 2004 16:49:59 +0100 (MET) Date: Fri, 12 Mar 2004 16:49:58 +0100 From: Thomas Heide Clausen To: Krishna Prabhala Cc: manet@ietf.org Subject: Re: [manet] OLSR and IP Addresses Message-Id: <20040312164958.1e64fed8.T.Clausen@computer.org> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Krishna, These are very good questions. They are not specific to OLSR, but apply equally to all MANET routing protocols (or, indeed, to the MANET domain in general). Your question, as I understand it, addresses basically two issues: - how do we do auto-configuration in MANETs; - how do we do route aggregation in MANETs. There have been a number of drafts regarding the issue of autoconfiguration, and some discussion on this topic at the last MANET meeting in Seoul. Regarding the second issue, I believe that this hasn't been fully explored, however one could envision employing mobile IP (or similar solutions) to accomodate "forigen nodes" in a manet. This really concerns how MANETs play into the larger Internet infrastructure, and should probably be addressed. It would be interresting to discuss these issues, however as I've stated, they apply equally to all MANET routing protocols. Regards, --thomas On Fri, 12 Mar 2004 09:17:47 -0500 (EST) Krishna Prabhala wrote: > Thomas, > > Still, I am not very clear. If nodes belonging to any subnet can be in a > MANET, how is that the MANET prefix for auto-configuration is being fixed > at 169.254/16? (for route aggregation?) What about if nodes having an IP > address outside this range move into a MANET? Will their old IP > addresses be changed to be within 169.254/16? > > Also, how can route aggregation be guaranteed in a MANET wherein nodes > have IP addresses belonging to different subnets? > > Thanks, > Krishna. > > > On Fri, 12 Mar 2004, Thomas Heide Clausen wrote: > > - Richard, > - > - Thanks for your interrest in OLSR. > - > - On Thu, 11 Mar 2004 17:33:34 -0700 > - richard.r.herron@L-3com.com wrote: > - > - > > - > I have a question about how to assign IP addresses when using OLSR. > - > > - > Section 11.1 of RFC 3626 says: > - > The nodes in the MANET network SHOULD be assigned addresses within a > - > defined address sequence, i.e., the nodes in the MANET SHOULD be > - > addressable through a network address and a netmask. > - > > - > Since the OLSR routing protocol messages contain only IP addresses > and- > not subnet masks, it seems like this is implying that all IP > addresses in- > the OLSR > - > MANET should be on the same IP subnet. Is this the case? > - > - Nope. Each node must have an IP-address, however there are no > requirements- as to how these addresses are assigned within the OLSR > network. You may- have nodes from different "IP subnet" in the same OLSR > manet -- it makes no- difference as to how the routing protocol routes. > For all OLSR is- concirned, an IP address is an IP address -- always. > - > - The condition from section 11.1 (which is a SHOULD, btw., not a MUST) > comes- from the simple fact that if you want to advertice routes from the > OLSR- manet into another routing domain, then it is smart to be able to > address- the entire manet as a "chunk" -- to aggregate the node addresses > by means- of a subnet. However this is a real issue only at the time when > you want to- inject routes to manet nodes into an external network. This > is similar to- the way aggregation is done by other prevailing internet > routing protocols.- > - > > - > If so, this seems like a limitation in OLSR that is not present in > other- > protocols > - > such as AODV. The AODV RFC says it was designed for use by mobile > nodes- > with IP addresses that are not necessarily related to each > other.- > > - > - AODV and OLSR works identically wrt. requirements address assignment > within- the manet. There is no difference on this point. > - > - I hope this answers your question? > - > - Regards, > - > - --thomas > - > - > Can someone please provide some clarification on these points? > - > > - > Thanks, > - > > - > Richard Herron > - > L-3 Communications > - _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 12 11:31:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01528 for ; Fri, 12 Mar 2004 11:31:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pYn-00011x-PN for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 11:30:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CGUvc0003960 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 11:30:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pYn-00011n-LV for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 11:30:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01355 for ; Fri, 12 Mar 2004 11:30:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1pYm-0005mN-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 11:30:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1pWr-0005I3-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 11:28:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1pVc-0004yv-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 11:27:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1pK2-0002dG-A5 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 11:15:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pJQ-00005T-HP; Fri, 12 Mar 2004 11:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pIV-0008Ur-KH for manet@optimus.ietf.org; Fri, 12 Mar 2004 11:14:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00609 for ; Fri, 12 Mar 2004 11:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1pIU-0003TO-00 for manet@ietf.org; Fri, 12 Mar 2004 11:14:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1pHl-0003IC-00 for manet@ietf.org; Fri, 12 Mar 2004 11:13:22 -0500 Received: from web61103.mail.yahoo.com ([216.155.196.105]) by ietf-mx with smtp (Exim 4.12) id 1B1pGr-0002xw-00 for manet@ietf.org; Fri, 12 Mar 2004 11:12:25 -0500 Message-ID: <20040312160521.59405.qmail@web61103.mail.yahoo.com> Received: from [141.156.71.10] by web61103.mail.yahoo.com via HTTP; Fri, 12 Mar 2004 08:05:21 PST Date: Fri, 12 Mar 2004 08:05:21 -0800 (PST) From: manet user To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1454454881-1079107521=:57373" Subject: [manet] OLSR MID 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1454454881-1079107521=:57373 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA00610 Content-Transfer-Encoding: quoted-printable Hi, =20 I am styduying the OLSR implementations and RFC. I couldn't understand fr= om the RFC, how does the communication starts in a network.=20 =20 My understanding is:=20 - every node that has multiple interfaces sends out MID messages (full bo= radcast),=20 - each node also sends out Hello message (with no addresses in Data part) - nodes receving these packets create various sets/tuples. =20 My question is, do we need to send MID messages periodically like Hellos = or TC messages ? Since RFC suggests MID_INTERVAL =3D TC_INTERVAL and both= are network wide broadcast, what is the need of so frequent MIDs. =20 Thanks in advance. -MU --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster. --0-1454454881-1079107521=:57373 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA00610 Content-Transfer-Encoding: quoted-printable
    Hi,
     
    I am styduying the OLSR implementations and RFC. I couldn't understa= nd from the RFC, how does the communication starts in a network.
     
    My understanding is:
    - every node that has multiple interfaces sends out MID messages (fu= ll boradcast),
    - each node also sends out Hello message (with no addresses in Data = part)
    - nodes receving these packets create various sets/tuples.
     
    My question is, do we need to send MID messages periodically like He= llos or TC messages ? Since RFC suggests MID_INTERVAL =3D TC_INTERVAL and= both are network wide broadcast, what is the need of so freque= nt MIDs.
     
    Thanks in advance.
    -MU

    Do you Yahoo!?
    Yahoo! Search - Find what you=92re looking for faster. --0-1454454881-1079107521=:57373-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 12 11:51:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02485 for ; Fri, 12 Mar 2004 11:51:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1psJ-0005DB-BI for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 11:51:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CGp7GG020027 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 11:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1psJ-0005Cw-1o for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 11:51:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02410 for ; Fri, 12 Mar 2004 11:51:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1psH-0000hP-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 11:51:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1prM-0000Tg-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 11:50:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1pqR-0000Hn-01 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 11:49:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1pfr-0003K4-VL for manet-web-archive@ietf.org; Fri, 12 Mar 2004 11:38:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pfd-0001mH-Pg; Fri, 12 Mar 2004 11:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1pfD-0001fd-Fn for manet@optimus.ietf.org; Fri, 12 Mar 2004 11:37:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01945 for ; Fri, 12 Mar 2004 11:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1pfC-0006qm-00 for manet@ietf.org; Fri, 12 Mar 2004 11:37:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1peM-0006ki-00 for manet@ietf.org; Fri, 12 Mar 2004 11:36:43 -0500 Received: from mailhost.cs.auc.dk ([130.225.194.6] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B1pdq-0006e8-00 for manet@ietf.org; Fri, 12 Mar 2004 11:36:10 -0500 Received: from armada (voop@borg.cs.auc.dk [130.225.194.22]) by mailhost.cs.auc.dk (8.12.10/8.12.10) with SMTP id i2CGa6Ws013102; Fri, 12 Mar 2004 17:36:07 +0100 (MET) Date: Fri, 12 Mar 2004 17:36:06 +0100 From: Thomas Heide Clausen To: manet user Cc: manet@ietf.org Subject: Re: [manet] OLSR MID messages Message-Id: <20040312173606.480f6914.T.Clausen@computer.org> In-Reply-To: <20040312160521.59405.qmail@web61103.mail.yahoo.com> References: <20040312160521.59405.qmail@web61103.mail.yahoo.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 12 Mar 2004 08:05:21 -0800 (PST) manet user wrote: > Hi, > > I am styduying the OLSR implementations and RFC. I couldn't understand > from the RFC, how does the communication starts in a network. > > My understanding is: > - every node that has multiple interfaces sends out MID messages (full > boradcast), - each node also sends out Hello message (with no addresses > in Data part)- nodes receving these packets create various sets/tuples. > > My question is, do we need to send MID messages periodically like Hellos > or TC messages ? Since RFC suggests MID_INTERVAL = TC_INTERVAL and both > are network wide broadcast, what is the need of so frequent MIDs. > > Thanks in advance. > -MU Hello, Thanks for your interrest in OLSR. It helps to think about it this way: an MID message is what is used to associate "interfaces" with "nodes". I.e. the link sensing part of OLSR detects links between interfaces -- the MID messages associate these interfaces (and thereby links) to the notion of a "node" -- with a node being the entities we're concirned about creating routes between in the MANET. The periodicity of MID messages is basically due to two things: first, nodes may actually change their interface associations over time (e.g., a node may decide that a given interface no longer is to be used for MANET routing), thus interface association information must be able to expire; second, new nodes may appear in the network at any time, thus the interface association must be made available periodically to ensure that such "new" nodes have the required information. Hope this helps, --thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 12 12:36:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05622 for ; Fri, 12 Mar 2004 12:36:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qZh-0000MK-SX for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 12:35:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CHZvFn001379 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 12:35:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qZh-0000MA-Ni for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 12:35:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05599 for ; Fri, 12 Mar 2004 12:35:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qZf-0007h6-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 12:35:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qYh-0007XE-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 12:34:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1qY3-0007Nh-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 12:34:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1qY4-0004NV-8X for manet-web-archive@ietf.org; Fri, 12 Mar 2004 12:34:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qXq-0008Ho-BA; Fri, 12 Mar 2004 12:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qXP-0008FB-S3 for manet@optimus.ietf.org; Fri, 12 Mar 2004 12:33:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05278 for ; Fri, 12 Mar 2004 12:33:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qXN-0007HK-00 for manet@ietf.org; Fri, 12 Mar 2004 12:33:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qWP-00073g-00 for manet@ietf.org; Fri, 12 Mar 2004 12:32:34 -0500 Received: from gehenna.ece.cornell.edu ([128.84.95.235]) by ietf-mx with esmtp (Exim 4.12) id 1B1qVQ-0006pP-00 for manet@ietf.org; Fri, 12 Mar 2004 12:31:32 -0500 Received: from Panacea_2.cornell.edu (dhcp-128-84-210-143-r3a-desktop.ece.cornell.edu [128.84.210.143]) by gehenna.ece.cornell.edu (Postfix) with ESMTP id CF2961E801B for ; Fri, 12 Mar 2004 12:31:29 -0500 (EST) Message-Id: <5.2.1.1.2.20040312122813.01146ed0@postoffice7.mail.cornell.edu> X-Sender: papadp@pop.ece.cornell.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 12 Mar 2004 12:31:30 -0500 To: manet@ietf.org From: Panos Papadimitratos Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] CfP: 1st European Workshop on Security in Ad-Hoc and Sensor Networks (ESAS 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 1st European Workshop on Security in Ad-Hoc and Sensor Networks (ESAS 2004) 5-6 August, 2004 EURESCOM, Heidelberg, Germany Technically co-sponsored by COMSOC Germany Chapter The Keynote speech will be given by Jean-Pierre Hubaux from the EPFL, Switzerland. General Information With more and more devices getting smart and interconnected, ad hoc and sensor networks will open up a realm of new communication and data exchange opportunities. These upcoming networks are characterized by their dynamic structure, lack of a pre-established fixed infrastructure, and constrained resources. In order to allow their successful deployment, various security challenges must be met. Examples include missing `a priori' security associations, no clear line of defense, the lack of a trusted infrastructure, complex multiple domain relationships, as well as bandwidth, computing, memory and energy constraints. Due to the pervasive nature of applications relying on ad-hoc and sensor networks effective provisions for robust security solutions in a reliable and power efficient way must be taken. This workshop seeks submissions presenting novel research on all aspects of security and cryptography for ad-hoc and sensor networks. ESAS 2004 will be a workshop where the cryptography, security and wireless networking communities meet. Submission of papers based on work-in-progress is encouraged. The topics include but are not limited to: Cryptographic protocols Trust establishment, negotiation, and management Security in constrained environments Cooperation and fairness based protocols Key management Scalability evaluation of secure and reliable protocols Secure routing Secure hardware modules Implementations of secure protocols Deployment of secure protocols Privacy and anonymity Secure MAC protocols Instructions for Authors Authors are invited to submit original papers. The preferred submission form is by electronic mail to Claude.Castelluccia@inrialpes.fr . The submissions must not exceed 10 pages (excluding the title page, bibliography and appendices) nor 12 pages overall. The final version should not exceed 15 pages. Please submit the paper in Postscript or PDF, together with an extra file containing the email and physical address of the authors, an indication of the corresponding author and a copy of the title, key words and abstract. We recommend that you generate the PS or PDF file using LaTeX and the LNCS style available at www.springer.de/comp/lncs. All submissions will be refereed. Submissions must not substantially duplicate work that any of the authors have published elsewhere or have submitted in parallel. The workshop will also include a poster and demonstrator session. Submissions will include a 2-page summary as well as a rough draft of the poster. Important Dates Submission Deadline: 15th March, 2004 [Extended to 22th March 2004] Acceptance Notifications: 30th April, 2004 Final Version due: 1st June, 2004 Workshop: 5th-6th August, 2004 Proceedings Version Deadline: 6th September, 2004 Mailing List If you want to receive subsequent Call for Papers and registration information, please send a brief mail to majordomo@netlab.nec.de and in the mail body write "subscribe esasworkshop". Registration Registration is available now! All session will be held at EURESCOM. Workshop Organizers Claude Castelluccia, INRIA, France (Claude.Castelluccia@inrialpes.fr) Hannes Hartenstein, University of Karlsruhe, Germany (hannes.hartenstein@rz.uni-karlsruhe.de) Christof Paar, University of Bochum, Germany (cpaar@crypto-ruhr-uni-bochum.de) Dirk Westhoff, NEC Network Labs Heidelberg, Germany (dirk.westhoff@netlab.nec.de) Program Committee N. Asokan, Nokia, Finland Levente Buttyan, BME-HIT, Hungary Sonja Buchegger, EPFL, Switzerland Claude Castelluccia, INRIA, France Claudia Eckert, TU Darmstadt, Germany Hannes Hartenstein, University of Karlsruhe, Germany Stefan Lucks, University of Mannheim, Germany Refik Molva, Eurecom, France Gabriel Montenegro, SunLabs, France Pekka Nikander, Ericsson, Finland Christof Paar, University of Bochum, Germany Panagiotis Papadimitratos, Cornell University, USA Ahmad-Reza Sadeghi, University of Bochum, Germany Frank Stajano, University of Cambridge, UK Gene Tsudik, UC Irvine, USA Andre Weimerskirch, University of Bochum, Germany Nathalie Weiler, ETH Zuerich, Switzerland Dirk Westhoff, NEC Europe Ltd., Germany Susanne Wetzel, Stevens Institute of Technology, USA Manel Guerrero Zapata, University Pompeu Fabra, Barcelona, Spain Workshop Proceedings The Proceedings will be published by Springer after the Workshop in the Lecture Notes in Computer Science (LNCS) Series (www.springer.de/comp/lncs). Notice that in order to be included in the proceedings, the authors of an accepted paper must guarantee to present their contribution at the workshop. Further Workshop Information Dirk Westhoff NEC Europe Ltd. Kurfuersten-Anlage 36 D-69115 Heidelberg Germany Phone: +49/(0)6221/90511-49 Fax: +49/(0)6221/90511-55 Email: dirk.westhoff@netlab.nec.de Technically co-sponsored by IEEE Communications Society, Germany Chapter Supported by Inria Supported by Cosy Group Supported by DSN Group Supported by NL-E Proceedings published as Springer LNCS _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 12 16:58:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21232 for ; Fri, 12 Mar 2004 16:58:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uf4-00054H-JF for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 16:57:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLvkgb019480 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 16:57:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uf4-000547-FL for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:57:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21216 for ; Fri, 12 Mar 2004 16:57:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uf2-0001xv-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 16:57:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1ue9-0001vm-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 16:56:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1udR-0001uA-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 16:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1udO-0004hc-8N; Fri, 12 Mar 2004 16:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ud7-0004h1-HM for manet@optimus.ietf.org; Fri, 12 Mar 2004 16:55:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21131 for ; Fri, 12 Mar 2004 16:55:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ud5-0001sh-00 for manet@ietf.org; Fri, 12 Mar 2004 16:55:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uc8-0001r1-00 for manet@ietf.org; Fri, 12 Mar 2004 16:54:45 -0500 Received: from web61103.mail.yahoo.com ([216.155.196.105]) by ietf-mx with smtp (Exim 4.12) id 1B1ubH-0001n3-00 for manet@ietf.org; Fri, 12 Mar 2004 16:53:51 -0500 Message-ID: <20040312215319.89783.qmail@web61103.mail.yahoo.com> Received: from [141.156.71.10] by web61103.mail.yahoo.com via HTTP; Fri, 12 Mar 2004 13:53:19 PST Date: Fri, 12 Mar 2004 13:53:19 -0800 (PST) From: manet user To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1224288445-1079128399=:89637" Subject: [manet] AODV 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1224288445-1079128399=:89637 Content-Type: text/plain; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA21132 Content-Transfer-Encoding: quoted-printable Hi, =20 If i need to support AODV (currently running for IPv4) for IPv6, i MUST c= hange the control packet (RREQ, RREP) structures according to draft-perki= ns-manet-aodv6-01.txt ?=20 =20 Just making the source, destination IP addresses larger will surely affec= t the allignment. It seems implemention of "Flood Data Option" is optiona= l and will not affect the normal AODV functionalities ? Please correct if= i am wrong. =20 Thanks in advance, -MU --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you=92re looking for faster. --0-1224288445-1079128399=:89637 Content-Type: text/html; charset=us-ascii X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA21132 Content-Transfer-Encoding: quoted-printable
    Hi,
     
    If i need to support AODV (currently running for IPv4) for IPv6= , i MUST change the control packet (RREQ, RREP) structures according= to draft-perkins-manet-aodv6-01.txt ?
     
    Just making the source, destination IP addresses larger will surely = affect the allignment. It seems implemention of "Flood Data Option" is op= tional and will not affect the normal AODV functionalities ? Please corre= ct if i am wrong.
     
    Thanks in advance,
    -MU

    Do you Yahoo!?
    Yahoo! Search - Find what you=92re looking for faster. --0-1224288445-1079128399=:89637-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 12 20:49:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05791 for ; Fri, 12 Mar 2004 20:49:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yGm-0001wW-2Y for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 20:48:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2D1mu2h007462 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 20:48:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yGl-0001wH-Tl for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 20:48:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05779 for ; Fri, 12 Mar 2004 20:48:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yGj-0001lX-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 20:48:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yFo-0001iN-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 20:47:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1yF8-0001fm-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 20:47:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yEw-0001e7-Jr; Fri, 12 Mar 2004 20:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1yEn-0001dk-It for manet@optimus.ietf.org; Fri, 12 Mar 2004 20:46:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05697 for ; Fri, 12 Mar 2004 20:46:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1yEl-0001er-00 for manet@ietf.org; Fri, 12 Mar 2004 20:46:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1yDn-0001dh-00 for manet@ietf.org; Fri, 12 Mar 2004 20:45:52 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B1yDU-0001ca-00 for manet@ietf.org; Fri, 12 Mar 2004 20:45:32 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B1yDU-000Osc-Jj for manet@ietf.org; Sat, 13 Mar 2004 01:45:32 +0000 Date: Fri, 12 Mar 2004 17:08:12 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <29235727017.20040312170812@psg.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] Minutes from Seoul? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- Could the person that took the minutes at the meeting please send them to me and the WG chairs? Thank you. -- Alex http://www.psg.com/~zinin/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Mar 13 16:41:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02112 for ; Sat, 13 Mar 2004 16:41:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Gsu-0003vn-AG for manet-archive@odin.ietf.org; Sat, 13 Mar 2004 16:41:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2DLfW3k015107 for manet-archive@odin.ietf.org; Sat, 13 Mar 2004 16:41:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Gsu-0003va-6M for manet-web-archive@optimus.ietf.org; Sat, 13 Mar 2004 16:41:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02108 for ; Sat, 13 Mar 2004 16:41:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Gss-0006BC-00 for manet-web-archive@ietf.org; Sat, 13 Mar 2004 16:41:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Grt-00067n-00 for manet-web-archive@ietf.org; Sat, 13 Mar 2004 16:40:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2Grn-00064i-00 for manet-web-archive@ietf.org; Sat, 13 Mar 2004 16:40:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2GrV-0003mC-9O; Sat, 13 Mar 2004 16:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Gr0-0003kp-HV for manet@optimus.ietf.org; Sat, 13 Mar 2004 16:39:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02039 for ; Sat, 13 Mar 2004 16:39:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Gqy-00064A-00 for manet@ietf.org; Sat, 13 Mar 2004 16:39:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Gq2-00060J-00 for manet@ietf.org; Sat, 13 Mar 2004 16:38:35 -0500 Received: from ux5.cso.uiuc.edu ([128.174.5.45] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B2GpX-0005wW-00 for manet@ietf.org; Sat, 13 Mar 2004 16:38:03 -0500 Received: from csmincao (csl-mincao.csl.uiuc.edu [130.126.136.213]) by ux5.cso.uiuc.edu (8.12.10/8.12.10) with SMTP id i2DLc3t9001701 for ; Sat, 13 Mar 2004 15:38:03 -0600 (CST) Message-ID: <005401c40943$76eda0c0$d123fea9@ad.uiuc.edu> From: "Min Cao" To: Date: Sat, 13 Mar 2004 15:38:03 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C40911.2C3632E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [manet] 802.11n 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C40911.2C3632E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all, Can anyone provide some useful links for 802.11n technical information? = Do they have a maillist for it? Thansk, -min ------=_NextPart_000_0051_01C40911.2C3632E0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    Hi all,
     
    Can anyone provide some useful links = for 802.11n=20 technical information?  Do they have a maillist for = it?
     
    Thansk,
    -min
    ------=_NextPart_000_0051_01C40911.2C3632E0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Mar 14 03:15:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08099 for ; Sun, 14 Mar 2004 03:15:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Qlq-0000G7-GG for manet-archive@odin.ietf.org; Sun, 14 Mar 2004 03:14:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2E8EsPl000990 for manet-archive@odin.ietf.org; Sun, 14 Mar 2004 03:14:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Qlp-0000Fs-MK for manet-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 03:14:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08082 for ; Sun, 14 Mar 2004 03:14:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Qln-0005tk-00 for manet-web-archive@ietf.org; Sun, 14 Mar 2004 03:14:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Qkr-0005oq-00 for manet-web-archive@ietf.org; Sun, 14 Mar 2004 03:13:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2QkE-0005jy-00 for manet-web-archive@ietf.org; Sun, 14 Mar 2004 03:13:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Qk0-0008EF-FI; Sun, 14 Mar 2004 03:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2Qjq-0008Da-Th for manet@optimus.ietf.org; Sun, 14 Mar 2004 03:12:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08029 for ; Sun, 14 Mar 2004 03:12:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2Qjo-0005ig-00 for manet@ietf.org; Sun, 14 Mar 2004 03:12:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2Qiu-0005eJ-00 for manet@ietf.org; Sun, 14 Mar 2004 03:11:53 -0500 Received: from mail.ict.ac.cn ([159.226.39.4]) by ietf-mx with smtp (Exim 4.12) id 1B2Qi3-0005UO-00 for manet@ietf.org; Sun, 14 Mar 2004 03:10:59 -0500 Received: (qmail 23175 invoked from network); 14 Mar 2004 08:11:53 -0000 Received: from unknown (HELO dream) (159.226.39.104) by mail.ict.ac.cn with SMTP; 14 Mar 2004 08:11:53 -0000 Message-ID: <005e01c4099b$cf0e53a0$0906a8c0@dream> From: "Li Ru" To: Date: Sun, 14 Mar 2004 16:10:26 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C409DE.DCC51630" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Subject: [manet] the scope of manet 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C409DE.DCC51630 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGw6DQogIENhbiBhbnlib2R5IHRlbGwgbWUgaXMgdGhlcmUgYW55IHBhcGVyIHRhbGsg YWJvdXQgdGhlIHNjb3BlIG9mIG1hbmV0PyBPciB3aGF0IGZhY3RvciBkZXRlcm1pbmF0ZXMgdGhp cyBzY29wZT8gVGhhbmtzLg0KDQpMZWUNCg== ------=_NextPart_000_005B_01C409DE.DCC51630 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNzM3LjgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxC T0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkRlYXIgYWxsOjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPiZuYnNwOyBDYW4gYW55Ym9keSB0ZWxsIG1lIGlzIHRo ZXJlIGFueSBwYXBlciB0YWxrIGFib3V0IHRoZSANCnNjb3BlIG9mIG1hbmV0PyBPciB3aGF0IGZh Y3RvciZuYnNwO2RldGVybWluYXRlcyB0aGlzIHNjb3BlPyANClRoYW5rcy48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5MZWU8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_005B_01C409DE.DCC51630-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Mar 14 16:16:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08955 for ; Sun, 14 Mar 2004 16:16:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2cy7-0003DE-BV for manet-archive@odin.ietf.org; Sun, 14 Mar 2004 16:16:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ELGNXq012347 for manet-archive@odin.ietf.org; Sun, 14 Mar 2004 16:16:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2cy7-0003D4-3P for manet-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 16:16:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08934 for ; Sun, 14 Mar 2004 16:16:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2cy5-0006Wc-00 for manet-web-archive@ietf.org; Sun, 14 Mar 2004 16:16:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2cxB-0006P1-00 for manet-web-archive@ietf.org; Sun, 14 Mar 2004 16:15:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2cwG-0006GA-00 for manet-web-archive@ietf.org; Sun, 14 Mar 2004 16:14:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2cvp-0002xt-Om; Sun, 14 Mar 2004 16:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2cvF-0002xB-Uv for manet@optimus.ietf.org; Sun, 14 Mar 2004 16:13:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08715 for ; Sun, 14 Mar 2004 16:13:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2cvE-00063w-00 for manet@ietf.org; Sun, 14 Mar 2004 16:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2cuG-0005rT-00 for manet@ietf.org; Sun, 14 Mar 2004 16:12:25 -0500 Received: from bay1-dav51.bay1.hotmail.com ([65.54.244.40] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B2ctA-0005a3-00 for manet@ietf.org; Sun, 14 Mar 2004 16:11:16 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 14 Mar 2004 13:10:45 -0800 Received: from 69.157.53.56 by bay1-dav51.bay1.hotmail.com with DAV; Sun, 14 Mar 2004 21:10:44 +0000 X-Originating-IP: [69.157.53.56] X-Originating-Email: [jack_sci03@hotmail.com] X-Sender: jack_sci03@hotmail.com From: "Jack Chan's Hotmail Account" To: References: Date: Sun, 14 Mar 2004 16:09:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 14 Mar 2004 21:10:45.0143 (UTC) FILETIME=[D0BF4A70:01C40A08] Content-Transfer-Encoding: 7bit Subject: [manet] HELP HELP Testing NIST-Kernel-AODV 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, FROM_HAS_ULINE_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi everybody, I am trying to test NIST's Kernel AODV implementation on my wireless testbed. I have successfully poured the code into my wireless testbed. However, we are not quit sure on how to test the performance of this routing protocol. I have tried NFS (Network File Sharing) and SCP (remote command) in Linux to send file to destination node through intermediate nodes, but it seems these two functions do not work with AODV. Is there any better suggestion to send file or create video conferencing to other nodes and using AODV protocol? What I am trying to do is to test the performance of AODV by generating some control traffic. Any help would be greatly appreciated. Thank you Sincerely, Jack Chan ----- Original Message ----- From: "Bin Lu" To: "Ram Ramanathan" Cc: Sent: Friday, March 12, 2004 3:45 PM Subject: Re: [manet] question about bandwidth reservation > > > > > Any papers on the subject of 802.11e-like things for ad hoc nets? Any > > paper that summarizes 802.11e? > > > > Here is a paper that gives an overview of the new features of IEEE > 802.11e: > > "IEEE 802.11e Wireless LAN for Quality of Service", Stefan Mangold etc., > http://citeseer.ist.psu.edu/537394.html > > _______________________________________________ > 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 exim@www1.ietf.org Mon Mar 15 05:34:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20042 for ; Mon, 15 Mar 2004 05:34:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2pQQ-0006hT-96 for manet-archive@odin.ietf.org; Mon, 15 Mar 2004 05:34:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FAYQWT025754 for manet-archive@odin.ietf.org; Mon, 15 Mar 2004 05:34:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2pQP-0006hJ-Ty for manet-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 05:34:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19951 for ; Mon, 15 Mar 2004 05:34:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2pQM-000006-00 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 05:34:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2pPQ-0007aW-00 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 05:33:24 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B2pON-0007Nq-03 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 05:32:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B2pBs-000591-V1 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 05:19:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2pBd-0005tu-4T; Mon, 15 Mar 2004 05:19:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2p9h-0005hA-1e for manet@optimus.ietf.org; Mon, 15 Mar 2004 05:17:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19213 for ; Mon, 15 Mar 2004 05:17:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2p9b-0005c6-00 for manet@ietf.org; Mon, 15 Mar 2004 05:17:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2p8X-0005Li-00 for manet@ietf.org; Mon, 15 Mar 2004 05:15:58 -0500 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx with esmtp (Exim 4.12) id 1B2p7E-0004rr-00 for manet@ietf.org; Mon, 15 Mar 2004 05:14:36 -0500 Received: from igor.urz.unibas.ch (igor.urz.unibas.ch [131.152.1.3]) by balu1.urz.unibas.ch (8.12.10/8.12.10) with ESMTP id i2FADwaT026089; Mon, 15 Mar 2004 11:13:58 +0100 Date: Mon, 15 Mar 2004 11:13:58 +0100 (MET) From: Christian Tschudin To: manet@ietf.org cc: evgeny.osipov@unibas.ch, rmg@docs.uu.se, Oskar Wibling , Olof Rensfelt Subject: [manet] Internet Draft for LUNAR -00 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 LUNAR and its implementation was first announced on this list on Dec 6, 2001, more than two years ago. Now there is an Internet Draft: http://www.ietf.org/internet-drafts/draft-tschudin-manet-lunar-00.txt Abstract: The Lightweight Underlay Network Ad hoc Routing (LUNAR) Protocol is intended for use by mobile nodes in small size wireless ad hoc networks. LUNAR operates at layer 2.5. It emulates a single-hop IP subnet with unicast as well as broadcast communication primitives. DHCP and ARP messages are intercepted and serve as hooks for self-configuration of IP addresses as well as the mapping of IP addresses to the underlying layer 2.5 multihop routes. LUNAR's Roadmap: My goal is to complete this ID within one year such that we have: - a single document - not more than 30 pages - which contains *all* info (e.g., including WiFi settings) needed for producing a self-configuring implementation that works out of the box. LUNAR shall become a pragmatic ad hoc routing solution that is simple and small in every way: specs, implementation and operation. Looking forward to reading your comments! Best, christian. PS: Sources (lnx, win, ns2) will be released in three weeks. ACK: Richard Gold, Evgeny Osipov, Olof Rensfelt, David Rosen and Oskar Wibling have substantially contributed to LUNAR. --- Christian Tschudin, University of Basel http://cn.cs.unibas.ch/ Computer Science Dept, Bernoullistr. 16, CH - 4056 Basel, Switzerland _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 15 10:32:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03503 for ; Mon, 15 Mar 2004 10:32:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2u4g-0005t3-JL for manet-archive@odin.ietf.org; Mon, 15 Mar 2004 10:32:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FFWIG6022628 for manet-archive@odin.ietf.org; Mon, 15 Mar 2004 10:32:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2u4g-0005st-Ee for manet-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 10:32:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03480 for ; Mon, 15 Mar 2004 10:32:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2u4d-0007PP-00 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 10:32:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2u3g-0007FO-00 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 10:31:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2u2t-00076O-00 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 10:30:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2u2V-0005TS-Jm; Mon, 15 Mar 2004 10:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2u2M-0005SV-ND for manet@optimus.ietf.org; Mon, 15 Mar 2004 10:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03348 for ; Mon, 15 Mar 2004 10:29:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2u2K-000734-00 for manet@ietf.org; Mon, 15 Mar 2004 10:29:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2u1N-0006ue-00 for manet@ietf.org; Mon, 15 Mar 2004 10:28:54 -0500 Received: from host-bs.adtran.com ([208.61.208.100] helo=srv-exchange2.adtran.com) by ietf-mx with esmtp (Exim 4.12) id 1B2u0S-0006m5-00 for manet@ietf.org; Mon, 15 Mar 2004 10:27:56 -0500 Received: by pobox.adtran.com with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Mar 2004 09:27:55 -0600 Message-ID: <39B01E2189D99F4B8C9612462DB3922A153B8AAF@srv-exchange.adtran.com> From: DANIEL BYRNE To: "'Christian Tschudin'" , manet@ietf.org Cc: evgeny.osipov@unibas.ch, rmg@docs.uu.se, Oskar Wibling , Olof Rensfelt Subject: RE: [manet] Internet Draft for LUNAR -00 Date: Mon, 15 Mar 2004 09:27:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 The document has so far been indispensible in our work. However, my collegue has a foggy view of how the RREP messages work. He suggests that you provide a RREP example just like you provided a RREQ example in the internet draft text. -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On Behalf Of Christian Tschudin Sent: Monday, March 15, 2004 4:14 AM To: manet@ietf.org Cc: evgeny.osipov@unibas.ch; rmg@docs.uu.se; Oskar Wibling; Olof Rensfelt Subject: [manet] Internet Draft for LUNAR -00 LUNAR and its implementation was first announced on this list on Dec 6, 2001, more than two years ago. Now there is an Internet Draft: http://www.ietf.org/internet-drafts/draft-tschudin-manet-lunar-00.txt Abstract: The Lightweight Underlay Network Ad hoc Routing (LUNAR) Protocol is intended for use by mobile nodes in small size wireless ad hoc networks. LUNAR operates at layer 2.5. It emulates a single-hop IP subnet with unicast as well as broadcast communication primitives. DHCP and ARP messages are intercepted and serve as hooks for self-configuration of IP addresses as well as the mapping of IP addresses to the underlying layer 2.5 multihop routes. LUNAR's Roadmap: My goal is to complete this ID within one year such that we have: - a single document - not more than 30 pages - which contains *all* info (e.g., including WiFi settings) needed for producing a self-configuring implementation that works out of the box. LUNAR shall become a pragmatic ad hoc routing solution that is simple and small in every way: specs, implementation and operation. Looking forward to reading your comments! Best, christian. PS: Sources (lnx, win, ns2) will be released in three weeks. ACK: Richard Gold, Evgeny Osipov, Olof Rensfelt, David Rosen and Oskar Wibling have substantially contributed to LUNAR. --- Christian Tschudin, University of Basel http://cn.cs.unibas.ch/ Computer Science Dept, Bernoullistr. 16, CH - 4056 Basel, Switzerland _______________________________________________ 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 exim@www1.ietf.org Mon Mar 15 15:02:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19768 for ; Mon, 15 Mar 2004 15:02:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yHo-00015g-VF for manet-archive@odin.ietf.org; Mon, 15 Mar 2004 15:02:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FK28oJ004165 for manet-archive@odin.ietf.org; Mon, 15 Mar 2004 15:02:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yHo-000155-PG for manet-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 15:02:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19721 for ; Mon, 15 Mar 2004 15:02:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yHl-00012M-00 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 15:02:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yGt-0000zl-00 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 15:01:12 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2yG8-0000wt-00 for manet-web-archive@ietf.org; Mon, 15 Mar 2004 15:00:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yFr-0006vd-OC; Mon, 15 Mar 2004 15:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2yF3-0006tH-6u for manet@optimus.ietf.org; Mon, 15 Mar 2004 14:59:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19613 for ; Mon, 15 Mar 2004 14:59:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2yF0-0000tO-00 for manet@ietf.org; Mon, 15 Mar 2004 14:59:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2yE5-0000r1-00 for manet@ietf.org; Mon, 15 Mar 2004 14:58:18 -0500 Received: from itc100.adtran.com ([66.0.238.100] helo=srv-exchange1.adtran.com) by ietf-mx with esmtp (Exim 4.12) id 1B2yDj-0000nc-00 for manet@ietf.org; Mon, 15 Mar 2004 14:57:55 -0500 Received: by srv-exchange1.adtran.com with Internet Mail Service (5.5.2657.72) id <196WVF2Y>; Mon, 15 Mar 2004 13:57:42 -0600 Message-ID: <39B01E2189D99F4B8C9612462DB3922A153B8AB2@srv-exchange.adtran.com> From: DANIEL BYRNE To: "'manet@ietf.org'" , "Christian Tschudin (E-mail)" Subject: FW: [manet] LUNAR Date: Mon, 15 Mar 2004 13:57:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 How is the data path created from the node that initiates the RREQ packet to the target node that initiates the RREP packet? Conceptually, I think I understand that the RREP packet contains the necessary information to do this, but I haven't made the connection yet. Would it be possible to get an example similar to the one given for a RREQ along with how the link is made? Also, in step 0.a and step 1.e the statement "Allocate an unused "receiver chosen" selector S...". Should the statement in 1.e be a new receiver chosen selector S'? Thanks -----Original Message----- From: DANIEL BYRNE Sent: Friday, March 12, 2004 6:05 PM To: 'Christian Tschudin' Cc: GEAN JOHNSON Subject: RE: [manet] LUNAR Our goal is to develop a hardware implementation of LUNAR. We are writing VHDL to be loaded initially on an FPGA to achieve this goal; although, we have only just started the work. We are trying to decipher the published C code and the spec, but we have run into a few questions regarding the wording of the LUNAR document and the software implementation. Specifically it is unclear how reply messages are handled, and how XRP is used to setup dynamic links? How does the orgininating node know when the path has been completed? etc. A document describing message formats would be fabulous. Also, any informative documents on XRP and LUNAR in general would help us to get started on the right path. Thanks in advance for your help. Daniel Byrne and Gean Johnson -----Original Message----- From: Christian Tschudin [mailto:Christian.Tschudin@unibas.ch] Sent: Tuesday, February 24, 2004 9:27 AM To: DANIEL BYRNE Cc: 'Evgeny Osipov' Subject: RE: [manet] LUNAR Dear Daniel, Evgeny forwarded your email to me and I'm delighted: Having a an independent implementation of LUNAR is very useful and makes a big difference! What are your plans with LUNAR? I would like to quickly sketch our strategy and would be interested to learn your views: a) We have been working during the last year on a second version of LUNAR which - runs in Linux kernel space (2.4.x) - is ported to Windows (as an intermediate driver, identical code for protocol logic) - is ported to ns-2 (identical code for protocol logic) Now we are close to finalizing the package for public distribution. (There is also a version for Bluetooth, but it's more a hack, so it will probably not be included). b) During this process we: - changed the XRP message format, which is now much easier to parse and generate - added a slight optimization to the protocol logic (setting up a bidirectional tunnel right away) One thing I hope for is that we could coordinate the message formats. It would be great if we envisaged inter-op tests between the two LUNAR implementations, which is very helpful for ironing out bugs. Adopting the new message format should not be a big issue. We would be very willing to share the spec and current code even before we release the package to the public, so you don't incur any delay. Simulation results (which look good and competitive!) will be available too, of course. Kind regards, christian tschudin. --- Christian Tschudin, University of Basel http://cn.cs.unibas.ch/ Computer Science Dept, Bernoullistr. 16, CH - 4056 Basel, Switzerland On Fri, 20 Feb 2004, DANIEL BYRNE wrote: > We are developing a LUNAR implementation, not simulation, that is > currently scheduled for beta release in 2 months. This is not a > simulation implementation, however. I'd be interested in any data you'd > be willing to share. > > Thanks, > > Daniel _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 16 07:32:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27495 for ; Tue, 16 Mar 2004 07:32:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3DjW-0002ru-Te for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 07:31:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GCVkTo011023 for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 07:31:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3DjW-0002ri-M3 for manet-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 07:31:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27487 for ; Tue, 16 Mar 2004 07:31:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3DjW-000630-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 07:31:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3DiX-0005ye-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 07:30:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Dhp-0005uG-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 07:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Dgr-0002Xc-HB; Tue, 16 Mar 2004 07:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Dgg-0002X1-DD for manet@optimus.ietf.org; Tue, 16 Mar 2004 07:28:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27391 for ; Tue, 16 Mar 2004 07:28:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Dgf-0005o1-00 for manet@ietf.org; Tue, 16 Mar 2004 07:28:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Dfo-0005iA-00 for manet@ietf.org; Tue, 16 Mar 2004 07:27:57 -0500 Received: from bay16-f7.bay16.hotmail.com ([65.54.186.57] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Det-0005VV-00 for manet@ietf.org; Tue, 16 Mar 2004 07:26:59 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Mar 2004 04:26:22 -0800 Received: from 61.187.56.10 by by16fd.bay16.hotmail.msn.com with HTTP; Tue, 16 Mar 2004 12:26:22 GMT X-Originating-IP: [61.187.56.10] X-Originating-Email: [zongmng@hotmail.com] X-Sender: zongmng@hotmail.com From: "Zong Ming" To: manet@ietf.org Date: Tue, 16 Mar 2004 20:26:22 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 16 Mar 2004 12:26:22.0735 (UTC) FILETIME=[E48451F0:01C40B51] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA27392 Subject: [manet] Clustering 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hello,everyone I am a student.I want to study clutering in mobile ad hoc networks,b= ut=20 i don't know how to start.Can anyone tell where i can find some papers=20 about overview of the clustering? Thank you! Zong Ming _________________________________________________________________ =C3=E2=B7=D1=CF=C2=D4=D8 MSN Explorer: http://explorer.msn.com/lccn =20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 16 12:10:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11377 for ; Tue, 16 Mar 2004 12:10:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3I4d-0001wk-Dw for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 12:09:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GH9pin007479 for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 12:09:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3I4d-0001wY-8z for manet-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 12:09:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11350 for ; Tue, 16 Mar 2004 12:09:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3I4b-000051-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 12:09:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3I3l-0007l9-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 12:08:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3I2r-0007dz-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 12:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3I1u-0001Fr-IX; Tue, 16 Mar 2004 12:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3I12-0001Dc-54 for manet@optimus.ietf.org; Tue, 16 Mar 2004 12:06:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11189 for ; Tue, 16 Mar 2004 12:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3I10-0007PR-00 for manet@ietf.org; Tue, 16 Mar 2004 12:06:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3I06-0007I9-00 for manet@ietf.org; Tue, 16 Mar 2004 12:05:11 -0500 Received: from cs.sfu.ca ([142.58.111.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B3Hz7-0007Ax-00 for manet@ietf.org; Tue, 16 Mar 2004 12:04:10 -0500 Received: from css.css.sfu.ca (daemon@css [199.60.1.20]) by cs.sfu.ca (8.12.10/8.12.9) with ESMTP id i2GH3xT2002565; Tue, 16 Mar 2004 09:03:59 -0800 (PST) Received: from localhost (yzchen@localhost) by css.css.sfu.ca (8.11.6/8.11.6) with ESMTP id i2GH3xx06023; Tue, 16 Mar 2004 09:03:59 -0800 (PST) X-Authentication-Warning: css.css.sfu.ca: yzchen owned process doing -bs Date: Tue, 16 Mar 2004 09:03:59 -0800 (PST) From: Yuanzhu Peter Chen X-X-Sender: yzchen@css.css.sfu.ca To: Zong Ming cc: manet@ietf.org Subject: Re: [manet] Clustering In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=gb2312 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Hello Ming, There is a large body of work on clustering ad hoc networks. To start with, you can look at these: 1. Geng Chen, Ivan Stojmenovic. Clustering and Routing in Mobile Wireless Networks. Technical Report, TR-99-05, SITE, University of Ottawa, 1999. 2. Rajmohan Rajaraman, Topology Control and Routing in Ad Hoc Networks: A Survey, SIGACT News, 33:60-73, June 2002. 3. Martha Steenstrup, Cluster-Based Networks, in "Ad Hoc Networking" (ed. Charles E. Perkins), Addison-Wesley, 2001. 4. J. Sucec and I. Marsic, "Hierarchical routing overhead in mobile ad hoc networks," IEEE Trans. Mobile Computing, Vol. 3, No. 1, Jan-Feb, 2004, pp. 46-56. 5. Yuanzhu P. Chen and Arthur L. Liestman, A Zonal Algorithm for Clustering Ad Hoc Networks, International Journal of Foundations of Computer Science, 14(2):305-322, April 2003. Cizhi, Peter ------------------------------------------------ "I have not powered down. I have just rebooted." On Tue, 16 Mar 2004, Zong Ming wrote: > hello,everyone > I am a student.I want to study clutering in mobile ad hoc networks,b= ut > i don't know how to start.Can anyone tell where i can find some papers > about overview of the clustering? > > Thank you! > Zong Ming > > _________________________________________________________________ > =C3=E2=B7=D1=CF=C2=D4=D8 MSN Explorer: http://explorer.msn.com/lccn > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Mar 16 12:23:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12043 for ; Tue, 16 Mar 2004 12:23:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IHV-0002y9-UE for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 12:23:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GHN9Ai011407 for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 12:23:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IHV-0002xu-PI for manet-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 12:23:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12020 for ; Tue, 16 Mar 2004 12:23:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3IHU-0001No-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 12:23:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3IGX-0001GS-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 12:22:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3IFc-00019D-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 12:21:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IEW-0002Pt-Ri; Tue, 16 Mar 2004 12:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IDW-0002MC-EV for manet@optimus.ietf.org; Tue, 16 Mar 2004 12:19:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11827 for ; Tue, 16 Mar 2004 12:18:58 -0500 (EST) From: crentel@sce.carleton.ca Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3IDV-0000y1-00 for manet@ietf.org; Tue, 16 Mar 2004 12:19:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3ICR-0000tU-00 for manet@ietf.org; Tue, 16 Mar 2004 12:17:56 -0500 Received: from sangam.sce.carleton.ca ([134.117.4.4]) by ietf-mx with esmtp (Exim 4.12) id 1B3IBi-0000oY-00 for manet@ietf.org; Tue, 16 Mar 2004 12:17:10 -0500 Received: from localhost (webmail.sce.carleton.ca [134.117.4.46]) by sangam.sce.carleton.ca (8.12.11/8.12.11) with ESMTP id i2GHGutG001136 for ; Tue, 16 Mar 2004 12:16:56 -0500 (EST) Received: from wmc-10.sce.carleton.ca (wmc-10.sce.carleton.ca [134.117.61.128]) by webmail.sce.carleton.ca (IMP) with HTTP for ; Tue, 16 Mar 2004 12:19:15 -0500 Message-ID: <1079457555.4057371329cd9@webmail.sce.carleton.ca> Date: Tue, 16 Mar 2004 12:19:15 -0500 To: manet@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 Content-Transfer-Encoding: 8bit Subject: [manet] the TSF timer in 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hello, The TSF timer in 802.11 is a 64 bits counter, and it ticks every microsecond. This timer if set to 0 will wrap-around in approx. 590.000 years! later. Obviously the designers didn't want it to wrap-around. My question is, how is this timer set initially ( to what value: 0?), when the beacons are sent the stations will set this timer to the APs timer value or to the larger value in an IBSS, but what is the value initially set for this timer when the product comes out of factory? or when it's turn on? is the value reset when the station is turn off and on? Thanks Carlos _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 16 13:45:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17891 for ; Tue, 16 Mar 2004 13:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3JYa-0001EN-5f for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 13:44:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GIiq3c004725 for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 13:44:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3JYa-0001E8-1Z for manet-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 13:44:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17854 for ; Tue, 16 Mar 2004 13:44:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3JYX-0003Cj-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 13:44:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3JXc-00035k-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 13:43:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3JWg-0002ya-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 13:42:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3JVp-0000se-9x; Tue, 16 Mar 2004 13:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3JVg-0000rt-KP for manet@optimus.ietf.org; Tue, 16 Mar 2004 13:41:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17577 for ; Tue, 16 Mar 2004 13:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3JVe-0002pG-00 for manet@ietf.org; Tue, 16 Mar 2004 13:41:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3JUm-0002gm-00 for manet@ietf.org; Tue, 16 Mar 2004 13:40:57 -0500 Received: from bareed3.maktoob.net ([195.172.126.104] helo=maktoobchat.net) by ietf-mx with esmtp (Exim 4.12) id 1B3JTs-0002Yq-00 for manet@ietf.org; Tue, 16 Mar 2004 13:40:00 -0500 Received: from [195.172.126.106] (HELO maktoobchat.net) by maktoobchat.net (CommuniGate Pro SMTP 4.1.6) with ESMTP id 12200383 for manet@ietf.org; Tue, 16 Mar 2004 18:43:07 +0000 Received: from [195.172.126.112] (HELO maktoob.com) by maktoobchat.net (CommuniGate Pro SMTP 4.1.6) with ESMTP id 13155945 for manet@ietf.org; Tue, 16 Mar 2004 18:25:01 +0000 From: "yazeed al-sbou" To: manet@ietf.org Comment: Maktoob By BOC X-Mailer: Maktoob 2.0 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)] X-Originating-IP: [143.52.2.200] MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 7bit Date: Tue, 16 Mar 2004 18:25:01 +0000 Message-ID: Content-Transfer-Encoding: 7bit Subject: [manet] Question about ECHO packets... 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=AWL,FORGED_MUA_MOZILLA autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all... Just I want to ask anout how can I measure the Round Trip Time (RTT) for a packet. Or, I want to transmit a packet via a network (wired or wireless) and generate an echo for that packet to be sent to the sender node to ensure that the packet is received to use this echo to measure the RTT for my network... I s there anyone have an idea about that? Thanks in advance.. YOURS.. Yazeed Ahamd Al-Sbou, Research Student School of Engineering Sheaf Building - Room 4311, Sheffield Hallam University,City Campus Sheiffield, S1 1WB Tel(university):+441142253254 Mobile 00447813402741 Yazeed.A.Al-Sbou@student.shu.ac.uk _________________________________________________ Only at Maktoob. Send your Arabic email without a need for an Arabic Operating System. http://www.maktoob.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 16 16:37:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26980 for ; Tue, 16 Mar 2004 16:37:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3MFP-0005WC-Ov for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 16:37:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GLbFqF021203 for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 16:37:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3MFP-0005Vp-Ci for manet-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 16:37:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26889 for ; Tue, 16 Mar 2004 16:37:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3MFN-0004gb-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 16:37:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3MEL-0004W2-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 16:36:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3MDT-0004PG-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 16:35:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3MDH-0005Ae-M7; Tue, 16 Mar 2004 16:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3MCI-000573-Ot for manet@optimus.ietf.org; Tue, 16 Mar 2004 16:34:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26661 for ; Tue, 16 Mar 2004 16:33:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3MCG-0004II-00 for manet@ietf.org; Tue, 16 Mar 2004 16:34:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3MBP-0004DO-00 for manet@ietf.org; Tue, 16 Mar 2004 16:33:08 -0500 Received: from che.ojctech.com ([209.254.133.74]) by ietf-mx with esmtp (Exim 4.12) id 1B3MAn-00045l-00 for manet@ietf.org; Tue, 16 Mar 2004 16:32:29 -0500 Received: from che.ojctech.com (localhost [127.0.0.1]) by che.ojctech.com (8.12.8/8.12.8) with ESMTP id i2GLVwRG002347 for ; Tue, 16 Mar 2004 15:31:58 -0600 Received: (from dyoung@localhost) by che.ojctech.com (8.12.8/8.12.8/Submit) id i2GLVw9k002345 for manet@ietf.org; Tue, 16 Mar 2004 15:31:58 -0600 Date: Tue, 16 Mar 2004 15:31:58 -0600 From: David Young To: manet@ietf.org Subject: Re: [manet] the TSF timer in 802.11 Message-ID: <20040316213158.GZ17009@che.ojctech.com> Mail-Followup-To: manet@ietf.org References: <1079457555.4057371329cd9@webmail.sce.carleton.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1079457555.4057371329cd9@webmail.sce.carleton.ca> User-Agent: Mutt/1.4.1i 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, Mar 16, 2004 at 12:19:15PM -0500, crentel@sce.carleton.ca wrote: > The TSF timer in 802.11 is a 64 bits counter, and it ticks every > microsecond. This timer if set to 0 will wrap-around in approx. 590.000 > years! later. Obviously the designers didn't want it to wrap-around. My > question is, how is this timer set initially ( to what value: 0?), > when the beacons are sent the > > stations will set this timer to the APs timer value or to the larger > value in an IBSS, but what is the value initially set for this timer > when the product comes out of factory? or when it's turn on? is the > value reset when the station is turn off and on? On the commonplace 802.11b chip by Realtek, the TSFT starts counting from zero. It is only necessary to turn the receive and/or transmit circuits off and on to reset the TSFT to zero. It is not unusual for a driver to turn those circuits off while it tunes a new channel. I think that you can count on the fact that the TSFT will not persist if you cycle power. I don't think any manufacturer could justify the cost of a persistent TSFT. 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 exim@www1.ietf.org Tue Mar 16 19:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09178 for ; Tue, 16 Mar 2004 19:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PLo-0000cl-Cg for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 19:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H0u4ca002399 for manet-archive@odin.ietf.org; Tue, 16 Mar 2004 19:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PLo-0000cc-5u for manet-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 19:56:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09145 for ; Tue, 16 Mar 2004 19:56:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PLm-000559-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 19:56:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PKo-0004ye-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 19:55:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3PK1-0004su-00 for manet-web-archive@ietf.org; Tue, 16 Mar 2004 19:54:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PJp-0000JR-9s; Tue, 16 Mar 2004 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3PIs-0000GU-L3 for manet@optimus.ietf.org; Tue, 16 Mar 2004 19:53:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09031 for ; Tue, 16 Mar 2004 19:53:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3PIq-0004lB-00 for manet@ietf.org; Tue, 16 Mar 2004 19:53:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3PHt-0004fD-00 for manet@ietf.org; Tue, 16 Mar 2004 19:52:02 -0500 Received: from bay16-f49.bay16.hotmail.com ([65.54.186.99] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B3PGy-0004UN-00 for manet@ietf.org; Tue, 16 Mar 2004 19:51:04 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Mar 2004 16:50:30 -0800 Received: from 61.187.56.10 by by16fd.bay16.hotmail.msn.com with HTTP; Wed, 17 Mar 2004 00:50:30 GMT X-Originating-IP: [61.187.56.10] X-Originating-Email: [zongmng@hotmail.com] X-Sender: zongmng@hotmail.com From: "Zong Ming" To: manet@ietf.org Subject: RE: [manet] Clustering Date: Wed, 17 Mar 2004 08:50:30 +0800 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed Message-ID: X-OriginalArrivalTime: 17 Mar 2004 00:50:30.0502 (UTC) FILETIME=[D8A8E860:01C40BB9] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA09032 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable =20 Thanks.It's helpful to me. Zong Ming _________________________________________________________________ =C3=E2=B7=D1=CF=C2=D4=D8 MSN Explorer: http://explorer.msn.com/lccn =20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 17 07:03:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02531 for ; Wed, 17 Mar 2004 07:03:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Zll-0003IE-SX for manet-archive@odin.ietf.org; Wed, 17 Mar 2004 07:03:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HC3Xhe012655 for manet-archive@odin.ietf.org; Wed, 17 Mar 2004 07:03:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Zll-0003I2-LW for manet-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 07:03:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02525 for ; Wed, 17 Mar 2004 07:03:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Zlh-0002B3-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 07:03:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Zkm-00024D-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 07:02:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3ZkQ-0001xR-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 07:02:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ZkH-0002q5-Mn; Wed, 17 Mar 2004 07:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Zjj-0002ib-I3 for manet@optimus.ietf.org; Wed, 17 Mar 2004 07:01:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02470 for ; Wed, 17 Mar 2004 07:01:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Zjf-0001vs-00 for manet@ietf.org; Wed, 17 Mar 2004 07:01:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Zil-0001pv-00 for manet@ietf.org; Wed, 17 Mar 2004 07:00:27 -0500 Received: from zeus.ruca.ua.ac.be ([143.129.201.210] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B3Zhu-0001kB-00 for manet@ietf.org; Wed, 17 Mar 2004 06:59:35 -0500 Received: from portinf25 (pcinf40.ruca.ua.ac.be [143.129.75.58]) by zeus.ruca.ua.ac.be (8.9.3 (PHNE_22672)/8.9.3) with SMTP id MAA15504 for ; Wed, 17 Mar 2004 12:59:29 +0100 (MET) Message-ID: <006201c40c17$50e6f170$0092fea9@portinf25> From: "Sylwia Van den Heuvel-Romaszko" To: Date: Wed, 17 Mar 2004 12:59:35 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C40C1F.B26CC9D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MailScanner-Information: Please contact the HelpDesk for more information X-MailScanner: Found to be clean Subject: [manet] MANETs mailing list 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C40C1F.B26CC9D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ---------------------------------------------------------------------- Sylwia Van den Heuvel-Romaszko University of Antwerp (UIA) Dept. Mathemathics and Computer Science Performance Analysis of Telecommunication Systems (PATS) Research Group Middelheimlaan 1 B-2020 Antwerp Belgium email: sylwia.romaszko@ua.ac.be url: http://win-www.ruca.ua.ac.be/u/pats ------=_NextPart_000_005F_01C40C1F.B26CC9D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
    ----------------------------------------------------------------= ------
    Sylwia=20 Van den Heuvel-Romaszko
    University of Antwerp (UIA)
    Dept. = Mathemathics and=20 Computer Science
    Performance Analysis of Telecommunication = Systems
    (PATS)=20 Research Group
    Middelheimlaan 1 B-2020 Antwerp
    Belgium
    email: = sylwia.romaszko@ua.ac.be
    = url: http://win-www.ruca.ua.ac.be= /u/pats
    ------=_NextPart_000_005F_01C40C1F.B26CC9D0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 17 09:50:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08816 for ; Wed, 17 Mar 2004 09:50:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cNL-0006Np-Hd for manet-archive@odin.ietf.org; Wed, 17 Mar 2004 09:50:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HEoVOL024536 for manet-archive@odin.ietf.org; Wed, 17 Mar 2004 09:50:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cNL-0006Nf-CS for manet-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 09:50:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08781 for ; Wed, 17 Mar 2004 09:50:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cNJ-00069L-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 09:50:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cMP-00060w-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 09:49:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3cLY-0005sx-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 09:48:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cKv-0005yV-PD; Wed, 17 Mar 2004 09:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3cKP-0005sg-KY for manet@optimus.ietf.org; Wed, 17 Mar 2004 09:47:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08542 for ; Wed, 17 Mar 2004 09:47:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3cKN-0005jz-00 for manet@ietf.org; Wed, 17 Mar 2004 09:47:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3cJO-0005ca-00 for manet@ietf.org; Wed, 17 Mar 2004 09:46:26 -0500 Received: from zeus.ruca.ua.ac.be ([143.129.201.210] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1B3cIS-0005Ur-00 for manet@ietf.org; Wed, 17 Mar 2004 09:45:29 -0500 Received: from portinf25 (pcinf40.ruca.ua.ac.be [143.129.75.58]) by zeus.ruca.ua.ac.be (8.9.3 (PHNE_22672)/8.9.3) with SMTP id PAA27402 for ; Wed, 17 Mar 2004 15:45:13 +0100 (MET) Message-ID: <007a01c40c2e$7836e930$3a4b818f@portinf25> From: "Sylwia Van den Heuvel-Romaszko" To: Subject: [manet] impact MAC layer - routing Date: Wed, 17 Mar 2004 15:45:19 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C40C36.D9C8CF80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MailScanner-Information: Please contact the HelpDesk for more information X-MailScanner: Found to be clean 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0077_01C40C36.D9C8CF80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all,=20 I search papers/links about an impact MAC protocols on routing = performance and vice versa. Thanks, Sylvieke=20 ---------------------------------------------------------------------- Sylwia Van den Heuvel-Romaszko University of Antwerp (UIA) Dept. Mathemathics and Computer Science Performance Analysis of Telecommunication Systems (PATS) Research Group Middelheimlaan 1 B-2020 Antwerp Belgium email: sylwia.romaszko@ua.ac.be url: http://win-www.ruca.ua.ac.be/u/pats ------=_NextPart_000_0077_01C40C36.D9C8CF80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
    Dear all,
     
    I search papers/links about an impact = MAC protocols=20 on routing performance and vice versa.
     
    Thanks,
    Sylvieke 
     
    ----------------------------------------------------------------= ------
    Sylwia=20 Van den Heuvel-Romaszko
    University of Antwerp (UIA)
    Dept. = Mathemathics and=20 Computer Science
    Performance Analysis of Telecommunication = Systems
    (PATS)=20 Research Group
    Middelheimlaan 1 B-2020 Antwerp
    Belgium
    email: = sylwia.romaszko@ua.ac.be
    = url: http://win-www.ruca.ua.ac.be= /u/pats
    ------=_NextPart_000_0077_01C40C36.D9C8CF80-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 17 17:08:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11317 for ; Wed, 17 Mar 2004 17:08:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3jCM-0000dY-80 for manet-archive@odin.ietf.org; Wed, 17 Mar 2004 17:07:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HM7cbe002447 for manet-archive@odin.ietf.org; Wed, 17 Mar 2004 17:07:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3jCL-0000d8-Nr for manet-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 17:07:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11186 for ; Wed, 17 Mar 2004 17:07:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3jCJ-0003Fm-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 17:07:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3jAE-0002jB-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 17:05:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3j7z-0002LU-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 17:03:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3j0y-00052Y-L4 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 16:55:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3j0R-000813-Ro; Wed, 17 Mar 2004 16:55:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3izx-00080E-TU for manet@optimus.ietf.org; Wed, 17 Mar 2004 16:54:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10601 for ; Wed, 17 Mar 2004 16:54:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3izv-0001NU-00 for manet@ietf.org; Wed, 17 Mar 2004 16:54:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3iz6-0001Go-00 for manet@ietf.org; Wed, 17 Mar 2004 16:53:57 -0500 Received: from adsl-67-123-116-138.dsl.sndg02.pacbell.net ([67.123.116.138] helo=srv-f8w.f8w.com) by ietf-mx with esmtp (Exim 4.12) id 1B3iyp-00019O-00 for manet@ietf.org; Wed, 17 Mar 2004 16:53:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40C6A.C5F40CE0" Date: Wed, 17 Mar 2004 13:57:00 -0800 Message-ID: <0007A02FF9664844AD8340E76E7029890903F5@srv-f8w.f8w.com> Thread-Topic: Question regarding IPR on AODV Thread-Index: AcQMasXxv4Tcn/bnRg28e8Z0L6GWAQ== From: "Don Sturek" To: Subject: [manet] Question regarding IPR on AODV 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C40C6A.C5F40CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a question regarding specific IPR on AODV (we are specifically = using AODV-Tiny). Could anyone provide a pointer to a summary of IPR on = AODV?=20 =20 Best Regards, Don Sturek=20 Chief Technical Officer=20 Figure 8 Wireless, Inc.=20 =20 10145 Pacific Heights Blvd., Suite 220=20 San Diego, CA 92121=20 USA=20 =20 Tel: +1-858-552-8500 Ext. 14=20 Mobile: +1-619-504-3615=20 Fax: +1-858-552-8501=20 E-mail: dsturek@f8w.com=20 =20 =20 =20 ------_=_NextPart_001_01C40C6A.C5F40CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    I have = a question=20 regarding specific IPR on AODV (we are specifically using = AODV-Tiny). =20 Could anyone provide a pointer to a summary of IPR on=20 AODV? 
     
    Best=20 Regards,

    Don Sturek
    Chief Technical Officer
    Figure 8=20 Wireless, Inc.
      =
    10145 Pacific Heights Blvd., Suite 220 =
    San Diego, CA  92121
    USA
      =
    Tel:         =20 +1-858-552-8500  Ext. 14
    Mobile:     +1-619-504-3615 =
    Fax:        =20 +1-858-552-8501
    E-mail:      dsturek@f8w.com =
     
     

     
    ------_=_NextPart_001_01C40C6A.C5F40CE0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 18 08:33:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09756 for ; Thu, 18 Mar 2004 08:33:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xeD-0005I5-6S for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 08:33:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IDXLPZ020336 for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 08:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xeD-0005Hv-20 for manet-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 08:33:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09721 for ; Thu, 18 Mar 2004 08:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xeB-0005Cj-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 08:33:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xdD-00054T-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 08:32:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3xcJ-0004wd-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 08:31:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xc0-0004xp-0d; Thu, 18 Mar 2004 08:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3xbW-0004wN-Bp for manet@optimus.ietf.org; Thu, 18 Mar 2004 08:30:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09589 for ; Thu, 18 Mar 2004 08:30:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3xbV-0004pP-00 for manet@ietf.org; Thu, 18 Mar 2004 08:30:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3xac-0004hK-00 for manet@ietf.org; Thu, 18 Mar 2004 08:29:38 -0500 Received: from [202.106.187.158] (helo=sina.com) by ietf-mx with smtp (Exim 4.12) id 1B3xZj-0004Y6-00 for manet@ietf.org; Thu, 18 Mar 2004 08:28:47 -0500 Received: (qmail 61494 invoked from network); 18 Mar 2004 13:28:14 -0000 Received: from unknown (HELO RavProxy) (218.2.242.171) by sina187-158.sina.com.cn with SMTP; 18 Mar 2004 13:28:14 -0000 Received: from(wht_slh_bao@sina.com) to(manet@ietf.org) Message-ID: <002d01c40cec$e7ceee50$0400a8c0@trust> From: "wht" To: Date: Thu, 18 Mar 2004 21:28:18 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C40D2F.EE2CBD70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] ABOUT CLUSTERING 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE, MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C40D2F.EE2CBD70 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VEhFUkUgQVJFIE1BTlkgUEFQRVJTIEFCT1VUIENMVVNURVJJTkcsIFVTRSBHT09HTEUsIFlPVSBD QU4gRklORCBBIExPVFMsIFdJU0ggVSBMVUNLLg0K ------=_NextPart_000_0025_01C40D2F.EE2CBD70 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yNjAwLjAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5USEVSRSBBUkUgTUFOWSBQQVBF UlMgQUJPVVQgQ0xVU1RFUklORywgVVNFIEdPT0dMRSwgWU9VIENBTiANCkZJTkQgQSBMT1RTLCBX SVNIIFUgTFVDSy48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0025_01C40D2F.EE2CBD70-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 18 13:46:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00043 for ; Thu, 18 Mar 2004 13:46:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42WP-0001bv-Ix for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 13:45:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IIjbCJ006187 for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 13:45:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42WP-0001bi-DG for manet-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 13:45:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00036 for ; Thu, 18 Mar 2004 13:45:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42WN-0002Mn-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 13:45:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42VT-0002Jy-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 13:44:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B42V6-0002Hi-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 13:44:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42Ur-0001N5-W4; Thu, 18 Mar 2004 13:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B42UO-0001M3-7e for manet@optimus.ietf.org; Thu, 18 Mar 2004 13:43:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29932 for ; Thu, 18 Mar 2004 13:43:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42UL-0002FH-00 for manet@ietf.org; Thu, 18 Mar 2004 13:43:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42TP-0002CQ-00 for manet@ietf.org; Thu, 18 Mar 2004 13:42:32 -0500 Received: from [203.199.83.148] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1B42Sh-00029n-00 for manet@ietf.org; Thu, 18 Mar 2004 13:41:47 -0500 Received: (qmail 5539 invoked by uid 510); 18 Mar 2004 18:41:39 -0000 Date: 18 Mar 2004 18:41:39 -0000 Message-ID: <20040318184139.5538.qmail@webmail26.rediffmail.com> Received: from unknown (202.9.164.13) by rediffmail.com via HTTP; 18 mar 2004 18:41:39 -0000 MIME-Version: 1.0 From: "kani mozhi" Reply-To: "kani mozhi" To: manet@ietf.org Content-type: multipart/alternative; boundary="Next_1079635299---0-203.199.83.148-5535" Subject: [manet] manet 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_20_30,HTML_IMAGE_ONLY_06,HTML_MESSAGE,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 This is a multipart mime message --Next_1079635299---0-203.199.83.148-5535 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

    =0Ahi
    =0Aiam working on intrusion detection and response for adhoc ne= tworks.
    =0A
    =0Awhat is the probability that a node will experience li= nk error when receiving and forwarding packets
    =0Ai need this to set a t= hreshold value such that it mitigates the link error=0A

    =0A

    =0A=0A --Next_1079635299---0-203.199.83.148-5535 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi=0Aiam working on intrusion detection and response for adhoc networks.=0A= =0Awhat is the probability that a node will experience link error when rece= iving and forwarding packets=0Ai need this to set a threshold value such th= at it mitigates the link error --Next_1079635299---0-203.199.83.148-5535-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 18 14:22:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01802 for ; Thu, 18 Mar 2004 14:22:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B435V-000463-Ln for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 14:21:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IJLr9P015741 for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 14:21:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B435V-00045o-EW for manet-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 14:21:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01795 for ; Thu, 18 Mar 2004 14:21:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B435S-0004am-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 14:21:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B434Y-0004WE-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 14:20:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B433p-0004Rq-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 14:20:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B433i-0003k9-Bf; Thu, 18 Mar 2004 14:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B433B-0003it-Pj for manet@optimus.ietf.org; Thu, 18 Mar 2004 14:19:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01644 for ; Thu, 18 Mar 2004 14:19:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4339-0004MR-00 for manet@ietf.org; Thu, 18 Mar 2004 14:19:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B432A-0004HN-00 for manet@ietf.org; Thu, 18 Mar 2004 14:18:27 -0500 Received: from nestor.nmsu.edu ([128.123.34.146] helo=mail.nmsu.edu) by ietf-mx with esmtp (Exim 4.12) id 1B431C-0004Bw-00 for manet@ietf.org; Thu, 18 Mar 2004 14:17:26 -0500 Received: from PCMullen2 (pc-mullen-2.NMSU.Edu [128.123.245.103]) by mail.nmsu.edu (Postfix) with ESMTP id 6372C2023; Thu, 18 Mar 2004 12:17:18 -0700 (MST) From: "John Mullen" To: "'kani mozhi'" , Subject: RE: [manet] manet Date: Thu, 18 Mar 2004 12:17:18 -0700 Message-ID: <006901c40d1d$a1560b80$67f57b80@IEngr.ad.nmsu.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01C40CE2.F4F73380" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20040318184139.5538.qmail@webmail26.rediffmail.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_006A_01C40CE2.F4F73380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The answer to your question depends primarily on 1) average received signal-to-noise ratio, 2) waveform and encoding, 3) shadowing, 4) fading, and 5) packet size. Average received radio S/N itself depends mainly on frequency, the composition of the environment, terrain, antenna gain and distance. Other factors include decisions made at the MAC and link levels on what constitutes a reliable link. Given the RF complexity of a typical MANET manifestation, these parameters will differ from place to place. As a result, you will need some sort of adaptive rule. John Mullen -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of kani mozhi Sent: Thursday, March 18, 2004 11:42 AM To: manet@ietf.org Subject: [manet] manet hi iam working on intrusion detection and response for adhoc networks. what is the probability that a node will experience link error when receiving and forwarding packets i need this to set a threshold value such that it mitigates the link error ------=_NextPart_000_006A_01C40CE2.F4F73380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
    Hi,
     
    The=20 answer to your question = depends=20 primarily on 1) average received signal-to-noise ratio, 2) waveform and=20 encoding, 3) shadowing, 4) fading, and 5) packet size.  = Average=20 received radio S/N itself depends mainly on frequency, the composition = of the=20 environment, terrain, antenna gain and distance. Other factors include decisions made at the = MAC and=20 link levels on what constitutes a reliable link.  Given the = RF=20 complexity of a typical MANET manifestation, these parameters will = differ from=20 place to place.  As a result, you will need some sort of adaptive=20 rule.
     
    John=20 Mullen
    -----Original Message-----
    From:=20 manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of = kani=20 mozhi
    Sent: Thursday, March 18, 2004 11:42 AM
    To:=20 manet@ietf.org
    Subject: [manet] manet

    hi
    iam working on intrusion detection and response for adhoc=20 networks.

    what is the probability that a node will experience = link=20 error when receiving and forwarding packets
    i need this to set a = threshold=20 value such that it mitigates the link error



    ------=_NextPart_000_006A_01C40CE2.F4F73380-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 18 15:16:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05684 for ; Thu, 18 Mar 2004 15:16:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43vS-0007G7-QM for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 15:15:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IKFY3D027902 for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 15:15:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43vS-0007Fv-EH for manet-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 15:15:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05614 for ; Thu, 18 Mar 2004 15:15:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B43vR-0000Qe-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 15:15:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B43ua-0000Nn-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 15:14:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B43tg-0000Le-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 15:13:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43tB-00065R-Db; Thu, 18 Mar 2004 15:13:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B43sa-0005vT-68 for manet@optimus.ietf.org; Thu, 18 Mar 2004 15:12:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05301 for ; Thu, 18 Mar 2004 15:12:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B43sY-0000HQ-00 for manet@ietf.org; Thu, 18 Mar 2004 15:12:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B43rc-0000F7-00 for manet@ietf.org; Thu, 18 Mar 2004 15:11:37 -0500 Received: from cecom6.monmouth.army.mil ([134.80.0.9]) by ietf-mx with esmtp (Exim 4.12) id 1B43qt-0000Aq-00 for manet@ietf.org; Thu, 18 Mar 2004 15:10:51 -0500 Received: from mailsw2.monmouth.army.mil (mailsw2.monmouth.army.mil [134.80.5.41]) by cecom6.monmouth.army.mil (8.12.11/8.12.11) with ESMTP id i2IKAJdw011151 for ; Thu, 18 Mar 2004 15:10:19 -0500 (EST) Received: from SWGM6.monmouth.army.mil (unverified) by mailsw2.monmouth.army.mil (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Thu, 18 Mar 2004 15:10:19 -0500 Received: by SWGM6.monmouth.army.mil with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Mar 2004 15:10:19 -0500 Message-ID: <33120BB62E0A7643AE75E2B03CA0EDA0351F19@mail7.monmouth.army.mil> From: "Green, David B RDECOM CERDEC STCD SRI" To: "'manet@ietf.org'" Subject: RE: : [manet] manet Date: Thu, 18 Mar 2004 15:10:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Kani, Your wireless system should decide at the PHY and MAC layer what constitutes a good packet. There is a minimum receive threshold in the physical layer - you can't receive a signal below that signal to noise ratio. Also, the MAC layer generally institutes a checksum on frames to ensure they are not damaged. Generally anything that gets up above that gets handed to upper layers. You may be able to tap into some neighbor information from layer 1-2 (you can in many WLANs) to see the relative signal strength from a neighbor and determine if that neighbor is marginal or is fading out so you can pro-actively avoid link failure. Some experimental MANET protocols implement such a system when assigning link weights to relays. The "forward handoff" in cellular systems uses the same principle. David B. Green SRI International RE: [manet] manet * To: "'kani mozhi'" >, > * Subject: RE: [manet] manet * From: "John Mullen" > * Date: Thu, 18 Mar 2004 12:17:18 -0700 * Importance: Normal * In-reply-to: <20040318184139.5538.qmail@webmail26.rediffmail.com > * List-help: <> * List-id: Mobile Ad-hoc Networks * List-post: <> * List-subscribe: <>,<> * List-unsubscribe: <>,<> * Sender: manet-admin at ietf.org Title: Message Hi, The answer to your question depends primarily on 1) average received signal-to-noise ratio, 2) waveform and encoding, 3) shadowing, 4) fading, and 5) packet size. Average received radio S/N itself depends mainly on frequency, the composition of the environment, terrain, antenna gain and distance. Other factors include decisions made at the MAC and link levels on what constitutes a reliable link. Given the RF complexity of a typical MANET manifestation, these parameters will differ from place to place. As a result, you will need some sort of adaptive rule. John Mullen -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of kani mozhi Sent: Thursday, March 18, 2004 11:42 AM To: manet@ietf.org Subject: [manet] manet hi iam working on intrusion detection and response for adhoc networks. what is the probability that a node will experience link error when receiving and forwarding packets i need this to set a threshold value such that it mitigates the link error * References: * [manet] manet * From: kani mozhi * Prev by Date: [manet] manet * Previous by thread: [manet] manet * Next by thread: =?Big5?B?rV67ebt7w9K7ULROt36odKZDwb+ueQ==?= * Index(es): * Date * Thread _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 18 15:44:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07768 for ; Thu, 18 Mar 2004 15:44:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44Mv-0003xc-VQ for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 15:43:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IKhvoP015223 for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 15:43:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44Mv-0003xS-QW for manet-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 15:43:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07717 for ; Thu, 18 Mar 2004 15:43:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B44Mu-0002PR-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 15:43:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B44Lt-0002HV-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 15:42:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B44Kq-0002Bn-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 15:41:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44K7-0003J2-63; Thu, 18 Mar 2004 15:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B44Jc-00039H-5P for manet@optimus.ietf.org; Thu, 18 Mar 2004 15:40:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07452 for ; Thu, 18 Mar 2004 15:40:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B44Ja-00025U-00 for manet@ietf.org; Thu, 18 Mar 2004 15:40:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B44Ih-00022D-00 for manet@ietf.org; Thu, 18 Mar 2004 15:39:35 -0500 Received: from cecom6.monmouth.army.mil ([134.80.0.9]) by ietf-mx with esmtp (Exim 4.12) id 1B44Hv-0001wF-00 for manet@ietf.org; Thu, 18 Mar 2004 15:38:47 -0500 Received: from mailsw2.monmouth.army.mil (mailsw2.monmouth.army.mil [134.80.5.41]) by cecom6.monmouth.army.mil (8.12.11/8.12.11) with ESMTP id i2IKcGo4014291 for ; Thu, 18 Mar 2004 15:38:16 -0500 (EST) Received: from SWGM6.monmouth.army.mil (unverified) by mailsw2.monmouth.army.mil (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Thu, 18 Mar 2004 15:38:16 -0500 Received: by SWGM6.monmouth.army.mil with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Mar 2004 15:38:16 -0500 Message-ID: <33120BB62E0A7643AE75E2B03CA0EDA0351F1C@mail7.monmouth.army.mil> From: "Green, David B RDECOM CERDEC STCD SRI" To: "'manet@ietf.org'" Date: Thu, 18 Mar 2004 15:38:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] Multipoint ROHC for MANET 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Has anyone in the group worked on a schema for point to multipoint robust header compression suitable for broadcast and multicast links in MANETs? The base spec for RObust Header Compression (RFC 3095 "ROHC") only seems to consider point to point links for cellular systems. I'm proposing the work in the ROHC group, but want to consider any expertise from the MANET group that might be helpful since this will be "MANET" header compression in our ultimate application on a MANET style radio. David B. Green SRI International Myer Ctr Rm 4D305 desk (732) 532-6715 cell (732) 693-6500 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 18 17:00:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11142 for ; Thu, 18 Mar 2004 17:00:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45YL-0000fa-QH for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 16:59:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ILxnWg002574 for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 16:59:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45YL-0000fR-AI for manet-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 16:59:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11108 for ; Thu, 18 Mar 2004 16:59:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B45YI-0000Nl-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 16:59:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B45XO-0000KZ-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 16:58:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B45X2-0000Gw-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 16:58:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45Wd-0000UO-7M; Thu, 18 Mar 2004 16:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B45WQ-0000Rq-3X for manet@optimus.ietf.org; Thu, 18 Mar 2004 16:57:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11027 for ; Thu, 18 Mar 2004 16:57:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B45WN-0000GG-00 for manet@ietf.org; Thu, 18 Mar 2004 16:57:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B45VS-0000DH-00 for manet@ietf.org; Thu, 18 Mar 2004 16:56:51 -0500 Received: from web61105.mail.yahoo.com ([216.155.196.107]) by ietf-mx with smtp (Exim 4.12) id 1B45V1-000098-00 for manet@ietf.org; Thu, 18 Mar 2004 16:56:23 -0500 Message-ID: <20040318215409.14035.qmail@web61105.mail.yahoo.com> Received: from [141.156.71.10] by web61105.mail.yahoo.com via HTTP; Thu, 18 Mar 2004 13:54:09 PST Date: Thu, 18 Mar 2004 13:54:09 -0800 (PST) From: manet user To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1844568698-1079646849=:13523" Subject: [manet] OLSR packet format implementation 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1844568698-1079646849=:13523 Content-Type: text/plain; charset=us-ascii Hi, I am trying to implement OLSR and have couple of questions regarding OLSR packet format. OLSR packet contain "Packet Length" and "Packet Seq Num" and after that there can be multiple messages (for e.g. 1 Hello, 1 TC). 1) Since Hello and TC messages are periodically sent, each having its own timer expiry. When will a condition happen that OLSR packet contains more than one message type ? Also, if an OLSR packet has 1 hello and 1 TC, where TC needs to be forwarded, will receiving node create a new TC extracting information from the received packet ? 2) When a node receives an OLSR packet, it will loop through each message type and process it accordingly. It will keep on adding "Message Size" from each message processed till it becomes equal to the "Packet Length". Can this be one of the right ways of processing an OLSR packet? Your comments will be a great help. Thanks in advance. -MU Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam --0-1844568698-1079646849=:13523 Content-Type: text/html; charset=us-ascii
    Hi,
     
    I am trying to implement OLSR and have couple of questions regarding OLSR packet format. OLSR packet contain "Packet Length" and "Packet Seq Num" and after that there can be multiple messages (for e.g. 1 Hello, 1 TC).
     
    1) Since Hello and TC messages are periodically sent, each having its own timer expiry. When will a condition happen that OLSR packet contains more than one message type ? Also, if an OLSR packet has 1 hello and 1 TC,  where TC needs to be forwarded, will receiving node create a new TC extracting information from the received packet ?
     
    2) When a node receives an OLSR packet, it will loop through each message type and process it accordingly. It will keep on adding "Message Size" from each message processed till it becomes equal to the "Packet Length". Can this be one of the right ways of processing an OLSR packet?
     
    Your comments will be a great help. Thanks in advance.
     
    -MU

    Do you Yahoo!?
    Yahoo! Mail - More reliable, more storage, less spam --0-1844568698-1079646849=:13523-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 18 20:55:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22729 for ; Thu, 18 Mar 2004 20:55:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49Dq-0005hV-Ol for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 20:54:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J1ssYs021913 for manet-archive@odin.ietf.org; Thu, 18 Mar 2004 20:54:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49Dq-0005hM-Is for manet-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 20:54:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22725 for ; Thu, 18 Mar 2004 20:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B49Dn-0000zK-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 20:54:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B49Cu-0000vj-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 20:53:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B49CN-0000rn-00 for manet-web-archive@ietf.org; Thu, 18 Mar 2004 20:53:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49C1-0005Us-LI; Thu, 18 Mar 2004 20:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B49Bl-0005TU-J3 for manet@optimus.ietf.org; Thu, 18 Mar 2004 20:52:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22655 for ; Thu, 18 Mar 2004 20:52:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B49Bj-0000pw-00 for manet@ietf.org; Thu, 18 Mar 2004 20:52:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B49Aq-0000mq-00 for manet@ietf.org; Thu, 18 Mar 2004 20:51:48 -0500 Received: from web40207.mail.yahoo.com ([66.218.78.68]) by ietf-mx with smtp (Exim 4.12) id 1B499s-0000gq-00 for manet@ietf.org; Thu, 18 Mar 2004 20:50:49 -0500 Message-ID: <20040319015019.6704.qmail@web40207.mail.yahoo.com> Received: from [61.2.240.43] by web40207.mail.yahoo.com via HTTP; Thu, 18 Mar 2004 17:50:19 PST Date: Thu, 18 Mar 2004 17:50:19 -0800 (PST) From: mayur raghuveer To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-853710022-1079661019=:4648" Subject: [manet] Which simulator? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --0-853710022-1079661019=:4648 Content-Type: text/plain; charset=us-ascii Hello everyone, I am a new member to this group.I am a student who has become very interested in MANETS.I am looking at various papers on the net to get idea about manets but i thought this was too very tedious so is there any focused approach i can follow to learn more about manets and the latest research going on in manets.Also i was looking at the various simulators,i found many like glomosim,ns-2,opnet,etc .. how do i choose a simulator?What factors do i look before choosing one?Please bear with me for asking such trivial questions but i had to start somewhere. Mayur Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam --0-853710022-1079661019=:4648 Content-Type: text/html; charset=us-ascii

    Hello everyone,
     
                       I am a new member to this group.I am a student who has become very interested in MANETS.I am looking at various papers on the net to get idea about manets but i thought this was too very tedious so is there any focused approach i can follow to learn more about manets and the latest research going on in manets.Also i was looking at the various simulators,i found many like glomosim,ns-2,opnet,etc .. how do i choose a simulator?What factors do i look before choosing one?Please bear with me for asking such trivial questions but i had to start somewhere.
     
    Mayur

    Do you Yahoo!?
    Yahoo! Mail - More reliable, more storage, less spam --0-853710022-1079661019=:4648-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 19 00:50:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02561 for ; Fri, 19 Mar 2004 00:50:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4CtL-0003RB-Gs for manet-archive@odin.ietf.org; Fri, 19 Mar 2004 00:49:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J5nx0F013214 for manet-archive@odin.ietf.org; Fri, 19 Mar 2004 00:49:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4CtL-0003R3-AW for manet-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 00:49:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02545 for ; Fri, 19 Mar 2004 00:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4CtI-0002xF-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 00:49:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4CsL-0002rr-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 00:48:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4Crf-0002oC-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 00:48:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4CrR-00038X-OS; Fri, 19 Mar 2004 00:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4CrH-000377-TZ for manet@optimus.ietf.org; Fri, 19 Mar 2004 00:47:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02436 for ; Fri, 19 Mar 2004 00:47:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4CrF-0002ls-00 for manet@ietf.org; Fri, 19 Mar 2004 00:47:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4CqI-0002hG-00 for manet@ietf.org; Fri, 19 Mar 2004 00:46:50 -0500 Received: from web41308.mail.yahoo.com ([66.218.93.57]) by ietf-mx with smtp (Exim 4.12) id 1B4CpV-0002bJ-00 for manet@ietf.org; Fri, 19 Mar 2004 00:46:01 -0500 Message-ID: <20040319054531.86565.qmail@web41308.mail.yahoo.com> Received: from [24.49.97.31] by web41308.mail.yahoo.com via HTTP; Thu, 18 Mar 2004 21:45:31 PST Date: Thu, 18 Mar 2004 21:45:31 -0800 (PST) From: Sochi K To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-223117408-1079675131=:84123" Subject: [manet] Glomosim ODMRP simulation 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS,HTML_MESSAGE autolearn=no version=2.60 --0-223117408-1079675131=:84123 Content-Type: text/plain; charset=us-ascii Hi, I found this while tracking the formation of forwarding groups in ODMRP. I was wondering if anybody else has found the same and have a solution to this. I use a simple simulation scenario, such as 10 nodes, in a 1000 x 1000 area. Assume that node 0 is the source and some node 3-4 hops away is the intended receiver for the multicast packets. While trying to trace the formation of forwarding groups, I realized that the forwarding group flag was never being set. What is actually happening is that the join reply, although being created at the receiver node - and supposedly sent to the mac layer to be broadcasted - is never being broadcasted to the other nodes, thus no forwarding groups formation is taking place. The join reply at the receiver node is being relayed by using the method NetworkIpSendRawGlomoMessageToMacLayer( node, newMsg, lastAddr, CONTROL, IPPROTO_ODMRP, 1, DEFAULT_INTERFACE, ANY_DEST); This is called from the method: RoutingOdmrpSendReply in odmrp.pc. This should send the join reply to the neighbors of the receiver node toward the source, setting the forwarding group flags along the way. >From my understanding of this code, any packet upon broadcast by the mac layer would be received by the method RoutingOdmrpRouterFunction in odmrp.pc, which would determine whether it is a data packet or a control packet, done by the following comparison: ipHeader->ip_p == IPPROTO_ODMRP. Thus, if a Join Reply is received by a node, it will have this ipHeader->ip_p field value set as 145 (for odmrp). I find that all the packets which are handled by this function have ipHeader->ip_p = 17, that is, are data packets. None of them have this field set as 145. Hence, since no join replies are ever received, no forwarding groups etc. are formed. My guess is something is amiss in the header value settings in the join reply formation. I have not altered the ODMRP code that came with Glomosim. I'm not very familiar with the mac layer code in glomosim, so if anyone could please suggest something that might be missing in the code or an error in my findings, it would be appreciated. Thanks. Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam --0-223117408-1079675131=:84123 Content-Type: text/html; charset=us-ascii

     
    Hi, I found this while tracking the formation of forwarding groups in ODMRP. I was wondering if anybody else has found the same and have a solution to this.
     
    I use a simple simulation scenario, such as 10 nodes, in a 1000 x 1000 area. Assume that node 0 is the source and some node 3-4 hops away is the intended receiver for the multicast packets. While trying to trace the formation of forwarding groups, I realized that the forwarding group flag was never being set. What is actually happening is that the join reply, although being created at the receiver node - and supposedly sent to the mac layer to be broadcasted - is never being broadcasted to the other nodes, thus no forwarding groups formation is taking place.
     
    The join reply at the receiver node is being relayed by using the method
     NetworkIpSendRawGlomoMessageToMacLayer(
                            node, newMsg, lastAddr, CONTROL, IPPROTO_ODMRP, 1,
                            DEFAULT_INTERFACE, ANY_DEST);
     
    This is called from the method: RoutingOdmrpSendReply in odmrp.pc. This should send the join reply to the neighbors of the receiver node toward the source, setting the forwarding group flags along the way.
     
    From my understanding of this code, any packet upon broadcast by the mac layer would be received by the method RoutingOdmrpRouterFunction in odmrp.pc, which would determine whether it is a data packet or a control packet, done by  the following comparison:
     
    ipHeader->ip_p == IPPROTO_ODMRP.
     
    Thus, if a Join Reply is received by a node, it will have this ipHeader->ip_p field value set as 145 (for odmrp). I find that all the packets which are handled by this function have ipHeader->ip_p = 17, that is, are data packets. None of them have this field set as 145. Hence, since no join replies are ever received, no forwarding groups etc. are formed. My guess is something is amiss in the header value settings in the join reply formation. I have not altered the ODMRP code that came with Glomosim.
     
    I'm not very familiar with the mac layer code in glomosim, so if anyone could please suggest something that might be missing in the code or an error in my findings, it would be appreciated.
     
    Thanks.
     
     

    Do you Yahoo!?
    Yahoo! Mail - More reliable, more storage, less spam --0-223117408-1079675131=:84123-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 19 16:26:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24185 for ; Fri, 19 Mar 2004 16:26:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RUi-0000sO-Lv for manet-archive@odin.ietf.org; Fri, 19 Mar 2004 16:25:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JLPWPO003352 for manet-archive@odin.ietf.org; Fri, 19 Mar 2004 16:25:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RUi-0000rx-EZ for manet-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 16:25:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24129 for ; Fri, 19 Mar 2004 16:25:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4RUg-00045r-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 16:25:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RTA-0003jp-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 16:23:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4RRa-0003N2-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 16:22:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RRL-0000U0-If; Fri, 19 Mar 2004 16:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RR9-0000TM-8u for manet@optimus.ietf.org; Fri, 19 Mar 2004 16:21:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23634 for ; Fri, 19 Mar 2004 16:21:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4RR7-0003GR-00 for manet@ietf.org; Fri, 19 Mar 2004 16:21:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RPK-0002un-00 for manet@ietf.org; Fri, 19 Mar 2004 16:19:59 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B4ROS-0002ix-00 for manet@ietf.org; Fri, 19 Mar 2004 16:19:05 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2JLIN708563; Fri, 19 Mar 2004 13:18:23 -0800 X-mProtect: <200403192118> Nokia Silicon Valley Messaging Protection Received: from ftemplin.iprg.nokia.com (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrKqcGn; Fri, 19 Mar 2004 13:18:22 PST Message-ID: <405B63A7.4010805@iprg.nokia.com> Date: Fri, 19 Mar 2004 13:18:31 -0800 From: Fred 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: Francois.PAUL@fr.thalesgroup.com CC: Dave.B.Green@us.army.mil, manet@ietf.org Subject: Re: [manet] Multipoint ROHC for MANET References: <66CE949D18BCB249ABE8D9AF48C4F1CE2D48A3@helios.clb.tcfr.thales> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I proposed some work on IPv6 header compression for the same sorts of radio links Dave is referring to back in the 1998 timeframe, and I know others had been thinking about the subject since well before that time also. The proposal was never funded, but the subject has been well covered by others and remains particularly important for low-bandwidth radio links given the uncomfortably large overhead for 40+ byte IPv6 headers. Fred ftemplin@iprg.nokia.com Francois.PAUL@fr.thalesgroup.com wrote: >ROHC offers several "modes" of operation. The mode called "unidirectional" >(see RFC 3095 ' 4.4.1) does not require any "return path", and therefore >seems well suited to your point to multipoint scheme. >Nevertheless there is a drawback : as there is no return path, this mode is >less robust than the other ones ... > >Frangois PAUL > >-----Message d'origine----- >De : Green, David B RDECOM CERDEC STCD SRI >[mailto:Dave.B.Green@us.army.mil] >Envoyi : jeudi 18 mars 2004 21:38 >@ : 'manet@ietf.org' >Objet : [manet] Multipoint ROHC for MANET > > >Has anyone in the group worked on a schema for point to multipoint robust >header compression >suitable for broadcast and multicast links in MANETs? The base spec for >RObust Header Compression >(RFC 3095 "ROHC") only seems to consider point to point links for cellular >systems. I'm >proposing the work in the ROHC group, but want to consider any expertise >from the MANET group >that might be helpful since this will be "MANET" header compression in our >ultimate application >on a MANET style radio. > >David B. Green >SRI International >Myer Ctr Rm 4D305 >desk (732) 532-6715 >cell (732) 693-6500 > > > >_______________________________________________ >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 exim@www1.ietf.org Fri Mar 19 16:44:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25971 for ; Fri, 19 Mar 2004 16:44:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RmI-000309-Jo for manet-archive@odin.ietf.org; Fri, 19 Mar 2004 16:43:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2JLhglK011531 for manet-archive@odin.ietf.org; Fri, 19 Mar 2004 16:43:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4RmI-0002zu-Fg for manet-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 16:43:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25819 for ; Fri, 19 Mar 2004 16:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4RmG-0006Pz-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 16:43:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4RlJ-0006Dz-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 16:42:42 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4RkW-00066R-02 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 16:41:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4RiD-00081G-4C for manet-web-archive@ietf.org; Fri, 19 Mar 2004 16:39:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Rhn-0002YO-JO; Fri, 19 Mar 2004 16:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4Rh9-0002VK-6t for manet@optimus.ietf.org; Fri, 19 Mar 2004 16:38:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25686 for ; Fri, 19 Mar 2004 16:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4Rh7-0005qT-00 for manet@ietf.org; Fri, 19 Mar 2004 16:38:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4Rg9-0005md-00 for manet@ietf.org; Fri, 19 Mar 2004 16:37:22 -0500 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 1B4RfM-0005dn-00 for manet@ietf.org; Fri, 19 Mar 2004 16:36:32 -0500 Received: from SRCATL-MTA by mail.scires.com with Novell_GroupWise; Fri, 19 Mar 2004 16:33:39 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Fri, 19 Mar 2004 16:33:28 -0500 From: "Pete Sholander" To: , Cc: , Subject: Re: [manet] Multipoint ROHC for MANET Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hey! Could a "return path" be supplied a link-quality estimator associated with = the neighbor discovery process of ?.= That would allow you to adjust the soft-state header refresh interval -- = if you were using RFC 2507 style header compression. --Pete Sholander Atlanta, GA >>> Fred Templin 03/19/04 04:18PM >>> I proposed some work on IPv6 header compression for the same sorts of radio links Dave is referring to back in the 1998 timeframe, and I know others had been thinking about the subject since well before that time also. The proposal was never funded, but the subject has been well covered by others and remains particularly important for low-bandwidth radio links given the uncomfortably large overhead for 40+ byte IPv6 headers. Fred ftemplin@iprg.nokia.com=20 Francois.PAUL@fr.thalesgroup.com wrote: >ROHC offers several "modes" of operation. The mode called "unidirectional"= >(see RFC 3095 ' 4.4.1) does not require any "return path", and therefore >seems well suited to your point to multipoint scheme. >Nevertheless there is a drawback : as there is no return path, this mode = is >less robust than the other ones ... > >Frangois PAUL > >-----Message d'origine----- >De : Green, David B RDECOM CERDEC STCD SRI >[mailto:Dave.B.Green@us.army.mil]=20 >Envoyi : jeudi 18 mars 2004 21:38 >@ : 'manet@ietf.org'=20 >Objet : [manet] Multipoint ROHC for MANET > > >Has anyone in the group worked on a schema for point to multipoint robust >header compression=20 >suitable for broadcast and multicast links in MANETs? The base spec for >RObust Header Compression=20 >(RFC 3095 "ROHC") only seems to consider point to point links for = cellular >systems. I'm=20 >proposing the work in the ROHC group, but want to consider any expertise >from the MANET group >that might be helpful since this will be "MANET" header compression in = our >ultimate application=20 >on a MANET style radio.=20 > >David B. Green >SRI International >Myer Ctr Rm 4D305 >desk (732) 532-6715 >cell (732) 693-6500 > > > >_______________________________________________ >manet mailing list >manet@ietf.org=20 >https://www1.ietf.org/mailman/listinfo/manet=20 > >_______________________________________________ >manet mailing list >manet@ietf.org=20 >https://www1.ietf.org/mailman/listinfo/manet=20 > =20 > _______________________________________________ manet mailing list manet@ietf.org=20 https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Mar 20 00:47:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13870 for ; Sat, 20 Mar 2004 00:47:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZJk-0001kp-B1 for manet-archive@odin.ietf.org; Sat, 20 Mar 2004 00:46:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2K5kioL006737 for manet-archive@odin.ietf.org; Sat, 20 Mar 2004 00:46:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZJk-0001ka-5G for manet-web-archive@optimus.ietf.org; Sat, 20 Mar 2004 00:46:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13852 for ; Sat, 20 Mar 2004 00:46:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4ZJh-0005uY-00 for manet-web-archive@ietf.org; Sat, 20 Mar 2004 00:46:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ZIk-0005pR-00 for manet-web-archive@ietf.org; Sat, 20 Mar 2004 00:45:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4ZIJ-0005kJ-00 for manet-web-archive@ietf.org; Sat, 20 Mar 2004 00:45:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZI6-0001Pk-22; Sat, 20 Mar 2004 00:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4ZHh-0001Ne-Pt for manet@optimus.ietf.org; Sat, 20 Mar 2004 00:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13811 for ; Sat, 20 Mar 2004 00:44:33 -0500 (EST) From: Duc.Tran@notes.udayton.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4ZHe-0005jW-00 for manet@ietf.org; Sat, 20 Mar 2004 00:44:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ZGl-0005fb-00 for manet@ietf.org; Sat, 20 Mar 2004 00:43:41 -0500 Received: from facstaff03.udayton.edu ([131.238.75.127]) by ietf-mx with esmtp (Exim 4.12) id 1B4ZGY-0005bH-00 for manet@ietf.org; Sat, 20 Mar 2004 00:43:26 -0500 In-Reply-To: To: P2P@LISTSERV.UTK.EDU Cc: manet@ietf.org, tccc@cs.columbia.edu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 Message-ID: Date: Sat, 20 Mar 2004 00:43:24 -0500 X-MIMETrack: Serialize by Router on FacStaff03/SVR/UDayton(Release 6.0.3|September 26, 2003) at 03/20/2004 12:43:28 AM, Serialize complete at 03/20/2004 12:43:28 AM Content-Type: multipart/alternative; boundary="=_alternative 001F9F0685256E5D_=" Subject: [manet] CFP: Journal of Wireless and Mobile Computing 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 001F9F0685256E5D_= Content-Type: text/plain; charset="US-ASCII" CALL FOR PAPERS Special Issue on Group Communications in Ad hoc Networks International Journal of Wireless and Mobile Computing (IJWMC) http://academic.udayton.edu/DucTran/research/cfpIJWMC.htm ISSN (PRINT): 1741-1084 ISSN (ONLINE): 1741-1092 Published by Inderscience Publishers Important Dates Manuscript submission deadline: June 10th, 2004 Notification due date: September 10th, 2004 Camera-ready manuscript due date: November 1st, 2004 Publication: Issue 3, 2005 Guest Editors Dr. Duc A. Tran (duc.tran@notes.udayton.edu) Department of Computer Science 300 College Park Dayton, OH 45429 Dr. Deb A. Agarwal (daagarwal@lbl.gov) Lawrence Berkeley National Laboratory 1 Cyclotron Road, MS 50B-2239 Berkeley, CA 94720 Dr. Mark D. Yarvis (mark.d.yarvis@intel.com) Intel Research and Development Intel Corporation, JF3-206 2111 N.E. 25th Ave. Hillsboro, OR 97124-5961 Subject Coverage Since people frequently work beyond their office desk, it is expected that the next generation of communication networks will include rapid deployments of independent mobile users. With the emergence of wireless technologies such as IEEE 802.11 and Bluetooth, mobile users are enabled to connect to each other directly and wirelessly without any networking infrastructure, such as the Internet or infrastructure-based wireless networks. Instead, users form mobile ad hoc networks (MANET). These networks are self-configurable and self-healable, and therefore easily adopted in a home environment and more cheaply deployed and maintained in a business environment. While ad hoc networks are rapidly gaining in popularity, group communication technologies have already shown their importance in education, entertainment, business, military, and other industries. However, thus far those technologies have mainly been designed for use in the Internet. This special journal issue is focused on development of group communication solutions in ad hoc networks. This work is significant to many interesting applications. Examples are strategic collaboration among soldiers in a battlefield, collaborative data processing such as tracking and localization in sensor networks, collaborative intrusion detection among a group of distant surveillance cameras, to name just a few. Also relevant to ad hoc networks is the concept of peer-to-peer (P2P). P2P networks are commonly used in the Internet to enable services that leverage a collection of peer nodes rather than a single infrastructure server, making them resilient to the failure of an individual node. These properties are attractive for applications deployed in ad hoc wireless networks, which have similar requirements. Research on group communications in ad hoc networks is still in its infancy. There are many open issues due to the deviation between resource, energy, and bandwidth availability of ad hoc networks and the quality of service required by group communication services. Areas of interest for this special journal issue include, but are not limited to, the following topics: - Ad hoc networking architectures with inherent P2P communication support - Use of P2P technology for ad hoc network formation and management - Multicast routing in mobile ad hoc and sensor networks - Algorithms for reliable delivery and congestion control in ad hoc networks - Location and mobility management in ad hoc group communications - Algorithms for self-configuration, maintenance, and stabilization - Data management, operating system, and middleware for ad hoc group communications - Security and privacy in ad hoc group communications - Collaborative multimedia systems in ad hoc networks - Collaborative signal processing and information retrieval in ad hoc networks - Innovative applications of group communication in ad hoc networks Paper Submission Submissions should include a cover page with authors' names, affiliations, fax and telephone numbers and e-mail addresses. Please submit full papers in PDF via email to one of the guest editors. Submitted papers must not be previously published nor submitted for publication elsewhere. Accepted papers will not exceed 6000 words or 15 single spaced pages in IEEE Transactions style. Hard copies should only be sent if electronic submission is not possible. All manuscripts will be reviewed by a selected panel of referees. Original artwork and a signed copy of the copyright release form will be required for all accepted papers. --=_alternative 001F9F0685256E5D_= Content-Type: text/html; charset="US-ASCII"
    <Apologies if you receive multiple copies of this message>

    CALL FOR PAPERS

    Special Issue on Group Communications in Ad hoc Networks
    International Journal of Wireless and Mobile Computing (IJWMC)

    http://academic.udayton.edu/DucTran/research/cfpIJWMC.htm

    ISSN (PRINT): 1741-1084
    ISSN (ONLINE): 1741-1092
    Published by Inderscience Publishers

    Important Dates
            Manuscript submission deadline: June 10th, 2004
            Notification due date: September 10th, 2004
            Camera-ready manuscript due date: November 1st, 2004
            Publication: Issue 3, 2005

    Guest Editors
            Dr. Duc A. Tran (duc.tran@notes.udayton.edu)
            Department of Computer Science
            300 College Park
            Dayton, OH 45429

            Dr. Deb A. Agarwal (daagarwal@lbl.gov)
            Lawrence Berkeley National Laboratory      
            1 Cyclotron Road, MS 50B-2239              
            Berkeley, CA 94720                      

            Dr. Mark D. Yarvis (mark.d.yarvis@intel.com)
            Intel Research and Development
            Intel Corporation, JF3-206
            2111 N.E. 25th Ave.
            Hillsboro, OR 97124-5961

    Subject Coverage

    Since people frequently work beyond their office desk, it is expected that the next generation
    of communication networks will include rapid deployments of independent mobile users.  With the
    emergence of wireless technologies such as IEEE 802.11 and Bluetooth, mobile users are enabled
    to connect to each other directly and wirelessly without any networking infrastructure, such as
    the Internet or infrastructure-based wireless networks.  Instead, users form mobile ad hoc
    networks (MANET). These networks are self-configurable and self-healable, and therefore easily
    adopted in a home environment and more cheaply deployed and maintained in a business environment.  

    While ad hoc networks are rapidly gaining in popularity, group communication technologies have
    already shown their importance in education, entertainment, business, military, and other
    industries.  However, thus far those technologies have mainly been designed for use in the
    Internet.  This special journal issue is focused on development of group communication
    solutions in ad hoc networks.  This work is significant to many interesting applications.  
    Examples are strategic collaboration among soldiers in a battlefield, collaborative data
    processing such as tracking and localization in sensor networks, collaborative intrusion
    detection among a group of distant surveillance cameras, to name just a few. Also relevant to
     ad hoc networks is the concept of peer-to-peer (P2P). P2P networks are commonly used in the
    Internet to enable services that leverage a collection of peer nodes rather than a single
    infrastructure server, making them resilient to the failure of an individual node.  These
    properties are attractive for applications deployed in ad hoc wireless networks, which have
    similar requirements.  
     
    Research on group communications in ad hoc networks is still in its infancy.  There are many open
    issues due to the deviation between resource, energy, and bandwidth availability of ad hoc networks
    and the quality of service required by group communication services.  Areas of interest for this
    special journal issue include, but are not limited to, the following topics:
     
    - Ad hoc networking architectures with inherent P2P communication support
    - Use of P2P technology for ad hoc network formation and management
    - Multicast routing in mobile ad hoc and sensor networks
    - Algorithms for reliable delivery and congestion control in ad hoc networks
    - Location and mobility management in ad hoc group communications
    - Algorithms for self-configuration, maintenance, and stabilization
    - Data management, operating system, and middleware for ad hoc group communications
    - Security and privacy in ad hoc group communications
    - Collaborative multimedia systems in ad hoc networks
    - Collaborative signal processing and information retrieval in ad hoc networks
    - Innovative applications of group communication in ad hoc networks

    Paper Submission
    Submissions should include a cover page with authors' names, affiliations, fax and telephone numbers
    and e-mail addresses. Please submit full papers in PDF via email to one of the guest editors. Submitted
    papers must not be previously published nor submitted for publication elsewhere. Accepted papers will
    not exceed 6000 words or 15 single spaced pages in IEEE Transactions style. Hard copies should only be
    sent if electronic submission is not possible. All manuscripts will be reviewed by a selected panel of
    referees. Original artwork and a signed copy of the copyright release form will be required for all
    accepted papers. --=_alternative 001F9F0685256E5D_=-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Mar 20 08:33:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09976 for ; Sat, 20 Mar 2004 08:33:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4gav-0007oa-Vr for manet-archive@odin.ietf.org; Sat, 20 Mar 2004 08:32:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2KDWvFW030034 for manet-archive@odin.ietf.org; Sat, 20 Mar 2004 08:32:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4gav-0007oL-NY for manet-web-archive@optimus.ietf.org; Sat, 20 Mar 2004 08:32:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09952 for ; Sat, 20 Mar 2004 08:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4gau-0006mY-00 for manet-web-archive@ietf.org; Sat, 20 Mar 2004 08:32:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4ga1-0006ff-00 for manet-web-archive@ietf.org; Sat, 20 Mar 2004 08:32:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4gZL-0006ZT-00 for manet-web-archive@ietf.org; Sat, 20 Mar 2004 08:31:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4gZ4-0007ZL-B9; Sat, 20 Mar 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4gZ1-0007Ya-Nj for manet@optimus.ietf.org; Sat, 20 Mar 2004 08:30:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09906 for ; Sat, 20 Mar 2004 08:30:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4gZ0-0006Ya-00 for manet@ietf.org; Sat, 20 Mar 2004 08:30:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4gY2-0006Sy-00 for manet@ietf.org; Sat, 20 Mar 2004 08:29:59 -0500 Received: from egaheer.interia.pl ([217.74.65.182] helo=poczta.interia.pl) by ietf-mx with esmtp (Exim 4.12) id 1B4gXp-0006NF-00 for manet@ietf.org; Sat, 20 Mar 2004 08:29:46 -0500 Received: from 127.0.0.1 (localhost [127.0.0.1]) by system.wewnetrzny9 (poczta.interia.pl) with SMTP id 2ACBF374270 for ; Sat, 20 Mar 2004 14:29:43 +0100 (CET) Received: by poczta.fm (poczta.fm, from userid 502) id 177FE64310; Sat, 20 Mar 2004 14:29:43 +0100 (CET) Received: from gawlin (194.gw.ip.pl [195.116.22.194]) by poczta.fm (poczta.fm) with ESMTP id 554F764305 for ; Sat, 20 Mar 2004 14:29:42 +0100 (CET) Message-ID: <003901c40e7f$e10bd120$8b000b0a@gawlin> From: "gawlin" To: Date: Sat, 20 Mar 2004 14:33:06 +0100 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.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [manet] Association in IBSS? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I'd like to ask if there exists association process in IBSS mode in 802.11? 802.11 specification says that only STA services applay to an IBSS and association belongs to distribution system services, so it seems thet in IBSS there shouldn't be association. I want to make sure if I'm right. Thanks M. Gawlinski _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Mar 20 20:59:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05662 for ; Sat, 20 Mar 2004 20:59:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4sFB-0002WM-6P for manet-archive@odin.ietf.org; Sat, 20 Mar 2004 20:59:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2L1xHnm009690 for manet-archive@odin.ietf.org; Sat, 20 Mar 2004 20:59:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4sFB-0002WD-1X for manet-web-archive@optimus.ietf.org; Sat, 20 Mar 2004 20:59:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05621 for ; Sat, 20 Mar 2004 20:59:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4sF8-0001YT-00 for manet-web-archive@ietf.org; Sat, 20 Mar 2004 20:59:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4sED-0001OE-00 for manet-web-archive@ietf.org; Sat, 20 Mar 2004 20:58:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4sDK-0001G2-00 for manet-web-archive@ietf.org; Sat, 20 Mar 2004 20:57:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4sCz-00024V-NJ; Sat, 20 Mar 2004 20:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4sCU-00023v-GB for manet@optimus.ietf.org; Sat, 20 Mar 2004 20:56:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05530 for ; Sat, 20 Mar 2004 20:56:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4sCS-00016f-00 for manet@ietf.org; Sat, 20 Mar 2004 20:56:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4sBQ-0000zg-00 for manet@ietf.org; Sat, 20 Mar 2004 20:55:26 -0500 Received: from web41313.mail.yahoo.com ([66.218.93.62]) by ietf-mx with smtp (Exim 4.12) id 1B4sB5-0000t8-00 for manet@ietf.org; Sat, 20 Mar 2004 20:55:03 -0500 Message-ID: <20040321015433.76200.qmail@web41313.mail.yahoo.com> Received: from [128.205.25.161] by web41313.mail.yahoo.com via HTTP; Sat, 20 Mar 2004 17:54:33 PST Date: Sat, 20 Mar 2004 17:54:33 -0800 (PST) From: Sochi K To: manet@ietf.org In-Reply-To: <20040320170005.4242.78391.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1556037192-1079834073=:75993" Subject: [manet] Re: ODMRP Glomosim forwarding group formation 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.60 --0-1556037192-1079834073=:75993 Content-Type: text/plain; charset=us-ascii Hello, I had earlier sent the question copied below, after having trouble figuring out why the Join Reply was never received by the sender's neighbors, thus inhibiting the formation of forwarding groups. The Join Reply is sent by the method NetworkIpSendRawGlomoMessageToMacLayer. Smaller packets such as Join Query are sent by the method NetworkIPSendPacketToMacLayer. I tested the process by sending a test message using both methods, and it was effectively broadcast if sent by NetworkIpSendPacketToMacLayer, but not when sent by NetworkIpSendRawGlomoMessageToMacLayer. The difference in the two methods is merely AddIpHeader added in the body of the latter. In both cases, ANY_DEST was used as the next-hop, and no other modifications have been made to the odmrp code that comes with glomosim. Has anybody else found this..? Please email me back if anyone has any suggestion. Thank you, Harleen On Fri, 19 Mar 2004, Harleen Dhillon wrote: > > > Hi, I found this while tracking the formation of forwarding groups in > ODMRP. I was wondering if anybody else has found the same and have a > solution to this. > > I use a simple simulation scenario, such as 10 nodes, in a 1000 x 1000 > area. Assume that one node is the source and some node 3-4 hops away is > the intended receiver for the multicast packets. While trying to trace > the formation of forwarding groups, I realized that the forwarding group > flag was never being set. What is actually happening is that the join > reply, although being created at the receiver node - and supposedly sent > to the mac layer to be broadcasted - is never being broadcasted to the > other nodes, thus no forwarding groups formation is taking place. > > The join reply at the receiver node is being relayed by using the > method > NetworkIpSendRawGlomoMessageToMacLayer( > node, newMsg, lastAddr, CONTROL, IPPROTO_ODMRP, > 1, DEFAULT_INTERFACE, ANY_DEST); > > This is called from the method: RoutingOdmrpSendReply in odmrp.pc. This > should send the join reply to the neighbors of the receiver node toward > the source, setting the forwarding group flags along the way. > > From my understanding of this code, any packet upon broadcast by the > mac layer would be received by the method RoutingOdmrpRouterFunction in > odmrp.pc, which would determine whether it is a data packet or a control > packet, done by the following comparison: > > ipHeader->ip_p == IPPROTO_ODMRP. > > Thus, if a Join Reply is received by a node, it will have this > ipHeader->ip_p field value set as 145 (for odmrp). I find by some > debugging that all the > packets which are handled by this function have ipHeader->ip_p = 17, that is, > are data packets. None of them have this field set as 145. Hence, since > no join replies are ever received, no forwarding groups etc. are > formed. My guess is something is amiss in the header value settings in the > join reply formation. I have not altered the ODMRP code that came with > Glomosim. (The method NetworkIpSendRawGlomoMessageToMacLayer calls AddIpHeader > and then NetworkIpSendPacketToMacLayer. In AddIpHeader, the ipHeader->ip_p > IS set to 145 at certain points, meaning that a Join Reply or Ack type of > packet is created at certain points in the simulation, but the only ones > that are received by any node have ip_p field as 17... so is something > missing between the creation of the ip header and the receiving > of packets by the nodes?). > > I'm not very familiar with the mac layer code in glomosim, so if anyone > could please suggest something that might be missing in the code or an > error in my findings, it would be appreciated. > > Thanks. > Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. --0-1556037192-1079834073=:75993 Content-Type: text/html; charset=us-ascii

     

    Hello, I had earlier sent the question copied below, after having trouble
    figuring out why the Join Reply was never received by the sender's
    neighbors, thus inhibiting the formation of forwarding groups.

    The Join Reply is sent by the method NetworkIpSendRawGlomoMessageToMacLayer. Smaller packets such as Join Query are sent by the method NetworkIPSendPacketToMacLayer. I tested the process by sending a test message using both methods, and it was effectively
    broadcast if sent by NetworkIpSendPacketToMacLayer, but not when sent by
    NetworkIpSendRawGlomoMessageToMacLayer. The difference in the two methods is merely AddIpHeader added in the body of the latter. In both cases, ANY_DEST was used as the next-hop, and no other modifications have been made to the odmrp code that comes with glomosim.

    Has anybody else found this..? Please email me back if anyone has any
    suggestion. Thank you,

    Harleen


    On Fri, 19 Mar 2004, Harleen Dhillon wrote:

    >
    >
    > Hi, I found this while tracking the formation of forwarding groups in
    > ODMRP. I was wondering if anybody else has found the same and have a
    > solution to this.
    > 
    > I use a simple simulation scenario, such as 10 nodes, in a 1000 x 1000
    > area. Assume that one node is the source and some node 3-4 hops away is
    > the intended receiver for the multicast packets. While trying to trace
    > the formation of forwarding groups, I realized that the forwarding group
    > flag was never being set. What is actually happening is that the join
    > reply, although being created at the receiver node - and supposedly sent
    > to the mac layer to be broadcasted - is never being broadcasted to the
    > other nodes, thus no forwarding groups formation is taking place.
    > 
    > The join reply at the receiver node is being relayed by using the
    > method
    >  NetworkIpSendRawGlomoMessageToMacLayer(
    >                         node, newMsg, lastAddr, CONTROL, IPPROTO_ODMRP,
    > 1, DEFAULT_INTERFACE, ANY_DEST);
    > 
    > This is called from the method: RoutingOdmrpSendReply in odmrp.pc. This
    > should send the join reply to the neighbors of the receiver node toward
    > the source, setting the forwarding group flags along the way.
    > 
    > From my understanding of this code, any packet upon broadcast by the
    > mac layer would be received by the method RoutingOdmrpRouterFunction in
    > odmrp.pc, which would determine whether it is a data packet or a control
    > packet, done by  the following comparison:
    > 
    > ipHeader->ip_p == IPPROTO_ODMRP.
    > 
    > Thus, if a Join Reply is received by a node, it will have this > ipHeader->ip_p field value set as 145 (for odmrp). I find by some
    > debugging that all the
    > packets which are handled by this function have ipHeader->ip_p = 17, that is,
    > are data packets. None of them have this field set as 145. Hence, since
    > no join replies are ever received, no forwarding groups etc. are
    > formed. My guess is something is amiss in the header value settings in the
    > join reply formation. I have not altered the ODMRP code that came with
    > Glomosim. (The method NetworkIpSendRawGlomoMessageToMacLayer calls AddIpHeader
    > and then NetworkIpSendPacketToMacLayer. In AddIpHeader, the ipHeader->ip_p
    > IS set to 145 at certain points, meaning that a Join Reply or Ack type of
    > packet is created at certain points in the simulation, but the only ones
    > that are received by any node have ip_p field as 17... so is something
    > missing between the creation of the ip header and the receiving
    > of packets by the nodes?).
    > 
    > I'm not very familiar with the mac layer code in glomosim, so if anyone
    > could please suggest something that might be missing in the code or an
    > error in my findings, it would be appreciated.
    > 
    > Thanks.
    >

    Do you Yahoo!?
    Yahoo! Finance Tax Center - File online. File on time. --0-1556037192-1079834073=:75993-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Mar 21 00:42:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13346 for ; Sun, 21 Mar 2004 00:42:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4viT-00012u-Qa for manet-archive@odin.ietf.org; Sun, 21 Mar 2004 00:41:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2L5fjWP004016 for manet-archive@odin.ietf.org; Sun, 21 Mar 2004 00:41:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4viT-00012h-JW for manet-web-archive@optimus.ietf.org; Sun, 21 Mar 2004 00:41:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13208 for ; Sun, 21 Mar 2004 00:41:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4viQ-0004Fs-00 for manet-web-archive@ietf.org; Sun, 21 Mar 2004 00:41:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4vhV-00041z-00 for manet-web-archive@ietf.org; Sun, 21 Mar 2004 00:40:46 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B4vgZ-0003tJ-02 for manet-web-archive@ietf.org; Sun, 21 Mar 2004 00:39:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B4vS4-0007UE-8D for manet-web-archive@ietf.org; Sun, 21 Mar 2004 00:24:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4vRP-0006pU-Nz; Sun, 21 Mar 2004 00:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4usm-0003nw-TF for manet@optimus.ietf.org; Sat, 20 Mar 2004 23:48:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11251 for ; Sat, 20 Mar 2004 23:48:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4usk-0005pq-00 for manet@ietf.org; Sat, 20 Mar 2004 23:48:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4urn-0005lA-00 for manet@ietf.org; Sat, 20 Mar 2004 23:47:20 -0500 Received: from bay8-f123.bay8.hotmail.com ([64.4.27.123] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B4ur5-0005bQ-00 for manet@ietf.org; Sat, 20 Mar 2004 23:46:35 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Mar 2004 20:46:06 -0800 Received: from 202.156.2.114 by by8fd.bay8.hotmail.msn.com with HTTP; Sun, 21 Mar 2004 04:46:05 GMT X-Originating-IP: [202.156.2.114] X-Originating-Email: [liugenping@hotmail.com] X-Sender: liugenping@hotmail.com From: "genping liu" To: manet@ietf.org Date: Sun, 21 Mar 2004 12:46:05 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Mar 2004 04:46:06.0302 (UTC) FILETIME=[6BE7CFE0:01C40EFF] Subject: [manet] Local recovery of AODV 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hi, I was using ns2.1b8a to simulate of the peformance of AODV with and without local recovery. it is expected that AODV with local recovery should outperform AODV without. however, our simulation results shows that the local recovery decreased the performance of AODV. our simulation scenario is map of 2000mx1600m, node number=100, transmission range of 350, random way point with medium mobility. anyone know that reason that local recovery decreased the performance of AODV? Thanks Regards Genping _________________________________________________________________ Get 10mb of inbox space with MSN Hotmail Extra Storage http://join.msn.com/?pgmarket=en-sg _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 22 04:36:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12195 for ; Mon, 22 Mar 2004 04:36:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Lr3-0007gs-Kh for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 04:36:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2M9aLAU029556 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 04:36:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Lr1-0007gd-C4 for manet-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 04:36:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12143 for ; Mon, 22 Mar 2004 04:36:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Lqy-0005gh-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 04:36:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Lq0-0005ZT-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 04:35:17 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Lp4-0005T7-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 04:34:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Lop-00073o-30; Mon, 22 Mar 2004 04:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5LoE-00072f-Qu for manet@optimus.ietf.org; Mon, 22 Mar 2004 04:33:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11997 for ; Mon, 22 Mar 2004 04:33:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5LoB-0005NF-00 for manet@ietf.org; Mon, 22 Mar 2004 04:33:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5LnB-0005Gw-00 for manet@ietf.org; Mon, 22 Mar 2004 04:32:22 -0500 Received: from anyida.tts.lth.se ([130.235.18.10]) by ietf-mx with esmtp (Exim 4.12) id 1B5LmE-0005C3-00 for manet@ietf.org; Mon, 22 Mar 2004 04:31:23 -0500 Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id KAA19788; Mon, 22 Mar 2004 10:32:30 +0100 (MET) Message-ID: <405EB237.6030508@telecom.lth.se> Date: Mon, 22 Mar 2004 10:30:31 +0100 From: Ali Hamidian User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: genping liu CC: manet@ietf.org Subject: Re: [manet] Local recovery of AODV References: In-Reply-To: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, genping liu wrote: > hi, > > I was using ns2.1b8a to simulate of the peformance of AODV with and > without > local recovery. it is expected that AODV with local recovery should > outperform AODV without. however, our simulation results shows that the > local recovery decreased the performance of AODV. our simulation scenario > is > map of 2000mx1600m, node number=100, transmission range of 350, random > way > point with medium mobility. > > anyone know that reason that local recovery decreased the performance of > AODV? I don't think that local recovery is implemented correctly in the aodv code of ns-2.1b8(a). I also think there is some comment in aodv.h which says that local recovery shouldn't be used and that it doesn't show any significant performance improvements. Regards Ali Hamidian > > Thanks > > Regards > Genping > > _________________________________________________________________ > Get 10mb of inbox space with MSN Hotmail Extra Storage > http://join.msn.com/?pgmarket=en-sg > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Mar 22 06:24:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16813 for ; Mon, 22 Mar 2004 06:24:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NWr-0001MC-Na for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 06:23:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MBNb1k005216 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 06:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NWr-0001M3-FG for manet-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 06:23:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16808 for ; Mon, 22 Mar 2004 06:23:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5NWn-0001e3-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 06:23:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5NVs-0001Y4-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 06:22:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5NVU-0001RG-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 06:22:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NVJ-0000wp-S9; Mon, 22 Mar 2004 06:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5NUl-0000nU-4i for manet@optimus.ietf.org; Mon, 22 Mar 2004 06:21:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16718 for ; Mon, 22 Mar 2004 06:21:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5NUh-0001Pu-00 for manet@ietf.org; Mon, 22 Mar 2004 06:21:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5NTo-0001L1-00 for manet@ietf.org; Mon, 22 Mar 2004 06:20:29 -0500 Received: from rissala173.outgw.tn ([193.95.17.173]) by ietf-mx with esmtp (Exim 4.12) id 1B5NTL-0001Fg-00 for manet@ietf.org; Mon, 22 Mar 2004 06:19:59 -0500 Received: from tounes-22.ati.tn (tounes-22.ati.tn [193.95.66.22]) by rissala164.ingw.tn (8.12.9/8.12.9) with ESMTP id i2MDK35J029594 for ; Mon, 22 Mar 2004 12:20:03 -0100 (GMT) Received: from smtp1.planet.net.tn (smtp.planet.tn [193.95.123.25]) by tounes-22.ati.tn (8.12.8/8.12.8) with ESMTP id i2MAJMxw006224 for ; Mon, 22 Mar 2004 12:19:22 +0200 (EET) Received: from home ([193.95.96.15]) by smtp1.planet.net.tn (Switch-3.1.3/Switch-3.1.0) with SMTP id i2MDKaCt027704 for ; Mon, 22 Mar 2004 12:20:40 -0100 (GMT) Message-ID: <008b01c40fff$8b6a1980$0f605fc1@home> From: "Wala Turki Latrous" To: Date: Mon, 22 Mar 2004 12:19:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01C41007.EBF16DA0" 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 Subject: [manet] OLSR attack 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0088_01C41007.EBF16DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 In the OLSR protocol : if a node X wants to send HELLO messages, = pretending to have the identity of another node A ; knowing the main = address of A and then use it as his originator address is sufficient for = this attack ? or X must also know the sequence numbers recently used by = A for the packets and/or the HELLO messages ?=20 =20 In the same way, X wants to send TC messages, pretending to have the = identity of A. Must X know the packet sequence number and the ANSN = recently used by A? =20 Is there any works on attacks on OLSR or securing OLSR ? ------=_NextPart_000_0088_01C41007.EBF16DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hello,

     

    In=20 the OLSR protocol :  if a = node X=20 wants to send HELLO messages, pretending to have the identity of another = node A=20 ; knowing the main address of A and then use it as his originator = address is=20 sufficient for this attack ? or X must also know the sequence numbers = recently=20 used by A for the packets and/or the HELLO messages ?=20

     

    In=20 the same way, X wants to send TC messages, pretending to have the = identity of A.=20 Must X know the packet sequence number and the ANSN recently used by=20 A?

     

    Is=20 there any works on attacks on OLSR or securing OLSR=20 ?

    ------=_NextPart_000_0088_01C41007.EBF16DA0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 22 07:21:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19372 for ; Mon, 22 Mar 2004 07:21:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OQ1-0007lk-OX for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 07:20:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MCKbSx029861 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 07:20:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OQ1-0007lY-3Q for manet-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 07:20:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19366 for ; Mon, 22 Mar 2004 07:20:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5OQ0-0000Rw-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 07:20:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5OOz-0000LF-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 07:19:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5OOe-0000Fd-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 07:19:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OOU-0007LD-8C; Mon, 22 Mar 2004 07:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5ONx-0007Kj-5s for manet@optimus.ietf.org; Mon, 22 Mar 2004 07:18:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19319 for ; Mon, 22 Mar 2004 07:18:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5ONw-0000Dn-00 for manet@ietf.org; Mon, 22 Mar 2004 07:18:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ON6-00008L-00 for manet@ietf.org; Mon, 22 Mar 2004 07:17:36 -0500 Received: from trinity.critical-systems.no ([194.143.111.171] helo=trinity.gnist.org) by ietf-mx with esmtp (Exim 4.12) id 1B5OMi-00001T-00 for manet@ietf.org; Mon, 22 Mar 2004 07:17:12 -0500 Received: from localhost (unknown [127.0.0.1]) by trinity.gnist.org (Postfix) with ESMTP id 56E22633062; Mon, 22 Mar 2004 13:17:10 +0100 (CET) Received: from trinity.gnist.org ([127.0.0.1]) by localhost (trinity.gnist.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32383-02; Mon, 22 Mar 2004 13:17:09 +0100 (CET) Received: from olsr.org (orkdal.unik.no [193.156.97.77]) by trinity.gnist.org (Postfix) with ESMTP id 08B66633066; Mon, 22 Mar 2004 13:17:09 +0100 (CET) Message-ID: <405ED943.6010807@olsr.org> Date: Mon, 22 Mar 2004 13:17:07 +0100 From: =?ISO-8859-1?Q?Andreas_T=F8nnesen?= Organization: olsr.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Wala Turki Latrous Cc: manet@ietf.org Subject: Re: [manet] OLSR attack References: <008b01c40fff$8b6a1980$0f605fc1@home> In-Reply-To: <008b01c40fff$8b6a1980$0f605fc1@home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable You could check out: *"Securing the OLSR protocol"* Thomas Heide Clausen, Cedric Adjih, Philippe Jacquet, Anis Laouiti, Paul=20 Muhltahler, Daniele Raffo http://voop.free.fr/Publications/2003/medhoc03.shtml - Andreas Wala Turki Latrous wrote: > Hello, > > =20 > > In the OLSR protocol : if a node X wants to send HELLO messages,=20 > pretending to have the identity of another node A ; knowing the main=20 > address of A and then use it as his originator address is sufficient=20 > for this attack ? or X must also know the sequence numbers recently=20 > used by A for the packets and/or the HELLO messages ? > > =20 > > In the same way, X wants to send TC messages, pretending to have the=20 > identity of A. Must X know the packet sequence number and the ANSN=20 > recently used by A? > > =20 > > Is there any works on attacks on OLSR or securing OLSR ? > --=20 --=20 Andreas T=F8nnesen(andreas@olsr.org) UniK University Graduation Center University of Oslo http://www.olsr.org _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 22 12:12:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06683 for ; Mon, 22 Mar 2004 12:12:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Sxe-0003Rs-PF for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 12:11:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MHBcwD013252 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 12:11:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Sxe-0003Rf-Lg for manet-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 12:11:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06675 for ; Mon, 22 Mar 2004 12:11:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Sxd-00060U-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 12:11:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Swm-0005vG-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 12:10:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5SwK-0005pP-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 12:10:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Sry-00025Y-Lm; Mon, 22 Mar 2004 12:05:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SqF-00020z-Ib for manet@optimus.ietf.org; Mon, 22 Mar 2004 12:03:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06306 for ; Mon, 22 Mar 2004 12:03:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5SqE-00059N-00 for manet@ietf.org; Mon, 22 Mar 2004 12:03:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5SpO-00051Q-00 for manet@ietf.org; Mon, 22 Mar 2004 12:03:07 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B5Soh-0004qO-00 for manet@ietf.org; Mon, 22 Mar 2004 12:02:23 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2MH1qTN012008 for ; Mon, 22 Mar 2004 11:01:52 -0600 (CST) Message-ID: <405F1D5B.D911EA58@alcatel.com> Date: Mon, 22 Mar 2004 11:07:39 -0600 From: Tim Ozugur X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] CFP:Broadband Wireless Networking Symposium 2004 - Extended Deadline 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING, LINES_OF_YELLING_2 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Apologies if you are receiving this message more than once) ----------------------------------------------------------------------- CALL FOR PAPERS BroadNets 2004 Broadband Wireless Networking Symposium 2004 October 25 - 29, 2004 San Jose, California, USA www.broadnets.org ***** Extended Submission Deadline: April 1, 2004 ***** ----------------------------------------------------------------------- SCOPE ----- BroadNets 2004 is a new conference focusing on broadband networking and covers the entire gamut of next generation networks with ultra-high bandwidth available all the way from access networks (xDSL, Cable, EPON, Broadband Wireless, multi-Gigabit uplinks), to regional and metropolitan networks to wide-area core networks. The conference will consist of the following two symposia: ** Broadband Wireless Networking that is defined to cover high-speed wireless networking for access, regional and backhaul networks including backhaul capacity provisioning using wireless, including the WLAN networks and WMAN. ** Broadband Optical Networking includes WDM technologies, Ethernet and MPLS integration into the optical layer, Next-Gen SONET/SDH, as well as SAN extentions over DWDM/SONET/SDH. BroadNets 2004 will thus offer a unique forum for researchers from academia, government and industry to share ideas and disseminate new results in these important areas. In addition to expansion in scope, BroadNets 2004 will expand its target audience by encouraging industry contributions, through architecture and position papers. More details can be found at www.broadnets.org. This Call for Papers describes the details for the Broadband Wireless Networking Symposium ONLY. (Refer to the broadnets.org website for the Broadband Optical Symposium details.) We are soliciting full papers in all research, development, and deployment areas on broadband wireless networking. Applications/position/system papers from industry are also encouraged. Topics of interest include, but not limited to, the following: - 3G/4G Systems - Fixed Broadband Wireless Access - Wireless Local Area Networks - WLAN Hotspots - Wireless indoor & home networks - Wireless Personal Area Networks including IEEE 802.15 - IEEE 802.16 (WiMax) Standards Activities and Products - Wireless Metropolitan Area Networks - Wireless Wide Area Networks - Free-Space Optics - Ultra Wideband (UWB) Networks - Ad-hoc networks - Cellular mobile/WLAN interoperability - System architecture - Network Topology management - Neighbour discovery - Unicast and multicast routing - Quality-of-Service support - Security techniques and systems - Resource management - Software-defined radio - Space-time processing, MIMO systems - Digital signal processing - Smart (directional) antennas - Power control - Wireless emergency systems - Standards, Licensing and regulation - Interference mitigation for multiple access - Economics and business cases IMPORTANT DATES --------------- Full papers due: April 1, 2004 Notification of acceptance: June 7, 2004 Final manuscript due: July 7, 2004 Conference Dates: October 25 - 29, 2004 PAPER SUBMISSION INSTRUCTIONS ----------------------------- Authors are invited to submit full papers of up to 20 double-spaced pages in Times 10pt font, including references, figures and tables. All submissions should be submitted electronically to EDAS system at http://edas.info/Conferences.cgi and in Postscript or Adobe PDF format. Papers of particular merit will be considered for a special issue of ACM/Kluwer Mobile Networks (MONET) Journal. PROPOSALS FOR WORKSHOPS, TUTORIALS AND PANELS --------------------------------------------- Proposals for workshops, tutorials and panels on broadband wireless networking and related topics are solicited. Contact information for respective Chairs can be found at www.broadnets.org. Workshop proposals should consist of: 1) title of the workshop, 2) description of potential audience, 3) description of the workshop topic and justification of why the proposed topic is interesting and timely and, 4) intended format of the workshop. Please submit your proposals to the appropriate Chairs by April 1, 2004. Tutorial proposals should consist of: 1) title and outline of materials to be presented, 2) description of potential audience, 3) justification of why the proposed topic is interesting and timely and, 4) biographical sketch of the presenter(s). Please submit your proposals to the appropriate Chairs by May 1, 2004. Panel topics should address innovative, controversial, or otherwise provocative issues of interest related to broadband wireless networking and communications. Please submit your proposals to the appropriate Chairs by May 1, 2004. CONFERENCE INFORMATION ---------------------- For the general information about the organization of the BroadNets 2004 conference, please visit http://www.broadnets.org or contact one of the conference chairs listed below (more details are on the website). CONFERENCE ORGANIZING COMMITTEE ------------------------------- BroadNets Conference General Chair: Dr. Raj Jain, Nayna Networks/Ohio State University, raj@nayna.com Broadband Wireless Networking Symposium Chair: Dr. Zhensheng Zhang, San Diego Research Center, zzhang@ieee.org Technical Program Co-Chairs: Dr. Parameswaran Ramanathan, Univ. of Wisconsin-Madison, parmesh@ece.wisc.edu Dr. Thomas Hou, Virginia Tech, thou@vt.edu Panels Co-Chairs: Dr. Byrav Ramamurthy, University of Nebraska - Lincoln, byrav@cse.unl.edu Dr. Loukas Paraschis, Cisco Systems, loukas@cisco.com Tutorials Co-Chairs: Dr. Hakki Candan Cankaya, Alcatel USA, hakki.cankaya@alcatel.com Dr. Surendar Chandra, Univ of Notre Dame, surendar@cse.nd.edu Workshops Co-Chairs: Dr. Nasir Ghani, Tennessee Tech University, nghani@ieee.org Dr. Rajeev Shorey, National University of Singapore and IBM Research India, rajeev@comp.nus.edu.sg Exhibits and Sponsorships Chairs: Dr. Samrat Ganguly, NEC Labs, samrat@nec-labs.com Dr. Javier Aracil, Universidad Publica de Navarra, Spain, javier.aracil@unavarra.es Publications Chair: Dr. Srinivasan Ramasubramanian, U. of Arizona srini@ece.arizona.edu Local Arrangements Co-Chairs: Dr. Subhankar Dhar, San Jose State University, dhar_s@cob.sjsu.edu Dr. Sukesh Pai, Microsoft, sukeshp@microsoft.com Publicity Co-Chairs: Dr. Tim Ozugur, Alcatel USA, tim.ozugur@alcatel.com Dr. Gaoxi Xiao, Nanyang Technological Univ. Singapore, egxxiao@ntu.edu.sg Dr. Marcos Rogerio Salvador, CPqD Telecom & IT Solutions, marcosrs@cpqd.com.br Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, University of Maryland, Baltimore County, krishna@umbc.edu -------------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 22 15:00:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15693 for ; Mon, 22 Mar 2004 15:00:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VZh-0001KB-Hj for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 14:59:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MJwtZT005074 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 14:58:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VZT-0001JF-KF for manet-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 14:58:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15618 for ; Mon, 22 Mar 2004 14:58:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5VZL-0002VO-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 14:58:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5VYQ-0002P9-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 14:57:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5VXV-0002Ig-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 14:56:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VWl-0000zb-Ak; Mon, 22 Mar 2004 14:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5VWN-0000sx-R8 for manet@optimus.ietf.org; Mon, 22 Mar 2004 14:55:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15472 for ; Mon, 22 Mar 2004 14:55:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5VWK-0002B4-00 for manet@ietf.org; Mon, 22 Mar 2004 14:55:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5VVV-00025z-00 for manet@ietf.org; Mon, 22 Mar 2004 14:54:45 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1B5VV1-00020a-00 for manet@ietf.org; Mon, 22 Mar 2004 14:54:16 -0500 Received: from yosemite.cs.ucsb.edu (yosemite [128.111.40.103]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id i2MJsAX15829 for ; Mon, 22 Mar 2004 11:54:10 -0800 (PST) From: Elizabeth Belding-Royer To: manet@ietf.org Content-Type: text/plain Message-Id: <1079985213.32639.35.camel@yosemite.cs.ucsb.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 22 Mar 2004 11:54:13 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] MWCN 2004 CFP: Reminder! 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ONLY 9 DAYS UNTIL PAPER SUBMISSIONS DEADLINE!!! *************************************************** ****** CALL FOR PAPERS ********* *************************************************** * * * IFIP/IEEE MWCN 2004 * * The Sixth IFIP/IEEE International Conference on * * Mobile and Wireless Communications Networks * * * * Paris, France, 25 - 27 October, 2004 * * * * http://mwcn2004.lri.fr/ * *************************************************** MWCN 2004 is the sixth annual international conference dedicated to advancing research on mobile wireless networks. In the past few years, there has been growing interest in integrating stand-alone mobile networks with infrastructured wireless networks to create more robust and adaptable wireless networks. To further encourage research in this area, the theme of this years conference is: ** Convergence of Mobile Wireless Networks and the Internet ** You are invited to submit original papers to the conference for review. Potential topics include, but are not limited to, the following areas: * Mobile network architecture * Resource and information management * Mobility support, protocols, and algorithms * Connection management * Applications * Mobile ad hoc networks * Wireless local area networks * Analysis and simulation of mobile networks * Evaluation of mobile network testbeds * Mobile network security * Quality of service * Energy efficiency of protocols and devices All papers should be submitted electronically in Portable Document Format (PDF). Submissions should be in English, and the maximum page length is 6 pages in no smaller than 10 point font. The name and affiliation of all authors should be included on the paper, and the contact information for the lead author should be included in a cover page. Full submission instructions can be found at http://mwcn2004.lri.fr IMPORTANT DATES --------------- Submission deadline: March 31, 2004, 11:59PM PST Notification of acceptance: June 1, 2004 Camera-ready deadline: July 1, 2004 Conference: 25-27 October 2004 Conference General Chairs ------------------------- Khaldoun Al Agha LRI, University of Paris XI, France khaldoun.alagha@lri.fr Guy Pujolle University of Paris VI, France guy.pujolle@lip6.fr Conference Technical Program Chair ---------------------------------- Elizabeth M. Belding-Royer University of California, Santa Barbara ebelding@cs.ucsb.edu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 22 19:38:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06673 for ; Mon, 22 Mar 2004 19:38:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Zvo-0000iI-5u for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 19:38:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N0cC5J002735 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 19:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Zvn-0000hu-E6 for manet-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 19:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06669 for ; Mon, 22 Mar 2004 19:38:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Zvl-0007c4-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 19:38:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Zuv-0007T2-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 19:37:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5ZuB-0007K5-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 19:36:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Ztj-0008QB-29; Mon, 22 Mar 2004 19:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Zsc-0008L4-E2 for manet@optimus.ietf.org; Mon, 22 Mar 2004 19:34:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06517 for ; Mon, 22 Mar 2004 19:34:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Zsa-00076E-00 for manet@ietf.org; Mon, 22 Mar 2004 19:34:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Zrj-0006xV-00 for manet@ietf.org; Mon, 22 Mar 2004 19:34:00 -0500 Received: from netns.kjist.ac.kr ([203.237.53.16] helo=NML.netmedia.kjist.ac.kr) by ietf-mx with esmtp (Exim 4.12) id 1B5ZrF-0006qu-00 for manet@ietf.org; Mon, 22 Mar 2004 19:33:29 -0500 Received: from netmediahyyoon ([203.237.53.145]) by NML.netmedia.kjist.ac.kr with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Mar 2004 09:31:00 +0900 Reply-To: From: "Ha Young, Yoon" To: Date: Tue, 23 Mar 2004 09:33:13 +0900 Organization: NETMEDIA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C410B9.DD2CA020" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQQbmyUiEtcE3T7RY6DwYOz41gLew== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 23 Mar 2004 00:31:00.0687 (UTC) FILETIME=[1DDFCDF0:01C4106E] Subject: [manet] Why MAODV draft is not exist in the MANET working group 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_FONT_FACE_BAD, HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C410B9.DD2CA020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi seniors, I really wonder why MAODV draft is disused. Is it out of scope of MANET working group? Please, let me sense the reason. Yours, HaYoung Yoon ------=_NextPart_000_0000_01C410B9.DD2CA020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi = seniors,

     

    I really wonder why MAODV = draft is disused.

     

    Is it out of scope of MANET = working group?

     

    Please, let me sense the = reason.

     

    Yours,

     

    HaYoung = Yoon

    ------=_NextPart_000_0000_01C410B9.DD2CA020-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 22 20:17:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08296 for ; Mon, 22 Mar 2004 20:17:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5aXW-0003BZ-F0 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 20:17:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N1HAot012234 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 20:17:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5aXW-0003B0-4v for manet-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 20:17:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08258 for ; Mon, 22 Mar 2004 20:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5aXU-0004RO-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 20:17:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5aWk-0004Jb-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 20:16:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5aWR-0002ow-Nc; Mon, 22 Mar 2004 20:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5aWN-0002nt-Al for manet@optimus.ietf.org; Mon, 22 Mar 2004 20:15:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08150 for ; Mon, 22 Mar 2004 20:15:57 -0500 (EST) From: zinin@psg.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5aWL-0004HP-00 for manet@ietf.org; Mon, 22 Mar 2004 20:15:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5aVQ-0004AB-00 for manet@ietf.org; Mon, 22 Mar 2004 20:15:33 -0500 Received: from [203.92.97.178] (helo=GERRYW.net) by ietf-mx with smtp (Exim 4.12) id 1B5aUh-00042F-00 for manet@ietf.org; Mon, 22 Mar 2004 20:14:16 -0500 Date: Tue, 23 Mar 2004 11:13:09 +1000 To: manet@ietf.org Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.5 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK, FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_EMBEDS,HTML_MESSAGE, MIME_HTML_ONLY,NORMAL_HTTP_TO_IP,NO_REAL_NAME,WEIRD_PORT autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.3 HTML_EMBEDS BODY: HTML with embedded plugin object * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.9 WEIRD_PORT URI: Uses non-standard port number for HTTP * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * -0.1 AWL AWL: Auto-whitelist adjustment Content-Transfer-Encoding: 7bit Subject: [manet] Re: Incoming Message 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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 23 02:25:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08725 for ; Tue, 23 Mar 2004 02:25:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gHi-0005Id-5P for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 02:25:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N7PDKN020369 for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 02:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gHh-0005IO-66 for manet-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 02:25:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08698 for ; Tue, 23 Mar 2004 02:25:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5gHd-00031a-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 02:25:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5gGf-0002u5-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 02:24:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5gG1-0002nd-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 02:23:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gFd-0004Hw-8q; Tue, 23 Mar 2004 02:23:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gCp-0003Xa-Mr for manet@optimus.ietf.org; Tue, 23 Mar 2004 02:20:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08295 for ; Tue, 23 Mar 2004 02:20:08 -0500 (EST) From: Duc.Tran@notes.udayton.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5gCm-0002VX-00 for manet@ietf.org; Tue, 23 Mar 2004 02:20:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5gBn-0002PW-00 for manet@ietf.org; Tue, 23 Mar 2004 02:19:07 -0500 Received: from facstaff03.udayton.edu ([131.238.75.127]) by ietf-mx with esmtp (Exim 4.12) id 1B5gBS-0002Jf-00 for manet@ietf.org; Tue, 23 Mar 2004 02:18:46 -0500 To: tccc@cs.columbia.edu, manet@ietf.org, P2P@LISTSERV.UTK.EDU MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 Message-ID: Date: Tue, 23 Mar 2004 02:18:44 -0500 X-MIMETrack: Serialize by Router on FacStaff03/SVR/UDayton(Release 6.0.3|September 26, 2003) at 03/23/2004 02:18:48 AM, Serialize complete at 03/23/2004 02:18:48 AM Content-Type: multipart/alternative; boundary="=_alternative 0028573B85256E60_=" Subject: [manet] Final CFP: Multimedia Streaming in Ad hoc Networks at DMS 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 0028573B85256E60_= Content-Type: text/plain; charset="US-ASCII" CALL FOR PAPERS Complete CFP at http://academic.udayton.edu/DucTran/research/dms2004.htm Special Session on MULTIMEDIA STREAMING IN AD HOC NETWORKS at the 2004 International Conference on Distributed Multimedia Systems (DMS '04) Hotel Sofitel, San Francisco Bay, California September 8 - 10, 2004 Important Dates March 31, 2004 Paper submission due June 1, 2004 Notification of acceptance July 1, 2004 Final manuscript due July 1, 2004 Early conference registration due --=_alternative 0028573B85256E60_= Content-Type: text/html; charset="US-ASCII"
    <Apologies if you receive this message multiple times>

    CALL FOR PAPERS

    Complete CFP at http://academic.udayton.edu/DucTran/research/dms2004.htm

    Special Session on MULTIMEDIA STREAMING IN AD HOC NETWORKS
    at the 2004 International Conference on Distributed Multimedia Systems (DMS '04)
    Hotel Sofitel, San Francisco Bay, California
    September 8 - 10, 2004

    Important Dates
     
          March 31, 2004   Paper submission due
             June 1, 2004     Notification of acceptance
             July 1, 2004     Final manuscript due
             July 1, 2004     Early conference registration due
    --=_alternative 0028573B85256E60_=-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 23 03:06:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10493 for ; Tue, 23 Mar 2004 03:06:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gvJ-00017D-KN for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 03:06:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2N869xe004281 for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 03:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gvJ-00016y-1T for manet-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 03:06:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10446 for ; Tue, 23 Mar 2004 03:06:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5gvF-00006J-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 03:06:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5guD-0007lZ-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 03:05:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5gtN-0007f6-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 03:04:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gtG-0000mB-TF; Tue, 23 Mar 2004 03:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5gsJ-0000fU-Bz for manet@optimus.ietf.org; Tue, 23 Mar 2004 03:03:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10309 for ; Tue, 23 Mar 2004 03:03:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5gsF-0007Wh-00 for manet@ietf.org; Tue, 23 Mar 2004 03:02:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5grJ-0007QS-00 for manet@ietf.org; Tue, 23 Mar 2004 03:02:01 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27] helo=i2r.a-star.edu.sg) by ietf-mx with esmtp (Exim 4.12) id 1B5gqO-0007Ju-00 for manet@ietf.org; Tue, 23 Mar 2004 03:01:05 -0500 Received: from newmailhost (localhost [127.0.0.1]) by i2r.a-star.edu.sg (8.12.10/8.12.10) with ESMTP id i2N7x8F1028366 for ; Tue, 23 Mar 2004 15:59:08 +0800 (SGT) Received: from localhost.localdomain ([192.168.152.135]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HV000I37RIOFL@mailhost.lit.org.sg> for manet@ietf.org; Tue, 23 Mar 2004 15:59:15 +0800 (SGT) Received: by localhost.localdomain (Postfix, from userid 1000) id A769F465C7; Tue, 23 Mar 2004 16:00:56 +0800 (SGT) Date: Tue, 23 Mar 2004 16:00:56 +0800 From: "Sukanta K. Hazra" Subject: Re: [manet] Local Recovery of AODV In-reply-to: To: manet@ietf.org Mail-followup-to: manet@ietf.org Message-id: <20040323080056.GA23439@i2r.a-star.edu.sg> Organization: Institute for Infocomm Research MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 User-Agent: Mutt/1.5.4i References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > I was using ns2.1b8a to simulate of the peformance of AODV with and without > local recovery. it is expected that AODV with local recovery should > outperform AODV without. however, our simulation results shows that the > local recovery decreased the performance of AODV. our simulation scenario > is map of 2000mx1600m, node number=100, transmission range of 350, random > way point with medium mobility. > > anyone know that reason that local recovery decreased the performance of > AODV? By performance you mean the throughput, delay or? In our simulations on similar scenario, in Glomosim, the average end-to-end delay increased when local recovery is used. On the other hand, the throughput remains almost the same. The average end-to-end delay increased due to an increase in the average path length. - Sukanta _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 23 14:30:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19882 for ; Tue, 23 Mar 2004 14:30:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rai-0001hx-4C for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 14:29:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NJTa5Y006562 for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 14:29:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rah-0001hl-Fd for manet-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 14:29:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19855 for ; Tue, 23 Mar 2004 14:29:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rae-0004QY-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 14:29:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rZi-0004Mn-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 14:28:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5rZG-0004JI-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 14:28:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rZB-0001Jc-TL; Tue, 23 Mar 2004 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5rYt-0001J1-5k for manet@optimus.ietf.org; Tue, 23 Mar 2004 14:27:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19789 for ; Tue, 23 Mar 2004 14:27:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5rYq-0004Gr-00 for manet@ietf.org; Tue, 23 Mar 2004 14:27:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5rXu-0004D6-00 for manet@ietf.org; Tue, 23 Mar 2004 14:26:43 -0500 Received: from web12906.mail.yahoo.com ([216.136.174.73]) by ietf-mx with smtp (Exim 4.12) id 1B5rXN-00048r-00 for manet@ietf.org; Tue, 23 Mar 2004 14:26:09 -0500 Message-ID: <20040323190156.18552.qmail@web12906.mail.yahoo.com> Received: from [158.94.254.20] by web12906.mail.yahoo.com via HTTP; Tue, 23 Mar 2004 19:01:56 GMT Date: Tue, 23 Mar 2004 19:01:56 +0000 (GMT) From: =?iso-8859-1?q?kani=20sundar?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-997933938-1080068516=:17680" Content-Transfer-Encoding: 8bit Subject: [manet] Problem in running OPNET model simulation for 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=HTML_MESSAGE autolearn=no version=2.60 --0-997933938-1080068516=:17680 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, I am currently doing my research in simulation of DSR protocol in adhoc networks. I am using opnet for my simulation and when i run the the example file for DSR then iam getting the error message as follows... <<>> Object repository construction failed due to errors encountered by the binder program(bind_so_msvc) <<< Program Abort>>> Error encountered rebuilding repository-unable to proceed ---- Creating library C:\PROGRA~1\OPNET\10.0.A\sys\lib\project2-scenario1.dev32.io.nt.lib and C:\PROGRA~1\OPNET\10.0.A\sys\lib\project2-scenario1.dev32.io.nt.exp wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_mac_pk_bbstruct_copy wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_mac_pk_bbstruct_destroy wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_mac_pk_bbstruct_create wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_ap_reliablity_eval wlan_power.dev32.io.ps.obj : error LNK2001: unresolved external symbol _wlan_ap_reliabilty_eval Creating library C:\PROGRA~1\OPNET\10.0.A\sys\lib\project2-scenario1.dev32.io.nt.dll : fatal error LNK1120 : 4 unresolved externals This error is coming whenever i run the manet for simulation in opnet Can anyone pl help me out from this problem Kanimaran Sundarasekaran --------------------------------- Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now --0-997933938-1080068516=:17680 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    Hi all,
     
           I am currently doing my research in simulation of DSR  protocol in adhoc networks.
     
    I am using opnet for my simulation and when i run the the example file for DSR then iam getting the error message as follows...
     
    <<<Recoverable Error>>>
    Object repository construction failed due to errors encountered by the binder program(bind_so_msvc)
    <<< Program Abort>>>
    Error encountered rebuilding repository-unable to proceed
    ----
     
    Creating library C:\PROGRA~1\OPNET\10.0.A\sys\lib\project2-scenario1.dev32.io.nt.lib and C:\PROGRA~1\OPNET\10.0.A\sys\lib\project2-scenario1.dev32.io.nt.exp
     
    wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_mac_pk_bbstruct_copy
    wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_mac_pk_bbstruct_destroy
    wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_mac_pk_bbstruct_create
    wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_ap_reliablity_eval
    wlan_power.dev32.io.ps.obj : error LNK2001: unresolved external symbol _wlan_ap_reliabilty_eval
    Creating library C:\PROGRA~1\OPNET\10.0.A\sys\lib\project2-scenario1.dev32.io.nt.dll : fatal error LNK1120 : 4 unresolved externals
     
    This error is coming whenever i run the manet for simulation in opnet
     
    Can anyone pl help me out from this problem
     
    Kanimaran Sundarasekaran
     
     
     

    Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now --0-997933938-1080068516=:17680-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 23 18:27:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11593 for ; Tue, 23 Mar 2004 18:27:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vIJ-0002SH-W6 for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 18:26:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NNQpMR009436 for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 18:26:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vIJ-0002S7-SC for manet-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 18:26:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11544 for ; Tue, 23 Mar 2004 18:26:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vIG-0000eP-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 18:26:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vHM-0000Z6-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 18:25:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5vGu-0000Tf-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 18:25:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vGX-0001ym-Fu; Tue, 23 Mar 2004 18:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5vFc-0001ve-TX for manet@optimus.ietf.org; Tue, 23 Mar 2004 18:24:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11364 for ; Tue, 23 Mar 2004 18:24:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5vFZ-0000OB-00 for manet@ietf.org; Tue, 23 Mar 2004 18:24:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5vEc-0000HF-00 for manet@ietf.org; Tue, 23 Mar 2004 18:23:03 -0500 Received: from patty.levels.unisa.edu.au ([130.220.36.156]) by ietf-mx with esmtp (Exim 4.12) id 1B5vDg-00009Z-00 for manet@ietf.org; Tue, 23 Mar 2004 18:22:05 -0500 Received: from server1 (server1 [172.17.0.2]) by patty.levels.unisa.edu.au (8.12.10/8.12.2) with SMTP id i2NNLsCE005319; Wed, 24 Mar 2004 09:51:54 +1030 (CST) Date: Wed, 24 Mar 2004 09:51:54 +1030 (CST) From: Peter Pham To: =?iso-8859-1?q?kani=20sundar?= cc: manet@ietf.org Subject: Re: [manet] Problem in running OPNET model simulation for DSR In-Reply-To: <20040323190156.18552.qmail@web12906.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Tick the forced compile option to recompile the whole model. It should work. Best Regards. Peter Phuc Pham ========================================== The University of South Australia Institute for Telecommunications Research Mawson Lakes Campus SA5095 Office: 08-83025188 Fax : 08-83023873 Email : ppham@spri.levels.unisa.edu.au WWW : http://www.itr.unisa.edu.au/~ppham ========================================== On Tue, 23 Mar 2004, =?iso-8859-1?q?kani=20sundar?= wrote: > Hi all, > > I am currently doing my research in simulation of DSR protocol in adhoc networks. > > I am using opnet for my simulation and when i run the the example file for DSR then iam getting the error message as follows... > > <<>> > Object repository construction failed due to errors encountered by the binder program(bind_so_msvc) > <<< Program Abort>>> > Error encountered rebuilding repository-unable to proceed > ---- > > Creating library C:\PROGRA~1\OPNET\10.0.A\sys\lib\project2-scenario1.dev32.io.nt.lib and C:\PROGRA~1\OPNET\10.0.A\sys\lib\project2-scenario1.dev32.io.nt.exp > > wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_mac_pk_bbstruct_copy > wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_mac_pk_bbstruct_destroy > wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_mac_pk_bbstruct_create > wlan_mac.dev32.io.pr.obj : error LNK2001: unresolved external symbol _wlan_ap_reliablity_eval > wlan_power.dev32.io.ps.obj : error LNK2001: unresolved external symbol _wlan_ap_reliabilty_eval > Creating library C:\PROGRA~1\OPNET\10.0.A\sys\lib\project2-scenario1.dev32.io.nt.dll : fatal error LNK1120 : 4 unresolved externals > > This error is coming whenever i run the manet for simulation in opnet > > Can anyone pl help me out from this problem > > Kanimaran Sundarasekaran > > > > > > > --------------------------------- > Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 23 22:53:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23296 for ; Tue, 23 Mar 2004 22:53:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zRl-0001Uq-O4 for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 22:52:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O3qrEI005751 for manet-archive@odin.ietf.org; Tue, 23 Mar 2004 22:52:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zRl-0001Ug-J2 for manet-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 22:52:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23290 for ; Tue, 23 Mar 2004 22:52:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5zRi-00023e-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 22:52:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5zR1-0001xZ-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 22:52:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5zQ8-0001rW-00 for manet-web-archive@ietf.org; Tue, 23 Mar 2004 22:51:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zPz-0001AI-FU; Tue, 23 Mar 2004 22:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5zPh-00018x-79 for manet@optimus.ietf.org; Tue, 23 Mar 2004 22:50:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23224 for ; Tue, 23 Mar 2004 22:50:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5zPd-0001nm-00 for manet@ietf.org; Tue, 23 Mar 2004 22:50:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5zOl-0001gE-00 for manet@ietf.org; Tue, 23 Mar 2004 22:49:48 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1B5zNq-0001QO-00 for manet@ietf.org; Tue, 23 Mar 2004 22:48:51 -0500 Received: from canth.inria.fr (canth.inria.fr [128.93.17.102]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2O3mHHd015300; Wed, 24 Mar 2004 04:48:17 +0100 Received: from adjih by canth.inria.fr with local (Exim 3.36 #1 (Debian)) id 1B5zNI-00045E-00; Wed, 24 Mar 2004 04:48:16 +0100 From: Cedric Adjih Reply-To: Cedric.Adjih@inria.fr To: manet@ietf.org Subject: Re: [manet] MID message received from a non-symmetric neighbor Date: Wed, 24 Mar 2004 04:48:16 +0100 User-Agent: KMail/1.6.1 Cc: Li Li References: <005301c40025$0235b280$6de325da@jafymobile> <016a01c40122$44eb3e80$1f175d80@inria.fr> <200403122039.i2CKdi6R008326@mercury.dgim.crc.ca> In-Reply-To: <200403122039.i2CKdi6R008326@mercury.dgim.crc.ca> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403240448.16609.Cedric.Adjih@inria.fr> X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday 12 March 2004 21:46, Li Li wrote: > If a MID message is received from a non-symmetric neighbor, we'd discard > the message. Why is this? For security reasons? If we don't discard the > MID, what're the negative impacts? Hello Li Li, The issue you are rising, is indeed subtle ;-): the reason MID message processing discards packets from non-symmetric neighbors (same for TC, and HNA), is mainly for simplicity reasons. It was introduced when OLSR protocol presentation was clarified and simplified around draft-version-8: . the problem is that even if you process messages from non-symetric neighbors, the "default forwarding algorithm" won't put them in the duplicate table. As a result, the negative impact is that you could process the same MID twice. Actually, if the network is static, and there is no packet loss, you will also receive it from some symmetrical neighbor, so you would process it at least twice. Not satisfying :-) . if you want to prevent this, you have to add some flags in the duplicate table, and complicate the processing/forwarding algorithm a little bit. Well, it was decided that somehow, maybe the potential gain was not worth it. Hope this helps, Regards, -- Cedric _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 01:04:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28901 for ; Wed, 24 Mar 2004 01:04:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61Uc-0007fa-8Q for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 01:03:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O63wXs029476 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 01:03:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61Uc-0007fL-4X for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 01:03:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28882 for ; Wed, 24 Mar 2004 01:03:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61UZ-0002mk-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 01:03:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61Te-0002c1-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 01:02:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B61Ss-0002R8-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 01:02:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61Sk-0007D5-0R; Wed, 24 Mar 2004 01:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B61SZ-0007BI-Pr for manet@optimus.ietf.org; Wed, 24 Mar 2004 01:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28749 for ; Wed, 24 Mar 2004 01:01:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B61SX-0002OL-00 for manet@ietf.org; Wed, 24 Mar 2004 01:01:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B61RX-0002DT-00 for manet@ietf.org; Wed, 24 Mar 2004 01:00:48 -0500 Received: from gateway.scalable-networks.com ([63.205.33.202] helo=mithrandir.scalable-networks.com) by ietf-mx with smtp (Exim 4.12) id 1B61QZ-000235-00 for manet@ietf.org; Wed, 24 Mar 2004 00:59:47 -0500 Received: (qmail 32452 invoked from network); 24 Mar 2004 05:59:47 -0000 Received: from web.lan.scalable-solutions.com (HELO cs.ucla.edu) (sssmail@192.168.0.1) by 0 with SMTP; 24 Mar 2004 05:59:47 -0000 Message-ID: <406123A9.1090408@cs.ucla.edu> Date: Tue, 23 Mar 2004 21:59:05 -0800 From: Mineo Takai User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF Manet Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Reminder: MobiHoc 2004 Call for Posters 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,LINES_OF_YELLING, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Our apologies if you receive multiple copies of this message. ---------- CALL FOR POSTERS The Fifth ACM International Symposium on Mobile Ad Hoc Networking and Computing MobiHoc 2004 http://www.sigmobile.org/mobihoc/2004/ May 24-26, 2004 Tokyo, Japan MobiHoc 2004 is the fifth of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 at Long Beach, California, in 2002 at Lausanne, Switzerland, in 2003 at Annapolis, Maryland, and now in 2004 at Tokyo, Japan, on Monday through Wednesday, May 24-26, 2004. The symposium will include a poster session that highlights recent and on-going research that has not been published elsewhere. Poster submissions will be reviewed and the summaries of accepted posters will appear in the SIGMOBILE's Mobile Computing Communications Review (MC2R). Submissions should consist of a 2-page summary as well as a rough draft of the poster in PDF. Please contact the Poster Co-Chairs, Mineo Takai and Srikanth V. Krishnamurthy for further details. SUBMISSION INSTRUCTIONS: Submissions for posters should be unpublished and must not be currently under review for any other publication, conference or workshop. Authors of accepted posters will need to sign an ACM copyright release form and present their poster at the conference. All poster submissions will be reviewed and their summaries will appear in the SIGMOBILE's Mobile Computing & Communications Review (MC2R). Poster submissions consist of two parts -- a two-page summary, and a draft of the poster layout. Both parts of the submission must be in PDF. The summary must be formatted for US Letter (8.5" x 11") paper with 1" margins all around, 10 point font (minimum), and single line spacing (minimum) for the main text. The purpose of the summary is to evaluate the quality, interest and depth of the work to be presented. The summary is the primary item for review consideration. The poster draft may be either a single sheet or multiple sheets (all 8.5" x 11"). The draft is meant to provide an initial impression of the organization and presentation of the work. It does not need to be a completed poster but needs to at least convey the flow and presentation of what will be the final poster. The final posters will be 1 x 1.25 meters. We must be able to print your summary and draft once they are submitted. Due to the large variety of systems available for formatting papers and producing PDF, this is not always possible for some systems. To maximize the chances that your paper will print correctly, please use only standard printer fonts (e.g., Times Roman, Helvetica, etc.); other fonts may be used but must be included in the PDF file. IMPORTANT: The two-page summary of the poster and the poster draft will be submitted to DIFFERENT places. The summary will be submitted over the web at http://edas.info (please select the MobiHoc Poster as the conference). The poster submission link will be enabled 10 days prior to the poster deadline. After you have successfully uploaded your summary, the poster draft should be mailed to the Poster Co-Chairs Mineo Takai and Srikanth V. Krishnamurthy indicating the Paper ID that was assigned to the poster summary by EDAS. IMPORTANT DATES: Poster Submission Deadline March 24, 2004 Notification of Acceptance April 19, 2004 For further details or any questions about the poster session, please contact the Poster Co-Chairs, Mineo Takai and Srikanth V. Krishnamurthy . For more information about the symposium, please visit the MobiHoc 2004 Home Page at http://www.sigmobile.org/mobihoc/2004/, or send email to the General Chair, Jun Murai , or to . _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 02:38:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01217 for ; Wed, 24 Mar 2004 02:38:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62xo-0000pW-I8 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 02:38:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O7cCMm003186 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 02:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62xo-0000pJ-CA for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 02:38:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01184 for ; Wed, 24 Mar 2004 02:38:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62xj-0005Wo-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 02:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B62wm-0005Je-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 02:37:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B62vz-00057J-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 02:36:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62vj-0000AU-CG; Wed, 24 Mar 2004 02:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B62uu-0008Ti-Dl for manet@optimus.ietf.org; Wed, 24 Mar 2004 02:35:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01009 for ; Wed, 24 Mar 2004 02:35:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B62uq-0004px-00 for manet@ietf.org; Wed, 24 Mar 2004 02:35:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B62tq-0004dt-00 for manet@ietf.org; Wed, 24 Mar 2004 02:34:07 -0500 Received: from netns.kjist.ac.kr ([203.237.53.16] helo=NML.netmedia.kjist.ac.kr) by ietf-mx with esmtp (Exim 4.12) id 1B62tG-0004Rl-00 for manet@ietf.org; Wed, 24 Mar 2004 02:33:30 -0500 Received: from netmediahyyoon ([203.237.53.145]) by NML.netmedia.kjist.ac.kr with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Mar 2004 16:31:08 +0900 Reply-To: From: "Ha Young, Yoon" To: Date: Wed, 24 Mar 2004 16:33:31 +0900 Organization: NETMEDIA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C411BD.BECDB560" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQRck4ijudUzYumQpC/H5ezDv7+zQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 24 Mar 2004 07:31:08.0390 (UTC) FILETIME=[F93FC860:01C41171] Subject: [manet] Why MAODV and ODMRP draft is not exist in the MANET working group 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_FONT_FACE_BAD, HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C411BD.BECDB560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi seniors, I really wonder why MAODV and ODMRP drafts are disused. Are they out of scope of MANET working group? Please, let me sense the reason. Yours, HaYoung Yoon ------=_NextPart_000_0000_01C411BD.BECDB560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi = seniors,

     =

    I = really wonder why MAODV and ODMRP drafts are disused.

     =

    Are = they out of scope of MANET working group?

     =

    Please, let me = sense the reason.

     =

    Yours,=

     =

    HaYoung = Yoon

     

    ------=_NextPart_000_0000_01C411BD.BECDB560-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 03:20:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04066 for ; Wed, 24 Mar 2004 03:20:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63cY-0005hR-Vk for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 03:20:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O8KIZJ021902 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 03:20:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63cY-0005hB-Kn for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 03:20:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04029 for ; Wed, 24 Mar 2004 03:20:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B63cW-0006uL-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 03:20:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B63bQ-0006dk-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 03:19:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B63aQ-0006OF-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 03:18:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63aL-0005Dk-MO; Wed, 24 Mar 2004 03:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B63ZT-0005CE-TU for manet@optimus.ietf.org; Wed, 24 Mar 2004 03:17:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03792 for ; Wed, 24 Mar 2004 03:17:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B63ZR-000682-00 for manet@ietf.org; Wed, 24 Mar 2004 03:17:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B63YZ-0005vt-00 for manet@ietf.org; Wed, 24 Mar 2004 03:16:12 -0500 Received: from web40809.mail.yahoo.com ([66.218.78.186]) by ietf-mx with smtp (Exim 4.12) id 1B63Xp-0005hf-00 for manet@ietf.org; Wed, 24 Mar 2004 03:15:25 -0500 Message-ID: <20040324081455.398.qmail@web40809.mail.yahoo.com> Received: from [220.255.9.137] by web40809.mail.yahoo.com via HTTP; Wed, 24 Mar 2004 00:14:55 PST Date: Wed, 24 Mar 2004 00:14:55 -0800 (PST) From: Alvin Valera Subject: Re: [manet] Local recovery of AODV To: Ali Hamidian , genping liu Cc: manet@ietf.org In-Reply-To: <405EB237.6030508@telecom.lth.se> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi All, I discussed this behavior in my master's thesis. My observations are: (1) Additional routing overhead is generated for local repair. Supposedly, this overhead should be less than the overhead of performing a new route discovery. (2) In a congested and highly mobile environment, many local repairs fail. The penalty for such failures is a significant increase in the routing overhead. (Why? because routing overhead = local repair overhead + route discovery overhead) Such additional overhead then worsens congestion and increases packet loss. (3) In light load environments, I observed that local repair is advantageous, that is, it improves packet delivery. Best regards, Alvin --- Ali Hamidian wrote: > Hi, > > genping liu wrote: > > > hi, > > > > I was using ns2.1b8a to simulate of the peformance > of AODV with and > > without > > local recovery. it is expected that AODV with > local recovery should > > outperform AODV without. however, our simulation > results shows that the > > local recovery decreased the performance of AODV. > our simulation scenario > > is > > map of 2000mx1600m, node number=100, transmission > range of 350, random > > way > > point with medium mobility. > > > > anyone know that reason that local recovery > decreased the performance of > > AODV? > > I don't think that local recovery is implemented > correctly in the aodv > code of ns-2.1b8(a). I also think there is some > comment in aodv.h which > says that local recovery shouldn't be used and that > it doesn't show any > significant performance improvements. > > Regards > Ali Hamidian > > > > > Thanks > > > > Regards > > Genping > > > > > _________________________________________________________________ > > Get 10mb of inbox space with MSN Hotmail Extra > Storage > > http://join.msn.com/?pgmarket=en-sg > > > > > > _______________________________________________ > > 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 __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 04:36:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09072 for ; Wed, 24 Mar 2004 04:36:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64o4-0005XZ-TH for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 04:36:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O9aG54021286 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 04:36:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64o3-0005X7-Ch for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 04:36:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09013 for ; Wed, 24 Mar 2004 04:36:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B64o0-0001NG-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 04:36:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B64n7-00016j-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 04:35:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B64m1-0000qZ-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 04:34:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64lv-00057Y-OF; Wed, 24 Mar 2004 04:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64lT-00054u-JX for manet@optimus.ietf.org; Wed, 24 Mar 2004 04:33:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08847 for ; Wed, 24 Mar 2004 04:33:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B64lQ-0000cq-00 for manet@ietf.org; Wed, 24 Mar 2004 04:33:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B64kF-0000Io-00 for manet@ietf.org; Wed, 24 Mar 2004 04:32:20 -0500 Received: from venus.uos.ac.kr ([203.249.110.25]) by ietf-mx with esmtp (Exim 4.12) id 1B64j3-0007Uw-00 for manet@ietf.org; Wed, 24 Mar 2004 04:31:06 -0500 Received: from LocalHost (blhole.uos.ac.kr [203.249.110.30]) (authenticated bits=0) by venus.uos.ac.kr (8.12.3/8.12.3/Debian -4) with ESMTP id i2O9UTUb020929; Wed, 24 Mar 2004 18:30:30 +0900 Message-Id: <200403240930.i2O9UTUb020929@venus.uos.ac.kr> From: "Youngmin Kim" To: , Subject: RE: [manet] Why MAODV and ODMRP draft is not exist in the MANET working group Date: Wed, 24 Mar 2004 18:30:29 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01C411CE.167B21C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: AcQRck4ijudUzYumQpC/H5ezDv7+zQAEBxZg 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_FONT_FACE_BAD,HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_00AB_01C411CE.167B21C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That's right!! Multicasting is out of scope of MANET You can read Charter of MANET _____ From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Ha Young, Yoon Sent: Wednesday, March 24, 2004 4:34 PM To: manet@ietf.org Subject: [manet] Why MAODV and ODMRP draft is not exist in the MANET working group Hi seniors, I really wonder why MAODV and ODMRP drafts are disused. Are they out of scope of MANET working group? Please, let me sense the reason. Yours, HaYoung Yoon ------=_NextPart_000_00AB_01C411CE.167B21C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    That’s right!!

    Multicasting is out of = scope of MANET

     

    You can read Charter of = MANET

     

     

    From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Ha Young, Yoon
    Sent: Wednesday, March = 24, 2004 4:34 = PM
    To: manet@ietf.org
    Subject: [manet] Why = MAODV and ODMRP draft is not exist in the MANET working group

     

    Hi = seniors,

     

    I really wonder why MAODV = and ODMRP drafts are disused.

     

    Are they out of scope of = MANET working group?

     

    Please, let me sense the = reason.

     

    Yours,

     

    HaYoung = Yoon

     

    ------=_NextPart_000_00AB_01C411CE.167B21C0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 04:46:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09598 for ; Wed, 24 Mar 2004 04:46:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64xg-0006uq-4O for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 04:46:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2O9kBM4026575 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 04:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64xd-0006uX-HU for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 04:46:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09561 for ; Wed, 24 Mar 2004 04:46:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B64xa-0003gv-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 04:46:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B64wd-0003T6-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 04:45:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B64vg-0003GW-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 04:44:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64vb-0006Um-2z; Wed, 24 Mar 2004 04:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B64uk-0006TK-M7 for manet@optimus.ietf.org; Wed, 24 Mar 2004 04:43:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09469 for ; Wed, 24 Mar 2004 04:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B64uh-00033D-00 for manet@ietf.org; Wed, 24 Mar 2004 04:43:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B64tq-0002q9-00 for manet@ietf.org; Wed, 24 Mar 2004 04:42:15 -0500 Received: from netns.kjist.ac.kr ([203.237.53.16] helo=NML.netmedia.kjist.ac.kr) by ietf-mx with esmtp (Exim 4.12) id 1B64t7-0002dX-00 for manet@ietf.org; Wed, 24 Mar 2004 04:41:29 -0500 Subject: RE: [manet] Why MAODV and ODMRP draft is not exist in the MANET working group MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41183.DA43233C" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 24 Mar 2004 18:39:07 +0900 content-class: urn:content-classes:message Message-ID: Thread-Topic: [manet] Why MAODV and ODMRP draft is not exist in the MANET working group Thread-Index: AcQRck4ijudUzYumQpC/H5ezDv7+zQAEBxZgAABX4cA= From: "HaYoung Yoon" To: "Youngmin Kim" , 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41183.DA43233C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Youngmin Kim =20 Thank you for your answer. Have a nice day.:-) =20 Yours, Hayoung Yoon =20 _____ =20 From: Youngmin Kim [mailto:blhole@venus.uos.ac.kr]=20 Sent: Wednesday, March 24, 2004 6:30 PM To: HaYoung Yoon; manet@ietf.org Subject: RE: [manet] Why MAODV and ODMRP draft is not exist in the MANET working group =20 That's right!! Multicasting is out of scope of MANET =20 You can read Charter of MANET =20 =20 _____ =20 From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Ha Young, Yoon Sent: Wednesday, March 24, 2004 4:34 PM To: manet@ietf.org Subject: [manet] Why MAODV and ODMRP draft is not exist in the MANET working group =20 Hi seniors, =20 I really wonder why MAODV and ODMRP drafts are disused. =20 Are they out of scope of MANET working group? =20 Please, let me sense the reason. =20 Yours, =20 HaYoung Yoon =20 ------_=_NextPart_001_01C41183.DA43233C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear Youngmin Kim

     =

    Thank you for = your answer.

    Have a nice day.:-)

     =

    Yours,=

    Hayoung = Yoon

     =

    From: Youngmin Kim [mailto:blhole@venus.uos.ac.kr]
    Sent: Wednesday, March = 24, 2004 6:30 = PM
    To: HaYoung Yoon; = manet@ietf.org
    Subject: RE: [manet] Why = MAODV and ODMRP draft is not exist in the MANET working group

     

    That’s right!!

    Multicasting is out of scope of MANET

     =

    You = can read Charter of MANET

     =

     =

    From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Ha Young, Yoon
    Sent: Wednesday, March = 24, 2004 4:34 = PM
    To: manet@ietf.org
    Subject: [manet] Why = MAODV and ODMRP draft is not exist in the MANET working group

     

    Hi = seniors,

     

    I really wonder why MAODV = and ODMRP drafts are disused.

     

    Are they out of scope of = MANET working group?

     

    Please, let me sense the = reason.

     

    Yours,

     

    HaYoung = Yoon

     

    ------_=_NextPart_001_01C41183.DA43233C-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 07:36:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18486 for ; Wed, 24 Mar 2004 07:36:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67cE-00071k-W8 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 07:36:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OCaEmW027011 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 07:36:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67cE-00071a-RU for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 07:36:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18410 for ; Wed, 24 Mar 2004 07:36:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B67cE-0002yx-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 07:36:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B67bE-0002hd-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 07:35:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B67aI-0002Rr-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 07:34:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67a6-0006Jn-G6; Wed, 24 Mar 2004 07:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B67ZZ-0006IC-0H for manet@optimus.ietf.org; Wed, 24 Mar 2004 07:33:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18302 for ; Wed, 24 Mar 2004 07:33:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B67ZY-0002F4-00 for manet@ietf.org; Wed, 24 Mar 2004 07:33:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B67Ya-0001zZ-00 for manet@ietf.org; Wed, 24 Mar 2004 07:32:29 -0500 Received: from netns.kjist.ac.kr ([203.237.53.16] helo=NML.netmedia.kjist.ac.kr) by ietf-mx with esmtp (Exim 4.12) id 1B67Xm-0001mB-00 for manet@ietf.org; Wed, 24 Mar 2004 07:31:38 -0500 Received: from netmediahyyoon ([203.237.53.145]) by NML.netmedia.kjist.ac.kr with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Mar 2004 21:29:13 +0900 Reply-To: From: "Ha Young, Yoon" To: , Date: Wed, 24 Mar 2004 21:31:36 +0900 Organization: NETMEDIA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C411E7.638821C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQRm/KcMLtsg0FnTua3VzxdijNd6w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 24 Mar 2004 12:29:13.0828 (UTC) FILETIME=[9DCD0A40:01C4119B] Subject: [manet] Is there ODMRP implementation codes on NS-2? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_FONT_FACE_BAD, HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C411E7.638821C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I want to find ODMRP implementation codes on NS-2. If there is one who knows about that even URL or key-words, let me know that, please. Yours, Hayoung Yoon ------=_NextPart_000_0004_01C411E7.638821C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear = all,

     

     I want to find ODMRP = implementation codes on NS-2.

     

    If there is one who knows = about that even URL or key-words, let me know that, = please.

     

    Yours,

     

    Hayoung = Yoon

    ------=_NextPart_000_0004_01C411E7.638821C0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 09:45:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25215 for ; Wed, 24 Mar 2004 09:45:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69dB-0002ZQ-VA for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 09:45:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OEjLDb009878 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 09:45:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69dB-0002ZF-8L for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 09:45:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25173 for ; Wed, 24 Mar 2004 09:45:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69d9-0004Th-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 09:45:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69cA-0004Cf-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 09:44:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B69bB-0003x0-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 09:43:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69aw-0002Cz-Al; Wed, 24 Mar 2004 09:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B69aF-000239-6n for manet@optimus.ietf.org; Wed, 24 Mar 2004 09:42:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25081 for ; Wed, 24 Mar 2004 09:42:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B69aD-0003hc-00 for manet@ietf.org; Wed, 24 Mar 2004 09:42:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B69Za-0003Th-00 for manet@ietf.org; Wed, 24 Mar 2004 09:41:39 -0500 Received: from mercury.dgim.crc.ca ([142.92.39.129]) by ietf-mx with esmtp (Exim 4.12) id 1B69Yf-0002xs-00 for manet@ietf.org; Wed, 24 Mar 2004 09:40:41 -0500 Received: from ROGER (roger.dgrc.crc.ca [142.92.38.14]) by mercury.dgim.crc.ca (8.12.11/8.12.11) with SMTP id i2OEe9TO019649; Wed, 24 Mar 2004 09:40:10 -0500 Message-Id: <200403241440.i2OEe9TO019649@mercury.dgim.crc.ca> X-Sender: lli@mail.crc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 24 Mar 2004 09:46:53 -0500 To: Cedric.Adjih@inria.fr, manet@ietf.org From: Li Li Subject: Re: [manet] MID message received from a non-symmetric neighbor In-Reply-To: <200403240448.16609.Cedric.Adjih@inria.fr> References: <200403122039.i2CKdi6R008326@mercury.dgim.crc.ca> <005301c40025$0235b280$6de325da@jafymobile> <016a01c40122$44eb3e80$1f175d80@inria.fr> <200403122039.i2CKdi6R008326@mercury.dgim.crc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.39 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Thanks a lot! Cedric. It does help to explain for me. Li Li At 04:48 AM 3/24/2004 +0100, Cedric Adjih wrote: >On Friday 12 March 2004 21:46, Li Li wrote: >> If a MID message is received from a non-symmetric neighbor, we'd discard >> the message. Why is this? For security reasons? If we don't discard the >> MID, what're the negative impacts? > >Hello Li Li, > >The issue you are rising, is indeed subtle ;-): the reason MID message >processing discards packets from non-symmetric neighbors >(same for TC, and HNA), is mainly for simplicity reasons. > >It was introduced when OLSR protocol presentation was clarified >and simplified around draft-version-8: >. the problem is that even if you process messages from non-symetric >neighbors, the "default forwarding algorithm" won't put them >in the duplicate table. As a result, the negative impact is >that you could process the same MID twice. Actually, if the >network is static, and there is no packet loss, you >will also receive it from some symmetrical neighbor, >so you would process it at least twice. Not satisfying :-) >. if you want to prevent this, you have to add some flags in >the duplicate table, and complicate the processing/forwarding >algorithm a little bit. Well, it was decided that somehow, >maybe the potential gain was not worth it. > >Hope this helps, >Regards, >-- Cedric > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 11:34:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04944 for ; Wed, 24 Mar 2004 11:34:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BK1-0003VI-Av for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 11:33:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGXfwo013468 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 11:33:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BK1-0003V9-6C for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 11:33:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04916 for ; Wed, 24 Mar 2004 11:33:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BK0-0001Ob-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 11:33:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BJ7-0001Il-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 11:32:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6BIW-0001Cn-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 11:32:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BIQ-00034A-95; Wed, 24 Mar 2004 11:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BHr-00031S-CK for manet@optimus.ietf.org; Wed, 24 Mar 2004 11:31:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04757 for ; Wed, 24 Mar 2004 11:31:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BHq-00019p-00 for manet@ietf.org; Wed, 24 Mar 2004 11:31:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BGw-00016H-00 for manet@ietf.org; Wed, 24 Mar 2004 11:30:30 -0500 Received: from ubatuba.dca.fee.unicamp.br ([143.106.11.134]) by ietf-mx with esmtp (Exim 4.12) id 1B6BGP-00012G-00 for manet@ietf.org; Wed, 24 Mar 2004 11:30:02 -0500 Received: from caolho.dca.fee.unicamp.br (caolho.dca.fee.unicamp.br [143.106.11.144]) by ubatuba.dca.fee.unicamp.br (8.9.3p3/8.9.3) with ESMTP id NAA08548; Wed, 24 Mar 2004 13:28:09 -0300 (EST) Received: from localhost by caolho.dca.fee.unicamp.br (8.9.3/8.9.3) with ESMTP id NAA03214; Wed, 24 Mar 2004 13:27:17 -0300 (EST) X-Authentication-Warning: caolho.dca.fee.unicamp.br: siqueira owned process doing -bs Date: Wed, 24 Mar 2004 13:27:16 -0300 (EST) From: Marcos Antonio de Siqueira To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] OLSP IPv4 autoconfiguration 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, I have a question about IPv4 autoconfiguration and OLSR. If anybody could help, I'd be glad! Section 7 of RFC3626 comments about "Link Sensing" - stating that the "Link Set" is filled when new neighbors are detected. The RFC states that on the Link sensing process, L_local_if_addr = "Address of the interface which received the Hello message". Using OLSR over IPv4 would be helpful if the interfaces connected to the same link had IP addresses on the same subnet. How OLSR could solve this issue? But, if a new node is turned on, ad if it doesn't have any information about the IP subnet address of the new neighbors, OLSR wouldn't work, since it exchanges messages over UDP!! How could this tie be undone? Marcos Siqueira. Campinas University, SP-BR. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 12:15:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07048 for ; Wed, 24 Mar 2004 12:15:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BxZ-0000SD-Dp for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 12:14:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OHEXPi001739 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 12:14:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BxZ-0000Ry-9p for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 12:14:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07016 for ; Wed, 24 Mar 2004 12:14:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BxX-0004Lo-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 12:14:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Bwa-0004G2-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 12:13:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Bvl-0004Av-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 12:12:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BvU-0008SE-3M; Wed, 24 Mar 2004 12:12:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BuS-0008Jg-L2 for manet@optimus.ietf.org; Wed, 24 Mar 2004 12:11:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06853 for ; Wed, 24 Mar 2004 12:11:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BuR-00043o-00 for manet@ietf.org; Wed, 24 Mar 2004 12:11:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BtY-00041U-00 for manet@ietf.org; Wed, 24 Mar 2004 12:10:24 -0500 Received: from [193.213.212.51] (helo=trinity.gnist.org) by ietf-mx with esmtp (Exim 4.12) id 1B6Bsu-0003yk-00 for manet@ietf.org; Wed, 24 Mar 2004 12:09:45 -0500 Received: from localhost (unknown [127.0.0.1]) by trinity.gnist.org (Postfix) with ESMTP id 3F221633061; Wed, 24 Mar 2004 18:09:44 +0100 (CET) Received: from trinity.gnist.org ([127.0.0.1]) by localhost (trinity.gnist.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32628-08; Wed, 24 Mar 2004 18:09:39 +0100 (CET) Received: from olsr.org (41.80-203-47.nextgentel.com [80.203.47.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trinity.gnist.org (Postfix) with ESMTP id C1080633060; Wed, 24 Mar 2004 18:09:39 +0100 (CET) Message-ID: <4061BEC2.4060203@olsr.org> Date: Wed, 24 Mar 2004 18:00:50 +0100 From: Andreas T Organization: olsr.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Marcos Antonio de Siqueira Cc: manet@ietf.org Subject: Re: [manet] OLSP IPv4 autoconfiguration References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Marcos Antonio de Siqueira wrote: > But, if a new node is turned on, ad if it doesn't have any information > about the IP subnet address of the new neighbors, OLSR wouldn't work, > since it exchanges messages over UDP!! >=20 > How could this tie be undone? One solution would be to broadcast OLSR control-traffic on 255.255.255.25= 5. --=20 --=20 Andreas T=F8nnesen(andreas@olsr.org) UniK University Graduation Center University of Oslo http://www.olsr.org _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 17:46:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26653 for ; Wed, 24 Mar 2004 17:46:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6H7u-0007zP-8Q for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 17:45:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OMjYZ8030704 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 17:45:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6H7t-0007z9-VW for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 17:45:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26639 for ; Wed, 24 Mar 2004 17:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6H7r-0000p1-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 17:45:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6H6w-0000mT-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 17:44:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6H6c-0000kD-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 17:44:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6H6Q-0007Hr-7o; Wed, 24 Mar 2004 17:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6H5v-0007GG-Ki for manet@optimus.ietf.org; Wed, 24 Mar 2004 17:43:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26593 for ; Wed, 24 Mar 2004 17:43:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6H5t-0000jE-00 for manet@ietf.org; Wed, 24 Mar 2004 17:43:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6H4u-0000hZ-00 for manet@ietf.org; Wed, 24 Mar 2004 17:42:28 -0500 Received: from web61104.mail.yahoo.com ([216.155.196.106]) by ietf-mx with smtp (Exim 4.12) id 1B6H4E-0000dw-00 for manet@ietf.org; Wed, 24 Mar 2004 17:41:47 -0500 Message-ID: <20040324211808.63298.qmail@web61104.mail.yahoo.com> Received: from [141.156.71.10] by web61104.mail.yahoo.com via HTTP; Wed, 24 Mar 2004 13:18:08 PST Date: Wed, 24 Mar 2004 13:18:08 -0800 (PST) From: manet user To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-915202961-1080163088=:63178" Subject: [manet] OLSR implementation 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-915202961-1080163088=:63178 Content-Type: text/plain; charset=us-ascii Hi, I am trying to implement OLSR according to RFC 3626. I have couple of doubts during implementation. Any comment or suggestion will be helpful. 1) While populating 2 hop neighbor table, according to RFC, if "interface address" listed in Hello message does not belong to me, add it in 2 hop neighbor table. There is no check if that address belongs to 1 hop neighbor (i.e. listed in neighbor table). Is it correct or i am missing something ? 2) In terms of "associated neighbor/link tuples" concept, each neighbor set entry will point to the list of corresponding "list of link set entries" (under the name of associated link tuples) ?? Similarly, each link set entry will point to corresponding "neighbor set entry" (under assocaited neighbor set name) ? This may be implementation detail, but just wanted to know if this will address the expected concept of associated nbr/link tuples. 3) In case of addition of a link to an existing neighbor, does neighborhood changes (leading to routing table recomputation)? Your comments will be greatly appreciated. Thanks in advance. -MS Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. --0-915202961-1080163088=:63178 Content-Type: text/html; charset=us-ascii
    Hi,
     
    I am trying to implement OLSR according to RFC 3626. I have couple of doubts during implementation. Any comment or suggestion will be helpful.
     
    1) While populating 2 hop neighbor table, according to RFC, if "interface address" listed in Hello message does not belong to me, add it in 2 hop neighbor table. There is no check if that address belongs to 1 hop neighbor (i.e. listed in neighbor table). Is it correct or i am missing something ?
     
    2) In terms of "associated neighbor/link tuples" concept, each neighbor set entry will point to the list of corresponding "list of link set entries" (under the name of associated link tuples) ??
    Similarly, each link set entry will point to corresponding "neighbor set entry" (under assocaited neighbor set name) ?
     
    This may be implementation detail, but just wanted to know if this will address the expected concept of associated nbr/link tuples.
     
    3) In case of addition of a link to an existing neighbor, does neighborhood changes (leading to routing table recomputation)?
     
    Your comments will be greatly appreciated. Thanks in advance.
     
    -MS

    Do you Yahoo!?
    Yahoo! Finance Tax Center - File online. File on time. --0-915202961-1080163088=:63178-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 21:18:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07337 for ; Wed, 24 Mar 2004 21:18:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KRC-0002tD-3C for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 21:17:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P2HgCa011103 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 21:17:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KRB-0002sz-VO for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 21:17:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07333 for ; Wed, 24 Mar 2004 21:17:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6KR9-0000nb-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 21:17:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6KQD-0000kB-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 21:16:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6KPj-0000gA-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 21:16:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KPa-0002eg-03; Wed, 24 Mar 2004 21:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6KPC-0002cy-ML for manet@optimus.ietf.org; Wed, 24 Mar 2004 21:15:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07292 for ; Wed, 24 Mar 2004 21:15:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6KPA-0000ev-00 for manet@ietf.org; Wed, 24 Mar 2004 21:15:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6KOI-0000ak-00 for manet@ietf.org; Wed, 24 Mar 2004 21:14:43 -0500 Received: from netns.kjist.ac.kr ([203.237.53.16] helo=NML.netmedia.kjist.ac.kr) by ietf-mx with esmtp (Exim 4.12) id 1B6KNM-0000Tp-00 for manet@ietf.org; Wed, 24 Mar 2004 21:13:44 -0500 Received: from netmediahyyoon ([203.237.53.145]) by NML.netmedia.kjist.ac.kr with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 Mar 2004 11:11:14 +0900 Reply-To: From: "Ha Young, Yoon" To: Date: Thu, 25 Mar 2004 11:13:39 +0900 Organization: NETMEDIA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C4125A.39DFEE70" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQSDskVpUSpP3fjRyShDJzJdZwy5g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 25 Mar 2004 02:11:15.0046 (UTC) FILETIME=[7389A860:01C4120E] Subject: [manet] Is there an available ODMRP implementation code on NS-2 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_FONT_FACE_BAD, HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C4125A.39DFEE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Is there an available ODMRP implementation code on NS-2. If there is one who knows about that even URL or key-words, let me know that, please. Yours, Hayoung Yoon ------=_NextPart_000_0008_01C4125A.39DFEE70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi all,

     

    Is = there an available ODMRP implementation code on NS-2.

     =

    If = there is one who knows about that even URL or key-words, let me = know

    that, = please.

     =

    Yours,=

     

    Hayoung = Yoon

     =

    ------=_NextPart_000_0008_01C4125A.39DFEE70-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 24 22:48:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11339 for ; Wed, 24 Mar 2004 22:48:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LqM-0000wu-CX for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 22:47:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P3lkQk003643 for manet-archive@odin.ietf.org; Wed, 24 Mar 2004 22:47:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LqM-0000wg-7B for manet-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 22:47:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11292 for ; Wed, 24 Mar 2004 22:47:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6LqI-0000ES-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 22:47:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6LpY-0000AH-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 22:46:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Lom-00005D-00 for manet-web-archive@ietf.org; Wed, 24 Mar 2004 22:46:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Lof-0000dE-Jf; Wed, 24 Mar 2004 22:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6LoV-0000cb-6G for manet@optimus.ietf.org; Wed, 24 Mar 2004 22:45:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11206 for ; Wed, 24 Mar 2004 22:45:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6LoR-00002g-00 for manet@ietf.org; Wed, 24 Mar 2004 22:45:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6LnT-0007kb-00 for manet@ietf.org; Wed, 24 Mar 2004 22:44:48 -0500 Received: from venus.uos.ac.kr ([203.249.110.25]) by ietf-mx with esmtp (Exim 4.12) id 1B6LmY-0007b2-00 for manet@ietf.org; Wed, 24 Mar 2004 22:43:51 -0500 Received: from LocalHost (blhole.uos.ac.kr [203.249.110.30]) (authenticated bits=0) by venus.uos.ac.kr (8.12.3/8.12.3/Debian -4) with ESMTP id i2P3hDUb026999; Thu, 25 Mar 2004 12:43:14 +0900 Message-Id: <200403250343.i2P3hDUb026999@venus.uos.ac.kr> From: "Youngmin Kim" To: , Subject: RE: [manet] Is there an available ODMRP implementation code on NS-2 Date: Thu, 25 Mar 2004 12:43:14 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DA_01C41266.BE1B7090" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: AcQSDskVpUSpP3fjRyShDJzJdZwy5gACbayA 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_FONT_FACE_BAD,HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_00DA_01C41266.BE1B7090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit http://www.monarch.cs.rice.edu/multicast_extensions.html _____ From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Ha Young, Yoon Sent: Thursday, March 25, 2004 11:14 AM To: manet@ietf.org Subject: [manet] Is there an available ODMRP implementation code on NS-2 Hi all, Is there an available ODMRP implementation code on NS-2. If there is one who knows about that even URL or key-words, let me know that, please. Yours, Hayoung Yoon ------=_NextPart_000_00DA_01C41266.BE1B7090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    http://= www.monarch.cs.rice.edu/multicast_extensions.html

     

     

    From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Ha Young, Yoon
    Sent: Thursday, March 25, = 2004 11:14 = AM
    To: manet@ietf.org
    Subject: [manet] Is there = an available ODMRP implementation code on NS-2

     

    Hi all,

     

    Is there an available ODMRP implementation code on NS-2.

     

    If there is one who knows = about that even URL or key-words, let me know

    that, = please.

     

    Yours,

     

    Hayoung = Yoon

     

    ------=_NextPart_000_00DA_01C41266.BE1B7090-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 25 03:25:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08761 for ; Thu, 25 Mar 2004 03:25:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6QAo-0008Tj-Vz for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 03:25:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2P8PA9u032586 for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 03:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6QAo-0008TV-MU for manet-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 03:25:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08749 for ; Thu, 25 Mar 2004 03:25:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6QAm-0004DY-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 03:25:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Q9p-00046e-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 03:24:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Q8z-0003zm-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 03:23:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Q8n-0007xZ-Kj; Thu, 25 Mar 2004 03:23:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Q2i-0007ko-PC for manet@optimus.ietf.org; Thu, 25 Mar 2004 03:16:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08447 for ; Thu, 25 Mar 2004 03:16:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Q2g-0003XG-00 for manet@ietf.org; Thu, 25 Mar 2004 03:16:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Q1o-0003Td-00 for manet@ietf.org; Thu, 25 Mar 2004 03:15:52 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1B6Q1M-0003Pk-00 for manet@ietf.org; Thu, 25 Mar 2004 03:15:24 -0500 Received: from canth.inria.fr (canth.inria.fr [128.93.17.102]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2P8EsHd027528; Thu, 25 Mar 2004 09:14:54 +0100 Received: from adjih by canth.inria.fr with local (Exim 3.36 #1 (Debian)) id 1B6Q0k-0005OS-00; Thu, 25 Mar 2004 09:14:46 +0100 From: Cedric Adjih Reply-To: Cedric.Adjih@inria.fr To: manet@ietf.org Subject: Re: [manet] OLSR implementation help Date: Thu, 25 Mar 2004 09:14:46 +0100 User-Agent: KMail/1.6.1 Cc: manet user , olsr@inria.fr References: <20040324211808.63298.qmail@web61104.mail.yahoo.com> In-Reply-To: <20040324211808.63298.qmail@web61104.mail.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403250914.46327.Cedric.Adjih@inria.fr> X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, On Wednesday 24 March 2004 22:18, manet user wrote: > Hi, > > I am trying to implement OLSR according to RFC 3626. I have couple of > doubts during implementation. Any comment or suggestion will be helpful. > > 1) While populating 2 hop neighbor table, according to RFC, if "interface > address" listed in Hello message does not belong to me, add it in 2 hop > neighbor table. There is no check if that address belongs to 1 hop neighbor > (i.e. listed in neighbor table). Is it correct or i am missing something ? This was intentional, although the reason is not laid out clearly: the reason is that if one of your neighbors moves slightly, your link to it may break, but it would still likely be a two-hop neighbor. The bet was that some two-hop neighbor relationships would still be valid in that case, so instead of waiting for the HELLOs of all neighbors in order fill the two-hop table with information about the moving previous-neighbor; proactively, the two-hop neighbor sets are made to include one-hop neighbor information. Of course, you probably noted that, then, the requirement of the RFC to ignore them, for instance in MPR calculation, would need to be implemented explicitly. Extra work ;-) > 2) In terms of "associated neighbor/link tuples" concept, each neighbor set > entry will point to the list of corresponding "list of link set entries" > (under the name of associated link tuples) ?? Similarly, each link set > entry will point to corresponding "neighbor set entry" (under assocaited > neighbor set name) ? > > This may be implementation detail, but just wanted to know if this will > address the expected concept of associated nbr/link tuples. Yes indeed, this is exactly the idea. Ah but also, when implementing the association that way, the only possible difficulty is handling main address change of a neighbor: if you were to create a new neighbor tuple with the new main address, the older link tuples might not point back to new neighbor tuple, which may, or may not create troubles later, depending on the implementation (been there, done that). For inquirying minds, the case of main address change is not as obscure as it may sounds, since it occurs when you are hearing a neighbor from one of its interface which has not the main address - that is, you should expect to met this case, as soon as you have one node with several interfaces in your network. > 3) In case of addition of a link to an existing neighbor, does neighborhood > changes (leading to routing table recomputation)? Yes, it's a good idea to consider that the neighborhood has changed (and to recompute MPRs and routing table). After all, that's what really happened :-) Happy to see there is even more interest in OLSR implementation, Regards, -- Cedric _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 25 09:28:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23697 for ; Thu, 25 Mar 2004 09:28:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vq1-0003jx-CN for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 09:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PES5Rq014376 for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 09:28:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Vq1-0003jn-8S for manet-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 09:28:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23558 for ; Thu, 25 Mar 2004 09:28:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Vpz-0000X1-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 09:28:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Vo1-0000Ay-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 09:26:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6VmZ-0007ly-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 09:24:31 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6Vap-0005YV-4J for manet-web-archive@ietf.org; Thu, 25 Mar 2004 09:12:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VZf-0007oP-1G; Thu, 25 Mar 2004 09:11:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Um1-0002w2-6Q for manet@optimus.ietf.org; Thu, 25 Mar 2004 08:19:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19396 for ; Thu, 25 Mar 2004 08:19:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6Um0-0000n8-00 for manet@ietf.org; Thu, 25 Mar 2004 08:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Ul1-0000fW-00 for manet@ietf.org; Thu, 25 Mar 2004 08:18:52 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1B6Uk2-0000Up-00 for manet@ietf.org; Thu, 25 Mar 2004 08:17:50 -0500 Received: from canth.inria.fr (canth.inria.fr [128.93.17.102]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2PDHIHd002755; Thu, 25 Mar 2004 14:17:18 +0100 Received: from adjih by canth.inria.fr with local (Exim 3.36 #1 (Debian)) id 1B6UjS-0005ap-00; Thu, 25 Mar 2004 14:17:14 +0100 From: Cedric Adjih Reply-To: Cedric.Adjih@inria.fr To: manet@ietf.org Subject: Re: [olsr] Re: [manet] OLSR implementation help Date: Thu, 25 Mar 2004 14:17:14 +0100 User-Agent: KMail/1.6.1 Cc: Ignacy Gawedzki , manet user , olsr@inria.fr References: <20040324211808.63298.qmail@web61104.mail.yahoo.com> <200403250914.46327.Cedric.Adjih@inria.fr> <20040325113851.GA14897@zenon.mine.nu> In-Reply-To: <20040325113851.GA14897@zenon.mine.nu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200403251417.14278.Cedric.Adjih@inria.fr> X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id i2PDHIHd002755 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Ignacy, On Thursday 25 March 2004 12:38, Ignacy Gawedzki wrote: > On Thu, Mar 25, 2004 at 09:14:46AM +0100, thus spake C=E9dric Adjih: > > For inquirying minds, the case of main address change is not as > > obscure as it may sounds, since it occurs when you are hearing a > > neighbor from one of its interface which has not the main address > > - that is, you should expect to met this case, as soon as you have > > one node with several interfaces in your network. > > This is wrong. Unless a node changes its main address itself, you woul= d > never add a tuple in any 1-hop neighbor set with the main address not > being the actual main address of the node. A new link to a 1-hop > neighbor is added upon reception of a HELLO message from that neighbor. > But the HELLO message, as well as any other OLSR message, contains the > originator address, which is *always* a node's main address. As a side > note, this information could be used to populate the Interface > Association Set for 1-hop neighbors, in addition to MID messages. This is perfectly true, it could be used. I forgot this important idea, I stand corrected, thank you for clearing this :-) But still, the problem, is twofolds: - we didn't precise that this (using HELLO to populate Multiple Interface Association Information Base) should be done in the RFC. A RFC-compliant implementation might choose to not to do that. - if you use HELLOs to populate the Multiple Interface Association Information Base, now the subtle issue is the following: what expire time do you use?=20 . It would make sense to use the vtime of the HELLO. . But if the vtime of the MID are lesser, really what you'd like to do is to take the vtime of the MID (because there might a very good reason why the other node set the MID to a low value). In practice using the vtime of the HELLO, is no problem, but this can lead to the theoritical following scenario, where an "unoptimized" implementation would have performed better, unless I am=20 mistaken: - a neighbor sends one HELLO with a big vtime (possible if it=20 relies on the "LOST" status to remove links if necessary later) - a multiple interface association entry is added with=20 expire time =3D big vtime of the HELLO + current time - the neighbor changes its main address (for instance it was performing IPv4/IPv6 autoconfiguration on a temporary main address, in a scheme similar to the one proposed for AODV). - the multiple interface association base is still polluted for a *big* time, with bogus multiple interface association tuples (which will be bogus competitors of the new ones, thus with implementation dependant results :-( ). -> Note while this may not be clever behavior from the part of the neighbor, this is still RFC-compliant behavior. What pyOLSR does for instance, on the other hand, is to add the multiple interface association (MIA) tuple from the HELLO, only for the duration, the processing of the HELLO, but as you noticed=20 then, the MIA tuples won't be there for processing of other messages. Maybe qolyester had already choosen to do the same :-) Or you can play adding min(...)+flags in the MIAB. > > The only time where some confusion is possible between interface > address and main address is when populating the 2-hop neighbor set. Fo= r > example, consider the current node A, a 1-hop neighbor B and a 2-hop > neighbor C that has two interfaces with addresses C1 and C2, C1 being > its main address. Say that B hears C through interface C2, then a HELL= O > message from B contains an entry with address C2 and A has no way to > know that in fact C1 and C2 belong to the same node. There are two way= s > to deal with that: > > 1) Correct the 2-hop tuple upon reception of the MID message. I.e. > replace any (*, C2) with (*, C1). > > 2) Ignore the confusion until another HELLO message from B is > received. Before updating the 2-hop neighbor set, check if the 2-hop > address resolves to another main address (because a MID message has > arrived in the meantime) and if so, remove explicitly the 2-hop tuple > (B, C2). Then update the 2-hop neighbor set as usually: add (B, C1) > in the set with a new validity time. > > Solution 1 should be avoided, since a lot of computation is required fo= r > a pretty rare case. > > Solution 2 is in fact the preferred one, since the false information i= n > the 2-hop neighbor set would only bias MPR computation a bit until > another HELLO is received after the reception of the MID message. Good idea! > > Important remark: 2-hop addresses in the 2-hop tuples are main addresse= s > of the nodes. Consider now the following scenario: A HELLO from B > makes A put (B, C2) in its 2-hop neighbor set. Then a MID message from > C informs A that C has two interfaces C1 and C2, with C1 being the main > address. Then the arrival of a TC message at A triggers an MPR > computation. Since 2-hop addresses in 2-hop tuples are main addresses, > there is no apparent reason to resolve these while doing MPR > computation, thus A "doesn't see" C1 and C2 as the same 2-hop neighbor. > This remains so until A receives a HELLO message from B and then remove= s > (B, C2) from the 2-hop neighbor set and inserts (B, C1). Since the > 2-hop neighbor set has been changed, an MPR computation is triggered. > > I suppose that keeping 2-hop neighbor's interface addresses in 2-hop > tuples instead of main addresses and performing main address resolution > at MPR selection time would lead to more accurate behavior. This would > have a negative impact on performance though, since address resolution > would not be "cached" into the 2-hop tuples. Regards, -- Cedric _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 25 10:21:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29598 for ; Thu, 25 Mar 2004 10:21:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6Wem-0007Nj-Pj for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 10:20:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PFKWU7028374 for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 10:20:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6WOf-00026j-EL for manet-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 10:03:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22628 for ; Thu, 25 Mar 2004 09:14:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6VcR-0006yj-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 09:14:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6Vaj-0006gm-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 09:12:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6VZQ-0006Mb-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 09:10:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6VXT-0006a6-In; Thu, 25 Mar 2004 09:08:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6SgS-0002Ip-KR for manet@optimus.ietf.org; Thu, 25 Mar 2004 06:06:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14897 for ; Thu, 25 Mar 2004 06:05:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6SgO-0003e9-00 for manet@ietf.org; Thu, 25 Mar 2004 06:05:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6SfU-0003Zd-00 for manet@ietf.org; Thu, 25 Mar 2004 06:05:01 -0500 Received: from netns.kjist.ac.kr ([203.237.53.16] helo=NML.netmedia.kjist.ac.kr) by ietf-mx with esmtp (Exim 4.12) id 1B6SfA-0003Ux-00 for manet@ietf.org; Thu, 25 Mar 2004 06:04:41 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C41258.A2BE0280" Subject: RE: [manet] Is there an available ODMRP implementation code on NS-2 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 25 Mar 2004 20:02:17 +0900 Message-ID: Thread-Topic: [manet] Is there an available ODMRP implementation code on NS-2 Thread-Index: AcQSDskVpUSpP3fjRyShDJzJdZwy5gACbayAABASMnA= From: "HaYoung Yoon" To: "Youngmin Kim" , 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C41258.A2BE0280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you, again.=20 =20 =20 _____ =20 From: Youngmin Kim [mailto:blhole@venus.uos.ac.kr]=20 Sent: Thursday, March 25, 2004 12:43 PM To: HaYoung Yoon; manet@ietf.org Subject: RE: [manet] Is there an available ODMRP implementation code on NS-2 =20 http://www.monarch.cs.rice.edu/multicast_extensions.html =20 =20 _____ =20 From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Ha Young, Yoon Sent: Thursday, March 25, 2004 11:14 AM To: manet@ietf.org Subject: [manet] Is there an available ODMRP implementation code on NS-2 =20 Hi all, =20 Is there an available ODMRP implementation code on NS-2. =20 If there is one who knows about that even URL or key-words, let me know that, please. =20 Yours, =20 Hayoung Yoon =20 ------_=_NextPart_001_01C41258.A2BE0280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Thank you, again.

     =

     =

    From: Youngmin Kim [mailto:blhole@venus.uos.ac.kr]
    Sent: Thursday, March 25, = 2004 12:43 = PM
    To: HaYoung Yoon; = manet@ietf.org
    Subject: RE: [manet] Is = there an available ODMRP implementation code on NS-2

     

    http://= www.monarch.cs.rice.edu/multicast_extensions.html

     =

     =

    From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Ha Young, Yoon
    Sent: Thursday, March 25, = 2004 11:14 = AM
    To: manet@ietf.org
    Subject: [manet] Is there = an available ODMRP implementation code on NS-2

     

    Hi all,

     

    Is there an available ODMRP implementation code on NS-2.

     

    If there is one who knows = about that even URL or key-words, let me know

    that, = please.

     

    Yours,

     

    Hayoung = Yoon

     

    ------_=_NextPart_001_01C41258.A2BE0280-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 25 11:15:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04303 for ; Thu, 25 Mar 2004 11:15:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XV3-0007QP-7u for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 11:14:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PGEX3T028542 for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 11:14:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XV2-0007QH-UV for manet-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 11:14:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04297 for ; Thu, 25 Mar 2004 11:14:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XV1-00044y-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 11:14:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XU8-00041g-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 11:13:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6XTi-0003xk-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 11:13:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XTX-00074R-7Z; Thu, 25 Mar 2004 11:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6XSt-000729-Bz for manet@optimus.ietf.org; Thu, 25 Mar 2004 11:12:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04162 for ; Thu, 25 Mar 2004 11:12:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6XSs-0003ts-00 for manet@ietf.org; Thu, 25 Mar 2004 11:12:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6XRv-0003p4-00 for manet@ietf.org; Thu, 25 Mar 2004 11:11:19 -0500 Received: from bareed3.maktoob.net ([195.172.126.104] helo=maktoobchat.net) by ietf-mx with esmtp (Exim 4.12) id 1B6XR0-0003lK-00 for manet@ietf.org; Thu, 25 Mar 2004 11:10:22 -0500 Received: from [195.172.126.106] (HELO maktoobchat.net) by maktoobchat.net (CommuniGate Pro SMTP 4.1.6) with ESMTP id 12343098 for manet@ietf.org; Thu, 25 Mar 2004 16:13:32 +0000 Received: from [195.172.126.109] (HELO maktoob.com) by maktoobchat.net (CommuniGate Pro SMTP 4.1.6) with ESMTP id 13258151 for manet@ietf.org; Thu, 25 Mar 2004 15:54:09 +0000 From: "yazeed al-sbou" To: manet@ietf.org Comment: Maktoob By BOC X-Mailer: Maktoob 2.0 [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)] X-Originating-IP: [143.52.2.45] MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 7bit Date: Thu, 25 Mar 2004 15:54:09 +0000 Message-ID: Content-Transfer-Encoding: 7bit Subject: [manet] Asking about ping.. 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.1 required=5.0 tests=AWL,FORGED_MUA_MOZILLA autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all.... I want to ask about the ping in ns, why in the tracegraph the sequence number is -1? how can get the sequence number if i want to send more than one ping during the simulation time.?? thanks in advance.. yours.. Yazeed Ahamd Al-Sbou, Research Student School of Engineering Sheaf Building - Room 4311, Sheffield Hallam University,City Campus Sheiffield, S1 1WB Tel(university):+441142253254 Mobile 00447813402741 Yazeed.A.Al-Sbou@student.shu.ac.uk _________________________________________________ Make someone's day! Send a friend a special Arabic card from Maktoob Cards NOW. http://www.maktoob.com/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 25 16:32:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25791 for ; Thu, 25 Mar 2004 16:32:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cSl-0002XZ-Jh for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 16:32:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PLWVGP009763 for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 16:32:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cSl-0002XO-E0 for manet-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 16:32:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25784 for ; Thu, 25 Mar 2004 16:32:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cSj-0004KW-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 16:32:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6cRo-0004IM-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 16:31:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6cRV-0004Ga-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 16:31:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cRL-0002Mj-HE; Thu, 25 Mar 2004 16:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cQm-0002JT-NY for manet@optimus.ietf.org; Thu, 25 Mar 2004 16:30:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25734 for ; Thu, 25 Mar 2004 16:30:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cQk-0004Ex-00 for manet@ietf.org; Thu, 25 Mar 2004 16:30:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6cPp-0004DD-00 for manet@ietf.org; Thu, 25 Mar 2004 16:29:30 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B6cOw-00049D-00 for manet@ietf.org; Thu, 25 Mar 2004 16:28:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2PLS3d08252; Thu, 25 Mar 2004 13:28:03 -0800 X-mProtect: <200403252128> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkMasnW; Thu, 25 Mar 2004 13:28:01 PST Message-ID: <40634ED7.F787C4ED@iprg.nokia.com> Date: Thu, 25 Mar 2004 13:27:51 -0800 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: Mobile Ad Hoc IETF working group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Comments on "Problem Statement for OSPF Extensions ..." draft 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, During the recent meeting, the abovementioned draft was discussed. The draft has been submitted for a long time, but after finally reading the draft, and motivated by the recent WG discussion, I have a few comments. - In section 2.1, it is stated that mobility makes the use of directional antennas into a pointless exercise. There are numerous studies that conclude otherwise. It seems likely that, given sufficient justification, a workable system can be built. Whether or not the additional cost is justified compared to other expenses is debatable. Overall, however, I would say that "pointless" is far too strong an adjective in this sentence. - In section 2.3, the acronym "VC" is left undefined. - In section 2.5, the misconception is promulgated that receiving takes less power than transmitting. While it is typically true per message, the fact is that receiving is often more power-consuming when the receiver has to be always powered up. In contrast, typically the transmitter can be powered down during most of the timm. - In section 2.7, if a node's ability to support new neighbors is exhausted, then one can truly say that the number of neighbors is numerically limited, so that the nodal degree is limited. Said another way, geographic proximity may not result in network adjacency. - In section 2.8, replace "should not thrash" by "should avoid thrashing" - In section 2.9, last paragraph: the suggested strategy requires too much binding between a node's IPv4 addressability and its IPv6 addressability. This issue may not need solution in this document anyway. In fact, I question the need for binding even separate network interfaces to the same nodal identifier, but again that is a separate issue. - Section 2.10 gets to the heart of a crucial problem. I would suggest that it be taken as a requirement to outfit the OSPF implementations so that unreliable flooding is acceptable, otherwise I just don't believe the solution will be scalable. I have other minor editorial improvements to suggest which don't really need to be brought out here; if the authors are interested, I will be happy to send them. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 25 16:45:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26448 for ; Thu, 25 Mar 2004 16:45:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cfM-0004Ld-Oc for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 16:45:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PLjWBf016710 for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 16:45:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cfM-0004LR-Kp for manet-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 16:45:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26433 for ; Thu, 25 Mar 2004 16:45:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cfK-00057p-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 16:45:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ceP-00054m-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 16:44:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6ce0-00052T-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 16:44:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cdu-0003yo-52; Thu, 25 Mar 2004 16:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cdT-0003xz-GB for manet@optimus.ietf.org; Thu, 25 Mar 2004 16:43:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26400 for ; Thu, 25 Mar 2004 16:43:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cdR-00051n-00 for manet@ietf.org; Thu, 25 Mar 2004 16:43:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6cca-0004zc-00 for manet@ietf.org; Thu, 25 Mar 2004 16:42:41 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B6ccB-0004wQ-00 for manet@ietf.org; Thu, 25 Mar 2004 16:42:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2PLfjb02685 for ; Thu, 25 Mar 2004 13:41:45 -0800 X-mProtect: <200403252141> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddxQkzk; Thu, 25 Mar 2004 13:41:42 PST Message-ID: <4063520C.87675F51@iprg.nokia.com> Date: Thu, 25 Mar 2004 13:41:32 -0800 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: Mobile Ad Hoc IETF working group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Manet charter item 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, During the recent WG meeting in Seoul, our Area Director pointed out that we did not seem to be making progress towards meeting the goal on the WG charter: Jul 03 Develop a further focused problem statement and address an approach for a common engineering work effort After that, I was quite surprised by a comment made to the effect that a problem statement had been submitted, but not much attention had been given to comments on that document. I found this to be very surprising, because the document referred to was the OSPF problem statement (for which I submitted comments a few minutes ago). Up until that point, I would not have thought that the OSPF problem statement was in any way intended to meet the task outlined in the abovementioned WG charter item. I have written down some other thoughts for a more general problem statement that focuses on other tasks besides determining the appropriate extensions for OSPF so that that protocol can be used in connection with operating ad hoc networks. I had always thought that the point of the OSPF work would be to enable OSPF routers to adjoin ad hoc networks to infrastructure networks, and Fred has made some presentations explaining various thinking along these lines. I'll try to post this initial document after one or two more proofreadings. I reckon it's time to do something about the charter item, so we can proceed. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Mar 25 19:29:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05099 for ; Thu, 25 Mar 2004 19:29:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fDH-0001Ck-A5 for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 19:28:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q0ShFQ004629 for manet-archive@odin.ietf.org; Thu, 25 Mar 2004 19:28:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fDH-0001Ca-6C for manet-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 19:28:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05029 for ; Thu, 25 Mar 2004 19:28:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6fDF-0007jb-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 19:28:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6fBy-0007WT-00 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 19:27:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6fAV-0007LN-02 for manet-web-archive@ietf.org; Thu, 25 Mar 2004 19:25:51 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6ezS-0000nb-Jl for manet-web-archive@ietf.org; Thu, 25 Mar 2004 19:14:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ez3-0000UP-JJ; Thu, 25 Mar 2004 19:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6eya-0000Ta-Qn for manet@optimus.ietf.org; Thu, 25 Mar 2004 19:13:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04425 for ; Thu, 25 Mar 2004 19:13:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6eyZ-0006gE-00 for manet@ietf.org; Thu, 25 Mar 2004 19:13:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6exd-0006eY-00 for manet@ietf.org; Thu, 25 Mar 2004 19:12:33 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1B6ewq-0006bK-00 for manet@ietf.org; Thu, 25 Mar 2004 19:11:44 -0500 Received: from canth.inria.fr (canth.inria.fr [128.93.17.102]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i2Q0BDHd020373; Fri, 26 Mar 2004 01:11:13 +0100 Received: from adjih by canth.inria.fr with local (Exim 3.36 #1 (Debian)) id 1B6ewI-00062F-00; Fri, 26 Mar 2004 01:11:10 +0100 From: Cedric Adjih Reply-To: Cedric.Adjih@inria.fr To: olsr@inria.fr Subject: Re: [olsr] Re: [manet] OLSR implementation help Date: Fri, 26 Mar 2004 01:11:10 +0100 User-Agent: KMail/1.6.1 Cc: Ignacy Gawedzki , manet@ietf.org, manet user References: <20040324211808.63298.qmail@web61104.mail.yahoo.com> <200403251417.14278.Cedric.Adjih@inria.fr> <20040325161202.A30740@qubit.lri.fr> In-Reply-To: <20040325161202.A30740@qubit.lri.fr> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403260111.10742.Cedric.Adjih@inria.fr> X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thursday 25 March 2004 16:12, Ignacy Gawedzki wrote: > [...snip..] > > > In practice using the vtime of the HELLO, is no problem, but this > > can lead to the theoritical following scenario, where an "unoptimized" > > implementation would have performed better, unless I am > > mistaken: > > - a neighbor sends one HELLO with a big vtime (possible if it > > relies on the "LOST" status to remove links if necessary later) > > - a multiple interface association entry is added with > > expire time = big vtime of the HELLO + current time > > - the neighbor changes its main address (for instance it was > > performing IPv4/IPv6 autoconfiguration on a temporary main > > address, in a scheme similar to the one proposed for AODV). > > - the multiple interface association base is still polluted for > > a *big* time, with bogus multiple interface association tuples > > (which will be bogus competitors of the new ones, thus with > > implementation dependant results :-( ). > > -> Note while this may not be clever behavior from the part of the > > neighbor, this is still RFC-compliant behavior. > > Hmmm, right, the RFC says that a node SHOULD keep the same main address. > =) > > > What pyOLSR does for instance, on the other hand, is to > > add the multiple interface association (MIA) tuple from the HELLO, > > only for the duration, the processing of the HELLO, but as you noticed > > then, the MIA tuples won't be there for processing of other messages. > > I don't quite get the use of that. If the MIA tuple is available only > during the processing of the HELLO message, it won't be used. Well it will be used during the processing of the HELLO message which is enough to have now a Neighbor Tuple with the proper main address (along with MPR Selector Tuples, thus it should generate proper TCs...). > It would > have been used during the processing of *another* HELLO message, where > an interface's address belonging to the originator of the first HELLO > would need resolution. Which is the point :-) In the scenario I gave, the MIA tuple becomes incorrect, and still stays for a long time. So I do not want to use it. Of course then the two hop neighbor set is less correct. Pick your poison :-) Now I see that you could also try to detect that case and explictly remove that bogus MIA tuple, but notice this is not done by step 2 of "5.4 MID Message Processing". Regards, -- Cedric _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Mar 26 21:41:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05280 for ; Fri, 26 Mar 2004 21:41:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73kU-00040f-Dv for manet-archive@odin.ietf.org; Fri, 26 Mar 2004 21:40:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2R2ect7015409 for manet-archive@odin.ietf.org; Fri, 26 Mar 2004 21:40:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73kU-00040R-8Q for manet-web-archive@optimus.ietf.org; Fri, 26 Mar 2004 21:40:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05266 for ; Fri, 26 Mar 2004 21:40:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B73kR-0005ei-00 for manet-web-archive@ietf.org; Fri, 26 Mar 2004 21:40:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B73jV-0005Zw-00 for manet-web-archive@ietf.org; Fri, 26 Mar 2004 21:39:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B73j9-0005VA-00 for manet-web-archive@ietf.org; Fri, 26 Mar 2004 21:39:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73iv-0003pc-Ra; Fri, 26 Mar 2004 21:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B73iV-0003oX-9b for manet@optimus.ietf.org; Fri, 26 Mar 2004 21:38:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05159 for ; Fri, 26 Mar 2004 21:38:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B73iS-0005Tr-00 for manet@ietf.org; Fri, 26 Mar 2004 21:38:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B73hX-0005PR-00 for manet@ietf.org; Fri, 26 Mar 2004 21:37:35 -0500 Received: from web12902.mail.yahoo.com ([216.136.174.69]) by ietf-mx with smtp (Exim 4.12) id 1B73gx-0005LC-00 for manet@ietf.org; Fri, 26 Mar 2004 21:36:59 -0500 Message-ID: <20040327023659.70594.qmail@web12902.mail.yahoo.com> Received: from [80.74.225.66] by web12902.mail.yahoo.com via HTTP; Sat, 27 Mar 2004 02:36:59 GMT Date: Sat, 27 Mar 2004 02:36:59 +0000 (GMT) From: =?iso-8859-1?q?kani=20sundar?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-69899716-1080355019=:70285" Content-Transfer-Encoding: 8bit Subject: [manet] Analysis of adhoc 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,HTML_MESSAGE,PLING_PLING autolearn=no version=2.60 --0-69899716-1080355019=:70285 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, I am currently doing my master thesis in Qos in Adhoc networks. Hence i want to know about the analysis of adhoc routing protocol in DSR. Hence in my thesis i have to explain the analysis of DSR in adhoc networks.I want to know clearly what are the things i need to explain and if possible can anybody give me a website i.e links which has lot of details about analysis of DSR in adhoc networks. Can anyone help me out. Kanimaran --------------------------------- WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards --0-69899716-1080355019=:70285 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
    Hi all,
     
            I am currently doing my master thesis in Qos in Adhoc networks.
     
    Hence i want to know about the analysis of adhoc routing protocol in DSR. Hence in my thesis i have to explain the analysis of DSR in adhoc networks.I want to know clearly what are the things i need to explain and if possible can anybody give me a website i.e links  which has lot of details about analysis of DSR in adhoc networks.
     
    Can anyone help me out.
     
    Kanimaran 

    WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards --0-69899716-1080355019=:70285-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Mar 27 19:18:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08102 for ; Sat, 27 Mar 2004 19:18:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7O07-0006xP-Ha for manet-archive@odin.ietf.org; Sat, 27 Mar 2004 19:18:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2S0I7pG026739 for manet-archive@odin.ietf.org; Sat, 27 Mar 2004 19:18:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7O07-0006xC-A3 for manet-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 19:18:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08054 for ; Sat, 27 Mar 2004 19:18:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7O05-0005KK-00 for manet-web-archive@ietf.org; Sat, 27 Mar 2004 19:18:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Nz6-0005CF-00 for manet-web-archive@ietf.org; Sat, 27 Mar 2004 19:17:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7NyI-00054b-00 for manet-web-archive@ietf.org; Sat, 27 Mar 2004 19:16:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7Ny6-0006gc-FY; Sat, 27 Mar 2004 19:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7NxS-0006eO-97 for manet@optimus.ietf.org; Sat, 27 Mar 2004 19:15:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07974 for ; Sat, 27 Mar 2004 19:15:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7NxQ-0004yz-00 for manet@ietf.org; Sat, 27 Mar 2004 19:15:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7Nwb-0004sY-00 for manet@ietf.org; Sat, 27 Mar 2004 19:14:30 -0500 Received: from web13201.mail.yahoo.com ([216.136.174.186]) by ietf-mx with smtp (Exim 4.12) id 1B7Nw1-0004lX-00 for manet@ietf.org; Sat, 27 Mar 2004 19:13:53 -0500 Message-ID: <20040328001353.23117.qmail@web13201.mail.yahoo.com> Received: from [156.26.20.132] by web13201.mail.yahoo.com via HTTP; Sat, 27 Mar 2004 16:13:53 PST Date: Sat, 27 Mar 2004 16:13:53 -0800 (PST) From: sumanth sarma To: manet@ietf.org In-Reply-To: <20040327235100.19215.47244.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Ariadne 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi I am very new to this field. I am trying to simulate Ariadne Routing Protocol using ns2 and and modify it to use digital signatures based on HORS . Please if anyone can give me some suggestions before starting and I saw monarch site. But still have doubts on ns2. anyways any help can be appreciated. thanks sumanth __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Mar 27 21:44:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12510 for ; Sat, 27 Mar 2004 21:44:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7QHX-0003zO-LL for manet-archive@odin.ietf.org; Sat, 27 Mar 2004 21:44:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2S2iF4Z015330 for manet-archive@odin.ietf.org; Sat, 27 Mar 2004 21:44:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7QHX-0003zB-G7 for manet-web-archive@optimus.ietf.org; Sat, 27 Mar 2004 21:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12476 for ; Sat, 27 Mar 2004 21:44:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7QHU-0004b0-00 for manet-web-archive@ietf.org; Sat, 27 Mar 2004 21:44:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7QGX-0004TA-00 for manet-web-archive@ietf.org; Sat, 27 Mar 2004 21:43:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7QFW-0004M4-00 for manet-web-archive@ietf.org; Sat, 27 Mar 2004 21:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7QFN-0003dy-Ru; Sat, 27 Mar 2004 21:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7QEg-0003dK-9C for manet@optimus.ietf.org; Sat, 27 Mar 2004 21:41:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12417 for ; Sat, 27 Mar 2004 21:41:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7QEd-0004Gp-00 for manet@ietf.org; Sat, 27 Mar 2004 21:41:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7QDh-0004Bb-00 for manet@ietf.org; Sat, 27 Mar 2004 21:40:18 -0500 Received: from mailoff.mtu.edu ([141.219.70.111]) by ietf-mx with esmtp (Exim 4.12) id 1B7QDN-000463-00 for manet@ietf.org; Sat, 27 Mar 2004 21:39:57 -0500 Received: from node21. (node21.mtu.edu [141.219.68.121]) by mailoff.mtu.edu (8.11.7p1+Sun/8.11.4) with ESMTP id i2S2dvU06660 for ; Sat, 27 Mar 2004 21:39:57 -0500 (EST) Received: from node25 (node25.mtu.edu [141.219.68.125]) by node21. (8.11.6/8.11.6) with ESMTP id i2S2dvi32152 for ; Sat, 27 Mar 2004 21:39:57 -0500 Received: from campus4.mtu.edu ([141.219.70.7]) by node25 (MailMonitor for SMTP v1.2.2 ) ; Sat, 27 Mar 2004 21:39:54 -0500 (EST) Received: from node40. (node40.mtu.edu [141.219.69.40]) by mail.mtu.edu (8.11.7p1+Sun/8.11.6) with ESMTP id i2S2dso02157 for ; Sat, 27 Mar 2004 21:39:54 -0500 (EST) Received: from dell4100 (pm414-05.dialip.mich.net [198.110.130.55]) (authenticated bits=0) by node40. (8.12.10/8.12.3/auth_ssl.mc v1.0) with ESMTP id i2S2doCw008771 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 27 Mar 2004 21:39:52 -0500 Message-ID: <00b301c4146e$c2950280$37826ec6@dell4100> From: "Leiyuan Li" To: Date: Sat, 27 Mar 2004 21:45:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01C41444.D809F780" 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 Subject: [manet] [MANET]Is there any secure MAC protocol to be used in MANET 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=AWL,FORGED_OUTLOOK_TAGS, MIME_BASE64_LATIN,MIME_BASE64_TEXT autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_00B0_01C41444.D809F780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpJJ20gZG9pbmcgcmVzZWFyY2ggb24gTUFORVQgc2VjdXJpdHkuICBJIHdvbmRl ciBpZiB0aGVyZSBpcyBhbnkgYWNjZXB0ZWQgb3IgcHJvcG9zZWQgTUFDIHByb3RvY29sIHRoYXQg aXMgY2FwYWJsZSBvZiBwcm92aWRpbmcgc2VjdXJpdHkgc2VydmljZXMgaW4gTUFORVQgc3lzdGVt PyAgSW4gb3RoZXIgd29yZHMsIGlzIHRoZXJlIGFueSBwcm90b2NvbCB0aGF0IGNhbiBwcm92aWRl IGNvbmZpZGVudGlhbGFsaXR5IGFuZCBhdXRoZW50aWNhdGlvbiBvZiB0aGUgTUFDIHBhY2tldHM/ ICBUaGFuayB5b3UgdmVyeSBtdWNoLg0KDQpDaGVlcnMsDQpMZWl5dWFuIGxp ------=_NextPart_000_00B0_01C41444.D809F780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMTA2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPkhpIEFsbCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPkknbSBkb2luZyByZXNlYXJjaCBvbiBNQU5FVCBzZWN1cml0eS4m bmJzcDsgSSB3b25kZXIgDQppZiB0aGVyZSBpcyBhbnkgYWNjZXB0ZWQgb3IgcHJvcG9zZWQgTUFD IHByb3RvY29sIHRoYXQgaXMgY2FwYWJsZSBvZiBwcm92aWRpbmcgDQpzZWN1cml0eSBzZXJ2aWNl cyBpbiBNQU5FVCBzeXN0ZW0/Jm5ic3A7IEluIG90aGVyIHdvcmRzLCBpcyB0aGVyZSBhbnkgcHJv dG9jb2wgDQp0aGF0IGNhbiBwcm92aWRlIGNvbmZpZGVudGlhbGFsaXR5IGFuZCBhdXRoZW50aWNh dGlvbiBvZiB0aGUgTUFDIHBhY2tldHM/Jm5ic3A7IA0KVGhhbmsgeW91IHZlcnkgbXVjaC48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkNo ZWVycyw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTI+TGVpeXVhbiBsaTwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_00B0_01C41444.D809F780-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Mar 28 14:20:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29702 for ; Sun, 28 Mar 2004 14:20:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7fpC-0003Ch-Ju for manet-archive@odin.ietf.org; Sun, 28 Mar 2004 14:20:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SJK2A2012309 for manet-archive@odin.ietf.org; Sun, 28 Mar 2004 14:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7fpC-0003CS-Cd for manet-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 14:20:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29684 for ; Sun, 28 Mar 2004 14:19:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7fp9-0000hD-00 for manet-web-archive@ietf.org; Sun, 28 Mar 2004 14:19:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7foD-0000Y3-00 for manet-web-archive@ietf.org; Sun, 28 Mar 2004 14:19:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7fnU-0000PC-00 for manet-web-archive@ietf.org; Sun, 28 Mar 2004 14:18:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7fnG-0002nm-3R; Sun, 28 Mar 2004 14:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7fnC-0002mw-9X for manet@optimus.ietf.org; Sun, 28 Mar 2004 14:17:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29611 for ; Sun, 28 Mar 2004 14:17:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7fn9-0000ND-00 for manet@ietf.org; Sun, 28 Mar 2004 14:17:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7fmE-0000FZ-00 for manet@ietf.org; Sun, 28 Mar 2004 14:16:58 -0500 Received: from mail.cis.ohio-state.edu ([164.107.123.5] helo=cis.ohio-state.edu) by ietf-mx with esmtp (Exim 4.12) id 1B7flr-00007T-00 for manet@ietf.org; Sun, 28 Mar 2004 14:16:35 -0500 Received: from lambda.cis.ohio-state.edu (lambda.cis.ohio-state.edu [164.107.112.39]) by cis.ohio-state.edu (8.11.6p2-20030924/8.11.6) with ESMTP id i2SJG5n14161 for ; Sun, 28 Mar 2004 14:16:05 -0500 (EST) Date: Sun, 28 Mar 2004 14:16:05 -0500 (EST) From: Vinayak Naik To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] transmission failure info from 802.11 cards 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 I have a quick question about an ad-hoc network that we are trying to build with 802.11 cards. In simulators (such as ns-2), a transmission failure at the MAC layer results in a callback to the routing layer to try for an alternate route. However, with real 802.11 cards in a testbed, is it possible to get a feedback about failure of MAC layer delivery? Are there any special 802.11 cards that might have this feature? Thanks, Vinayak _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Mar 28 20:46:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17491 for ; Sun, 28 Mar 2004 20:46:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lr4-0000XR-OZ for manet-archive@odin.ietf.org; Sun, 28 Mar 2004 20:46:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T1kM2B002058 for manet-archive@odin.ietf.org; Sun, 28 Mar 2004 20:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lr4-0000X7-0b for manet-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 20:46:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17466 for ; Sun, 28 Mar 2004 20:46:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7lr1-00045k-00 for manet-web-archive@ietf.org; Sun, 28 Mar 2004 20:46:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7lps-0003u3-00 for manet-web-archive@ietf.org; Sun, 28 Mar 2004 20:45:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7loz-0003mE-00 for manet-web-archive@ietf.org; Sun, 28 Mar 2004 20:44:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7loo-0008Ip-1C; Sun, 28 Mar 2004 20:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7lo9-0008GD-Dv for manet@optimus.ietf.org; Sun, 28 Mar 2004 20:43:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17407 for ; Sun, 28 Mar 2004 20:43:18 -0500 (EST) From: nbb2@njit.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7lo7-0003ee-00 for manet@ietf.org; Sun, 28 Mar 2004 20:43:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7lnG-0003WO-00 for manet@ietf.org; Sun, 28 Mar 2004 20:42:26 -0500 Received: from mail.njit.edu ([128.235.251.173] helo=mail-gw5.njit.edu) by ietf-mx with esmtp (Exim 4.12) id 1B7lme-0003MC-00 for manet@ietf.org; Sun, 28 Mar 2004 20:41:48 -0500 Received: from webmail.njit.edu (webmail.njit.edu [128.235.251.121]) by mail-gw5.njit.edu (8.12.10/8.12.4) with ESMTP id i2T1fHn1019672 for ; Sun, 28 Mar 2004 20:41:17 -0500 (EST) Received: (from apache@localhost) by webmail.njit.edu (8.11.7+Sun/8.11.7) id i2T1fH323073 for manet@ietf.org; Sun, 28 Mar 2004 20:41:17 -0500 (EST) To: manet@ietf.org Subject: Re: [manet] Simulation and comaprison of ad hoc routing protocols Message-ID: <1080524477.40677ebd2e6ba@webmail.njit.edu> Date: Sun, 28 Mar 2004 20:41:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.4 X-Originating-IP: 67.85.64.182 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I am also working on a similar project except that we have developed a variant on an existing ad-hoc routing algorithm. We need to compare our algorithm with existing ones, atleast the simplest flood model. Did you have any luck with finding some information on using OPNET for simulation. Any information would be helpful. Thanks, Nithin ---------- http://www.nitboss.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 29 01:37:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28841 for ; Mon, 29 Mar 2004 01:37:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qNt-00035R-8D for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 01:36:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T6aXwF011864 for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 01:36:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qNt-00035H-4e for manet-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 01:36:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28828 for ; Mon, 29 Mar 2004 01:36:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7qNp-0004IF-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 01:36:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7qNB-00047v-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 01:35:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7qM5-0003up-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 01:34:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qHa-0001UT-FR; Mon, 29 Mar 2004 01:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7qGj-0001HZ-RQ for manet@optimus.ietf.org; Mon, 29 Mar 2004 01:29:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28297 for ; Mon, 29 Mar 2004 01:29:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7qGg-0002sG-00 for manet@ietf.org; Mon, 29 Mar 2004 01:29:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7qFk-0002lW-00 for manet@ietf.org; Mon, 29 Mar 2004 01:28:09 -0500 Received: from web14711.mail.yahoo.com ([216.136.232.91]) by ietf-mx with smtp (Exim 4.12) id 1B7qEl-0002et-00 for manet@ietf.org; Mon, 29 Mar 2004 01:27:07 -0500 Message-ID: <20040329062707.90406.qmail@web14711.mail.yahoo.com> Received: from [203.197.138.167] by web14711.mail.yahoo.com via HTTP; Sun, 28 Mar 2004 22:27:07 PST Date: Sun, 28 Mar 2004 22:27:07 -0800 (PST) From: panneer pandi To: manet@ietf.org, glomosim-users-l@lists.ucla.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1976753178-1080541627=:90209" Subject: [manet] reg : 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1976753178-1080541627=:90209 Content-Type: text/plain; charset=us-ascii Hai friends, I need a small help. I need to send a control packet before sending a route request packet. If I intiate the control packet in the router function, this particular function is called only when the simulation time of application layer starts. But i need to do it in the initial period of the simulaiton. And this control packet should be handled by all the nodes as it does for route req packet. Please reply. --------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. --0-1976753178-1080541627=:90209 Content-Type: text/html; charset=us-ascii
    Hai friends,
     
      I need a small help.
     
       I need to send a control packet before sending a route request packet.
     
       If  I intiate the control packet in the router function, this particular function is called only when the simulation time of application layer starts.
     
    But i need to do it in the initial period of the simulaiton. And this control packet should be handled by all the nodes as it does for route req packet. 
     
    Please reply.

    Do you Yahoo!?
    Yahoo! Finance Tax Center - File online. File on time. --0-1976753178-1080541627=:90209-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 29 08:01:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00426 for ; Mon, 29 Mar 2004 08:01:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7wOG-00047Y-1V for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 08:01:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TD1KPD015834 for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 08:01:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7wOF-00047J-SC for manet-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 08:01:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00371 for ; Mon, 29 Mar 2004 08:01:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7wOE-0005XY-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 08:01:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7wNG-0005NZ-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 08:00:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7wMH-0005DB-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 07:59:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7wM2-0003ed-JJ; Mon, 29 Mar 2004 07:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7wLU-0003cC-9z for manet@optimus.ietf.org; Mon, 29 Mar 2004 07:58:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00240 for ; Mon, 29 Mar 2004 07:58:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7wLT-00057F-00 for manet@ietf.org; Mon, 29 Mar 2004 07:58:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7wKV-0004zw-00 for manet@ietf.org; Mon, 29 Mar 2004 07:57:28 -0500 Received: from postfix3-1.free.fr ([213.228.0.44] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1B7wJf-0004sj-00 for manet@ietf.org; Mon, 29 Mar 2004 07:56:35 -0500 Received: from imp6-q.free.fr (imp6-q.free.fr [212.27.42.6]) by postfix3-1.free.fr (Postfix) with ESMTP id 8B005C412B for ; Mon, 29 Mar 2004 14:56:34 +0200 (CEST) Received: by imp6-q.free.fr (Postfix, from userid 33) id 822F71EAF0; Mon, 29 Mar 2004 14:56:34 +0200 (MEST) Received: from eseoext.eseo.fr (eseoext.eseo.fr [193.49.148.2]) by imp6-q.free.fr (IMP) with HTTP for ; Mon, 29 Mar 2004 14:56:34 +0200 Message-ID: <1080564994.40681d0270ad6@imp6-q.free.fr> Date: Mon, 29 Mar 2004 14:56:34 +0200 From: David Tylski To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 User-Agent: Internet Messaging Program (IMP) 3.2.1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] Get routes in NS-2 at Tcl level 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi everyone.=20 =20 Does anyone have already need to get the routing tables (whatever the rou= ting=20 protocol) in NS-2 at (O)Tcl level ? Is it necessary to modify the C++ sou= rce=20 code to get these data or is it already available ? I am currently workin= g on=20 the 2.27 version.=20 =20 Excuse me, I am a bit lost into the NS-2 internals... It seems well hard = to=20 find all of that... :(=20 =20 Thanks for your help.=20 =20 David TYLSKI=20 =20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 29 10:05:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05780 for ; Mon, 29 Mar 2004 10:05:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yKS-0001c7-ME for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 10:05:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TF5WNT006198 for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 10:05:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yKS-0001bs-Gy for manet-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 10:05:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05733 for ; Mon, 29 Mar 2004 10:05:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yKQ-0007MH-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 10:05:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7yJS-0007Ex-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 10:04:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7yJ9-00078O-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 10:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yIz-0000vw-Hh; Mon, 29 Mar 2004 10:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7yId-0000q0-36 for manet@optimus.ietf.org; Mon, 29 Mar 2004 10:03:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05552 for ; Mon, 29 Mar 2004 10:03:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7yIb-00077j-00 for manet@ietf.org; Mon, 29 Mar 2004 10:03:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7yHp-000706-00 for manet@ietf.org; Mon, 29 Mar 2004 10:02:49 -0500 Received: from smtp3.andrew.cmu.edu ([128.2.10.83]) by ietf-mx with esmtp (Exim 4.12) id 1B7yH9-0006r9-00 for manet@ietf.org; Mon, 29 Mar 2004 10:02:07 -0500 Received: from VPN-128-2-245-13.CAMPUS.cmu.edu (VPN-128-2-245-13.CAMPUS.cmu.edu [128.2.245.13]) (user=dmaltz mech=KERBEROS_V4 (0 bits)) by smtp3.andrew.cmu.edu (8.12.10/8.12.10) with ESMTP id i2TF26Id018467 for ; Mon, 29 Mar 2004 10:02:07 -0500 Date: Mon, 29 Mar 2004 10:02:33 -0500 From: "David A. Maltz" To: manet@ietf.org Subject: Re: [manet] transmission failure info from 802.11 cards Message-ID: <601862172.1080554553@[192.168.2.104]> Originator-Info: login-token=Mulberry:01yW4l2i3bhkYP83RRFO6cSRzLnAZP2bL30ZJPyd6YYw==; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.0.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --On Sunday, March 28, 2004 2:16 PM -0500 Vinayak Naik wrote: > In simulators (such as ns-2), a transmission failure at the MAC layer > results in a callback to the routing layer to try for an alternate route. > However, with real 802.11 cards in a testbed, is it possible to get > a feedback about failure of MAC layer delivery? I'm not sure. When we built the Monarch testbed back in 1998, the WaveLAN cards didn't support 802.11 yet, so we implemented both passive acknowledgments and network layer acks. The Orinoco cards I've played around with since then have a counter for failed transmissions, which you could probably poll after sending a packet. -dam _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 29 12:47:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14530 for ; Mon, 29 Mar 2004 12:47:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B80ql-0002e6-Lh for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 12:47:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2THl3bX010171 for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 12:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B80ql-0002dy-8Y for manet-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 12:47:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14517 for ; Mon, 29 Mar 2004 12:46:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B80qi-0000JH-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 12:47:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B80pw-00009C-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 12:46:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B80p9-0007kY-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 12:45:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B80on-0002In-B9; Mon, 29 Mar 2004 12:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B80of-0002IL-5X for manet@optimus.ietf.org; Mon, 29 Mar 2004 12:44:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14464 for ; Mon, 29 Mar 2004 12:44:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B80od-0007iO-00 for manet@ietf.org; Mon, 29 Mar 2004 12:44:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B80nq-0007ZN-00 for manet@ietf.org; Mon, 29 Mar 2004 12:44:02 -0500 Received: from che.ojctech.com ([209.254.133.74]) by ietf-mx with esmtp (Exim 4.12) id 1B80nC-0007Nr-00 for manet@ietf.org; Mon, 29 Mar 2004 12:43:22 -0500 Received: from che.ojctech.com (localhost [127.0.0.1]) by che.ojctech.com (8.12.8/8.12.8) with ESMTP id i2THgkRG029194 for ; Mon, 29 Mar 2004 11:42:46 -0600 Received: (from dyoung@localhost) by che.ojctech.com (8.12.8/8.12.8/Submit) id i2THgkkB029192 for manet@ietf.org; Mon, 29 Mar 2004 11:42:46 -0600 Date: Mon, 29 Mar 2004 11:42:46 -0600 From: David Young To: manet@ietf.org Subject: Re: [manet] transmission failure info from 802.11 cards Message-ID: <20040329174245.GT16080@che.ojctech.com> Mail-Followup-To: manet@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 On Sun, Mar 28, 2004 at 02:16:05PM -0500, Vinayak Naik wrote: > > I have a quick question about an ad-hoc network that we are trying > to build with 802.11 cards. > > In simulators (such as ns-2), a transmission failure at the MAC layer > results in a callback to the routing layer to try for an alternate route. > However, with real 802.11 cards in a testbed, is it possible to get > a feedback about failure of MAC layer delivery? > > Are there any special 802.11 cards that might have this feature? Virtually every 802.11 card provides feedback. Lucent & Prism cards will indicate a transmit failure after the retry count has expired. The 802.11 ASICs by Atheros, ADMtek, and Realtek will tell you how many times they re-tried a transmission. The hardware capability is there, however, the Tx-failure indications do not climb the networking stack to routing daemons. 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 exim@www1.ietf.org Mon Mar 29 15:33:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24163 for ; Mon, 29 Mar 2004 15:33:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83RK-0001mR-Jh for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 15:33:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TKWwuc006837 for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 15:32:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83RK-0001mC-37 for manet-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 15:32:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24157 for ; Mon, 29 Mar 2004 15:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B83RI-0000kx-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 15:32:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B83Qd-0000bs-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 15:32:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83QP-0001Tn-Lk; Mon, 29 Mar 2004 15:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B83Q3-0001T8-0s for manet@optimus.ietf.org; Mon, 29 Mar 2004 15:31:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24051 for ; Mon, 29 Mar 2004 15:31:33 -0500 (EST) From: ebelding@cs.ucsb.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B83Py-0000Xt-00 for manet@ietf.org; Mon, 29 Mar 2004 15:31:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B83P1-0000Pf-00 for manet@ietf.org; Mon, 29 Mar 2004 15:30:35 -0500 Received: from h24-84-58-177.vc.shawcable.net ([24.84.58.177] helo=lucky.com) by ietf-mx with smtp (Exim 4.12) id 1B83O7-0000Ge-00 for manet@ietf.org; Mon, 29 Mar 2004 15:29:39 -0500 Date: Mon, 29 Mar 2004 00:04:23 -0800 To: manet@ietf.org Message-ID: MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.0 required=5.0 tests=DATE_IN_PAST_12_24, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS, HTML_EMBEDS,HTML_MESSAGE,MIME_HTML_ONLY,NORMAL_HTTP_TO_IP, NO_REAL_NAME,WEIRD_PORT autolearn=no version=2.60 X-Spam-Report: * 0.3 NO_REAL_NAME From: does not include a real name * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.3 HTML_EMBEDS BODY: HTML with embedded plugin object * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.9 WEIRD_PORT URI: Uses non-standard port number for HTTP * 0.4 DATE_IN_PAST_12_24 Date: is 12 to 24 hours before Received: date * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook Content-Transfer-Encoding: 7bit Subject: [manet] Re: Document 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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Mar 29 20:22:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07641 for ; Mon, 29 Mar 2004 20:22:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87wy-000547-Nf for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 20:21:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U1Lu8h019467 for manet-archive@odin.ietf.org; Mon, 29 Mar 2004 20:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87wy-00053u-JS for manet-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 20:21:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07627 for ; Mon, 29 Mar 2004 20:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B87ww-000399-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 20:21:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B87w1-00030f-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 20:20:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B87vL-0002sW-00 for manet-web-archive@ietf.org; Mon, 29 Mar 2004 20:20:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87v8-0004mF-KC; Mon, 29 Mar 2004 20:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B87v3-0004l1-5D for manet@optimus.ietf.org; Mon, 29 Mar 2004 20:19:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07577 for ; Mon, 29 Mar 2004 20:19:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B87v1-0002rN-00 for manet@ietf.org; Mon, 29 Mar 2004 20:19:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B87uB-0002jL-00 for manet@ietf.org; Mon, 29 Mar 2004 20:19:03 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1B87tH-0002ae-00 for manet@ietf.org; Mon, 29 Mar 2004 20:18:07 -0500 Received: from yosemite.cs.ucsb.edu (yosemite [128.111.40.103]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id i2U1I7O24895 for ; Mon, 29 Mar 2004 17:18:07 -0800 (PST) From: Elizabeth Belding-Royer To: manet@ietf.org Content-Type: text/plain Message-Id: <1080609486.26544.106.camel@yosemite.cs.ucsb.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 29 Mar 2004 17:18:07 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] MobiHoc 2004: Registration is open! 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,LINES_OF_YELLING, MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Registration is now open! Register by April 21, 2004 for reduced registration costs! ====================================================================== ** CALL FOR PARTICIPATION ** The Fifth ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc) 2004 www.sigmobile.org/mobihoc/2004/ May 24-26, 2004 Tokyo, Japan MobiHoc 2004 is the fifth of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 at Long Beach, California, in 2002 at Lausanne, Switzerland, in 2003 at Annapolis, Maryland, and now in 2004 at Tokyo, Japan. PROGRAM The MobiHoc 2004 program will consist of tutorials, technical papers and posters. Five tutorials will be presented, including tutorials on power control protocols in ad hoc networks, topology control, and sensor networks. The technical program spans 2 days and consists of 24 papers covering a wide variety of topics related to ad hoc networks and sensor networks. Please visit the MobiHoc 2004 Home Page at www.sigmobile.org/mobihoc/2004/, or send email to the General Chair, Jun Murai jun-mobihoc2004@wide.ad.jp or to mobihoc2004@isrmail.isr.umd.edu for any questions or for more information about the symposium. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 02:04:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24763 for ; Tue, 30 Mar 2004 02:04:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8DIG-000320-GW for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 02:04:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U74G2M011622 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 02:04:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8DIF-00031F-Jd for manet-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 02:04:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24206 for ; Tue, 30 Mar 2004 02:04:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8DIB-0004aK-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 02:04:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8DHB-0004Pq-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 02:03:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8DGI-0004H7-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 02:02:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8DG6-0001mY-A7; Tue, 30 Mar 2004 02:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8DFE-0001Tj-4N for manet@optimus.ietf.org; Tue, 30 Mar 2004 02:01:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20842 for ; Tue, 30 Mar 2004 02:01:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8DFA-00046Z-00 for manet@ietf.org; Tue, 30 Mar 2004 02:01:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8DEC-0003xw-00 for manet@ietf.org; Tue, 30 Mar 2004 02:00:05 -0500 Received: from web14708.mail.yahoo.com ([216.136.224.125]) by ietf-mx with smtp (Exim 4.12) id 1B8DDJ-0003pQ-00 for manet@ietf.org; Tue, 30 Mar 2004 01:59:09 -0500 Message-ID: <20040330065904.21276.qmail@web14708.mail.yahoo.com> Received: from [203.197.138.172] by web14708.mail.yahoo.com via HTTP; Mon, 29 Mar 2004 22:59:04 PST Date: Mon, 29 Mar 2004 22:59:04 -0800 (PST) From: panneer pandi To: Manoj K Pandey Cc: manet@ietf.org, glomosim-users-l@lists.ucla.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1510845198-1080629944=:16450" Subject: [manet] reg: sending control packet 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --0-1510845198-1080629944=:16450 Content-Type: text/plain; charset=us-ascii Hello Sir, I am in need of your help, I need to send a control packet before sending a route request packet. If I intiate the control packet in the router function, this particular function is called only when the simulation time of application layer starts. But i need to do it in the initial period of the simulaiton. And this control packet should be handled by all the nodes as it does for route req packet. If i set timer to activate this control packet and put it in the init function of dsr.pc this packet is not handled by other nodes. Please reply. --------------------------------- Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. --0-1510845198-1080629944=:16450 Content-Type: text/html; charset=us-ascii
    Hello Sir,
     
     I am in need of your help,
     
    I need to send a control packet before sending a route request packet.
     
       If  I intiate the control packet in the router function, this particular function is called only when the simulation time of application layer starts.
     
    But i need to do it in the initial period of the simulaiton. And this control packet should be handled by all the nodes as it does for route req packet. 
     
    If i set timer to activate this control packet and put it in the init function of dsr.pc this packet is not handled by other nodes. 
    Please reply.

    Do you Yahoo!?
    Yahoo! Finance Tax Center - File online. File on time. --0-1510845198-1080629944=:16450-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 03:03:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06315 for ; Tue, 30 Mar 2004 03:03:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EDO-0007YM-7Z for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 03:03:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U83IXQ029028 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 03:03:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EDN-0007Y3-FE for manet-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 03:03:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06263 for ; Tue, 30 Mar 2004 03:03:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EDJ-0005vM-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 03:03:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ECQ-0005k4-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 03:02:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8EBG-0005Yo-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 03:01:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EBC-0006sm-VZ; Tue, 30 Mar 2004 03:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EAI-0006pi-RB for manet@optimus.ietf.org; Tue, 30 Mar 2004 03:00:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06132 for ; Tue, 30 Mar 2004 03:00:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EAE-0005Ph-00 for manet@ietf.org; Tue, 30 Mar 2004 03:00:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8E9H-0005Ft-00 for manet@ietf.org; Tue, 30 Mar 2004 02:59:04 -0500 Received: from netns.kjist.ac.kr ([203.237.53.16] helo=NML.netmedia.kjist.ac.kr) by ietf-mx with esmtp (Exim 4.12) id 1B8E8N-00054Y-00 for manet@ietf.org; Tue, 30 Mar 2004 02:58:08 -0500 Received: from netmediahyyoon ([203.237.53.145]) by NML.netmedia.kjist.ac.kr with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 16:55:30 +0900 Reply-To: From: "Ha Young, Yoon" To: Cc: Date: Tue, 30 Mar 2004 16:58:10 +0900 Organization: NETMEDIA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C41678.2F58C590" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQWLL5hXopNRagvSyGw1Jv4U5S01Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 30 Mar 2004 07:55:30.0515 (UTC) FILETIME=[5F38DA30:01C4162C] Subject: [manet] Can I make the muliple channel configuration in MANET? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_FONT_FACE_BAD, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C41678.2F58C590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Link1 Link2 [WN1]- - - - - - - - - - - - [WN2]- - - - - - - - - - - [WN3] | | | Link3 | | [WN4] On the MANET topology above, is it available to make each links on different channel in 802.11b? I want to make all links are communicating at the same time. If it is available, how to I configure? If it is not, let me know the reason. If you have any information about them above, drop me a note, please. Have a nice day~ Regards, HaYoung Yoon ------=_NextPart_000_0000_01C41678.2F58C590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi all,

     

           &= nbsp;   = Link1           &n= bsp;            Link2

    [WN1]- - - - - - - - - - - - [WN2]- - - - = - - - - - - - [WN3]

           &= nbsp;           &n= bsp;         |

    |

    |  = Link3

    |

    |

    [WN4]<= /span>

     

     

    On the MANET topology above, is it = available to make each links on different channel in 802.11b?

     

    I want to make all links are communicating = at the same time.

     

    If it is available, how to I configure? =

     

    If it is not, let me know the = reason.

     

    If you have any information about them = above, drop me a note, please.

     

    Have a nice = day~

     

    Regards,

     

    HaYoung Yoon

    ------=_NextPart_000_0000_01C41678.2F58C590-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 03:49:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06314 for ; Tue, 30 Mar 2004 03:03:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EDO-0007YN-7l for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 03:03:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2U83InC029034 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 03:03:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EDN-0007Y5-UH for manet-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 03:03:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06266 for ; Tue, 30 Mar 2004 03:03:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EDJ-0005vT-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 03:03:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ECR-0005kC-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 03:02:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8EBG-0005Yp-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 03:01:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EBE-0006sy-HY; Tue, 30 Mar 2004 03:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8EAJ-0006pn-Ep for manet@optimus.ietf.org; Tue, 30 Mar 2004 03:00:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06135 for ; Tue, 30 Mar 2004 03:00:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8EAF-0005Pn-00 for manet@ietf.org; Tue, 30 Mar 2004 03:00:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8E9J-0005G4-00 for manet@ietf.org; Tue, 30 Mar 2004 02:59:06 -0500 Received: from netns.kjist.ac.kr ([203.237.53.16] helo=NML.netmedia.kjist.ac.kr) by ietf-mx with esmtp (Exim 4.12) id 1B8E8P-00054Y-00 for manet@ietf.org; Tue, 30 Mar 2004 02:58:09 -0500 Received: from netmediahyyoon ([203.237.53.145]) by NML.netmedia.kjist.ac.kr with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Mar 2004 16:55:30 +0900 Reply-To: From: "Ha Young, Yoon" To: Cc: Date: Tue, 30 Mar 2004 16:58:11 +0900 Organization: NETMEDIA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C41678.2F70BA60" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcQWLL5hXopNRagvSyGw1Jv4U5S01Q== Message-ID: X-OriginalArrivalTime: 30 Mar 2004 07:55:30.0609 (UTC) FILETIME=[5F473210:01C4162C] Subject: [manet] Can I make the muliple channel configuration in MANET? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_FONT_FACE_BAD, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C41678.2F70BA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Link1 Link2 [WN1]- - - - - - - - - - - - [WN2]- - - - - - - - - - - [WN3] | | | Link3 | | [WN4] On the MANET topology above, is it available to make each links on different channel in 802.11b? I want to make all links are communicating at the same time. If it is available, how to I configure? If it is not, let me know the reason. If you have any information about them above, drop me a note, please. Have a nice day~ Regards, HaYoung Yoon ------=_NextPart_000_0000_01C41678.2F70BA60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi all,

     

           &= nbsp;   = Link1           &n= bsp;            Link2

    [WN1]- - - - - - - - - - - - [WN2]- - - - = - - - - - - - [WN3]

           &= nbsp;           &n= bsp;         |

    |

    |  = Link3

    |

    |

    [WN4]<= /span>

     

     

    On the MANET topology above, is it = available to make each links on different channel in 802.11b?

     

    I want to make all links are communicating = at the same time.

     

    If it is available, how to I configure? =

     

    If it is not, let me know the = reason.

     

    If you have any information about them = above, drop me a note, please.

     

    Have a nice = day~

     

    Regards,

     

    HaYoung Yoon

    ------=_NextPart_000_0000_01C41678.2F70BA60-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 13:07:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02972 for ; Tue, 30 Mar 2004 13:07:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8NdF-0007LR-IQ for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 13:06:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UI6bCQ028234 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 13:06:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8NdF-0007LJ-Bi for manet-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 13:06:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02961 for ; Tue, 30 Mar 2004 13:06:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8NdD-0006fM-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 13:06:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8NcI-0006WF-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 13:05:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8Nbu-0006N2-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 13:05:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Nbi-00072u-Ny; Tue, 30 Mar 2004 13:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8NbJ-00070A-Da for manet@optimus.ietf.org; Tue, 30 Mar 2004 13:04:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02894 for ; Tue, 30 Mar 2004 13:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8NbH-0006MF-00 for manet@ietf.org; Tue, 30 Mar 2004 13:04:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8NaP-0006Dm-00 for manet@ietf.org; Tue, 30 Mar 2004 13:03:41 -0500 Received: from [203.199.83.246] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1B8NZj-00064d-00 for manet@ietf.org; Tue, 30 Mar 2004 13:02:59 -0500 Received: (qmail 8876 invoked by uid 510); 30 Mar 2004 18:02:47 -0000 Date: 30 Mar 2004 18:02:47 -0000 Message-ID: <20040330180247.8875.qmail@webmail35.rediffmail.com> Received: from unknown (219.65.124.109) by rediffmail.com via HTTP; 30 mar 2004 18:02:47 -0000 MIME-Version: 1.0 From: "mohannraj krishnamurthy" Reply-To: "mohannraj krishnamurthy" To: manet@ietf.org Content-type: multipart/alternative; boundary="Next_1080669767---0-203.199.83.246-8871" Subject: [manet] hello sir 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.7 required=5.0 tests=AWL,HTML_20_30, HTML_IMAGE_ONLY_10,HTML_MESSAGE,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 This is a multipart mime message --Next_1080669767---0-203.199.83.246-8871 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

    =0Ahello sir,
    =0A
    =0A i am currently working in Security aspects o= f manet..
    =0A
    =0Ai would like to get information regarding the variou= s routing algorithms available and different security schemes used in manet= ..
    =0A
    =0Aif possible please send me informations of the resources av= ailable regarding this..
    =0A
    =0Ai am a new user of glomosim and so if= possible please give me tips on glomosim usage and if possible the useful = resources..
    =0A
    =0Athanks,
    =0Abye.=0A

    =0A=0A=0Amohanraj

    = =0A=0A --Next_1080669767---0-203.199.83.246-8871 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hello sir,=0A=0A i am currently working in Security aspects of manet..=0A= =0Ai would like to get information regarding the various routing algorithms= available and different security schemes used in manet..=0A=0Aif possible = please send me informations of the resources available regarding this..=0A= =0Ai am a new user of glomosim and so if possible please give me tips on gl= omosim usage and if possible the useful resources..=0A=0Athanks,=0Abye.=0A= =0Amohanraj --Next_1080669767---0-203.199.83.246-8871-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 13:24:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03921 for ; Tue, 30 Mar 2004 13:24:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Nte-0000AM-T0 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 13:23:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2UINYgF000638 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 13:23:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Nte-0000AC-Iz for manet-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 13:23:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03886 for ; Tue, 30 Mar 2004 13:23:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Ntc-0001mv-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 13:23:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Nsr-0001dr-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 13:22:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8NsC-0001UB-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 13:22:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Ns9-0008HX-HO; Tue, 30 Mar 2004 13:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Nrt-0008H4-3L for manet@optimus.ietf.org; Tue, 30 Mar 2004 13:21:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03841 for ; Tue, 30 Mar 2004 13:21:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Nrr-0001S1-00 for manet@ietf.org; Tue, 30 Mar 2004 13:21:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Nr1-0001IP-00 for manet@ietf.org; Tue, 30 Mar 2004 13:20:52 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1B8NqW-00018g-00 for manet@ietf.org; Tue, 30 Mar 2004 13:20:20 -0500 Received: from yosemite.cs.ucsb.edu (yosemite [128.111.40.103]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id i2UIKJO12052 for ; Tue, 30 Mar 2004 10:20:19 -0800 (PST) From: Elizabeth Belding-Royer To: manet@ietf.org Content-Type: text/plain Message-Id: <1080670821.32419.55.camel@yosemite.cs.ucsb.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 30 Mar 2004 10:20:21 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] MWCN 2004 Deadline Extension! 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The paper submission deadline has been extended to Monday April 5, 2004 11:59PM PST! No further extensions will be given! *************************************************** ****** CALL FOR PAPERS ********* *************************************************** * * * IFIP/IEEE MWCN 2004 * * The Sixth IFIP/IEEE International Conference on * * Mobile and Wireless Communications Networks * * * * Paris, France, 25 - 27 October, 2004 * * * * http://mwcn2004.lri.fr/ * *************************************************** MWCN 2004 is the sixth annual international conference dedicated to advancing research on mobile wireless networks. In the past few years, there has been growing interest in integrating stand-alone mobile networks with infrastructured wireless networks to create more robust and adaptable wireless networks. To further encourage research in this area, the theme of this years conference is: ** Convergence of Mobile Wireless Networks and the Internet ** You are invited to submit original papers to the conference for review. Potential topics include, but are not limited to, the following areas: * Mobile network architecture * Resource and information management * Mobility support, protocols, and algorithms * Connection management * Applications * Mobile ad hoc networks * Wireless local area networks * Analysis and simulation of mobile networks * Evaluation of mobile network testbeds * Mobile network security * Quality of service * Energy efficiency of protocols and devices All papers should be submitted electronically in Portable Document Format (PDF). Submissions should be in English, and the maximum page length is 6 pages in no smaller than 10 point font. The name and affiliation of all authors should be included on the paper, and the contact information for the lead author should be included in a cover page. Full submission instructions can be found at http://mwcn2004.lri.fr IMPORTANT DATES --------------- Submission deadline: April 5, 2004, 11:59PM PST (Deadline Extended!) Notification of acceptance: June 1, 2004 Camera-ready deadline: July 1, 2004 Conference: 25-27 October 2004 Conference General Chairs ------------------------- Khaldoun Al Agha LRI, University of Paris XI, France khaldoun.alagha@lri.fr Guy Pujolle University of Paris VI, France guy.pujolle@lip6.fr Conference Technical Program Chair ---------------------------------- Elizabeth M. Belding-Royer University of California, Santa Barbara ebelding@cs.ucsb.edu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 17:42:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19131 for ; Tue, 30 Mar 2004 17:42:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006Xa-Ai for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24ASHWq026888 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 05:28:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayq5O-0006zb-DR for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 05:28:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06271 for ; Thu, 4 Mar 2004 05:28:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayq5K-0002WX-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 05:28:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayq3r-0002I3-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 05:26:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayq2q-00024y-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 05:25:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayq2Q-0006T9-V0; Thu, 04 Mar 2004 05:25:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayq1s-0006Rq-2o for manet@optimus.ietf.org; Thu, 04 Mar 2004 05:24:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06127 for ; Thu, 4 Mar 2004 05:24:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayq1d-0001rb-00 for manet@ietf.org; Thu, 04 Mar 2004 05:24:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayq0h-0001h1-00 for manet@ietf.org; Thu, 04 Mar 2004 05:23:24 -0500 Received: from csiges9.insa-lyon.fr ([134.214.79.200] helo=mail.insa-lyon.fr) by ietf-mx with esmtp (Exim 4.12) id 1Aypzp-0001NV-00 for manet@ietf.org; Thu, 04 Mar 2004 05:22:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.insa-lyon.fr (Postfix) with ESMTP id C6D374B73B; Thu, 4 Mar 2004 11:21:43 +0100 (CET) Received: from insa-lyon.fr (ares-chelius-1.insa-lyon.fr [134.214.144.146]) by mail.insa-lyon.fr (Postfix) with ESMTP id 5E7634B6F8; Thu, 4 Mar 2004 11:21:42 +0100 (CET) Message-ID: <40470344.3070202@insa-lyon.fr> Date: Thu, 04 Mar 2004 11:21:56 +0100 From: Guillaume Chelius Reply-To: guillaume.chelius@insa-lyon.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Ogier Cc: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> In-Reply-To: <40465203.6020407@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd 0.1 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Since Richard is quoting my mail of last year, I just want to reexpress my opinions on the subject. I think that the gateway discovery process (and prefix advertizement in IPv6) is deeply bound to the routing mechanism. As it has already been said many times, by myself and by others, the mechanism can be easily integrated into a proactive routing protocol. It requires the definition/addition of few flags/fields and would not only reduce the load induced by a separate gateway advertisement protocol but also set up an interesting adequation between the reactivity of the routing protocol and the advertizement frequency of gateways. Who wants to receive gateway advertizements every 2 seconds if routes are only refreshed every 5 seconds (or the opposite)? In the case of a reactive protocol, as Richard and Joe already said it, it could be usefull or interesting to design a proactive gateway advertizement protocol. The two gateway advertizement modes of operation (proactive or reactive) present different advantages and may be applied in different situations: - proactive: constant load (independant of the number of nodes accessing the Internet). - reactive: linear load in the number of nodes accessing the Internet. In conclusion, I think there is no need for a separate gateway/prefix advertizement protocol when a proactive routing protocol is used. It would be a waste (medium use) not to include it in the routing protocol. In the case of a reactive protocol, things are different as proactive advertizement can still be usefull. To go on with the discussion, I think the main issue is the following: should we impose or not gateway/prefix continuity. - with gateway/prefix continuity: routes are not optimal; routes to the gateway and routes to the Internet through the gateway may differ as they are computed respectively by the routing protocol and by the advertizement mechanism; defalt routing may be used to join the Internet. - without gateway/prefix continuity: routes are potentially optimal (depending on the routing protocol); necessity to use tunneling/source routing. If we give an answer to this question, other issues and implementations will be more straightforward. Regards, Guillaume. Richard Ogier wrote: > In fact, I made a similar point last September, which I will repeat > here: > > On 22 July 2002 Guillaume Chelius wrote: _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 17:43:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19219 for ; Tue, 30 Mar 2004 17:43:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006Xa-1t for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i259RCgv030745 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 04:27:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBbg-0007oJ-GI for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 04:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27821 for ; Fri, 5 Mar 2004 04:26:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzBbN-0001Sh-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 04:26:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzBaO-0001Cr-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 04:25:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzBZH-0000yj-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 04:24:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBZ1-00073H-6B; Fri, 05 Mar 2004 04:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzAXR-0000ex-7o for manet@optimus.ietf.org; Fri, 05 Mar 2004 03:18:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25503 for ; Fri, 5 Mar 2004 03:18:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzAXO-0003EZ-00 for manet@ietf.org; Fri, 05 Mar 2004 03:18:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzAWe-00032V-00 for manet@ietf.org; Fri, 05 Mar 2004 03:17:45 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx with smtp (Exim 4.12) id 1AzAVr-0002or-00 for manet@ietf.org; Fri, 05 Mar 2004 03:16:55 -0500 Received: (qmail 17162 invoked for bounce); 5 Mar 2004 08:17:01 -0000 Received: from unknown (HELO ?130.79.90.159?) (noel@unknown) by unknown with RC4-SHA encrypted SMTP; 5 Mar 2004 08:17:01 -0000 In-Reply-To: <4047762E.1080401@earthlink.net> References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <40470344.3070202@insa-lyon.fr> <404714FE.2010207@dpt-info.u-strasbg.fr> <4047762E.1080401@earthlink.net> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <74BDA2D0-6E7D-11D8-ADEA-000A95D03164@dpt-info.u-strasbg.fr> Content-Transfer-Encoding: 7bit Cc: guillaume.chelius@insa-lyon.fr, Christophe Jelger , manet From: Thomas Noel Subject: Re: [manet] Default Routes Date: Fri, 5 Mar 2004 09:16:51 +0100 To: Richard Ogier X-Mailer: Apple Mail (2.612) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Richard, > IF we decide we need > to ensure prefix continuity (and I have doubts about this), > then the link-state routing protocol can be modified to achieve this, > using link-state routing (instead of distance vectors). > I'm a co-author of draft draft-jelger-manet-gateway-autoconf Just to clarify the situation why do you doubt about prefix continuity ? Regards Thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 17:48:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20246 for ; Tue, 30 Mar 2004 17:48:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rji-0006Xa-UN for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24AfT2s031575 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 05:41:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqID-0008DC-DJ for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 05:41:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07057 for ; Thu, 4 Mar 2004 05:41:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyqI9-0005Sa-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 05:41:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyqHG-0005C3-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 05:40:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyqGG-0004xz-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 05:39:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqFv-0007id-Oh; Thu, 04 Mar 2004 05:39:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqFD-0007fH-8z for manet@optimus.ietf.org; Thu, 04 Mar 2004 05:38:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06876 for ; Thu, 4 Mar 2004 05:38:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyqF9-0004lL-00 for manet@ietf.org; Thu, 04 Mar 2004 05:38:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyqEG-0004bQ-00 for manet@ietf.org; Thu, 04 Mar 2004 05:37:25 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyqDN-0004RO-00 for manet@ietf.org; Thu, 04 Mar 2004 05:36:29 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i24AdIZr027254; Thu, 4 Mar 2004 11:39:18 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <404714FE.2010207@dpt-info.u-strasbg.fr> Date: Thu, 04 Mar 2004 12:37:34 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: guillaume.chelius@insa-lyon.fr CC: manet Subject: Re: [manet] Default Routes References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <1078323208.1364.48.camel@dhcp-8-241.it.uu.se> <006b01c40137$930f50a0$1f175d80@inria.fr> <1078334055.1364.99.camel@dhcp-8-241.it.uu.se> <40462332.9020908@dpt-info.u-strasbg.fr> <404649D3.1050208@loria.fr> <40465203.6020407@earthlink.net> <40470344.3070202@insa-lyon.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Guillaume, Just on point, see inline my comment. In general I agree that gateway discovery should not be separated, as stated in the draft. We first implemented it as a stand-alone process to check the operation. As you know, we plan to integrate it into OLSR. (see below for a last comment) Guillaume Chelius wrote: > Hello, > > Since Richard is quoting my mail of last year, I just want to > reexpress my opinions on the subject. I think that the gateway > discovery process (and prefix advertizement in IPv6) is deeply bound > to the routing mechanism. As it has already been said many times, by > myself and by others, the mechanism can be easily integrated into a > proactive routing protocol. It requires the definition/addition of few > flags/fields and would not only reduce the load induced by a separate > gateway advertisement protocol but also set up an interesting > adequation between the reactivity of the routing protocol and the > advertizement frequency of gateways. Who wants to receive gateway > advertizements every 2 seconds if routes are only refreshed every 5 > seconds (or the opposite)? > > In the case of a reactive protocol, as Richard and Joe already said > it, it could be usefull or interesting to design a proactive gateway > advertizement protocol. The two gateway advertizement modes of > operation (proactive or reactive) present different advantages and may > be applied in different situations: > - proactive: constant load (independant of the number of nodes > accessing the Internet). > - reactive: linear load in the number of nodes accessing the Internet. > > In conclusion, I think there is no need for a separate gateway/prefix > advertizement protocol when a proactive routing protocol is used. It > would be a waste (medium use) not to include it in the routing > protocol. In the case of a reactive protocol, things are different as > proactive advertizement can still be usefull. > > To go on with the discussion, I think the main issue is the following: > should we impose or not gateway/prefix continuity. > - with gateway/prefix continuity: routes are not optimal; routes to > the gateway and routes to the Internet through the gateway may differ > as they are computed respectively by the routing protocol and by the > advertizement mechanism; defalt routing may be used to join the Internet. > - without gateway/prefix continuity: routes are potentially optimal > (depending on the routing protocol); necessity to use tunneling/source > routing. With prefix continuity, routes are optimal if we use the "distance" algorithm : always choose closest gateway. In that case the route is a shortest route, but it can be different than the shortest route computed by the routing protocol. On the other hand, if we use the algorithm "prefix stability", then the route might not be optimal (I'm currently simulating this and it appears that routes are not much longer on average). > > If we give an answer to this question, other issues and > implementations will be more straightforward. > > Regards, > Guillaume. > > Richard Ogier wrote: > > In fact, I made a similar point last September, which I will repeat > > here: > > > > On 22 July 2002 Guillaume Chelius wrote: > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Mar 30 17:49:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20333 for ; Tue, 30 Mar 2004 17:49:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjj-0006a4-0M for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Gig7o023888 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 11:44:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayvxi-0006DB-KX for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 11:44:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01322 for ; Thu, 4 Mar 2004 11:44:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayvxh-0007lQ-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:44:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayvwm-0007bH-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:43:44 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyvwK-0007R9-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:43:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyvwK-0002T2-3t for manet-web-archive@ietf.org; Thu, 04 Mar 2004 11:43:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayvw5-0005eD-UR; Thu, 04 Mar 2004 11:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayvvl-0005dM-H5 for manet@optimus.ietf.org; Thu, 04 Mar 2004 11:42:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01225 for ; Thu, 4 Mar 2004 11:42:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayvvk-0007PQ-00 for manet@ietf.org; Thu, 04 Mar 2004 11:42:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayvup-0007Eg-00 for manet@ietf.org; Thu, 04 Mar 2004 11:41:44 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27] helo=i2r.a-star.edu.sg) by ietf-mx with esmtp (Exim 4.12) id 1AyvuM-00074O-00 for manet@ietf.org; Thu, 04 Mar 2004 11:41:14 -0500 Received: from newmailhost (localhost [127.0.0.1]) by i2r.a-star.edu.sg (8.12.10/8.12.10) with ESMTP id i24Ge9F1007175 for ; Fri, 5 Mar 2004 00:40:09 +0800 (SGT) Received: from localhost.localdomain ([192.168.152.135]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HU200KLA8Z68J@mailhost.lit.org.sg> for manet@ietf.org; Fri, 05 Mar 2004 00:40:18 +0800 (SGT) Received: by localhost.localdomain (Postfix, from userid 1000) id BBD854331E; Fri, 05 Mar 2004 00:41:11 +0800 (SGT) Date: Fri, 05 Mar 2004 00:41:11 +0800 From: "Sukanta K. Hazra" Subject: Re: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt In-reply-to: To: manet@ietf.org Mail-followup-to: manet@ietf.org Message-id: <20040304164111.GB13339@i2r.a-star.edu.sg> Organization: Institute for Infocomm Research MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 User-Agent: Mutt/1.5.4i References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi! Comments inline. ----- Original Message ----- From: "Pete Sholander " Date: Wed, 03 Mar, 2004 22:15 SGT Subject: Re: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt > If the charter doesn't include "internet connectivity" then it should be, IMHO :) I strongly agree. > > Standardizing that feature would be most useful to my customer set. Futhermore having a simple method that scaled to 50-100 node sized MANETs (with a reasonably-planned set of address blocks) might suffice for now. A general solution might be a ANS problem. I don't quite feel comfortable with restricting the scope of the solution to 50-100 nodes (at least not in so many words). Pushing the problem to ANS is not a solution. Networks do and will grow, and we will face the same problem again in near future. Any solution which is proposed should keep scalability in mind, which means be wary of flooding (even something which is as seemingly harmless as broadcast every 2 seconds may come back and haunt you in large dense networks). - Sukanta > > --Pete Sholander > Atlanta, GA > > >>> Ryuji Wakikawa 03/03/04 01:58AM >>> > > I think the first step is MANET WG should make decision whether the WG > includes internet connectivity stuff in manet charter or > not. Otherwise, many similar drafts are submitted without any progress > at IETF. > > > > ryuji > > > At Tue, 2 Mar 2004 16:07:17 +0900, > HyunWook Cha wrote: > > > > Hello, all. > > > > After my presentation is finished, I got two comments. Although Paal's > > comments which are more technical seem to be resolved(I guess. If wrong, > > please correct me, Paal), I think that I must tell what is different > > with existing solutions for MANET Internet connectivity in my draft. > > > > As I mentioned at my presentation, my draft consists of two component. > > Route determination algorithm and Forwarding algorithm. As you know, > > these are critical parts in this area(Int. Connectivity) and all > > existing solutions address with their own way. > > > > Firstly, route optimization is not mentioned at existing drafts > > referenced by mine (If wrong, please correct me.) > > > > As for proposed forwarding algorithm, forwarding using default route can > > be done for packets without routing header. I.E, after look up of > > routing table with destination address fails, forwarding decision is > > based on source global address of the packet. That is, gw_info list is > > searched with source prefix. If matched gw_info is found, the packet is > > forwarded through host route entry for the gw advertising the prefix. > > Thus, multiple addresses from multiple gateways can be configured in a > > node and intermediate nodes can forward packets without routing header > > only if gateway info list is maintained in the node. > > > > I request valuable comments on my draft from authors of previous drafts > > including C. Perkins, Wakikawa, C. Jelger, Pekka. Personally I also > > believe that this area is very important and it is time to make > > progress. How about requirement document or merged solution document? > > Please let me know what is in your mind. Whoever is interested in this > > topic may be welcomed in this thread. > > > > Kindly Regards, > > > > HyunWook Cha > > > > > > > > > > _______________________________________________ > > 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 -- Sukanta K. Hazra (Mr.) Institute for Infocomm Research Tel: +65 6874-1953 Fax: +65 6776-8109 Homepage: http://www1.i2r.a-star.edu.sg/~sukanta/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 17:49:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20439 for ; Tue, 30 Mar 2004 17:49:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rji-0006Zv-VY for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N9fAbu025908 for manet-archive@odin.ietf.org; Mon, 23 Feb 2004 04:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCaH-0006jb-D1 for manet-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 04:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15769 for ; Mon, 23 Feb 2004 04:41:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvCaE-0001ns-00 for manet-web-archive@ietf.org; Mon, 23 Feb 2004 04:41:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvCZG-0001jl-00 for manet-web-archive@ietf.org; Mon, 23 Feb 2004 04:40:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvCYU-0001gW-00 for manet-web-archive@ietf.org; Mon, 23 Feb 2004 04:39:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCYJ-0006KE-Bx; Mon, 23 Feb 2004 04:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCXS-0006Cu-Au for manet@optimus.ietf.org; Mon, 23 Feb 2004 04:38:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15688 for ; Mon, 23 Feb 2004 04:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvCXP-0001c4-00 for manet@ietf.org; Mon, 23 Feb 2004 04:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvCWT-0001Yk-00 for manet@ietf.org; Mon, 23 Feb 2004 04:37:10 -0500 Received: from smtp1.bae.co.uk ([20.138.254.61]) by ietf-mx with esmtp (Exim 4.12) id 1AvCW6-0001VQ-00 for manet@ietf.org; Mon, 23 Feb 2004 04:36:46 -0500 Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234]) by smtp1.bae.co.uk (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1N9aHg28877 for ; Mon, 23 Feb 2004 09:36:17 GMT Received: from bsrsmtp02.ng.bae.co.uk ([141.245.68.242]) by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998) with SMTP id <0HTJ00BET6MZQ7@ngbaux.net.bae.co.uk> for manet@ietf.org; Mon, 23 Feb 2004 09:35:23 +0000 (GMT) Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by 141.245.68.242 with InterScan Messaging Security Suite for SMTP; Mon, 23 Feb 2004 09:36:10 +0000 Received: from glkms0008.GREENLNK.NET ([10.15.184.8]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Feb 2004 09:36:11 +0000 Date: Mon, 23 Feb 2004 09:36:10 +0000 From: "Dearlove, Chris (UK)" Subject: RE: [manet] OLSR - link hysteresis questions To: Andreas T , manet@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable Thread-Topic: [manet] OLSR - link hysteresis questions Thread-Index: AcP4DcuUZY64dAs5QXybk1Er+FxF3wB4Vdfg content-class: urn:content-classes:message X-OriginalArrivalTime: 23 Feb 2004 09:36:11.0413 (UTC) FILETIME=[7901BC50:01C3F9F0] Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > I have implemented detection of "a long period of silence" in=20 > this way: > A link tuple records the following in addition to the fields specified > in the RFC: > next_hello_timer - a timer describing withing what time a new HELLO > should be received on this link. > last_htime - last recorded htime value from the=20 > neighbor(which this link > connects us to). >=20 > Upon receiving a HELLO the next_hello_timer is set to now + received > htime(+ some slack) and the last_htime is set to the received htime. > the link set is constantly checked for timed out entris with=20 > regards to > the next_hello_timer. If a links next_hello_timer is timed=20 > out - a "long > period of silence" is considered detected and the instabillity rule is > applied to that links link_quality. The next_hello_timer is the set to > now + last_htime to be able to detect another "long periode=20 > of silence". > I assume this is the correct way to do this? Or should this=20 > test not be > "reset" once a long period of silence is detected? In my (not publicly available) implementation I do something essentially as this, except that when what you've called next_hello_timer times out I only increment it by htime, I don't add the "slack" (which I have my own version of) again. Before reading your next paragraph I then typed the following comment If also tracking packet numbers for loss, you may want to adjust that, as otherwise a single lost packet containing a HELLO message gets double counted. And then found that was your point. I increment the "next expected packet number" when applying lost HELLO correction. I must admit I haven't discussed this externally, but not doing it is seriously wrong, as you have also found. I did suggest formally adding these fields with names to OLSR, but my comments to the authors were too late for the RFC. ******************************************************************** 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 exim@www1.ietf.org Tue Mar 30 17:51:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20716 for ; Tue, 30 Mar 2004 17:51:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006YH-4r for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0S0GX6F016514 for manet-archive@odin.ietf.org; Tue, 27 Jan 2004 19:16:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AldNh-0004IH-Hl for manet-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 19:16:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03109 for ; Tue, 27 Jan 2004 19:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AldNg-0006kY-00 for manet-web-archive@ietf.org; Tue, 27 Jan 2004 19:16:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AldLE-0006BX-00 for manet-web-archive@ietf.org; Tue, 27 Jan 2004 19:14:01 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AldJr-0005tK-00 for manet-web-archive@ietf.org; Tue, 27 Jan 2004 19:12:35 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AldAT-0004gd-Jb for manet-web-archive@ietf.org; Tue, 27 Jan 2004 19:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ald9h-0007Cc-Fh; Tue, 27 Jan 2004 19:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlADU-0003WK-2W for manet@optimus.ietf.org; Mon, 26 Jan 2004 12:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13141 for ; Mon, 26 Jan 2004 12:08:01 -0500 (EST) From: joan.martin@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlADS-0000zZ-00 for manet@ietf.org; Mon, 26 Jan 2004 12:08:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlACX-0000xh-00 for manet@ietf.org; Mon, 26 Jan 2004 12:07:06 -0500 Received: from gw-nl4.philips.com ([161.85.127.50]) by ietf-mx with esmtp (Exim 4.12) id 1AlABt-0000v2-00 for manet@ietf.org; Mon, 26 Jan 2004 12:06:25 -0500 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 712572B38A for ; Mon, 26 Jan 2004 18:06:24 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id F07D719C51 for ; Mon, 26 Jan 2004 18:06:23 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 986EF19C4E for ; Mon, 26 Jan 2004 18:06:23 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id SAA00856 for ; Mon, 26 Jan 2004 18:06:23 +0100 (MET) To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 26 Jan 2004 18:10:11 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 26/01/2004 18:08:17, Serialize complete at 26/01/2004 18:08:17 Content-Type: multipart/alternative; boundary="=_alternative 005DF165C1256E27_=" Subject: [manet] Selective Acknowledgement 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 005DF165C1256E27_= Content-Type: text/plain; charset="us-ascii" Hi, Does anybody know any literature about selective acknowledgement applied to manet (802.11). Concretely, selective acknowledge in response to a broadcast transmission. The IEEE 802.11 MAC specification does not allow acknowledging on receiving a broadcast transmission. Therefore how could I design a mechanism which ensures me that at least one neighboring node has received the broadcast message (imagine a critical application, e.g. car accident warning, in which you cannot permit a broadcast message "to be lost on the air") Best regards, Joan --=_alternative 005DF165C1256E27_= Content-Type: text/html; charset="us-ascii"
    Hi,

    Does anybody know any literature about selective acknowledgement applied to manet (802.11). Concretely, selective acknowledge in response to a broadcast transmission.

    The IEEE 802.11 MAC specification does not allow acknowledging on receiving a broadcast transmission. Therefore how could I design a mechanism which ensures me that at least one neighboring node has received the broadcast message (imagine a critical application, e.g. car accident warning, in which you cannot permit a broadcast message "to be lost on the air")

    Best regards,
    Joan --=_alternative 005DF165C1256E27_=-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 17:51:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20752 for ; Tue, 30 Mar 2004 17:51:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjg-0006ZK-OD for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0R8JZ09031817 for manet-archive@odin.ietf.org; Tue, 27 Jan 2004 03:19:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlORb-0008H6-Da for manet-web-archive@optimus.ietf.org; Tue, 27 Jan 2004 03:19:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24293 for ; Tue, 27 Jan 2004 03:19:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlORZ-00071w-00 for manet-web-archive@ietf.org; Tue, 27 Jan 2004 03:19:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlOQd-0006zU-00 for manet-web-archive@ietf.org; Tue, 27 Jan 2004 03:18:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AlOQK-0006xT-00 for manet-web-archive@ietf.org; Tue, 27 Jan 2004 03:18:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlOQ5-0007zn-Rm; Tue, 27 Jan 2004 03:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlOPb-0007z2-Ko for manet@optimus.ietf.org; Tue, 27 Jan 2004 03:17:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24255 for ; Tue, 27 Jan 2004 03:17:29 -0500 (EST) From: joan.martin@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlOPZ-0006wf-00 for manet@ietf.org; Tue, 27 Jan 2004 03:17:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlOOh-0006v2-00 for manet@ietf.org; Tue, 27 Jan 2004 03:16:35 -0500 Received: from gw-nl4.philips.com ([161.85.127.50]) by ietf-mx with esmtp (Exim 4.12) id 1AlOOO-0006t6-00 for manet@ietf.org; Tue, 27 Jan 2004 03:16:16 -0500 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl4.philips.com (Postfix) with ESMTP id D95852C656 for ; Tue, 27 Jan 2004 09:16:13 +0100 (MET) Received: from smtpscan-nl1.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id B4A6419C49 for ; Tue, 27 Jan 2004 09:16:12 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl1.philips.com (Postfix) with ESMTP id 3700719C45 for ; Tue, 27 Jan 2004 09:16:12 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id JAA07819 for ; Tue, 27 Jan 2004 09:16:11 +0100 (MET) To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 27 Jan 2004 09:19:58 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 27/01/2004 09:18:06, Serialize complete at 27/01/2004 09:18:06 Content-Type: multipart/alternative; boundary="=_alternative 002D6666C1256E28_=" Subject: [manet] Selective Acknowledgement 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE,NO_REAL_NAME autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 002D6666C1256E28_= Content-Type: text/plain; charset="us-ascii" Hi, Does anybody know any literature about selective acknowledgement applied to manet (802.11). Concretely, selective acknowledge in response to a broadcast transmission. The IEEE 802.11 MAC specification does not allow acknowledging on receiving a broadcast transmission. Therefore how could I design a mechanism which ensures me that at least one neighboring node has received the broadcast message (imagine a critical application, e.g. car accident warning, in which you cannot permit a broadcast message "to be lost on the air") Best regards, Joan --=_alternative 002D6666C1256E28_= Content-Type: text/html; charset="us-ascii"
    Hi,

    Does anybody know any literature about selective acknowledgement applied to manet (802.11). Concretely, selective acknowledge in response to a broadcast transmission.

    The IEEE 802.11 MAC specification does not allow acknowledging on receiving a broadcast transmission. Therefore how could I design a mechanism which ensures me that at least one neighboring node has received the broadcast message (imagine a critical application, e.g. car accident warning, in which you cannot permit a broadcast message "to be lost on the air")

    Best regards,
    Joan --=_alternative 002D6666C1256E28_=-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 17:53:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21095 for ; Tue, 30 Mar 2004 17:53:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjf-0006Zv-Li for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N819qo000833 for manet-archive@odin.ietf.org; Mon, 23 Feb 2004 03:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvB1X-0000DM-7S for manet-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 03:01:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12473 for ; Mon, 23 Feb 2004 03:01:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvB1T-0002zF-00 for manet-web-archive@ietf.org; Mon, 23 Feb 2004 03:01:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvB0T-0002u8-00 for manet-web-archive@ietf.org; Mon, 23 Feb 2004 03:00:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvAza-0002qr-00 for manet-web-archive@ietf.org; Mon, 23 Feb 2004 02:59:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvAzY-0008G8-EB; Mon, 23 Feb 2004 02:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvAyj-0008CA-AY for manet@optimus.ietf.org; Mon, 23 Feb 2004 02:58:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12380 for ; Mon, 23 Feb 2004 02:58:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvAyf-0002nj-00 for manet@ietf.org; Mon, 23 Feb 2004 02:58:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvAxh-0002k6-00 for manet@ietf.org; Mon, 23 Feb 2004 02:57:10 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27] helo=i2r.a-star.edu.sg) by ietf-mx with esmtp (Exim 4.12) id 1AvAxS-0002gW-00 for manet@ietf.org; Mon, 23 Feb 2004 02:56:54 -0500 Received: from newmailhost (localhost [127.0.0.1]) by i2r.a-star.edu.sg (8.12.10/8.12.10) with ESMTP id i1N7u67o017955 for ; Mon, 23 Feb 2004 15:56:06 +0800 (SGT) Received: from localhost.localdomain ([192.168.152.135]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HTJ00IIT21KJT@mailhost.lit.org.sg> for manet@ietf.org; Mon, 23 Feb 2004 15:56:10 +0800 (SGT) Received: by localhost.localdomain (Postfix, from userid 1000) id 92896352CD; Mon, 23 Feb 2004 15:56:45 +0800 (SGT) Date: Mon, 23 Feb 2004 15:56:45 +0800 From: "Sukanta K. Hazra" Subject: Re: [manet] Size of Traces In-reply-to: To: Karun Verma Cc: manet@ietf.org Mail-followup-to: Karun Verma , manet@ietf.org Message-id: <20040223075645.GA25088@i2r.a-star.edu.sg> Organization: Institute for Infocomm Research MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 User-Agent: Mutt/1.5.4i References: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi! The size of the trace (300MB) is not unusual considering the number of connections. If you are concerned about the trace size, then you should trace the relevant data. Using trace-all does generate large traces. Regards, Sukanta ----- Original Message ----- From: "Karun Verma " Date: Mon, 23 Feb, 2004 14:32 SGT Subject: [manet] Size of Traces > Hello everybody, > > After reading ur views on the size of tora traces due to high mobility. i > have reduced the mobility to 10m/s but increased the number of connections > during simulation time which is 200 sec and 200 connections in between. > used cbrgen.tcl fro generating the traffic. now the traces are coming with > size more than 300MB. Please also suggest me another script for generating > traffic automatically for the simulation environment. > > Thanx in Advance > > ############################################ > > # Karun Verma > # > > ########################################### > > _________________________________________________________________ > Contact brides & grooms FREE! http://www.shaadi.com/ptnr.php?ptnr=hmltag > Only on www.shaadi.com. Register now! > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- Sukanta K. Hazra (Mr.) Institute for Infocomm Research Tel: +65 6874-1953 Fax: +65 6776-8109 Homepage: http://www1.i2r.a-star.edu.sg/~sukanta/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 17:53:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21200 for ; Tue, 30 Mar 2004 17:53:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006Zv-In for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B9ukPg019946 for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 04:56:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Mvl-0005BY-V6 for manet-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 04:56:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22493 for ; Thu, 11 Mar 2004 04:56:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Mvg-00065J-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 04:56:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Mui-0005v6-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 04:55:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1MuH-0005lI-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 04:55:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Mu6-0004py-Vt; Thu, 11 Mar 2004 04:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Mt9-0004nE-NZ for manet@optimus.ietf.org; Thu, 11 Mar 2004 04:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22259 for ; Thu, 11 Mar 2004 04:54:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Mt6-0005Y2-00 for manet@ietf.org; Thu, 11 Mar 2004 04:54:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Mrr-0005KF-00 for manet@ietf.org; Thu, 11 Mar 2004 04:52:43 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1B1Mqv-00057Q-00 for manet@ietf.org; Thu, 11 Mar 2004 04:51:46 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Mar 2004 10:51:44 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : [manet] mesh networks Date: Thu, 11 Mar 2004 10:51:43 +0100 Message-ID: Thread-Topic: [manet] mesh networks Thread-Index: AcQHTi0GpgG4IdD9T3aoYuTPTgcG1QAACvDg From: "MEDDOUR Djamal Eddine thesard FTRD/DAC/LAN" To: "amine elabidi" , X-OriginalArrivalTime: 11 Mar 2004 09:51:44.0930 (UTC) FILETIME=[7672E020:01C4074E] Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Tou can take a look on this : Dave Beyer, "Fundamental Characteristics = and Benefits of Wireless Routing ("Mesh") Networks", National Wireless = Engineering Conference, 2002 Regards=20 Djamal=20 -----Message d'origine----- De : manet-admin@ietf.org [mailto:manet-admin@ietf.org] De la part de = amine elabidi Envoy=E9 : jeudi 11 mars 2004 10:47 =C0 : manet@ietf.org Objet : [manet] mesh networks I m looking for some references about mesh networks thank you =09 =09 =09 Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !=20 Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger = !T=E9l=E9chargez Yahoo! Messenger sur http://fr.messenger.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 exim@www1.ietf.org Tue Mar 30 17:54:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21452 for ; Tue, 30 Mar 2004 17:54:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rje-0006YH-AF for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J7AwpO019608 for manet-archive@odin.ietf.org; Fri, 19 Mar 2004 02:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E9h-00055x-T2 for manet-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 02:10:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16138 for ; Fri, 19 Mar 2004 02:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E9e-0000fI-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 02:10:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E8q-0000bK-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 02:10:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4E85-0000XC-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 02:09:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E7s-0004Jj-Jj; Fri, 19 Mar 2004 02:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4E70-00041B-By for manet@optimus.ietf.org; Fri, 19 Mar 2004 02:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13274 for ; Fri, 19 Mar 2004 02:08:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4E6w-0000QP-00 for manet@ietf.org; Fri, 19 Mar 2004 02:08:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4E62-0000Lg-00 for manet@ietf.org; Fri, 19 Mar 2004 02:07:11 -0500 Received: from trinity.critical-systems.no ([194.143.111.171] helo=trinity.gnist.org) by ietf-mx with esmtp (Exim 4.12) id 1B4E5g-0000HG-00 for manet@ietf.org; Fri, 19 Mar 2004 02:06:48 -0500 Received: from localhost (unknown [127.0.0.1]) by trinity.gnist.org (Postfix) with ESMTP id 024C6633057; Fri, 19 Mar 2004 08:06:48 +0100 (CET) Received: from trinity.gnist.org ([127.0.0.1]) by localhost (trinity.gnist.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06372-04; Fri, 19 Mar 2004 08:06:46 +0100 (CET) Received: from olsr.org (41.80-203-47.nextgentel.com [80.203.47.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trinity.gnist.org (Postfix) with ESMTP id 9056E63303C; Fri, 19 Mar 2004 08:06:46 +0100 (CET) Message-ID: <405B2915.6060805@olsr.org> Date: Fri, 19 Mar 2004 08:08:37 -0900 From: =?ISO-8859-1?Q?Andreas_T=F8nnesen?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040118 X-Accept-Language: nb, en-us, en MIME-Version: 1.0 To: manet user Cc: manet@ietf.org Subject: Re: [manet] OLSR packet format implementation References: <20040318215409.14035.qmail@web61105.mail.yahoo.com> In-Reply-To: <20040318215409.14035.qmail@web61105.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,DATE_IN_FUTURE_06_12 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, My comments are inline - based on my experiences from OLSR=20 implementation and testing. manet user wrote: > Hi, > =20 > I am trying to implement OLSR and have couple of questions regarding=20 > OLSR packet format. OLSR packet contain "Packet Length" and "Packet Seq= =20 > Num" and after that there can be multiple messages (for e.g. 1 Hello, 1= TC). > =20 > 1) Since Hello and TC messages are periodically sent, each having its=20 > own timer expiry. When will a condition happen that OLSR packet contain= s=20 > more than one message type ? Forwarded messages are to be cached in nodes for a certain time=20 interval(jitter) to avoid syncronization. Because of this several=20 packets will very often be stacked in the same OLSR package. You could probably stack generated messages as well - but I have not=20 implemented this... > Also, if an OLSR packet has 1 hello and 1=20 > TC, where TC needs to be forwarded, will receiving node create a new T= C=20 > extracting information from the received packet ? > The hopcount and TTL fields must be altered before forwarding the=20 message - but if one is to "rebuild" the TC or not is more of a=20 implementation choise. > 2) When a node receives an OLSR packet, it will loop through each=20 > message type and process it accordingly. It will keep on adding "Messag= e=20 > Size" from each message processed till it becomes equal to the "Packet=20 > Length". Can this be one of the right ways of processing an OLSR packet= ? Yes. First you should probably check if the size of the received data=20 matches the OLSR packet size. If so, you can loop trough messages until=20 your sum of processed data size equals the OLSR packet size. - Andreas T --=20 Andreas T=F8nnesen(andreas@olsr.org) UniK University Graduation Center University of Oslo http://www.olsr.org _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 17:55:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21545 for ; Tue, 30 Mar 2004 17:55:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjd-0006YH-Ko for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i249jUp0014145 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 04:45:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypQ1-0003g4-In for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 04:45:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03955 for ; Thu, 4 Mar 2004 04:45:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypPy-0001Ge-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:45:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypOv-00011e-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:44:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AypNu-0000ox-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:43:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypNe-0002uo-Gl; Thu, 04 Mar 2004 04:43:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypN2-0002rq-D7 for manet@optimus.ietf.org; Thu, 04 Mar 2004 04:42:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03790 for ; Thu, 4 Mar 2004 04:42:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypMz-0000dQ-00 for manet@ietf.org; Thu, 04 Mar 2004 04:42:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypM3-0000R0-00 for manet@ietf.org; Thu, 04 Mar 2004 04:41:24 -0500 Received: from xenon2.um.es ([155.54.212.101] helo=smtp.um.es) by ietf-mx with esmtp (Exim 4.12) id 1AypL5-00003i-00 for manet@ietf.org; Thu, 04 Mar 2004 04:40:23 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 14E83FA807; Thu, 4 Mar 2004 10:39:54 +0100 (CET) Received: from correo.um.es (zape.um.es [155.54.212.102]) by smtp.um.es (Postfix) with ESMTP id EEBD8FA7E6; Thu, 4 Mar 2004 10:39:53 +0100 (CET) Received: from correo.um.es (myotis.um.es [155.54.212.92]) by localhost (Postfix) with ESMTP id 75BDE18E14; Thu, 4 Mar 2004 10:39:53 +0100 (MET) Received: from dif.um.es (dibulibu.um.es [155.54.1.250]) by correo.um.es (Postfix) with ESMTP id B934618E16; Thu, 4 Mar 2004 10:39:51 +0100 (MET) Message-ID: <4046F6E0.5040307@dif.um.es> Date: Thu, 04 Mar 2004 10:29:04 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jafy@etri.re.kr Cc: "'Christophe Jelger'" , "'manet'" Subject: Re: [manet] Gateway Discovery : are we going forward ? References: <000001c401cb$b9d269e0$ae70fe81@jafywinxp> In-Reply-To: <000001c401cb$b9d269e0$ae70fe81@jafywinxp> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Guys, Completely agree with both of you on this issue. I think there is a clear interest on the topic, and we should move forward defining a clear problem statement, and then proposing "agreed" solutions. Regards, Pedro HyunWook Cha wrote: >Hello, all. > >I agree with Christophe, though "Gateway Discovery" seems to be narrow. >This is important issue since it is not an optional service, and basic >framework to enable communication through Internet as well as >incorporation with MIPv6 and multi-homing issues can be addressed in >this category. > >HyunWook > >-----Original Message----- >From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of >Christophe Jelger >Sent: Thursday, March 04, 2004 7:16 PM >To: manet >Subject: [manet] Gateway Discovery : are we going forward ? > > > >Hi all, > >Well I obviously appreciate the discussions we have on gateway >discovery, but as Eric Fleury said, we had similar discussions in the >past. This time I hope it won't be for nothing, and I hope there could >be some constructive consequences. It seems that many MANET members are >willing to work on that, so maybe we could summarize the discussions we >had and try to go ahead, maybe with a problem statement draft. > >So (maybe this is a very direct question) are the chairs willing to add >this issues in the WG charter ? > >I think we could start to discuss on how we could collaborate ... > >Christophe > > > >_______________________________________________ >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 exim@www1.ietf.org Tue Mar 30 17:55:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21562 for ; Tue, 30 Mar 2004 17:55:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjd-0006a4-Gc for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2ME5s5D016464 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 09:05:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q3t-0004HP-JN for manet-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 09:05:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25275 for ; Mon, 22 Mar 2004 09:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q3r-0005Hi-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 09:05:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Q2u-00058F-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 09:04:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q25-0004zh-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 09:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q1l-0003KR-BU; Mon, 22 Mar 2004 09:03:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Q0f-0003Hl-3j for manet@optimus.ietf.org; Mon, 22 Mar 2004 09:02:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25032 for ; Mon, 22 Mar 2004 09:02:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Q0d-0004oE-00 for manet@ietf.org; Mon, 22 Mar 2004 09:02:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Pzk-0004if-00 for manet@ietf.org; Mon, 22 Mar 2004 09:01:36 -0500 Received: from rissala173.outgw.tn ([193.95.17.173]) by ietf-mx with esmtp (Exim 4.12) id 1B5Pyw-0004dW-00 for manet@ietf.org; Mon, 22 Mar 2004 09:00:46 -0500 Received: from tounes-22.ati.tn (tounes-22.ati.tn [193.95.66.22]) by rissala164.ingw.tn (8.12.9/8.12.9) with ESMTP id i2MG1GoD009606; Mon, 22 Mar 2004 15:01:16 -0100 (GMT) Received: from smtp1.planet.net.tn (smtp.planet.tn [193.95.123.25]) by tounes-22.ati.tn (8.12.8/8.12.8) with ESMTP id i2MD0Yxw025004; Mon, 22 Mar 2004 15:00:34 +0200 (EET) Received: from home ([193.95.89.184]) by smtp1.planet.net.tn (Switch-3.1.3/Switch-3.1.0) with SMTP id i2MG13Ct007414; Mon, 22 Mar 2004 15:01:45 -0100 (GMT) Message-ID: <00ae01c41016$0cd61c60$0f605fc1@home> From: "Wala Turki Latrous" To: =?iso-8859-1?Q?Andreas_T=F8nnesen?= Cc: References: <008b01c40fff$8b6a1980$0f605fc1@home> <405ED943.6010807@olsr.org> Subject: Re: [manet] OLSR attack Date: Mon, 22 Mar 2004 14:59:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rissala173.outgw.tn id NAA19253 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thank you for your indication. But i had already checked out this documen= t and there is no clarification about the sequence number utilisation in su= ch type of attacks so i need to clarify this point. ----- Original Message ----- From: "Andreas T=F8nnesen" To: "Wala Turki Latrous" Cc: Sent: Monday, March 22, 2004 1:17 PM Subject: Re: [manet] OLSR attack > You could check out: > *"Securing the OLSR protocol"* > Thomas Heide Clausen, Cedric Adjih, Philippe Jacquet, Anis Laouiti, Pau= l > Muhltahler, Daniele Raffo > > http://voop.free.fr/Publications/2003/medhoc03.shtml > > - Andreas > > Wala Turki Latrous wrote: > > > Hello, > > > > > > > > In the OLSR protocol : if a node X wants to send HELLO messages, > > pretending to have the identity of another node A ; knowing the main > > address of A and then use it as his originator address is sufficient > > for this attack ? or X must also know the sequence numbers recently > > used by A for the packets and/or the HELLO messages ? > > > > > > > > In the same way, X wants to send TC messages, pretending to have the > > identity of A. Must X know the packet sequence number and the ANSN > > recently used by A? > > > > > > > > Is there any works on attacks on OLSR or securing OLSR ? > > > > -- > > -- > Andreas T=F8nnesen(andreas@olsr.org) > UniK University Graduation Center > University of Oslo > http://www.olsr.org > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Mar 30 17:57:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22143 for ; Tue, 30 Mar 2004 17:57:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjc-0006ZK-Lh for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23Af4Qp005663 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 05:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyToA-0001Sq-4D for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 05:40:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17326 for ; Wed, 3 Mar 2004 05:40:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTnS-0004HX-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:40:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTmU-00044G-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:39:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyTlX-0003q1-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:38:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyTlY-00011d-TF for manet-web-archive@ietf.org; Wed, 03 Mar 2004 05:38:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTlN-0000tt-DH; Wed, 03 Mar 2004 05:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTl0-0000qy-EP for manet@optimus.ietf.org; Wed, 03 Mar 2004 05:37:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17115 for ; Wed, 3 Mar 2004 05:37:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTkc-0003ec-00 for manet@ietf.org; Wed, 03 Mar 2004 05:37:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTjc-0003QP-00 for manet@ietf.org; Wed, 03 Mar 2004 05:36:17 -0500 Received: from anyida.tts.lth.se ([130.235.18.10]) by ietf-mx with esmtp (Exim 4.12) id 1AyTif-0003E2-00 for manet@ietf.org; Wed, 03 Mar 2004 05:35:17 -0500 Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id LAA24286; Wed, 3 Mar 2004 11:36:35 +0100 (MET) Message-ID: <4045B543.6000601@telecom.lth.se> Date: Wed, 03 Mar 2004 11:36:51 +0100 From: Anders Nilsson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Jelger , manet Subject: Re: [manet] Default Routes (WAS: Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt) (Intern) References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> In-Reply-To: <4045B7F7.9020902@dpt-info.u-strasbg.fr> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello again, Christophe Jelger wrote: > > Of course as one of the authors of a solution that uses default route > I don't agree with your statements. ;-) > > In our draft each MANET node knows which gateway it uses, and (in the > steady-state) it knows that all nodes on the "default route" path use > the same gateway. With our solution gateways don't announce routes, > they just announce prefixes. If two gateways announce the same prefix, > an ad hoc node selects the closest gateway (it can be specified that > it should from there use the same gateway). The propagation method > used to propagate the prefix information ensures that the path to the > gateway is made of nodes that also use the same gateway : there is no > need of a routing header, and default routes can be used safely. > That sounds like a good solution, but the node can't control what gateway it is currently using. A scenario where this is neeed is when the node is moving from gateway to gateway. The node is then unable to know what gateway it is currently communicating through. A node need to know this when it switches to a new gateway, and "registers" itself. This reason why this needed is because packets from the Internet needs to be routed to the correct gateway, which is difficult when mobile nodes are unware of its gateway. If a Cellular IP type of solution is used, the routing entries in the access network are updated by the actual packets flowing through the gateways. But there is problems here as well, because oscillations easily occurs that causes a lot of updates, especially when the mobile nodes are mobile. I have simulated this, and it is harder to maintain than you might think. If you rely on proactive gateway discovery, the default routing entries have to be maintained during link breaks and mobility, along with sequence number maintainence. I have a paper about this, in a slightly different context, but during mobility and several hops to the gateway, more complex control is needed. regards, Anders _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 17:58:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22329 for ; Tue, 30 Mar 2004 17:58:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006a4-QH for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PN67Ar031930 for manet-archive@odin.ietf.org; Wed, 25 Feb 2004 18:06:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw86R-0008Ir-9x for manet-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 18:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21300 for ; Wed, 25 Feb 2004 18:06:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw86O-0001tV-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 18:06:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw85O-0001o4-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 18:05:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw84V-0001k7-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 18:04:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw84Q-0007Ha-UJ; Wed, 25 Feb 2004 18:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw83U-0006Tg-FQ for manet@optimus.ietf.org; Wed, 25 Feb 2004 18:03:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21042 for ; Wed, 25 Feb 2004 18:03:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw83R-0001eR-00 for manet@ietf.org; Wed, 25 Feb 2004 18:03:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw82T-0001ZW-00 for manet@ietf.org; Wed, 25 Feb 2004 18:02:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1Aw81b-0001Ps-00 for manet@ietf.org; Wed, 25 Feb 2004 18:01:07 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i1PN0aq06095; Wed, 25 Feb 2004 15:00:36 -0800 X-mProtect: <200402252300> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2W2nKy; Wed, 25 Feb 2004 15:00:34 PST Message-ID: <403D2908.C72FC132@iprg.nokia.com> Date: Wed, 25 Feb 2004 15:00:24 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard Ogier , Mobile Ad Hoc IETF working group Subject: Re: [manet] MPRF [flooding protocol] document initial revision References: <403118FC.79B8305B@iprg.nokia.com> <40311DC6.5A2BE2DB@iprg.nokia.com> <40378B93.5040607@erg.sri.com> <403CDD75.A88D90CA@iprg.nokia.com> <6.0.3.0.2.20040225132245.02c9f548@pop.itd.nrl.navy.mil> <000b01c3fbd3$bfd4a040$0d81bb3f@Panoramic> <403D15 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello again Richard Looking again, I see that I made an obvious error. The first clause of the re-revised 5.2 should read as follows in order to handle the case of a graph with a single MPR: 5.2 If this node is MPR for the sending node, or for any neighboring MPR, and if the time to live of the message is greater than '1', the message MUST be forwarded according to the following by broadcasting it on all interfaces that have symmetric neighbors other than the sender, with the TTL of the message reduced by one. Regards, Charlie P. "Charles E. Perkins" wrote: > > Hello Richard, > > I did go back and look over the discussion that > you cited. It was very interesting work. I have > some further comments. > > I suppose I have been assuming that the MPRs > themselves form a connected dominating set. > This provides assurance that a message > transmitted by all MPRs goes everywhere. > I believe this assumption is justified by > the selection algorithm. > > Suppose that an MPR is taken as a "guaranteed" > relay for a flooded message. By that, I mean the > node _will_ transmit a flooded message if that > flooded message is sent by its MPR selector. > > My suggested change amounts to a "premature" > scheduling of this guaranteed relay operation. > In other words, I _claim_ that it "cannot" produce > _more_ transmissions, if the MPR selector itself > is an MPR. > > If my _claim_ is correct, then I can't see how > Cedric's simulations would show that more packets > were sent. Perhaps the aforementioned step 5.2 > needs one further refinement: > > 5.2 If this node is MPR for any neighboring MPR, and if the > time to live of the message is greater than '1', the mes- > sage MUST be forwarded according to the following by > broadcasting it on all interfaces that have symmetric > neighbors other than the sender, with the TTL of the mes- > sage reduced by one. > > If my claim is incorrect, it would be very > helpful for me if you might explain why. > > Regards, > Charlie P. > > Richard Ogier wrote: > > > > Yes, I recall that this method was discussed on the list about > > a year ago, and Cedric ran some simulations showing that > > it resulted in a large number of transmissions (in one case > > about 50% of the nodes transmitted a given flooded packet). > > So let's not forget about efficiency. > > > > There are several other methods that avoid having to know > > the previous hop, including one suggested by Thomas Clausen > > or Philippe Jacquet about a year ago in which a node relays a flooded > > packet if and only if the minimum ID neighbor is an MPR selector, > > or the node has smaller ID than all neighbors. I am comparing > > several of these via simulations and will announce the results > > in a few weeks. > > > > Richard > > > > ----- Original Message ----- > > From: "Joe Macker" > > To: "Charles E. Perkins" ; "Richard Ogier" > > > > Cc: "Mobile Ad Hoc IETF working group" > > Sent: Wednesday, February 25, 2004 10:43 AM > > Subject: Re: [manet] MPRF [flooding protocol] document initial revision > > > > > At 12:37 PM 2/25/2004, Charles E. Perkins wrote: > > > > > > >Hello Richard, > > > > > > > >Taking your suggestions out of order, I'd first agree > > > >with your proposed terminology. I have noticed many > > > >times that the terminology surrounding the flooding > > > >discussion can be very confusing. I will try to go > > > >through the MPRF draft to make the indicated revisions > > > >to our terminology. > > > > > > > >The example you give is, I think, applicable to other > > > >situations where an MPR node receives a flooded > > > >packet from other neighbors first. It seems to me > > > >that a very simple fix would work, though. > > > > > > > >If a MPR node receives a flooded packet from ANY > > > >neighbor, it should go ahead and transmit the > > > >packet again to its neighbors, and mark the > > > >packet as already processed. > > > Charlie: > > > > > > Several of us have been talking about and actually implementing > > > that for quite awhile. The previous hop state is also not required. > > > The election heuristics can also be tweaked in simple ways > > > to have more common or less common MPR sets. > > > > > > We have this MPR-F option functional in a > > > working implementation (providing generic multicast MANET forwarding). > > > We are presently examining its robustness and performance in a > > > few scenarios against other more stateful approaches. > > > > > > I must confess I haven't read the ID in detail yet, we're just busy > > > implementing things. > > > > > > -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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:00:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22856 for ; Tue, 30 Mar 2004 18:00:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjb-0006a4-ED for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QLQNA0021314 for manet-archive@odin.ietf.org; Thu, 26 Feb 2004 16:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwT1T-0005Xh-Kx for manet-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 16:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10176 for ; Thu, 26 Feb 2004 16:26:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwT1R-0007cv-00 for manet-web-archive@ietf.org; Thu, 26 Feb 2004 16:26:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwT0U-0007Sl-00 for manet-web-archive@ietf.org; Thu, 26 Feb 2004 16:25:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwSzc-0007IV-00 for manet-web-archive@ietf.org; Thu, 26 Feb 2004 16:24:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwSzE-0004U4-Dm; Thu, 26 Feb 2004 16:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwRv6-0007g5-Vw for manet@optimus.ietf.org; Thu, 26 Feb 2004 15:15:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07791 for ; Thu, 26 Feb 2004 15:15:42 -0500 (EST) From: Paal.Engelstad@telenor.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwRv5-0000Mo-00 for manet@ietf.org; Thu, 26 Feb 2004 15:15:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwRu6-0000Eo-00 for manet@ietf.org; Thu, 26 Feb 2004 15:14:42 -0500 Received: from virus-out.ttyl.com ([193.212.240.200] helo=scan.telenor.net) by ietf-mx with esmtp (Exim 4.12) id 1AwRt8-000029-00 for manet@ietf.org; Thu, 26 Feb 2004 15:13:42 -0500 Received: from tns-fbu-22-209.corp.telenor.no ([134.47.162.190] [134.47.162.190]) by scan.telenor.net with ESMTP; Thu, 26 Feb 2004 21:12:48 +0100 Received: from moffice3.nsc.no ([10.122.115.83]) by tns-fbu-22-209.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Feb 2004 21:12:48 +0100 Message-Id: <18158190.1077826368039.JavaMail.adm-moff@moffice3.nsc.no> To: =?iso-8859-1?Q?Erik_Nordstr=F6m?= To: Subject: SV: Re: [manet] ACTIVE_ROUTE_TIMEOUT in AODV (RFC 3561) (Intern) Cc: In-Reply-To: <1077713463.6384.24.camel@dhcp-8-241.it.uu.se> X-Priority: 3 (Normal) X-Mailer: Mobile Office v1.0 (Telenor Business Solutions) References: <375BFFDA619DBC4AA93996BF1F1D239657B8A7@TNS-FBU-2E-004.corp.telenor.no> <1077710169.6384.1.camel@dhcp-8-241.it.uu.se> <1077713463.6384.24.camel@dhcp-8-241.it.uu.se> X-OriginalArrivalTime: 26 Feb 2004 20:12:48.0823 (UTC) FILETIME=[E7AD3470:01C3FCA4] Date: 26 Feb 2004 21:12:48 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_450_6824966.1077826368038" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ------=_Part_450_6824966.1077826368038 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi Erik, Thanks for your comments. > Just wanted to add that ACTIVE_ROUTE_TIMEOUT probably just works as a > garbage collection timer, making sure that there is no stale information > in the network. It's a good point. The question is if the stale information can cause consierable damage to the routing functionality. > > Isn't it the case that routes are often preempted by other events, such > > as link break (link layer feedback or HELLO messages), with the result > > that ACTIVE_ROUTE_TIMEOUT doesn't really matter that much? Yes, I am about to convince myself of the same. So, if what you say is right, you may choose very high ACTIVE_ROUTE_TIMEOUT values (e.g 100-200 sec) without big consequences. Paal ------=_Part_450_6824966.1077826368038-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:02:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23449 for ; Tue, 30 Mar 2004 18:02:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006YH-7u for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PNRAVk020584 for manet-archive@odin.ietf.org; Wed, 25 Feb 2004 18:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8Qo-0005Lv-7c for manet-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 18:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23075 for ; Wed, 25 Feb 2004 18:27:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8Ql-0004Bm-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 18:27:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw8Pp-000459-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 18:26:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8Oq-0003yA-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 18:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8Oo-0004iF-M5; Wed, 25 Feb 2004 18:25:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8Nw-0004gC-Hb for manet@optimus.ietf.org; Wed, 25 Feb 2004 18:24:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22924 for ; Wed, 25 Feb 2004 18:24:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8Nt-0003sI-00 for manet@ietf.org; Wed, 25 Feb 2004 18:24:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw8Mz-0003mo-00 for manet@ietf.org; Wed, 25 Feb 2004 18:23:14 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8MO-0003hJ-00 for manet@ietf.org; Wed, 25 Feb 2004 18:22:36 -0500 Received: from sdn-ap-023castocp0383.dialsprint.net ([65.178.105.129] helo=Panoramic) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Aw8Lm-0003vX-00; Wed, 25 Feb 2004 15:21:58 -0800 Message-ID: <016601c3fbf6$42ea3e00$0d81bb3f@Panoramic> From: "Richard Ogier" To: "Charles E. Perkins" Cc: "Mobile Ad Hoc IETF working group" References: <403118FC.79B8305B@iprg.nokia.com> <40311DC6.5A2BE2DB@iprg.nokia.com> <40378B93.5040607@erg.sri.com> <403CDD75.A88D90CA@iprg.nokia.com> <6.0.3.0.2.20040225132245.02c9f548@pop.itd.nrl.navy.mil> <000b01c3fbd3$bfd4a040$0d81bb3f@Panoramic> <403D1576.97F72C27@iprg.nokia.com> Subject: Re: [manet] MPRF [flooding protocol] document initial revision Date: Wed, 25 Feb 2004 15:05:28 -0800 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charlie, Suppose that each MPR is a guaranteed relay as you say: > Suppose that an MPR is taken as a "guaranteed" > relay for a flooded message. By that, I mean the > node _will_ transmit a flooded message if that > flooded message is sent by its MPR selector. Then the nodes that relay the packet are the MPRs of the originator, the MPRs of the MPRs of the originator, etc. However, I don't think this set of nodes includes every node that is an MPR of some neighboring MPR (as in your modified step 5.2). The difference is that there has to be a sequence of nodes u_1,..., u_n where u_n is the originator and each node is an MPR of the next node in the sequence. The difference is that the sequence must lead to the originator, and it might not. I will have additional suggestions soon. Regards, Richard ----- Original Message ----- From: "Charles E. Perkins" To: "Richard Ogier" Cc: "Mobile Ad Hoc IETF working group" Sent: Wednesday, February 25, 2004 1:36 PM Subject: Re: [manet] MPRF [flooding protocol] document initial revision > > Hello Richard, > > I did go back and look over the discussion that > you cited. It was very interesting work. I have > some further comments. > > I suppose I have been assuming that the MPRs > themselves form a connected dominating set. > This provides assurance that a message > transmitted by all MPRs goes everywhere. > I believe this assumption is justified by > the selection algorithm. > > Suppose that an MPR is taken as a "guaranteed" > relay for a flooded message. By that, I mean the > node _will_ transmit a flooded message if that > flooded message is sent by its MPR selector. > > My suggested change amounts to a "premature" > scheduling of this guaranteed relay operation. > In other words, I _claim_ that it "cannot" produce > _more_ transmissions, if the MPR selector itself > is an MPR. > > If my _claim_ is correct, then I can't see how > Cedric's simulations would show that more packets > were sent. Perhaps the aforementioned step 5.2 > needs one further refinement: > > 5.2 If this node is MPR for any neighboring MPR, and if the > time to live of the message is greater than '1', the mes- > sage MUST be forwarded according to the following by > broadcasting it on all interfaces that have symmetric > neighbors other than the sender, with the TTL of the mes- > sage reduced by one. > > If my claim is incorrect, it would be very > helpful for me if you might explain why. > > Regards, > Charlie P. > > > > > > Richard Ogier wrote: > > > > Yes, I recall that this method was discussed on the list about > > a year ago, and Cedric ran some simulations showing that > > it resulted in a large number of transmissions (in one case > > about 50% of the nodes transmitted a given flooded packet). > > So let's not forget about efficiency. > > > > There are several other methods that avoid having to know > > the previous hop, including one suggested by Thomas Clausen > > or Philippe Jacquet about a year ago in which a node relays a flooded > > packet if and only if the minimum ID neighbor is an MPR selector, > > or the node has smaller ID than all neighbors. I am comparing > > several of these via simulations and will announce the results > > in a few weeks. > > > > Richard > > > > ----- Original Message ----- > > From: "Joe Macker" > > To: "Charles E. Perkins" ; "Richard Ogier" > > > > Cc: "Mobile Ad Hoc IETF working group" > > Sent: Wednesday, February 25, 2004 10:43 AM > > Subject: Re: [manet] MPRF [flooding protocol] document initial revision > > > > > At 12:37 PM 2/25/2004, Charles E. Perkins wrote: > > > > > > >Hello Richard, > > > > > > > >Taking your suggestions out of order, I'd first agree > > > >with your proposed terminology. I have noticed many > > > >times that the terminology surrounding the flooding > > > >discussion can be very confusing. I will try to go > > > >through the MPRF draft to make the indicated revisions > > > >to our terminology. > > > > > > > >The example you give is, I think, applicable to other > > > >situations where an MPR node receives a flooded > > > >packet from other neighbors first. It seems to me > > > >that a very simple fix would work, though. > > > > > > > >If a MPR node receives a flooded packet from ANY > > > >neighbor, it should go ahead and transmit the > > > >packet again to its neighbors, and mark the > > > >packet as already processed. > > > Charlie: > > > > > > Several of us have been talking about and actually implementing > > > that for quite awhile. The previous hop state is also not required. > > > The election heuristics can also be tweaked in simple ways > > > to have more common or less common MPR sets. > > > > > > We have this MPR-F option functional in a > > > working implementation (providing generic multicast MANET forwarding). > > > We are presently examining its robustness and performance in a > > > few scenarios against other more stateful approaches. > > > > > > I must confess I haven't read the ID in detail yet, we're just busy > > > implementing things. > > > > > > -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 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:02:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23662 for ; Tue, 30 Mar 2004 18:02:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006ZK-7O for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PNR9QF020569 for manet-archive@odin.ietf.org; Wed, 25 Feb 2004 18:27:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8Qn-0005Lg-EW for manet-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 18:27:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23072 for ; Wed, 25 Feb 2004 18:27:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8Qk-0004Bg-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 18:27:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw8Po-000450-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 18:26:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8Oq-0003y8-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 18:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8Ol-0004hI-9H; Wed, 25 Feb 2004 18:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw8Nu-0004g2-KU for manet@optimus.ietf.org; Wed, 25 Feb 2004 18:24:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22917 for ; Wed, 25 Feb 2004 18:24:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8Nr-0003s5-00 for manet@ietf.org; Wed, 25 Feb 2004 18:24:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw8Mx-0003mO-00 for manet@ietf.org; Wed, 25 Feb 2004 18:23:12 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1Aw8M5-0003hA-00 for manet@ietf.org; Wed, 25 Feb 2004 18:22:18 -0500 Received: from sdn-ap-023castocp0383.dialsprint.net ([65.178.105.129] helo=Panoramic) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Aw8LS-0003vX-00; Wed, 25 Feb 2004 15:21:39 -0800 Message-ID: <016301c3fbf6$3775cee0$0d81bb3f@Panoramic> From: "Richard Ogier" To: "Charles E. Perkins" Cc: "Mobile Ad Hoc IETF working group" References: <403118FC.79B8305B@iprg.nokia.com> <40311DC6.5A2BE2DB@iprg.nokia.com> <40378B93.5040607@erg.sri.com> <403CDD75.A88D90CA@iprg.nokia.com> <6.0.3.0.2.20040225132245.02c9f548@pop.itd.nrl.navy.mil> <000b01c3fbd3$bfd4a040$0d81bb3f@Panoramic> <403D1576.97F72C27@iprg.nokia.com> Subject: Re: [manet] MPRF [flooding protocol] document initial revision Date: Wed, 25 Feb 2004 15:04:35 -0800 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charlie, Suppose that each MPR is a guaranteed relay as you say: > Suppose that an MPR is taken as a "guaranteed" > relay for a flooded message. By that, I mean the > node _will_ transmit a flooded message if that > flooded message is sent by its MPR selector. Then the nodes that relay the packet are the MPRs of the originator, the MPRs of the MPRs of the originator, etc. However, I don't think this set of nodes includes every node that is an MPR of some neighboring MPR (as in your modified step 5.2). The difference is that there has to be a sequence of nodes u_1,..., u_n where u_n is the originator and each node is an MPR of the next node in the sequence. The difference is that the sequence must lead to the originator, and it might not. I will have additional suggestions soon. Regards, Richard ----- Original Message ----- From: "Charles E. Perkins" To: "Richard Ogier" Cc: "Mobile Ad Hoc IETF working group" Sent: Wednesday, February 25, 2004 1:36 PM Subject: Re: [manet] MPRF [flooding protocol] document initial revision > > Hello Richard, > > I did go back and look over the discussion that > you cited. It was very interesting work. I have > some further comments. > > I suppose I have been assuming that the MPRs > themselves form a connected dominating set. > This provides assurance that a message > transmitted by all MPRs goes everywhere. > I believe this assumption is justified by > the selection algorithm. > > Suppose that an MPR is taken as a "guaranteed" > relay for a flooded message. By that, I mean the > node _will_ transmit a flooded message if that > flooded message is sent by its MPR selector. > > My suggested change amounts to a "premature" > scheduling of this guaranteed relay operation. > In other words, I _claim_ that it "cannot" produce > _more_ transmissions, if the MPR selector itself > is an MPR. > > If my _claim_ is correct, then I can't see how > Cedric's simulations would show that more packets > were sent. Perhaps the aforementioned step 5.2 > needs one further refinement: > > 5.2 If this node is MPR for any neighboring MPR, and if the > time to live of the message is greater than '1', the mes- > sage MUST be forwarded according to the following by > broadcasting it on all interfaces that have symmetric > neighbors other than the sender, with the TTL of the mes- > sage reduced by one. > > If my claim is incorrect, it would be very > helpful for me if you might explain why. > > Regards, > Charlie P. > > > > > > Richard Ogier wrote: > > > > Yes, I recall that this method was discussed on the list about > > a year ago, and Cedric ran some simulations showing that > > it resulted in a large number of transmissions (in one case > > about 50% of the nodes transmitted a given flooded packet). > > So let's not forget about efficiency. > > > > There are several other methods that avoid having to know > > the previous hop, including one suggested by Thomas Clausen > > or Philippe Jacquet about a year ago in which a node relays a flooded > > packet if and only if the minimum ID neighbor is an MPR selector, > > or the node has smaller ID than all neighbors. I am comparing > > several of these via simulations and will announce the results > > in a few weeks. > > > > Richard > > > > ----- Original Message ----- > > From: "Joe Macker" > > To: "Charles E. Perkins" ; "Richard Ogier" > > > > Cc: "Mobile Ad Hoc IETF working group" > > Sent: Wednesday, February 25, 2004 10:43 AM > > Subject: Re: [manet] MPRF [flooding protocol] document initial revision > > > > > At 12:37 PM 2/25/2004, Charles E. Perkins wrote: > > > > > > >Hello Richard, > > > > > > > >Taking your suggestions out of order, I'd first agree > > > >with your proposed terminology. I have noticed many > > > >times that the terminology surrounding the flooding > > > >discussion can be very confusing. I will try to go > > > >through the MPRF draft to make the indicated revisions > > > >to our terminology. > > > > > > > >The example you give is, I think, applicable to other > > > >situations where an MPR node receives a flooded > > > >packet from other neighbors first. It seems to me > > > >that a very simple fix would work, though. > > > > > > > >If a MPR node receives a flooded packet from ANY > > > >neighbor, it should go ahead and transmit the > > > >packet again to its neighbors, and mark the > > > >packet as already processed. > > > Charlie: > > > > > > Several of us have been talking about and actually implementing > > > that for quite awhile. The previous hop state is also not required. > > > The election heuristics can also be tweaked in simple ways > > > to have more common or less common MPR sets. > > > > > > We have this MPR-F option functional in a > > > working implementation (providing generic multicast MANET forwarding). > > > We are presently examining its robustness and performance in a > > > few scenarios against other more stateful approaches. > > > > > > I must confess I haven't read the ID in detail yet, we're just busy > > > implementing things. > > > > > > -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 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:02:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23716 for ; Tue, 30 Mar 2004 18:02:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006ZK-2Q for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QLQNwL021299 for manet-archive@odin.ietf.org; Thu, 26 Feb 2004 16:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwT1T-0005XS-1w for manet-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 16:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10173 for ; Thu, 26 Feb 2004 16:26:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwT1R-0007cq-00 for manet-web-archive@ietf.org; Thu, 26 Feb 2004 16:26:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwT0T-0007Sd-00 for manet-web-archive@ietf.org; Thu, 26 Feb 2004 16:25:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwSzc-0007IU-00 for manet-web-archive@ietf.org; Thu, 26 Feb 2004 16:24:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwSzK-0004Xt-3C; Thu, 26 Feb 2004 16:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwS8m-0001Av-SA for manet@optimus.ietf.org; Thu, 26 Feb 2004 15:29:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08456 for ; Thu, 26 Feb 2004 15:29:50 -0500 (EST) From: Paal.Engelstad@telenor.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwS8l-0001tQ-00 for manet@ietf.org; Thu, 26 Feb 2004 15:29:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwS7u-0001om-00 for manet@ietf.org; Thu, 26 Feb 2004 15:28:59 -0500 Received: from virus-out.ttyl.com ([193.212.240.200] helo=virus-out-st.online.no) by ietf-mx with esmtp (Exim 4.12) id 1AwS7V-0001iw-00 for manet@ietf.org; Thu, 26 Feb 2004 15:28:33 -0500 Received: from tns-fbu-22-209.corp.telenor.no ([134.47.162.190] [134.47.162.190]) by scan.telenor.net with ESMTP; Thu, 26 Feb 2004 21:28:02 +0100 Received: from moffice3.nsc.no ([10.122.115.83]) by tns-fbu-22-209.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 Feb 2004 21:28:02 +0100 Message-Id: <2159159.1077827282337.JavaMail.adm-moff@moffice3.nsc.no> To: Vin To: Subject: SV: Re: [manet] ACTIVE_ROUTE_TIMEOUT in AODV (RFC 3561) (Intern) Cc: In-Reply-To: <20040225175424.65730.qmail@web21106.mail.yahoo.com> X-Priority: 3 (Normal) X-Mailer: Mobile Office v1.0 (Telenor Business Solutions) References: <375BFFDA619DBC4AA93996BF1F1D239657B8A7@TNS-FBU-2E-004.corp.telenor.no> <20040225175424.65730.qmail@web21106.mail.yahoo.com> X-OriginalArrivalTime: 26 Feb 2004 20:28:02.0969 (UTC) FILETIME=[088CD090:01C3FCA7] Date: 26 Feb 2004 21:28:02 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_457_32644176.1077827282335" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ------=_Part_457_32644176.1077827282335 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi Vinod, > I also think that your traffic model plays a part.If > you send packets continously from a starting point in > time, ACTIVE_ROUTE_TIMEOUT never gets a chance to come > into play.It should come into play only if that route > has been unused for that period of time. Actually, this point is what triggered my interest in the ACTIVE_ROUTE_TIMEOUT value in the first place. For normal bursty traffic (e.g. a ftp or http file download) it does not make much difference. However, in our AODV testbed with limited mobility/dynamics I tested communication that requires user interaction i.e. Telnet. Then a route may time out between each transmitted packet, which naturally is not a very desirable. At another instance, we also implemented event-based middleware on top of AODV and both periodic polling and unsolicited events may be sent on intervals exceeding normal settings of the ACTIVE_ROUTE_TIMEOUT. > many > simulations done on ns-2 are based on cbr traffic > starting at a certain time and going on till end of > simulation which isnt a good way to study the effect > of ACTIVE_ROUTE_TIMEOUT. Agreed. Well, I steered around that pithole, at least. Thanks for your comments, anyway. Paal > Regards, > Vinod > > --- Paal.Engelstad@telenor.com wrote: > > Hi, > > > > I did some GloMoSim simulations with AODV and > > experimented with the setting of the > > ACTIVE_ROUTE_TIMEOUT value. For the scenarios that I > > tested, I was surprised to see how little the > > performance degraded when I chose very large timeout > > values. I have obviously done something wrong - > > either not selected the right simulation scenarios > > or not measured the right things. > > > > To help me on the way, could someone please tell me > > the most important networking aspects that prohibits > > the choice of a large ACTIVE_ROUTE_TIMEOUT. What are > > the main trade-offs when setting this value? Or > > could someone give me a pointer to relevant > > publications. > > > > Thanks, > > Paal > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > ===== > Vinod Namboodiri > > Graduate Student > Department of Electrical and Computer Engineering > University of Massachusetts, Amherst > > __________________________________ > Do you Yahoo!? > Yahoo! Mail SpamGuard - Read only the mail you want. > http://antispam.yahoo.com/tools ------=_Part_457_32644176.1077827282335-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:03:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23778 for ; Tue, 30 Mar 2004 18:03:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjZ-0006YH-Rr for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2J8d8ih026735 for manet-archive@odin.ietf.org; Fri, 19 Mar 2004 03:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4FWy-0006wl-0A for manet-web-archive@optimus.ietf.org; Fri, 19 Mar 2004 03:39:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22406 for ; Fri, 19 Mar 2004 03:39:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4FWv-0006mu-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 03:39:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4FVy-0006hp-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 03:38:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B4FVG-0006dz-00 for manet-web-archive@ietf.org; Fri, 19 Mar 2004 03:37:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4FV1-0006Ij-RW; Fri, 19 Mar 2004 03:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B4FUy-0006IA-JH for manet@optimus.ietf.org; Fri, 19 Mar 2004 03:37:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22353 for ; Fri, 19 Mar 2004 03:36:58 -0500 (EST) From: Francois.PAUL@fr.thalesgroup.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B4FUw-0006bn-00 for manet@ietf.org; Fri, 19 Mar 2004 03:36:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B4FTy-0006Ym-00 for manet@ietf.org; Fri, 19 Mar 2004 03:35:59 -0500 Received: from gwout.thalesgroup.com ([195.101.39.227]) by ietf-mx with esmtp (Exim 4.12) id 1B4FTC-0006SV-00 for manet@ietf.org; Fri, 19 Mar 2004 03:35:10 -0500 Received: from thalescan.corp.thales (200.3.2.3) by GWOUT.thalesgroup.com (NPlex 6.5.026) id 4055EBF2000764D1 for manet@ietf.org; Fri, 19 Mar 2004 09:34:09 +0100 Received: from tccplex.tcc.thomson-csf.com ([200.3.1.11]) by thalescan with InterScan Messaging Security Suite; Fri, 19 Mar 2004 09:33:37 +0100 Received: from NODALNET.clb.tcfr.thales (146.11.5.4) by tccplex.tcc.thomson-csf.com (NPlex 6.5.026) id 40554A5A0001F405; Fri, 19 Mar 2004 09:34:52 +0100 Received: by NODALNET.clb.tcfr.thales with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Mar 2004 09:33:37 +0100 Message-ID: <66CE949D18BCB249ABE8D9AF48C4F1CE2D48A3@helios.clb.tcfr.thales> To: Dave.B.Green@us.army.mil, manet@ietf.org Subject: RE: [manet] Multipoint ROHC for MANET Date: Fri, 19 Mar 2004 09:33:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable ROHC offers several "modes" of operation. The mode called = "unidirectional" (see RFC 3095 =A7 4.4.1) does not require any "return path", and = therefore seems well suited to your point to multipoint scheme. Nevertheless there is a drawback : as there is no return path, this = mode is less robust than the other ones ... Fran=E7ois PAUL -----Message d'origine----- De : Green, David B RDECOM CERDEC STCD SRI [mailto:Dave.B.Green@us.army.mil] Envoy=E9 : jeudi 18 mars 2004 21:38 =C0 : 'manet@ietf.org' Objet : [manet] Multipoint ROHC for MANET Has anyone in the group worked on a schema for point to multipoint = robust header compression=20 suitable for broadcast and multicast links in MANETs? The base spec for RObust Header Compression=20 (RFC 3095 "ROHC") only seems to consider point to point links for = cellular systems. I'm=20 proposing the work in the ROHC group, but want to consider any = expertise from the MANET group that might be helpful since this will be "MANET" header compression in = our ultimate application=20 on a MANET style radio.=20 David B. Green SRI International Myer Ctr Rm 4D305 desk (732) 532-6715 cell (732) 693-6500 _______________________________________________ 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 exim@www1.ietf.org Tue Mar 30 18:03:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23873 for ; Tue, 30 Mar 2004 18:03:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjZ-0006ZK-Mk for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA49sOIo022469 for manet-archive@odin.ietf.org; Tue, 4 Nov 2003 04:54:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxtH-0005qG-Rg for manet-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 04:54:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06126 for ; Tue, 4 Nov 2003 04:54:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxtE-00020G-00 for manet-web-archive@ietf.org; Tue, 04 Nov 2003 04:54:20 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGxtD-00020D-00 for manet-web-archive@ietf.org; Tue, 04 Nov 2003 04:54:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxsz-0005m0-2u; Tue, 04 Nov 2003 04:54:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGxsM-0005jL-Lj for manet@optimus.ietf.org; Tue, 04 Nov 2003 04:53:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06094 for ; Tue, 4 Nov 2003 04:53:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGxsJ-0001z8-00 for manet@ietf.org; Tue, 04 Nov 2003 04:53:23 -0500 Received: from smtp1.bae.co.uk ([20.138.254.61]) by ietf-mx with esmtp (Exim 4.12) id 1AGxsI-0001yV-00 for manet@ietf.org; Tue, 04 Nov 2003 04:53:22 -0500 Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234]) by smtp1.bae.co.uk (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA49qrF06219 for ; Tue, 4 Nov 2003 09:52:53 GMT Received: from bsrsmtp02.ng.bae.co.uk ([141.245.68.242]) by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998) with SMTP id <0HNT002DTNEM41@ngbaux.net.bae.co.uk> for manet@ietf.org; Tue, 4 Nov 2003 09:51:58 +0000 (GMT) Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by 141.245.68.242 with InterScan Messaging Security Suite for SMTP; Tue, 04 Nov 2003 09:52:39 +0000 Received: from glkms0008.GREENLNK.NET ([10.15.184.8]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.5329); Tue, 04 Nov 2003 09:52:42 +0000 Date: Tue, 04 Nov 2003 09:52:42 +0000 From: "Dearlove, Chris (UK)" Subject: RE: [manet] OLSR: RFC 3626 observations. To: Richard Ogier , "Dearlove, Chris (UK)" , manet@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable Thread-Topic: [manet] OLSR: RFC 3626 observations. Thread-Index: AcOiMOTeztd1lLpaToucu+at4j3u2QAh8IfA content-class: urn:content-classes:message X-OriginalArrivalTime: 04 Nov 2003 09:52:42.0269 (UTC) FILETIME=[63C01CD0:01C3A2B9] Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable > This also fixes another problem when TC messages are partial: > when the first TC message with a larger sequence number is received, > assuming this TC message is partial, then all of the old tuples with the > same originator are removed, and you are left with only a partial=20 > neighbor set > until the other partial TC messages with the same sequence number are=20 > received, > which may not happen for several seconds since flooding is not reliable. I was aware of this one, but didn't discuss it because I was (in this part of my posting) considering only possible backwardly compatible changes. On a related point (definitely not backwardly compatible) merging the functionality of TC and HNA messages could be considered, HNA messages having no cancellation property unlike TC messages (even if not quite perfect). ******************************************************************** 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 exim@www1.ietf.org Tue Mar 30 18:03:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23887 for ; Tue, 30 Mar 2004 18:03:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjZ-0006YH-De for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248evxV014689 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 03:40:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoPX-0003ob-64 for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:40:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29376 for ; Thu, 4 Mar 2004 03:40:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoPU-0002J1-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:40:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoN4-0001XZ-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:38:23 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyoLJ-0001A5-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:36:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ayo9S-0000xd-Tl for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:24:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9D-0001Xi-Vq; Thu, 04 Mar 2004 03:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo8M-0001T4-NN for manet@optimus.ietf.org; Thu, 04 Mar 2004 03:23:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27803 for ; Thu, 4 Mar 2004 03:23:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo8K-00063g-00 for manet@ietf.org; Thu, 04 Mar 2004 03:23:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayo6h-0005fc-00 for manet@ietf.org; Thu, 04 Mar 2004 03:21:28 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo5Z-0005J3-00 for manet@ietf.org; Thu, 04 Mar 2004 03:20:17 -0500 Received: from jafymobile (6ants5.etri.re.kr [129.254.112.239]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW2A0C; Thu, 4 Mar 2004 17:19:44 +0900 Reply-To: From: "HyunWook Cha" To: , "'Erik Nordstr?'" Cc: Subject: RE: [manet] Default Routes Date: Thu, 4 Mar 2004 17:19:46 +0900 Organization: ETRI Message-ID: <001401c401c1$748f49c0$ef70fe81@jafymobile> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <61384.217.208.138.149.1078341070.squirrel@ww2.telecom.lth.se> Importance: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Anders. Please see my inline comments. > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of andersn@telecom.lth.se > Sent: Thursday, March 04, 2004 4:11 AM > To: Erik Nordstr? > Cc: manet@ietf.org > Subject: Re: [manet] Default Routes > > > > Hello, > > Let me see if I understood the draft correctly. > > > However, I have another question. How do you handle > "contention" between > > the announcements at the edges of bordering prefix islands? > > An upstream node chooses a new or different gateway if it is > 1 hop closer > than the one it is currently using. > Christophe proposes two different algorithms. As for one of them, you are correct. However, node does not change it's address as long as at least one neighbor keeps advertising same prefix in algorithm for prefix stability. Anyway, ping-ponging can be possible. > > I guess that > > borderline nodes have the ability to select gateway by > themselves, but > > that could potentially affect many downstream nodes that > previously used > > another prefix. A node could also cut off and isolate > islands of nodes > > if it chooses to change prefix/gateway. > > I think that depends on whether the network is using a reactive or > proactive protocol. If a reactive protocol is used, the routing protocol > is still responsisble for establishing a route to the gateway. In that > case the downstream node would at least not be isolated, it can continue > to use the old gateway. I do not agree. I am not sure what will happen when link failure to upstream node is found during forwarding packets. (Please clarify me, Christophe.) However, why route of gateway should be discovered by routing protocol? In his draft, packets are forwarded using not host route for the gateway but default route although some nodes including sender node on default path have default route entry as well as host route entry for the gateway. It is because he puts on "prefix continuity" much more weight than "efficiency". > The question is whether the downstream have to > configure a new address when the prefix announced by the upstream node > changes. If that is the case, we might have some problems. As > the network > can be very mobile, borderline nodes receiveing announcements > about two > different gateways, from two different neighbors, might choose two to > switch back forth between the two gateways. This easily happens when a > node chooses a new gateway when it is 1 hop closer than its > current one, > and the network have mobility that causes frequent topology changes. > > > What are the convergence times > > for situations like that? Is it desirable that borderline > nodes could > > have such a big effect on lots of downstream nodes? > > > > I do not think the convergence time is that big, as nodes "almost > immediately" rebroadcasts the message. Before updating it. However, if > nodes have to configure a new address upon receipt of the > announcement, > the result can be very bad. I have simulated this, and it > helps a lot if > the condition to switch is increased to 2 hops, but that > would of course > create non optimal routes. > Please think about algorithm for "prefix stability" how long it takes to change leaf node's address. His idea is not about simple flooding. Regards, HyunWook > I am not sure if the draft actually says that nodes should > reconfigure a > new address when your upstream tells you to. If that is so, > I am not so > sure that is a wise thing to do. Christophe, please correct > me if anything > I say here is wrong. > > /Anders > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:05:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24427 for ; Tue, 30 Mar 2004 18:05:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjY-0006YH-16 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BHbx6T013186 for manet-archive@odin.ietf.org; Wed, 11 Feb 2004 12:37:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqyJC-0003QT-Ig for manet-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 12:37:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11059 for ; Wed, 11 Feb 2004 12:37:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqyJA-0006Wp-00 for manet-web-archive@ietf.org; Wed, 11 Feb 2004 12:37:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqyIG-0006Oo-00 for manet-web-archive@ietf.org; Wed, 11 Feb 2004 12:37:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqyHS-0006Hi-00 for manet-web-archive@ietf.org; Wed, 11 Feb 2004 12:36:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqyHK-0002qG-KP; Wed, 11 Feb 2004 12:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqyGR-0002o9-L5 for manet@optimus.ietf.org; Wed, 11 Feb 2004 12:35:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10886 for ; Wed, 11 Feb 2004 12:35:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqyGP-000676-00 for manet@ietf.org; Wed, 11 Feb 2004 12:35:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqyFJ-0005zL-00 for manet@ietf.org; Wed, 11 Feb 2004 12:33:57 -0500 Received: from ext-nj2gw-1.online-age.net ([216.35.73.163]) by ietf-mx with esmtp (Exim 4.12) id 1AqyEX-0005mL-00 for manet@ietf.org; Wed, 11 Feb 2004 12:33:09 -0500 Received: from int-nj2gw-1.online-age.net (int-nj2gw-1 [3.159.236.65]) by ext-nj2gw-1.online-age.net (8.12.9/8.12.9/990426-RLH) with ESMTP id i1BHWcR4001187 for ; Wed, 11 Feb 2004 12:32:38 -0500 (EST) Received: from crdns.crd.ge.com (localhost [127.0.0.1]) by int-nj2gw-1.online-age.net (8.12.9/8.12.8/990426-RLH) with ESMTP id i1BHWa7x006321 for ; Wed, 11 Feb 2004 12:32:37 -0500 (EST) Received: from xbh01crdge.crd.ge.com (xbh01crdge.crd.ge.com [3.159.72.22]) by crdns.crd.ge.com (8.11.6p2/8.11.6) with ESMTP id i1BHWZR20141 for ; Wed, 11 Feb 2004 12:32:35 -0500 (EST) Received: by xbh01crdge.crd.ge.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Feb 2004 12:32:35 -0500 Message-ID: From: "Smith, Nathan (Research)" To: "'manet@ietf.org'" Date: Wed, 11 Feb 2004 12:32:33 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [manet] Receiver Centric MANET 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello all, I'm currently doing a literary search on L4 protocols in a MANET environment and I came across a paper that discusses the implementation of a receiver-based transport protocol: @ARTICLE{Hsieh2003, author = {H. Hsieh and K. Kim and Y. Zhu and R. Sivakumar}, title = {A Receiver-Centric Transport Protocol for Mobile Hosts with Heterogeneous Wireless Interfaces}, journal = {MobiCom}, year = {2003}, } The paper targeted the use of RCP as the wireless "last-hop". I was curious if there are other receiver-based transport protocols geared specifically for the MANET environment. Or is there something I'm missing makes these types of protocols a poor performer in MANET? .nathan. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:06:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24560 for ; Tue, 30 Mar 2004 18:06:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjY-0006Xa-6R for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLR4XP008004 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 16:27:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uBM-000251-C9 for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:27:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19446 for ; Fri, 12 Mar 2004 16:27:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uBK-0000MK-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 16:27:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uA4-000081-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 16:25:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1u93-0007iO-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 16:24:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1u8Z-0000iF-5v; Fri, 12 Mar 2004 16:24:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tTh-0007cB-Ob for manet@optimus.ietf.org; Fri, 12 Mar 2004 15:41:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17715 for ; Fri, 12 Mar 2004 15:41:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1tTg-0002oE-00 for manet@ietf.org; Fri, 12 Mar 2004 15:41:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1tSf-0002g6-00 for manet@ietf.org; Fri, 12 Mar 2004 15:40:53 -0500 Received: from mercury.dgim.crc.ca ([142.92.39.129]) by ietf-mx with esmtp (Exim 4.12) id 1B1tS3-0002X4-00 for manet@ietf.org; Fri, 12 Mar 2004 15:40:15 -0500 Received: from ROGER (roger.dgrc.crc.ca [142.92.38.14]) by mercury.dgim.crc.ca (8.12.11/8.12.11) with SMTP id i2CKdi6R008326 for ; Fri, 12 Mar 2004 15:39:44 -0500 Message-Id: <200403122039.i2CKdi6R008326@mercury.dgim.crc.ca> X-Sender: lli@mail.crc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 12 Mar 2004 15:46:17 -0500 To: manet From: Li Li In-Reply-To: <4045ED64.5050401@dpt-info.u-strasbg.fr> References: <005301c40025$0235b280$6de325da@jafymobile> <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> <4045B7F7.9020902@dpt-info.u-strasbg.fr> <4045B543.6000601@telecom.lth.se> <4045C597.4000204@dpt-info.u-strasbg.fr> <1078316927.1364.25.camel@dhcp-8-241.it.uu.se> <4045E2ED.2050704@dpt-info.u-strasbg.fr> <016a01c40122$44eb3e80$1f175d80@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.39 Subject: [manet] MID message received from a non-symmetric neighbor 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 If a MID message is received from a non-symmetric neighbor, we'd discard the message. Why is this? For security reasons? If we don't discard the MID, what're the negative impacts? Thanks for any insights, li li Li Li, Ph.D Communications Research Centre, Industry Canada 3701 Carling avenue P.O. box 11490 Station H, Ottawa, Ontario, Canada K2H 8S2 Tel: (613) 990-5246 Email: li.li@crc.ca _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:06:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24621 for ; Tue, 30 Mar 2004 18:06:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006Xa-K0 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19B53cn015277 for manet-archive@odin.ietf.org; Mon, 9 Feb 2004 06:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9Dq-0003yI-Cd for manet-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 06:05:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12118 for ; Mon, 9 Feb 2004 06:04:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9Dm-0006lD-00 for manet-web-archive@ietf.org; Mon, 09 Feb 2004 06:04:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq9Cu-0006ep-00 for manet-web-archive@ietf.org; Mon, 09 Feb 2004 06:04:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9C4-0006Z9-00 for manet-web-archive@ietf.org; Mon, 09 Feb 2004 06:03:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9Bu-0001DF-8L; Mon, 09 Feb 2004 06:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq9Ax-0001Cl-7S for manet@optimus.ietf.org; Mon, 09 Feb 2004 06:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12045 for ; Mon, 9 Feb 2004 06:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq9At-0006Qb-00 for manet@ietf.org; Mon, 09 Feb 2004 06:01:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq99x-0006LM-00 for manet@ietf.org; Mon, 09 Feb 2004 06:01:01 -0500 Received: from rissala173.outgw.tn ([193.95.17.173]) by ietf-mx with esmtp (Exim 4.12) id 1Aq99K-0006Gb-00 for manet@ietf.org; Mon, 09 Feb 2004 06:00:23 -0500 Received: from tounes-22.ati.tn (tounes-22.ati.tn [193.95.66.22]) by rissala164.ingw.tn (8.12.9/8.12.9) with ESMTP id i19D0sOe011633 for ; Mon, 9 Feb 2004 12:00:54 -0100 (GMT) Received: from smtp1.planet.net.tn (smtp.planet.tn [193.95.123.25]) by tounes-22.ati.tn (8.12.8/8.12.8) with ESMTP id i19A0Dbq019447 for ; Mon, 9 Feb 2004 12:00:13 +0200 (EET) Received: from home ([193.95.96.253]) by smtp1.planet.net.tn (Switch-3.1.3/Switch-3.1.0) with SMTP id i19D12Lu021404 for ; Mon, 9 Feb 2004 12:01:06 -0100 (GMT) Message-ID: <000c01c3eefb$e95d8c90$fd605fc1@home> From: "Wala Turki Latrous" To: Date: Mon, 9 Feb 2004 11:59:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C3EF04.233C2E00" 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 Subject: [manet] Securing proactive 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C3EF04.233C2E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello,=20 I have a question concerning the security of the ad hoc routing = protocols : there are several work for the security of the reactive = protocols, but not for the proactive protocols. Are there problems to = secure such protocols? ------=_NextPart_000_0009_01C3EF04.233C2E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hello,

    I=20 have a question concerning the security of the ad hoc routing protocols = :  there are several work for the = security=20 of the reactive protocols, but not for the proactive protocols. Are = there=20 problems to secure such protocols?
    ------=_NextPart_000_0009_01C3EF04.233C2E00-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:07:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25003 for ; Tue, 30 Mar 2004 18:07:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006a4-AF for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i18F7Q19008956 for manet-archive@odin.ietf.org; Sun, 8 Feb 2004 10:07:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApqWq-0002Jp-SX for manet-web-archive@optimus.ietf.org; Sun, 08 Feb 2004 10:07:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21062 for ; Sun, 8 Feb 2004 10:07:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApqWo-0005RA-00 for manet-web-archive@ietf.org; Sun, 08 Feb 2004 10:07:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApqVr-0005NV-00 for manet-web-archive@ietf.org; Sun, 08 Feb 2004 10:06:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApqVh-0005Ja-00 for manet-web-archive@ietf.org; Sun, 08 Feb 2004 10:06:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApqVW-0001nf-II; Sun, 08 Feb 2004 10:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApqUp-0001Zp-IY for manet@optimus.ietf.org; Sun, 08 Feb 2004 10:05:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20874 for ; Sun, 8 Feb 2004 10:05:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApqUn-0005IW-00 for manet@ietf.org; Sun, 08 Feb 2004 10:05:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApqTt-0005F8-00 for manet@ietf.org; Sun, 08 Feb 2004 10:04:21 -0500 Received: from mailhost.cs.auc.dk ([130.225.194.6] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ApqTe-0005BU-00 for manet@ietf.org; Sun, 08 Feb 2004 10:04:06 -0500 Received: from armada (voop@borg.cs.auc.dk [130.225.194.22]) by mailhost.cs.auc.dk (8.12.10/8.12.10) with SMTP id i18F3tcC029895; Sun, 8 Feb 2004 16:03:58 +0100 (MET) Date: Sat, 7 Feb 2004 00:19:25 +0100 From: Thomas Heide Clausen To: Joe Macker Cc: manet@ietf.org Subject: Re: [manet] Possible no MANET meeting in Seoul Message-Id: <20040207001925.655eafaf.T.Clausen@computer.org> In-Reply-To: <6.0.0.22.2.20040206152343.02a96fa8@pop.itd.nrl.navy.mil> References: <6.0.0.22.2.20040203120350.02910b40@pop.itd.nrl.navy.mil> <20040205143004.765017f6.ietflists@free.fr> <6.0.0.22.2.20040206150940.02b28108@pop.itd.nrl.navy.mil> <6.0.0.22.2.20040206152343.02a96fa8@pop.itd.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.14 Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks, Joe. Should proposed agenda items be posted to you guys or to the AD's? --thomas On Fri, 06 Feb 2004 15:25:00 -0500 Joe Macker wrote: > In the charis absence, the ADs have agree to host a short manet meeting > in Seoul. I have put in the request with the IETF agenda. >=20 > -Joe > >> > >>On Tue, 03 Feb 2004 12:09:22 -0500 > >>Joe Macker wrote: > >> > >>> MANETers: > >>>=20 > >>> Scott Corson and I (WG chairs) cannot attend the Seoul meeting and > >are>> recommended we skip this round and concentrate on firming up next > >step>> action items on the mailing list. > >>>=20 > >>> If enough participants feel there should be a meeting with specific > >>> agenda items the ADs could possibly host a short meeting. > >>>=20 > >>> -Joe > >>>=20 > >> > >>_______________________________________________ > >>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 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 --=20 ------------------------------------------------ Thomas Heide Clausen Civilingeni=F8r i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://voop.free.fr/ ------------------------------------------------ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:08:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25253 for ; Tue, 30 Mar 2004 18:08:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006WI-R4 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACGcOkl025232 for manet-archive@odin.ietf.org; Wed, 12 Nov 2003 11:38:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy0c-0006Yk-Kj for manet-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 11:38:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26107 for ; Wed, 12 Nov 2003 11:38:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJy0b-0001pU-00 for manet-web-archive@ietf.org; Wed, 12 Nov 2003 11:38:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJy0a-0001pR-00 for manet-web-archive@ietf.org; Wed, 12 Nov 2003 11:38:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy0I-0006In-NL; Wed, 12 Nov 2003 11:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJy0E-0006IK-EP for manet@optimus.ietf.org; Wed, 12 Nov 2003 11:37:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26087 for ; Wed, 12 Nov 2003 11:37:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJy0D-0001p1-00 for manet@ietf.org; Wed, 12 Nov 2003 11:37:57 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1AJy0C-0001oH-00 for manet@ietf.org; Wed, 12 Nov 2003 11:37:56 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id hACGbKCx007289 for ; Wed, 12 Nov 2003 17:37:21 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id hACGX6ei007069 for ; Wed, 12 Nov 2003 17:33:06 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id hACGX5Cx007068; Wed, 12 Nov 2003 17:33:06 +0100 (CET) Received: from [10.0.1.12] (girao.office [10.1.1.176]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 54E07DD619; Wed, 12 Nov 2003 17:33:05 +0100 (CET) Subject: RE: [manet] tora ietf draft From: Joao Girao To: DANIEL BYRNE Cc: manet@ietf.org In-Reply-To: <39B01E2189D99F4B8C9612462DB3922A0CEBA91F@srv-exchange.adtran.com> References: <39B01E2189D99F4B8C9612462DB3922A0CEBA91F@srv-exchange.adtran.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8rho+Y+eoaoURSmXpSsr" Organization: Network Laboratories Heidelberg Message-Id: <1068654801.5503.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 12 Nov 2003 17:33:22 +0100 X-Scanned-By: MIMEDefang 2.35 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: , --=-8rho+Y+eoaoURSmXpSsr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm sorry, I verified version 4 of the draft, not version 5. Version 4 you can still find there. Try the other mirrors. joao girao On Wed, 2003-11-12 at 17:29, DANIEL BYRNE wrote: > That link is broken >=20 > -----Original Message----- > From: Joao Girao [mailto:Joao.Girao@ccrle.nec.de] > Sent: Wednesday, November 12, 2003 10:01 AM > To: redouane > Cc: manet@ietf.org > Subject: Re: [manet] tora ietf draft >=20 >=20 > You'll find a link in the mirror archives of the ietf drafts. > For example: >=20 > ftp://ftp.fccn.pt/pub/IETF/Internet-Drafts/draft-ietf-manet-tora-spec-05.= txt >=20 >=20 > joao girao >=20 > On Wed, 2003-11-12 at 16:49, redouane wrote: > > Hi > > I need tora ietf draft for understanding implemtation > > of this protocol. > > there is a link for this? > > thanks > >=20 > > redouane > >=20 > >=20 > > ___________________________________________________________ > > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=C3=A7ais ! > > Yahoo! Mail : http://fr.mail.yahoo.com > >=20 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet --=20 Jo=C3=A3o Gir=C3=A3o (Joao.Girao@ccrle.nec.de) NEC Europe Ltd., Network Laboratories Tel. (+49) 6221 90511-17 Fax: (+49) 6221 90511-55 --=-8rho+Y+eoaoURSmXpSsr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA/smDRzT+O0HlWj/8RAoraAJ9dejX1/qX44uQz2M0jw81DfnoCfwCgt/eM 2XgJJalsUHp95Mt2O/M4Eto= =S7y5 -----END PGP SIGNATURE----- --=-8rho+Y+eoaoURSmXpSsr-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:10:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25842 for ; Tue, 30 Mar 2004 18:10:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006ZK-W4 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242P4MV023911 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 21:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiXn-0006DX-MJ for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:25:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17244 for ; Wed, 3 Mar 2004 21:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiXk-00026Y-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 21:25:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiWe-0001iF-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 21:23:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyiVJ-0001RV-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 21:22:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiUs-0005UF-RZ; Wed, 03 Mar 2004 21:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiTz-0005BK-To for manet@optimus.ietf.org; Wed, 03 Mar 2004 21:21:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16876 for ; Wed, 3 Mar 2004 21:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiTw-0001Ad-00 for manet@ietf.org; Wed, 03 Mar 2004 21:21:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiT7-00010a-00 for manet@ietf.org; Wed, 03 Mar 2004 21:20:14 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1AyiST-0000nc-00 for manet@ietf.org; Wed, 03 Mar 2004 21:19:33 -0500 Received: from jafymobile (6ants5.etri.re.kr [129.254.112.239]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDWH09K; Thu, 4 Mar 2004 11:18:58 +0900 Reply-To: From: "HyunWook Cha" To: "'Anders Nilsson'" , "'manet'" , Date: Thu, 4 Mar 2004 11:18:59 +0900 Organization: ETRI Message-ID: <002f01c4018f$0dd85910$ef70fe81@jafymobile> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <4045ADCF.1030300@telecom.lth.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [manet] RE: Default Routes (WAS: Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Anders. Please see my inline comments. > -----Original Message----- > From: Anders Nilsson [mailto:andersn@telecom.lth.se] > Sent: Wednesday, March 03, 2004 7:05 PM > To: jafy@etri.re.kr; manet; Paal.Engelstad@telenor.com > Subject: Re: Default Routes (WAS: Request of Comments on the > i-d ietf-cha-manet-aodv-internet-00.txt) > > > > Hello, > > I must say that I agree with all the comments about trying to > coordinate > our efforts. (I am a co-author with Ryuji). > It doesn't make any sense at all to have several drafts that say > basically the same thing, with some minor modifications. This > is really > the case right now. But the fact that we have so similiar > drafts tells > us that we are close to consensus, so making a common requirement > document shouldn't be too hard. Having several drafts is > really bad, and > makes things bad for the implementors. There are implementors > out there > trying to implement these features, and they are clearly > confused by all > the different drafts. Nico Bayer have an implementation that he > presented last week at EW2004, that closely follows the > globalv6 draft. > This is great, and although the imp. seems to follow the > draft closely, > there are some major differences to the draft. This could be > explained > by the confusion created by the different drafts, but may also > implementation choices. Either way, a consensus is needed. > Do not tell that every other drafts are just variants from your drafts which have only negligible contribution, and have made just confusions to implementors. You must analyze what issues are targeted in their drafts and how efficiently they can be resolved before you told that efforts by others are harmful. > >Although I admit that I was inspired and motivated by your > draft, I do > >not think that your draft does address all related issues and propose > >all possilbe solutions. If you are interested in my > suggestion, we can > >have good chance to share ideas and make productive work in > this topic. > > > > > Please point out what you think is wrong. > I did not say that I wrote my drafts since yours is wrong. I like other authors want to see other ways to get the goal. > > > >As for your comment on my draft, please take it easy. > > > >[The draft says] > >one including [1 globalv6], [2], [3] which use next hop > forwarding for > >default routes and the other including [1 globalv6] which do not use > >next hop forwarding and require that a sender specifies a gateway in > >routing header. > > > > > > > What do you mean here? > I mean that your draft proposes default route as well as routing header for AODV. However, you authors prefers to the use of routing header because of several reasons including one mentioned by Paal. However, since many other authors do not like this overhead in all data packets, many alternative approaches have come out. My draft adopts source prefix based routing as you mentioned below and Christophe's tries to keep "prefix continuity". > This is from Paals mail: > > > If you have two gateways announcing the same default route, the > > MANET node has no control of which gateway the packet is routed > > out through. You might get problems with: > > - Stateless firewalls: E.g. The first packet of your (TCP-) session > > might go out through another gateway than the one corresponding to > > the selected source IP address. Thus, the return inbound > packets will > > not reach the gateway corresponding to the MANET node's > source IP address > > if the gateway is behind i firewall because no state is set > in the firewall. > > - Ingress filtering: Outbound packets escaping out through > "wrong" gateways > > are filtered out. > > As pointed out earlier, this problem can solved by letting > intermediate > forwarding nodes search their gateway list for the source > prefix. If the > source prefix matches an entry in the gateway list, the packet is > forwarded to the indicated gateway. I think this solves the problem > stated above. > However, there is an other problem here. If the node is > moving inside the network, it will probably want to switch to > different gateways as they become closer. The only way for this to work in the > mentioned solution is to onfigure a new address, which is not really a > good solution. Right. I do not address gateway handover issue in this draft. This issue is very important component in Internet connectivy support. I do not think that current address should be changed with new address to communicate through a closer gateway since this is harmful for tranport layers. I also support registration based mechanism for tunneling from old gateway for inbound traffic and to old gateway/peer node for outbound traffic. To do that, multiple addresses can be configured and used for a MANET interface simultaneously. Although MIPv6 is indispensable for macro-mobility, I think that MANET specific registration method is helpful for micro-mobility. I proposed reactive registration scheme incorporating(deeply coupled) with AODV in my draft named "extended support for MANET internet connectivity". Without MIPv6, this method can keep active session in which address from old gateway is involved as source address going through tunneling. In addtion, this approach can prevent frequent inefficient end-to-end signalling (RO in MIPv6) by hiding unreliable MANET topology. For example, this can enable MIPv6 to decide handover time according to urrent available(and reachable directly) gateway set while active sessions are kept alive. I will write more detail related to this issue in revised version. If the different gateways belong to the same > domain, it > might not even be possible, and routing header might be to prefer in > that case. I discuss this problem among other things in a paper to be > presented at WWC04, the main focus of the paper is performance though. > > regards, > > Anders > I am interested in this point. Could you explain what this scenario is for? For load balancing? Do you use proxy-nd? Regards, HyunWook _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:11:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25933 for ; Tue, 30 Mar 2004 18:11:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006ZK-6J for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PKA6IV003388 for manet-archive@odin.ietf.org; Wed, 25 Feb 2004 15:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5M4-0000rj-Q9 for manet-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 15:10:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09726 for ; Wed, 25 Feb 2004 15:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5M1-000562-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 15:10:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5L3-0004zP-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 15:09:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5KF-0004uJ-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 15:08:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5K9-0008BJ-FZ; Wed, 25 Feb 2004 15:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw5JK-0007gn-W1 for manet@optimus.ietf.org; Wed, 25 Feb 2004 15:07:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09460 for ; Wed, 25 Feb 2004 15:07:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5JI-0004mg-00 for manet@ietf.org; Wed, 25 Feb 2004 15:07:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw5IC-0004gL-00 for manet@ietf.org; Wed, 25 Feb 2004 15:06:05 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1Aw5HN-0004aD-00 for manet@ietf.org; Wed, 25 Feb 2004 15:05:13 -0500 Received: from sdn-ap-012castocp0433.dialsprint.net ([63.187.113.179] helo=Panoramic) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1Aw5HG-0003mZ-00; Wed, 25 Feb 2004 12:05:07 -0800 Message-ID: <005e01c3fbda$c2bd8b30$0d81bb3f@Panoramic> From: "Richard Ogier" To: "Charles E. Perkins" Cc: "Mobile Ad Hoc IETF working group" References: <403118FC.79B8305B@iprg.nokia.com> <40311DC6.5A2BE2DB@iprg.nokia.com> <40378B93.5040607@erg.sri.com> <403CDD75.A88D90CA@iprg.nokia.com> Subject: Re: [manet] MPRF [flooding protocol] document initial revision Date: Wed, 25 Feb 2004 12:00:20 -0800 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charlie and all, The discussion we had regarding the flooding method you are suggesting can be found here ftp://ftp.ietf.org/ietf-mail-archive/manet/2002-09.mail Search for "Cedric", who ran the simulations. Here is what Philippe Jacquet said about the approach: > Richard, > If you mean to include all MPR nodes in the dominating set, we have already > thought about it sometimes ago. We gave up this idea because it creates much > too large dominating sets (almost all nodes involved). > Philippe As Joe suggests, it is possible to reduce the size of the CDS by making the MPR sets overlap more, e.g., by preferring min ID neighbors as MPRs. In the extreme case, each step of the MPR selection algorithm selects the min ID neighbor that covers some 2-hop neighbor that is not yet covered. In this case, you don't even use degree, and thus it becomes possible for nodes to select *themselves* as MPRs or CDS nodes. (This is similar to how nodes select themselves as MPRs in TBRPF.) Having nodes select themselves as CDS nodes may also help reliability and robustness, since a node can select itself immediately as a CDS node following a link failure. It would be nice to have simulation results that measure how much this improves performance. Richard ----- Original Message ----- From: "Charles E. Perkins" To: "Richard Ogier" Cc: "Mobile Ad Hoc IETF working group" Sent: Wednesday, February 25, 2004 9:37 AM Subject: Re: [manet] MPRF [flooding protocol] document initial revision > > Hello Richard, > > Taking your suggestions out of order, I'd first agree > with your proposed terminology. I have noticed many > times that the terminology surrounding the flooding > discussion can be very confusing. I will try to go > through the MPRF draft to make the indicated revisions > to our terminology. > > The example you give is, I think, applicable to other > situations where an MPR node receives a flooded > packet from other neighbors first. It seems to me > that a very simple fix would work, though. > > If a MPR node receives a flooded packet from ANY > neighbor, it should go ahead and transmit the > packet again to its neighbors, and mark the > packet as already processed. > > This can be accomplished by modifying step 5.2 > to read as follows: > > 5.2 If this node is MPR for any of its neighbors, and if the > time to live of the message is greater than '1', the mes- > sage MUST be forwarded according to the following by > broadcasting it on all interfaces that have symmetric > neighbors other than the sender, with the TTL of the mes- > sage reduced by one. > > I must admit that I have only been puzzling over your > observation for a little while, so I might have missed > something. But even without the problem you raised, > this approach would be better for two reasons: > - Reduced broadcast latency, and > - Better robustness when the MPR selector's local > (typically unreliable!) broadcast is lost for some reason. > Lastly, I think I like this approach because I seem to > remember wanting to put it in a long time ago and I just > forgot to do so. > > Regards, > Charlie P. > > > Richard Ogier wrote: > > > > Here is an example where the MPRF protocol does not work. > > (Although it can be fixed as explained below.) > > > > 8 > > / \ > > 2-----5 > > / \ / \ > > / \ / \ > > 1 / 7 > > \ / \ / > > \ / \ / > > 3-----6 > > \ / > > 9 > > > > Node 1 is the source (originator of flooded packets), > > and its MPRs are nodes 2 and 3. > > Node 2 selects node 6 as MPR (to cover 3, 7, and 9) > > Node 3 selects node 5 as MPR (to cover 2, 7, and 8). > > > > Node 1 originates a packet, which is relayed by nodes 2 and 3. > > Suppose node 5 receives the packet first from node 2, then from node 3. > > Suppose node 6 receives the packet first from node 3, then from node 2. > > (I explain below how this is possible.) > > Since node 2 is not an MPR selector of node 5, node 5 does not relay > > the packet when it is received from node 2, but creates an entry > > in the Flooding History (step 5.1 in the draft). > > Then, when node 5 receives the packet from node 3 (its MPR selector), > > node 5 ignores the packet (step 2 in the draft). > > Therefore, node 5 does not relay the packet. > > Similarly, node 6 does not relay the packet. > > Therefore, node 7 never receives the packet. > > > > I think the solution is for each node to remember > > which flooded packets it has already transmitted. > > If a node receives a flooded packet from an MPR selector, > > and has not yet transmitted the same packet, then it > > should relay the packet. > > > > I think the same problem exists in > > draft-spagnolo-manet-ospf-wireless-interface-00 > > > > I can think of 3 situations that can result in the > > above example (in which node 5 receives the packet first from > > node 2, and node 6 receives the packet first from node 3): > > > > 1. Very long propagation delays. > > 2. As stated in the Introduction of the draft, link layer > > broadcast can be accomplished using iterated unicast. > > 3. If the flooded packet is sent reliably to all neighbors using > > ACKs with retransmissions, then the first transmission from > > node 2 (resp. 3) might be received only by node 5 (resp. 6). > > > > Regards, > > Richard > > > > P.S. Regarding the terms "reflood" and "retransmit". > > > > "Reflood" means to flood the packet again to all nodes. > > RFC 2328 for OSPF uses this term correctly, but some > > people have recently used it to mean "relay". > > > > "Retransmit" means for the same node to transmit the packet again, > > usually because an ACK was not received. > > It will be very confusing when we talk about reliable flooding > > with ACKs, if we use the word "retransmit" to mean both > > retransmission from the same node, and relaying a packet > > received from another node. > > > > When talking about a node relaying a packet, I suggest using > > either the term "relay" or "transmit". > > > > _______________________________________________ > > 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 exim@www1.ietf.org Tue Mar 30 18:11:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26091 for ; Tue, 30 Mar 2004 18:11:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006a4-CA for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CLR7kL008027 for manet-archive@odin.ietf.org; Fri, 12 Mar 2004 16:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1uBP-00025O-7q for manet-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 16:27:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19449 for ; Fri, 12 Mar 2004 16:27:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1uBN-0000Mm-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 16:27:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1uA6-00008K-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 16:25:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1u94-0007ic-00 for manet-web-archive@ietf.org; Fri, 12 Mar 2004 16:24:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1u8c-0000jo-7d; Fri, 12 Mar 2004 16:24:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1tYN-0007jv-1m for manet@optimus.ietf.org; Fri, 12 Mar 2004 15:46:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17870 for ; Fri, 12 Mar 2004 15:46:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1tYL-0003ND-00 for manet@ietf.org; Fri, 12 Mar 2004 15:46:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1tXN-0003GJ-00 for manet@ietf.org; Fri, 12 Mar 2004 15:45:46 -0500 Received: from pophost.cs.tamu.edu ([128.194.138.12] helo=pine.cs.tamu.edu) by ietf-mx with esmtp (Exim 4.12) id 1B1tWw-00039w-00 for manet@ietf.org; Fri, 12 Mar 2004 15:45:18 -0500 Received: from unix.cs.tamu.edu (unix.cs.tamu.edu [128.194.138.13]) by pine.cs.tamu.edu (8.12.9/8.12.9) with ESMTP id i2CKj0nf029241; Fri, 12 Mar 2004 14:45:01 -0600 (CST) Received: from localhost (b0l4549@localhost) by unix.cs.tamu.edu (8.11.7p1+Sun/8.10.2) with ESMTP id i2CKj0200936; Fri, 12 Mar 2004 14:45:00 -0600 (CST) X-Authentication-Warning: unix.cs.tamu.edu: b0l4549 owned process doing -bs Date: Fri, 12 Mar 2004 14:45:00 -0600 (CST) From: Bin Lu To: Ram Ramanathan cc: manet@ietf.org Subject: Re: [manet] question about bandwidth reservation 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=FROM_ENDS_IN_NUMS, FROM_HAS_MIXED_NUMS autolearn=no version=2.60 > > Any papers on the subject of 802.11e-like things for ad hoc nets? Any > paper that summarizes 802.11e? > Here is a paper that gives an overview of the new features of IEEE 802.11e: "IEEE 802.11e Wireless LAN for Quality of Service", Stefan Mangold etc., http://citeseer.ist.psu.edu/537394.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:12:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26125 for ; Tue, 30 Mar 2004 18:12:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006Xa-IY for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i247mZ4F016394 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 02:48:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynas-0004EW-Dh for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 02:48:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24403 for ; Thu, 4 Mar 2004 02:48:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynaZ-0005kT-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 02:48:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynZd-0005Z7-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 02:47:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AynYp-0005Mq-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 02:46:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynYT-0003bB-OC; Thu, 04 Mar 2004 02:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynY8-0003Ze-Hw for manet@optimus.ietf.org; Thu, 04 Mar 2004 02:45:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24045 for ; Thu, 4 Mar 2004 02:45:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynY4-00058W-00 for manet@ietf.org; Thu, 04 Mar 2004 02:45:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynX3-0004rI-00 for manet@ietf.org; Thu, 04 Mar 2004 02:44:38 -0500 Received: from cms4.etri.re.kr ([129.254.16.14]) by ietf-mx with esmtp (Exim 4.12) id 1AynW3-0004QR-00 for manet@ietf.org; Thu, 04 Mar 2004 02:43:35 -0500 Received: from jafymobile (6ants5.etri.re.kr [129.254.112.239]) by cms4.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id FHDW2A7G; Thu, 4 Mar 2004 16:43:05 +0900 Reply-To: From: "HyunWook Cha" To: , "'Christophe Jelger'" , "'manet'" Subject: RE: Re: [manet] Default Routes (Intern) Date: Thu, 4 Mar 2004 16:43:07 +0900 Organization: ETRI Message-ID: <001001c401bc$55a1c100$ef70fe81@jafymobile> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <9682082.1078322772838.JavaMail.adm-moff@moffice2.nsc.no> Importance: 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, Paal. I am sorry that I am now in Daejon not Seoul. Please see my inline comments. > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Paal.Engelstad@telenor.com > Sent: Wednesday, March 03, 2004 11:06 PM > To: Christophe Jelger; manet > Subject: SV: Re: [manet] Default Routes (Intern) > > > Christophe, > > It seems I triggered some discussion that passed me by, but > let me cut into this thread and response to your preference > for default routes. > > This is from Anders' mail: > > This is from Paals mail: > > > > > If you have two gateways announcing the same default route, the > > > MANET node has no control of which gateway the packet is routed > > > out through. You might get problems with: > > > - Stateless firewalls: E.g. The first packet of your > (TCP-) session > > > might go out through another gateway than the one > corresponding to > > > the selected source IP address. Thus, the return inbound > packets will > > > not reach the gateway corresponding to the MANET node's > source IP address > > > if the gateway is behind i firewall because no state is > set in the firewall. > > > - Ingress filtering: Outbound packets escaping out > through "wrong" gateways > > > are filtered out. > > > > As pointed out earlier, this problem can solved by letting > intermediate > > forwarding nodes search their gateway list for the source > prefix. If the > > source prefix matches an entry in the gateway list, the packet is > > forwarded to the indicated gateway. I think this solves the problem > > stated above. > > Here I think Anders gets to the core of the matter - i.e > destination based routing: Many nodes communicating with the > same external host cannot share the same destination-based > route and still get to different gateways. > For an external node, a route entry can not be discovered to be shared by all packets destined to the node. > 1) Either you need a tunneling solution or some sort, > 2) or you need source address based default routing > > The first is lean and mean, and works in nearly any > networking scenario, and with any routing protocol. > I do not see any problem a source address based default forwarding in corporating with routing protocols if forwarding routine in IP layer can be extended. > The functionality of the second is obscure, it is less clean > than the tunneling solution, and probably makes routing more > complicated. In addition, you bind internet access together > with address autoconfiguration, which reduces the level of modularity. > I think that the second method is not obsure, though forwarding function needs additional processing(almost one hash for searching gateway list + one more lookup for matched gateway's route entry). However, tunneling or routing header also require additional processing in IPv6 module since an extension header has been added after all. In addition, routers (Internet gateways) are given additional workload which is decapsulation or swpping between destination header and routing header entry. In tunneling based method, tunnel end point is determined for a given source address in packet. Difference between two methods, packet overhead for existing destination forwarding infra or extending forwarding functionality instead of packet overhead. For fast deployment, the former is better, I agree. > Since the latter solution resembles a hack (as compared to > the clean tunneling solution), I also think it might lead to > unforseen problems sooner or later. For example, if I would > use it in an IPv4 setting, it would obviously not work. > (Default routes is not a good idea, at least not with IPv4, > and should never have been accepted in the experimental RFCs, IMO). > > Yes, and by the way, here is another problem, which I didn't think of: > > > However, there is an other problem here. If the node is > > moving inside the network, it will probably want to switch > to different > > gateways as they become closer. The only way for this to > work in the > > mentioned solution is to onfigure a new address, which is > not really a > > good solution. If the different gateways belong to the same > domain, it > > might not even be possible > I do not understand what this scenario is for and the problem is. Could you tell me? Regards, HyunWook > I think I am willing to pay the little extra overhead of > tunneling to get a simpler, modular, and more robust solution. > > Paal > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:12:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26170 for ; Tue, 30 Mar 2004 18:12:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006Xa-1k for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i099RKLc016334 for manet-archive@odin.ietf.org; Fri, 9 Jan 2004 04:27:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AesvI-0004FN-AC for manet-web-archive@optimus.ietf.org; Fri, 09 Jan 2004 04:27:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19074 for ; Fri, 9 Jan 2004 04:27:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AesvF-00006j-00 for manet-web-archive@ietf.org; Fri, 09 Jan 2004 04:27:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AestO-0007ke-00 for manet-web-archive@ietf.org; Fri, 09 Jan 2004 04:25:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Aessh-0007b4-00 for manet-web-archive@ietf.org; Fri, 09 Jan 2004 04:24:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AessI-0003R8-9Y; Fri, 09 Jan 2004 04:24:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aes8W-0001e9-Jh for manet@optimus.ietf.org; Fri, 09 Jan 2004 03:36:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17674 for ; Fri, 9 Jan 2004 03:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aes8U-0005Pu-00 for manet@ietf.org; Fri, 09 Jan 2004 03:36:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aes6x-0005L4-00 for manet@ietf.org; Fri, 09 Jan 2004 03:35:20 -0500 Received: from cms4.etri.re.kr ([129.254.16.14] helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1Aes5g-0005BI-00 for manet@ietf.org; Fri, 09 Jan 2004 03:34:01 -0500 Received: from jafywinxp (pd412h.etri.re.kr [129.254.112.174]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id CK0BFRYR; Fri, 9 Jan 2004 17:36:04 +0900 Reply-To: From: "HyunWook Cha" To: "'Poornananda G R'" , "'Karun Verma'" , Subject: RE: [manet] Regarding Simulatiuon of AODV and TORA Date: Fri, 9 Jan 2004 17:33:29 +0900 Message-ID: <000001c3d68b$425830e0$ae70fe81@jafywinxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <003e01c3d683$d525ccf0$c9866840@apac.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yeap. Just change -adhocRouting option to respective routing protocols and call Simulater::node-config before Simulater::node is called. HyunWook Cha > -----Original Message----- > From: Poornananda G R [mailto:poorna@cisco.com] > Sent: Friday, January 09, 2004 4:40 PM > To: jafy@etri.re.kr; 'Karun Verma'; manet@ietf.org > Subject: RE: [manet] Regarding Simulatiuon of AODV and TORA > > > > Hi, > I have another related question- can we simulate one or more > of these routing protocols simultaneously? > For example, can we simulate a set of 100 nodes and say 50 of > them running aodv, 25 running dsr and the rest running tora? > Thanks, -Poorna > > % -----Original Message----- > % From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > % Behalf Of HyunWook Cha > % Sent: Friday, January 09, 2004 12:47 PM > % To: 'Karun Verma'; manet@ietf.org > % Subject: RE: [manet] Regarding Simulatiuon of AODV and TORA > % > % > % > % As for tora and aodv, you can refer > % test-suite-wirless-lan-aodv(or tora).tcl. (Both files seems > % to be almost same.) NS-2 provides a common framework to > % generate(instantiate) mobile nodes irrespective ad hoc > % routing protocols. What to do is as follows. > % > % set ns_ [new Simulator] > % set god_ [create-god $opt(nn) ] // opt(nn) = number of nodes > % $ns_ node-config -adhocRouting AODV [or DSR or TORA or > DSDV] .... ; > % refer the example file. > % for {set i 0} {$i < $opt(nn) } {incr i} { > % set node_($i) [$ns_ node] > % ... > % } > % > % For more details, you can refer the ns-2 manual. > % > % HyunWook Cha > % > % > -----Original Message----- > % > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] > On % > Behalf Of Karun Verma % > Sent: Friday, January 09, > 2004 3:18 PM % > To: manet@ietf.org % > Subject: [manet] > Regarding Simulatiuon of AODV and TORA % > > % > > % > When i want to simulate protocols aodv and tora using the > script % > wireless1.tcl in ~ns/tc/ex directory % > i get > thye following errors % > > % > invalid command name "tora-create-mobile-node" > % > while executing > % > "tora-create-mobile-node $i" > % > invoked from within > % > "if { [string compare $opt(rp) "dsr"] == 0} { > % > for {set i 0} {$i < $opt(nn) } {incr i} { > % > dsr-create-mobile-node $i > % > } > % > } elseif { [string compare $opt..." > % > (file "wireless_tora.tcl" line 209) > % > > % > i have modified the script. > % > What else modifications i have to do for both these > % > protocols. Help me. with this mail i am attaching the script > % > "wireless_tora.tcl" > % > > % > thanx in advance > % > > % > ############################################ > % > > % > # Karun Verma > % > > % > # > % > > % > ########################################### > % > > % > _________________________________________________________________ > % > Games, MMS cards, ringtones. Operator logos, picture > % messages & more. > % > http://server1.msn.co.in/sp03/mobilesms/ Jazz up your mobile! % > > % > > % > % > % _______________________________________________ > % 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 exim@www1.ietf.org Tue Mar 30 18:15:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27057 for ; Tue, 30 Mar 2004 18:15:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006Xa-3t for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0FJ93q8009470 for manet-archive@odin.ietf.org; Thu, 15 Jan 2004 14:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhCrX-0002Sf-TE for manet-web-archive@optimus.ietf.org; Thu, 15 Jan 2004 14:09:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20627 for ; Thu, 15 Jan 2004 14:09:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhCrV-0002OL-00 for manet-web-archive@ietf.org; Thu, 15 Jan 2004 14:09:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhCqX-0002JK-00 for manet-web-archive@ietf.org; Thu, 15 Jan 2004 14:08:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AhCpt-0002EB-00 for manet-web-archive@ietf.org; Thu, 15 Jan 2004 14:07:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhCpZ-0001rQ-Hu; Thu, 15 Jan 2004 14:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AhCpC-0001pi-Mk for manet@optimus.ietf.org; Thu, 15 Jan 2004 14:06:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20470 for ; Thu, 15 Jan 2004 14:06:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhCpA-0002Ax-00 for manet@ietf.org; Thu, 15 Jan 2004 14:06:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhCoB-00026m-00 for manet@ietf.org; Thu, 15 Jan 2004 14:05:35 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx with esmtp (Exim 4.12) id 1AhCn7-000216-00 for manet@ietf.org; Thu, 15 Jan 2004 14:04:43 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.10+Sun/8.12.8) with SMTP id i0FJ3mLd015321; Thu, 15 Jan 2004 14:03:48 -0500 (EST) Received: from [132.250.92.132] ([132.250.92.132]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.3.37) with SMTP id M2004011514034725486 ; Thu, 15 Jan 2004 14:03:47 -0500 Mime-Version: 1.0 X-Sender: wieselth@pop.itd.nrl.navy.mil Message-Id: Date: Thu, 15 Jan 2004 14:03:47 -0500 To: manet@ietf.org From: Jeff Wieselthier Cc: Allan.Gibb@drdc-rddc.gc.ca Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [manet] Workshop Announcement -- Cross-Layer Issues in the Design of Tactical Mobile Ad Hoc Wireless Networks: Integration of Communication and Networking Functions to Support Optimal Information 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At http://www.valcartier.drdc-rddc.gc.ca/tgonimdg/#upcoming you will find an Announcement and Call for Abstracts for a workshop on 'Cross-Layer Issues in the Design of Tactical Mobile Ad Hoc Wireless Networks: Integration of Communication and Networking Functions to Support Optimal Information Management'. The workshop is being organized under the auspices of Task Group 12 of the NATO Research and Technology Organization's Information Systems Technology Panel ( http://www.valcartier.drdc-rddc.gc.ca/tgonimdg/ ). It will take place on 2-3 June 2004 at the US Naval Research Laboratory in Washington, DC. The workshop will address the challenge of 'top-to-bottom' information management in disadvantaged (unreliable, low bandwidth or energy-constrained) mobile wireless military communication networks. Crucial issues relating to communication and networking in hostile environments span the entire layered structure from the physical layer up through the session layer. The conventional way to implement networks is to use a strictly layered structure, in which these issues are addressed separately, while defining interfaces to higher and lower layer functions. Although such an approach may be appropriate for wired networks, the characteristics of wireless networks suggest that improved performance may be obtained by addressing these issues in a coordinated (or "cross-layer") fashion. This workshop will address alternative approaches to various aspects of the communication/networking problem, and will assess the potential benefits that may be achieved through the vertical integration of layer functionality, with emphasis on improved collaboration with user applications to achieve optimal information management over a disadvantaged network. The topic will be of interest to military or scientific personnel concerned with the efficient use of limited resources in disadvantaged communications environments. Our keynote presentation will be given by Dr. Michael B. Pursley, Holcombe Professor of Electrical and Computer Engineering, Clemson University. The workshop is open to citizens of NATO member countries who are working for a government, military, industrial or academic organization or institution within a NATO nation on a topic relevant to the theme of the workshop. The workshop is UNCLASSIFIED. The working language will be English. There is no registration fee. Please notify the undersigned of your desire to attend and/or make a presentation, using the form included in the attached Word document, NOT LATER THAN 18 February 2004. Submission of the form by electronic means is encouraged. We would appreciate your cooperation in forwarding the Announcement to colleagues that you feel may have an interest in the subject. Sincerely, Jeffrey Wieselthier Code 5521 Information Technology Division Naval Research Laboratory Washington, DC 20375 Tel: +1 (202) 767-3043 Fax: +1 (202) 767-1191 wieselthier@itd.nrl.navy.mil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:16:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27331 for ; Tue, 30 Mar 2004 18:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjT-0006Xa-01 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22JvnCU005528 for manet-archive@odin.ietf.org; Tue, 2 Mar 2004 14:57:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyG1V-0001R5-Lu for manet-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 14:57:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27239 for ; Tue, 2 Mar 2004 14:57:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyG1S-0004pw-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 14:57:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyG0U-0004ij-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 14:56:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyFzw-0004bU-00 for manet-web-archive@ietf.org; Tue, 02 Mar 2004 14:56:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyFzm-0000uj-VC; Tue, 02 Mar 2004 14:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyFyy-0000l6-7u for manet@optimus.ietf.org; Tue, 02 Mar 2004 14:55:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27029 for ; Tue, 2 Mar 2004 14:55:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyFyv-0004SQ-00 for manet@ietf.org; Tue, 02 Mar 2004 14:55:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyFy3-0004HK-00 for manet@ietf.org; Tue, 02 Mar 2004 14:54:16 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1AyFx5-00042x-00 for manet@ietf.org; Tue, 02 Mar 2004 14:53:15 -0500 Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.12.10/8.12.10) with SMTP id i22JqgUM006723; Tue, 2 Mar 2004 20:52:42 +0100 Message-ID: <03dd01c4008e$456ace00$1f175d80@inria.fr> From: "Philippe Jacquet" To: "ying ge" , References: <5.1.0.14.2.20040302163149.02cca3c8@buzonpdi.uma.es> <007101c40084$404a22e0$4c225c8e@anik2> Subject: Re: [manet] OLSR - questions on MPR calculation Date: Tue, 2 Mar 2004 20:40:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Miltered: at concorde by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear Yi, My comments are in the text. Philippe ----- Original Message ----- From: ying ge To: Sent: Tuesday, March 02, 2004 7:29 PM Subject: [manet] OLSR - questions on MPR calculation > Dear group, > > I'm looking at the proposed OLSR_RFC MPR selection mechanism, and have the > following questions: > > 1) in step 1 of MPR calculation -- "Start with an MPR set made of all > members of N with N_willingness equal to WILL_ALWAYS" > > Does it mean that a "WILL_ALWAYS" neighbor has to be selected as MPR > even if it has no connection to any 2-hop neighbors? In this case, the MID > and TC messages would be unnecessarily relayed by that neighbor, which may > make the wireless media busier. Can we put it as "Start with an MPR set made > of all members of N with N_willingness equal to WILL_ALWAYS, and N has at > least one 2_hop_neighbor"? Basic OLSR routers should not have willingness equal to WILL_ALWAYS. We use WIL_ALWAYS when the network contains a set of node that the administrator wants to manually set as a wireless backbone. > > 2) in step 4.2 -- "Select as a MPR the node with highest N_willingness among > the nodes in N with non-zero reachability. In case of multiple choice select > the node which provides reachability to the maximum number of nodes in N2. > In case of multiple nodes providing the same amount of reachability, select > the node as MPR whose D(y) is greater. Remove the nodes from N2 which are > now covered by a node in the MPR set. " > > If we select neighbors with higher willingness as MPR, regardless how > many two hop neighbors it is connected to, may we ended up choose a lot of > MPRs? If there is too many MPRs in the network, the control overhead of the > OLSR may be very high, which may degrade the routing protocol's performance > (more data packet may be dropped because of the busy media, the end-to-end > delay of the data packets may be very long...). > This is true to some extend for broadcast control traffic (the increase is not that big) but not true for data traffic which should take the most bandwidth. The routes are still the shortest path with willingness, excepted that routes will take relay nodes with highest willingness. Willingness should be used with care, for example in order to reflect the battery capacity of the host. It helps to spread the broadcast relaying so that it does not kill the battery of some relay faster than it could be. > I have such a question because I used to introduce QoS routing into > OLSR, and tried to select as MPR the neighbors which have the best QoS > conditions, which is similar to the concept that "to select as the highest > willingness neighbors as MPR". From the OPENT simulation, I found that with > such mechanism, much more MPRs is selected, compared with the mechanism > proposed in OLSR draft version 3 (select the neighbor which have the most > reachability to the 2-hop-neighbors). Further more, the OPNET simulation > result shows that because of the large numbers of MPRs in the network, the > overhead is high, and the routing protocol's performance ("packet delivery > ratio" and "end-to-end-delay" for data packets) is not satisfactory. > > My idea to solve this problem is to define a formula, and put the > neighbor "willingness" and "reachability to 2-hop-neighbors" as two > inputs -- such as Weight(willingness, reachability) = neighbor' willingness > + neighbor's reachability. Then select the neighbour that has the highest > "Weight" as MPR. Will this work? Please give me your ideas... > > Maybe there are some special reasons or special scenarios the proposed MPR > selection mechanism should apply? If yes, would you please kindly tell me? > > Thanks and Best regards > > Ying > > Ying Ge > Communications Research Centre Canada | Centre de recherches sur les > communications Canada > 3701 Carling Ave. | 3701, avenue Carling > PO Box 11490, Station H | CP 11490, succursale H > Ottawa ON K2H 8S2 | Ottawa (Ontario) K2H 8S2 > (613) 998-2819 | ying.ge@crc.ca | > Web site / Site web : www.crc.ca > Government of Canada | Gouvernement du Canada > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:17:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27687 for ; Tue, 30 Mar 2004 18:17:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006Xa-RE for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HL1PhA029444 for manet-archive@odin.ietf.org; Tue, 17 Feb 2004 16:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCLM-0007ep-IS for manet-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 16:01:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05390 for ; Tue, 17 Feb 2004 16:01:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCLK-0004xv-00 for manet-web-archive@ietf.org; Tue, 17 Feb 2004 16:01:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCKH-0004qN-00 for manet-web-archive@ietf.org; Tue, 17 Feb 2004 16:00:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtCJG-0004d2-00 for manet-web-archive@ietf.org; Tue, 17 Feb 2004 15:59:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCJ6-0006nw-9E; Tue, 17 Feb 2004 15:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtCI7-0006X3-I5 for manet@optimus.ietf.org; Tue, 17 Feb 2004 15:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04926 for ; Tue, 17 Feb 2004 15:58:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtCI5-0004Ps-00 for manet@ietf.org; Tue, 17 Feb 2004 15:58:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtCGr-0004Ep-00 for manet@ietf.org; Tue, 17 Feb 2004 15:56:45 -0500 Received: from stamps.cs.ucsb.edu ([128.111.41.14]) by ietf-mx with esmtp (Exim 4.12) id 1AtCGE-00047h-00 for manet@ietf.org; Tue, 17 Feb 2004 15:56:06 -0500 Received: from kenai.cs.ucsb.edu (csil.cs.ucsb.edu [128.111.41.12]) by stamps.cs.ucsb.edu (8.12.8/8.12.8) with ESMTP id i1HKqqeL019663; Tue, 17 Feb 2004 12:52:52 -0800 (PST) From: Ian Chakeres MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16434.32731.543261.133544@gargle.gargle.HOWL> Date: Tue, 17 Feb 2004 12:55:55 -0800 To: "B.VenkataRamana" Cc: manet@ietf.org Subject: RE:[manet] interaction between IP & Any routing protocol In-Reply-To: References: X-Mailer: VM 7.15 under Emacs 21.3.1 Reply-To: idc@cs.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We have a paper "AODV Routing Protocol Implementation Design". You can download it from http://moment.cs.ucsb.edu/publications. It details the design of our AODV implementation. I will be presenting it at WWAN in Tokyo next month. Ian Chakeres >B.VenkataRamana wrote: > >hi > >can you please tell me, how does Internet Protocol(IP) interact with AODV >or any other routing protocol when it is required to forward a data >packet?. please tell me for both cases, when route info is available in >the table, when the route info is NOT available in the routing table. >finally, any changes/modifications are required for IP to work with the >routing protocols of MANETs. > >sincerely >Venkataramana > > > >_______________________________________________ >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 exim@www1.ietf.org Tue Mar 30 18:18:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27940 for ; Tue, 30 Mar 2004 18:18:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjS-0006WI-1y for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i289wQDf017322 for manet-archive@odin.ietf.org; Mon, 8 Mar 2004 04:58:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0HWj-0004Uz-G0 for manet-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 04:58:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22106 for ; Mon, 8 Mar 2004 04:58:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0HWe-0004WY-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 04:58:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0HVi-0004JT-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 04:57:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0HUk-00049l-00 for manet-web-archive@ietf.org; Mon, 08 Mar 2004 04:56:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0HUT-00044h-7H; Mon, 08 Mar 2004 04:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0HTp-00040l-8F for manet@optimus.ietf.org; Mon, 08 Mar 2004 04:55:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22047 for ; Mon, 8 Mar 2004 04:55:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0HTm-0003zc-00 for manet@ietf.org; Mon, 08 Mar 2004 04:55:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0HSy-0003rM-00 for manet@ietf.org; Mon, 08 Mar 2004 04:54:33 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1B0HSN-0003iN-00 for manet@ietf.org; Mon, 08 Mar 2004 04:53:55 -0500 Received: from [130.238.8.241] (dhcp-8-241.it.uu.se [130.238.8.241]) by aun.it.uu.se (8.12.11/8.12.10) with ESMTP id i289rsxT006230; Mon, 8 Mar 2004 10:53:54 +0100 (MET) Subject: RE: SV: Re: SV: Re: SV: RE: [manet] Default Routes (Intern) From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: "Fredrik Alriksson (KI/EAB)" Cc: "'manet'" In-Reply-To: <1F55F6582266314A85A55F6241509B670A295ACD@Esealnt863.al.sw.ericsson.se> References: <1F55F6582266314A85A55F6241509B670A295ACD@Esealnt863.al.sw.ericsson.se> Content-Type: text/plain Message-Id: <1078739634.25112.8.camel@dhcp-8-241.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 08 Mar 2004 10:53:54 +0100 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Mon, 2004-03-08 at 10:43, Fredrik Alriksson (KI/EAB) wrote: > > >>What makes you think that route entries for global > > addresses assigned to > > >>MANET nodes should not be maintained inside the MANET? I do > > not see any > > >>reason. If gateway obtains valid route entry for a > > destination node's > > >> > > >> > > > > > >Tunneling does not totally exclude global (non-adhoc) > > addresses in the > > >MANET. Routing entries for global addresses still have to be > > maintained > > >at end nodes. It just simplifies the routing, and you achieves route > > >aggregation since you can share a tunnel among many addresses. In the > > >AODV case, there is also no need to maintain sequence > > numbers for routes > > >to global destinations since it maps to the gateway route. This would > > >not be the case if you "import" global addresses/routes into > > the ad hoc > > >network. > > > > > > > > > > > Route aggregation ? Well usually route aggregation is for the routing > > table ... and if you don't use a default route it means you will still > > have a routing entry for each destination. The "next hop" entry will be > > the same tunnel, but still you have one entry per destination. This > > doesn't really look like route aggregation ... but maybe did you mean > > something else ? > > Erik didn't answer to this, right? Anyway: I agree that you won't see any route aggregation in the end node's routing table, but you will in the routing tables of the intermediate nodes. > Yes, exactly. You have aggregation (on intermediate nodes) in the sense that you map several destinations (on end nodes) to the same gateway route. I.e., a node close to the gateway can forward packets to many Internet destinations while only maintaining a gateway route. Overall, you can save a lot of entries (state) in the network. //Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:18:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27972 for ; Tue, 30 Mar 2004 18:18:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006a4-K2 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i07A0fci005880 for manet-archive@odin.ietf.org; Wed, 7 Jan 2004 05:00:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeAUP-0001WN-RJ for manet-web-archive@optimus.ietf.org; Wed, 07 Jan 2004 05:00:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00840 for ; Wed, 7 Jan 2004 05:00:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeAUM-0006IY-00 for manet-web-archive@ietf.org; Wed, 07 Jan 2004 05:00:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeASj-00066R-00 for manet-web-archive@ietf.org; Wed, 07 Jan 2004 04:58:54 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AeAQJ-0005u0-01 for manet-web-archive@ietf.org; Wed, 07 Jan 2004 04:56:23 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AeAEE-0005WO-IM for manet-web-archive@ietf.org; Wed, 07 Jan 2004 04:43:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeADR-0000j6-AH; Wed, 07 Jan 2004 04:43:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AeACW-0000hO-2W for manet@optimus.ietf.org; Wed, 07 Jan 2004 04:42:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29869 for ; Wed, 7 Jan 2004 04:42:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeACT-0005BB-00 for manet@ietf.org; Wed, 07 Jan 2004 04:42:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeABE-00055S-00 for manet@ietf.org; Wed, 07 Jan 2004 04:40:49 -0500 Received: from anyida.tts.lth.se ([130.235.18.10]) by ietf-mx with esmtp (Exim 4.12) id 1AeA9b-0004wK-00 for manet@ietf.org; Wed, 07 Jan 2004 04:39:07 -0500 Received: from telecom.lth.se (lina23.tts.lth.se [130.235.18.83]) by anyida.tts.lth.se (8.9.3/8.9.3) with ESMTP id KAA22792; Wed, 7 Jan 2004 10:38:37 +0100 (MET) Message-ID: <3FFBD3C6.2090306@telecom.lth.se> Date: Wed, 07 Jan 2004 10:39:18 +0100 From: Ali Hamidian User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: minhtam_nu@yahoo.com.au, manet@ietf.org Subject: Re: [manet] Trace file Content-Type: multipart/alternative; boundary="------------000202050107070404050309" 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=HTML_FONTCOLOR_BLUE, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000202050107070404050309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Minh Tam. I replied your mail before christmas but obviously you havn't received it. So now I resend it. Hope it's not too late. Hi! The trace file shows that the source (mobile node _3_) cannot find the destination (wired node _2_). Since the mobile node cannot find a route to the wired node, I suspect that you're still running AODV and not AODV+. So, please make sure that you have followed all the steps in the README file correctly! If you still cannot find why AODV is run instead of AODV+, contact me again. Regards Ali minh tam wrote: > Dear all, > > I am a NS2 new user . I really confuse about the format of trace file. > The attachment is the trace file after doing simulation of example > wireless2.tcl( tutorial ) using AODV+ > (http://www.telecom.lth.se/Personal/alexh/) > I've checked with cmu-trace.cc but it doesn't match perfectly. > Can anyone explain it to me? > > Thanks ! > > > > > ------------------------------------------------------------------------ > Yahoo! Personals > > - New people, new possibilities. FREE for a limited time! > >------------------------------------------------------------------------ > >M 0.0 nn 3 x 670 y 670 rp AODV >M 0.0 sc ../mobility/scene/scen-3-test cp none seed 0.0 >M 0.0 prop Propagation/TwoRayGround ant Antenna/OmniAntenna >M 33.00000 4194305 (83.36, 239.44, 0.00), (89.66, 283.49), 19.15 >M 50.00000 4194307 (591.26, 199.37, 0.00), (369.46, 170.52), 3.37 >M 51.00000 4194306 (257.05, 345.36, 0.00), (221.83, 80.86), 14.91 >s 160.000000000 _3_ AGT --- 0 tcp 40 [0 0 0 0] ------- [4194305:0 0:0 32 0] [0 0] 0 0 >r 160.000000000 _3_ RTR --- 0 tcp 40 [0 0 0 0] ------- [4194305:0 0:0 32 0] [0 0] 0 0 >f 160.000000000 _3_ RTR --- 0 AODV 48 [0 0 0 0] ------- [4194305:255 -1:255 30 0] [0x2 1 1 [0 0] [4194305 4]] (REQUEST) >r 160.001200806 _4_ RTR --- 0 AODV 48 [0 ffffffff 1 800] ------- [4194305:255 -1:255 30 0] [0x2 1 1 [0 0] [4194305 4]] (REQUEST) >f 160.009192361 _4_ RTR --- 0 AODV 48 [0 ffffffff 1 800] ------- [4194306:255 -1:255 29 0] [0x2 2 1 [0 0] [4194305 4]] (REQUEST) >r 160.010252937 _5_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 1 [0 0] [4194305 4]] (REQUEST) >r 160.010253143 _2_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 1 [0 0] [4194305 4]] (REQUEST) >r 160.010253167 _3_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 1 [0 0] [4194305 4]] (REQUEST) >f 160.012598954 _5_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194307:255 -1:255 28 0] [0x2 3 1 [0 0] [4194305 4]] (REQUEST) >r 160.013759530 _4_ RTR --- 0 AODV 48 [0 ffffffff 3 800] ------- [4194307:255 -1:255 28 0] [0x2 3 1 [0 0] [4194305 4]] (REQUEST) >f 160.016641794 _2_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194304:255 -1:255 28 0] [0x2 3 1 [0 0] [4194305 4]] (REQUEST) >r 160.017582576 _4_ RTR --- 0 AODV 48 [0 ffffffff 0 800] ------- [4194304:255 -1:255 28 0] [0x2 3 1 [0 0] [4194305 4]] (REQUEST) >f 162.000000000 _3_ RTR --- 0 AODV 48 [0 0 0 0] ------- [4194305:255 -1:255 30 0] [0x2 1 2 [0 0] [4194305 6]] (REQUEST) >r 162.001060806 _4_ RTR --- 0 AODV 48 [0 ffffffff 1 800] ------- [4194305:255 -1:255 30 0] [0x2 1 2 [0 0] [4194305 6]] (REQUEST) >f 162.009658083 _4_ RTR --- 0 AODV 48 [0 ffffffff 1 800] ------- [4194306:255 -1:255 29 0] [0x2 2 2 [0 0] [4194305 6]] (REQUEST) >r 162.010718659 _5_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 2 [0 0] [4194305 6]] (REQUEST) >r 162.010718865 _2_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 2 [0 0] [4194305 6]] (REQUEST) >r 162.010718890 _3_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 2 [0 0] [4194305 6]] (REQUEST) >f 162.011660048 _5_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194307:255 -1:255 28 0] [0x2 3 2 [0 0] [4194305 6]] (REQUEST) >r 162.012760623 _4_ RTR --- 0 AODV 48 [0 ffffffff 3 800] ------- [4194307:255 -1:255 28 0] [0x2 3 2 [0 0] [4194305 6]] (REQUEST) >f 162.018789151 _2_ RTR --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194304:255 -1:255 28 0] [0x2 3 2 [0 0] [4194305 6]] (REQUEST) >r 162.019709932 _4_ RTR --- 0 AODV 48 [0 ffffffff 0 800] ------- [4194304:255 -1:255 28 0] [0x2 3 2 [0 0] [4194305 6]] (REQUEST) >s 166.000000000 _3_ AGT --- 1 tcp 40 [0 0 0 0] ------- [4194305:0 0:0 32 0] [0 0] 0 0 >r 166.000000000 _3_ RTR --- 1 tcp 40 [0 0 0 0] ------- [4194305:0 0:0 32 0] [0 0] 0 0 >f 166.000000000 _3_ RTR --- 0 AODV 48 [0 0 0 0] ------- [4194305:255 -1:255 30 0] [0x2 1 3 [0 0] [4194305 8]] (REQUEST) > > --------------000202050107070404050309 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Minh Tam. I replied your mail before christmas but obviously you havn't received it. So now I resend it. Hope it's not too late.




    Hi!

    The trace file shows that the source (mobile node _3_) cannot find the destination (wired node _2_). Since the mobile node cannot find a route to the wired node, I suspect that you're still running AODV and not AODV+.

    So, please make sure that you have followed all the steps in the README file correctly!

    If you still cannot find why AODV is run instead of AODV+, contact me again.

    Regards
    Ali

    minh tam wrote:
    Dear all,
     
    I am a NS2 new user . I really confuse about the format of trace file.
    The attachment is the trace file after doing simulation of example wireless2.tcl( tutorial ) using AODV+ (http://www.telecom.lth.se/Personal/alexh/)
    I've checked with cmu-trace.cc but it doesn't match perfectly.
    Can anyone explain it to me?
     
    Thanks !
     
     


    Yahoo! Personals
    - New people, new possibilities. FREE for a limited time! 
    
M 0.0 nn 3 x 670 y 670 rp  AODV
M 0.0 sc ../mobility/scene/scen-3-test cp none seed 0.0
M 0.0 prop Propagation/TwoRayGround ant Antenna/OmniAntenna
M 33.00000 4194305 (83.36, 239.44, 0.00), (89.66, 283.49), 19.15
M 50.00000 4194307 (591.26, 199.37, 0.00), (369.46, 170.52), 3.37
M 51.00000 4194306 (257.05, 345.36, 0.00), (221.83, 80.86), 14.91
s 160.000000000 _3_ AGT  --- 0 tcp 40 [0 0 0 0] ------- [4194305:0 0:0 32 0] [0 0] 0 0
r 160.000000000 _3_ RTR  --- 0 tcp 40 [0 0 0 0] ------- [4194305:0 0:0 32 0] [0 0] 0 0
f 160.000000000 _3_ RTR  --- 0 AODV 48 [0 0 0 0] ------- [4194305:255 -1:255 30 0] [0x2 1 1 [0 0] [4194305 4]] (REQUEST)
r 160.001200806 _4_ RTR  --- 0 AODV 48 [0 ffffffff 1 800] ------- [4194305:255 -1:255 30 0] [0x2 1 1 [0 0] [4194305 4]] (REQUEST)
f 160.009192361 _4_ RTR  --- 0 AODV 48 [0 ffffffff 1 800] ------- [4194306:255 -1:255 29 0] [0x2 2 1 [0 0] [4194305 4]] (REQUEST)
r 160.010252937 _5_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 1 [0 0] [4194305 4]] (REQUEST)
r 160.010253143 _2_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 1 [0 0] [4194305 4]] (REQUEST)
r 160.010253167 _3_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 1 [0 0] [4194305 4]] (REQUEST)
f 160.012598954 _5_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194307:255 -1:255 28 0] [0x2 3 1 [0 0] [4194305 4]] (REQUEST)
r 160.013759530 _4_ RTR  --- 0 AODV 48 [0 ffffffff 3 800] ------- [4194307:255 -1:255 28 0] [0x2 3 1 [0 0] [4194305 4]] (REQUEST)
f 160.016641794 _2_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194304:255 -1:255 28 0] [0x2 3 1 [0 0] [4194305 4]] (REQUEST)
r 160.017582576 _4_ RTR  --- 0 AODV 48 [0 ffffffff 0 800] ------- [4194304:255 -1:255 28 0] [0x2 3 1 [0 0] [4194305 4]] (REQUEST)
f 162.000000000 _3_ RTR  --- 0 AODV 48 [0 0 0 0] ------- [4194305:255 -1:255 30 0] [0x2 1 2 [0 0] [4194305 6]] (REQUEST)
r 162.001060806 _4_ RTR  --- 0 AODV 48 [0 ffffffff 1 800] ------- [4194305:255 -1:255 30 0] [0x2 1 2 [0 0] [4194305 6]] (REQUEST)
f 162.009658083 _4_ RTR  --- 0 AODV 48 [0 ffffffff 1 800] ------- [4194306:255 -1:255 29 0] [0x2 2 2 [0 0] [4194305 6]] (REQUEST)
r 162.010718659 _5_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 2 [0 0] [4194305 6]] (REQUEST)
r 162.010718865 _2_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 2 [0 0] [4194305 6]] (REQUEST)
r 162.010718890 _3_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194306:255 -1:255 29 0] [0x2 2 2 [0 0] [4194305 6]] (REQUEST)
f 162.011660048 _5_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194307:255 -1:255 28 0] [0x2 3 2 [0 0] [4194305 6]] (REQUEST)
r 162.012760623 _4_ RTR  --- 0 AODV 48 [0 ffffffff 3 800] ------- [4194307:255 -1:255 28 0] [0x2 3 2 [0 0] [4194305 6]] (REQUEST)
f 162.018789151 _2_ RTR  --- 0 AODV 48 [0 ffffffff 2 800] ------- [4194304:255 -1:255 28 0] [0x2 3 2 [0 0] [4194305 6]] (REQUEST)
r 162.019709932 _4_ RTR  --- 0 AODV 48 [0 ffffffff 0 800] ------- [4194304:255 -1:255 28 0] [0x2 3 2 [0 0] [4194305 6]] (REQUEST)
s 166.000000000 _3_ AGT  --- 1 tcp 40 [0 0 0 0] ------- [4194305:0 0:0 32 0] [0 0] 0 0
r 166.000000000 _3_ RTR  --- 1 tcp 40 [0 0 0 0] ------- [4194305:0 0:0 32 0] [0 0] 0 0
f 166.000000000 _3_ RTR  --- 0 AODV 48 [0 0 0 0] ------- [4194305:255 -1:255 30 0] [0x2 1 3 [0 0] [4194305 8]] (REQUEST)
    --------------000202050107070404050309-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:18:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28085 for ; Tue, 30 Mar 2004 18:18:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006Zv-EZ for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248BMoS002434 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 03:11:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynwu-0000ct-IE for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:11:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27205 for ; Thu, 4 Mar 2004 03:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynwq-0003fB-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:11:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynvu-0003SM-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:10:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aynuy-0003Fq-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:09:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynrA-0007et-Tm; Thu, 04 Mar 2004 03:05:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynqO-0007PE-73 for manet@optimus.ietf.org; Thu, 04 Mar 2004 03:04:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26500 for ; Thu, 4 Mar 2004 03:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynq7-00022m-00 for manet@ietf.org; Thu, 04 Mar 2004 03:04:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynp2-0001hf-00 for manet@ietf.org; Thu, 04 Mar 2004 03:03:13 -0500 Received: from mail11.ntu.edu.sg ([155.69.5.163]) by ietf-mx with esmtp (Exim 4.12) id 1Aynnm-00018m-00 for manet@ietf.org; Thu, 04 Mar 2004 03:01:54 -0500 Received: from mail04.ntu.edu.sg ([155.69.5.168]) by mail11.ntu.edu.sg with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Mar 2004 16:01:23 +0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 4 Mar 2004 16:01:21 +0800 Message-ID: <4454557EC101FC47A1DC5DB2C70F0DDEF98D09@mail04.student.main.ntu.edu.sg> Thread-Topic: ZRP Simulation Thread-Index: AcQBvuFv78i+i813Ta2vX8a5D/xqxA== From: "#ZHOU XIAOFENG#" To: X-OriginalArrivalTime: 04 Mar 2004 08:01:23.0347 (UTC) FILETIME=[E2C93E30:01C401BE] Content-Transfer-Encoding: quoted-printable Subject: [manet] ZRP Simulation 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi,Justin I followed your advice and recompile the WHOLE of glomosim. but the problem seems more serious: after "Make", the error is: Failed linking = '../bin/glomosim',namely,there is no Executable file "glomosim" in the = directory "/bin" and another error is about the zrp: cause I replace the zrp.pc and zrp.h = in "/glomosim-2.03/glomosim/network",in the indication of "make failure" = there is a sentence"implicit declaration of function = 'NetworkIpSetMacLayerStatusEventHandlerFunction'. So,the problem is I can't use the executable file"glomosim" any more. Could you help me with this problem? Thank you very much! ________________________________ From: Justin Lipman [mailto:justin@titr.uow.edu.au] Sent: 2004-3-4 (=D0=C7=C6=DA=CB=C4) 13:17 To: #ZHOU XIAOFENG# Subject: Re: [manet] ZRP simulation Hi Zhou, No, your operation is incorrect. You need to copy the ZRP files to the correct locations as explained in = the documentation. Then you need to "recompile" the WHOLE of glomosim. go to glomosim/main there should be a "Makefile" there... type "make" and it should recompile glomosim. You can not just compile ZRP using pcc. I suggest you read the documentation on Glomosim to see how it works. There is a guide for it at the following location. Look at page 5. http://www.ida.liu.se/~TGTU09/mobnetwork/lab_mobile/Glomosim_Short_Manual= .pdf Hope this helps, Justin On Thu, 4 Mar 2004 04:02 pm, you wrote: > Hi,thank you for your advice. > Maybe the error exists my operation. > I want compile the zrp.pc, using the command "pcc -c zrp.pc",is it = right? > > Maybe the version of gcc has no relation with the errors. > there is an interesting phenomena: when I set PATH in .cshrc, adding = the > /home/glomosim-2.03/glomosim/include and /main, the compiling result = is > same; while if I change the source code of ZRP, such as add the path = of > each include head file, the errors reduced. I don't know what's the = reason, > could you explain it to me? > Thank you very much. > > ________________________________ > > From: Justin Lipman [mailto:justin@titr.uow.edu.au] > Sent: 2004-3-4 (=D0=C7=C6=DA=CB=C4) 11:42 > To: #ZHOU XIAOFENG#; manet@ietf.org > Subject: Re: [manet] ZRP simulation > > > > Hi Zhou, > > Sounds like you have a problem with the version of gcc that is being = used. > I havent tried compiling ZRP in GlomoSim, but your description of the > errors sounds familiar to the problem I had when using the incorrect > version of gcc. > > at your unix prompt type gcc -v > if you have any other version of gcc other than gcc-2.95 then you will = have > this problem. > > You might also want to limit these types of questions to the GlomoSim > mailing lists... if they still exist... > > hope this helps, > Justin > > On Thu, 4 Mar 2004 01:22 pm, #ZHOU XIAOFENG# wrote: > > Hi,all > > I have download the source code of ZRP in Glomosim from > > http://wnl.ece.cornell.edu/wnlprojects.html and I untar the = compressed > > package release the zrp.h and zrp.pc > > then copy these two files into the /glomosim-2.03/glomosim/network = to > > overwrite the existed files with same name. then delete the files = zrp.o > > and zrp.pi the next step is compile zrp.pc to produce .pi and .o = files, > > but when I compile the zrp.pc, there are some errors: such as all of = the > > include files in the source code of zrp.pc. > > > > Could anybody tell me the reason? and how to tackle it. > > or could you tell me how to perform the simulation of zrp > > Thank you very much! > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > -- > Research Associate > Smart Internet Technology Cooperative Research Centre > http://www.titr.uow.edu.au/~justin -- Research Associate Smart Internet Technology Cooperative Research Centre http://www.titr.uow.edu.au/~justin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:19:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28183 for ; Tue, 30 Mar 2004 18:19:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006a4-E3 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248g396015279 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 03:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoQV-0003xc-1c for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:41:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29551 for ; Thu, 4 Mar 2004 03:41:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoQS-0002bp-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:41:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoOO-0001ve-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:39:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyoM1-0001KU-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 03:37:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoLm-0002qF-Pi; Thu, 04 Mar 2004 03:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoL5-0002mm-Bn for manet@optimus.ietf.org; Thu, 04 Mar 2004 03:36:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29043 for ; Thu, 4 Mar 2004 03:36:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoL3-00018i-00 for manet@ietf.org; Thu, 04 Mar 2004 03:36:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoKA-0000zH-00 for manet@ietf.org; Thu, 04 Mar 2004 03:35:23 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyoJY-0000pU-00 for manet@ietf.org; Thu, 04 Mar 2004 03:34:44 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i248bXZr023588 for ; Thu, 4 Mar 2004 09:37:33 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <4046F875.5060707@dpt-info.u-strasbg.fr> Date: Thu, 04 Mar 2004 10:35:49 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] Default Routes References: <61384.217.208.138.149.1078341070.squirrel@ww2.telecom.lth.se> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Anders and Erik, see my comments inline. andersn@telecom.lth.se wrote: >Hello, > >Let me see if I understood the draft correctly. > > > >>However, I have another question. How do you handle "contention" between >>the announcements at the edges of bordering prefix islands? >> >> > >An upstream node chooses a new or different gateway if it is 1 hop closer >than the one it is currently using. > > We have proposed two main approaches : either an ad hoc node periodically chooses the closest gateway (whatever prefix it uses) or it tries to keep its current prefix as long as possible, whatever the distance to the gateway. Note that to do so the node must keep a view of its one-hop neighborhood, in order to check if it still has neighbors that use the same prefix. So a node at the edges of two or more islands will choose its upstream neighbor according to one of these two proposals. > > >>I guess that >>borderline nodes have the ability to select gateway by themselves, but >>that could potentially affect many downstream nodes that previously used >>another prefix. A node could also cut off and isolate islands of nodes >>if it chooses to change prefix/gateway. >> >> > >I think that depends on whether the network is using a reactive or >proactive protocol. If a reactive protocol is used, the routing protocol >is still responsisble for establishing a route to the gateway. In that >case the downstream node would at least not be isolated, it can continue >to use the old gateway. The question is whether the downstream have to >configure a new address when the prefix announced by the upstream node >changes. If that is the case, we might have some problems. As the network >can be very mobile, borderline nodes receiveing announcements about two >different gateways, from two different neighbors, might choose two to >switch back forth between the two gateways. This easily happens when a >node chooses a new gateway when it is 1 hop closer than its current one, >and the network have mobility that causes frequent topology changes. > > > I'm afraid this is not correct. Whatever routing protocol, the ad hoc node MUST use its upstream neighbor as next hop to the gateway (otherwise prefix continuity is not guaranteed, and because packets have no routing header they could end-up at another gateway). You are right when you say that a change of prefix at a given node can trigger a change in prefix at all "downstream" nodes. It of course depends on the algorithm used (distance or prefix stability), the topology, the mobility etc ... I am doing some simulations in order to evaluate the impact of a change, I hope to be able to submit a paper for publication very soon. Also not that changes of address are expected to be handled by MIPv6 to maintain connectivity at the transport layer. So the address obtained in the ad hoc network is a care-of address. >>What are the convergence times >>for situations like that? Is it desirable that borderline nodes could >>have such a big effect on lots of downstream nodes? >> >> >> > >I do not think the convergence time is that big, as nodes "almost >immediately" rebroadcasts the message. Before updating it. However, if >nodes have to configure a new address upon receipt of the announcement, >the result can be very bad. I have simulated this, and it helps a lot if >the condition to switch is increased to 2 hops, but that would of course >create non optimal routes. > >I am not sure if the draft actually says that nodes should reconfigure a >new address when your upstream tells you to. If that is so, I am not so >sure that is a wise thing to do. Christophe, please correct me if anything >I say here is wrong. > >/Anders > > > Convergence is indeed very quick, because when there is change of prefix all "downstream" nodes are impacted almost immediately (the time it takes for control packets to propagate). Christophe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:20:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28644 for ; Tue, 30 Mar 2004 18:20:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006Zv-3s for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2497Vkh028650 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 04:07:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyopG-0007Ry-GY for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 04:07:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01753 for ; Thu, 4 Mar 2004 04:07:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyopD-0000sM-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:07:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyooH-0000ff-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:06:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyonZ-0000UF-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:05:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayomv-0006vz-1q; Thu, 04 Mar 2004 04:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyomI-0006uQ-I6 for manet@optimus.ietf.org; Thu, 04 Mar 2004 04:04:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01622 for ; Thu, 4 Mar 2004 04:04:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyomF-0000Fy-00 for manet@ietf.org; Thu, 04 Mar 2004 04:04:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyolL-000048-00 for manet@ietf.org; Thu, 04 Mar 2004 04:03:28 -0500 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AyokN-0007dj-00 for manet@ietf.org; Thu, 04 Mar 2004 04:02:28 -0500 Received: from dpt-info.u-strasbg.fr (patinet.u-strasbg.fr [130.79.90.172]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id i2495HZr024523 for ; Thu, 4 Mar 2004 10:05:18 +0100 (CET) (envelope-from jelger@dpt-info.u-strasbg.fr) Message-ID: <4046FEF5.5070607@dpt-info.u-strasbg.fr> Date: Thu, 04 Mar 2004 11:03:33 +0100 From: Christophe Jelger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 X-Accept-Language: en MIME-Version: 1.0 To: "'manet'" Subject: Re: [manet] Default Routes References: <000201c401a8$74d0c8f0$ef70fe81@jafymobile> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please see my comments inline. HyunWook Cha wrote: >Hello, Christophe. > >Please see my inline comments. > > > >>-----Original Message----- >>From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On >>Behalf Of Christophe Jelger >>Sent: Wednesday, March 03, 2004 10:19 PM >>To: manet >>Subject: Re: [manet] Default Routes >> >> >> >>Anders, >> >>The difference with pure flooding is that an ad hoc does not >>forward the >>information if it does not use it. With this very simple rule prefix >>continuity is possible. >> >>We did not want to add a default route for reactive protocols >>because : >>1. If there is a default route, how can the protocol be reactive ? >>(there is always a match in the routing table for any destination) >> >> > >Why not? It depends on the condition on which route discovery should be >triggered based. We can give more stric constraint like this to reactive >routing protocol. If a valid route entry which is not a default route >is not found, peform route discovery. Otherwise, another way is >presented in my draft(and somewhere in other draft). If default route is >available according to source address, do not "route discovery" and just >forward using the default route. And later, prefix route(/n) >entry from solicited/unsolicited gateway advertisement is found, packets >are forwarded using the prefix route and perform route discovery. -> >"route optimization". I think that this approach is also >reacive(on-demand). > > > OK you are right, one could find some rules in order to use a default route. However this is slightly contradictory with the basic routing approach : there is a route, therefore I use it ! ;-) I think this is something that is maybe more related to routing, so people of AODV and DSR are better placed to decide whether they want to do something like that or not. I don't really bother, I just prefered not to do so. (more below) >>2. If there is no default route, the gateway can reply to REQ for >>destinations that are outside the Internet. Of course if we want to >>guarantee that all nodes on the path to the gateway share the same >>prefix, we cannot use the route obtained via the reactive >>protol. Each node must send the packet to the neighbor from which it >> >> >got > > >>its prefix. I'm sure how this could be specified within the operation >> >> >of > > >>a reactive protocol. >> >>Christophe >> >> >> > >I remember that we have discussed about this. Could you elaborate on >this? > >More question. When current default route(path) which share same prefix >breaks, how can this fact is informed to downstream nodes immediately? >By RERR for the corresponding gateway? As I mentioned several times >before, it is not guaranteed that route informaition(next hop of the gw) >obtained by routing protocol is same as upstream neighbor of the default >route. > If there is a break, downstream nodes are not informed in an active way. They have a timer associated with the upstream neighbor entry. If it does not send updated information within a short period of time (we chose a default value of 3*2 seconds, 2 seconds being the period at which this information should be updated), the entry is removed, and the node chooses a new upstream neighbor. Maybe we could use a more clever mechanism to detect link breaks, but in this case there is a probability to detect "false" breaks. >Thus, RERR for the gateway may not be issued. If different >neighbor node advertising same prefix is available, you can switch this >node as new upstream node. However, If not, (It may take a few seconds >to recognize this.) the node should change its address with one with >different prefix. In recuresively, all downstream nodes will change >their addresses if they are arranged in a line. Total delays are >incremented node by node until leaf node will recognize breakage of the >default route. > >I have a question which has not been asked before. In your draft, how >can a gateway determine that a global address affiliated to its prefix >is owned by a MANET node or not? A gateway can do this because it should >issue ICMP destination unreachable for addresses which are not used any >more by MANET nodes and perform route discovery for addresses which are >used by MANET nodes. In other drafts including Wakikawa's, Pekka's, and >mine, a node updates its address lifetime as well as reachability from a >gateway through periodic RREQ/RREP exchange. > >Regards, > >HyunWook > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:22:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29216 for ; Tue, 30 Mar 2004 18:22:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006WI-Ka for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A7cfPe012365 for manet-archive@odin.ietf.org; Tue, 10 Feb 2004 02:38:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSTf-0003DB-Uz for manet-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 02:38:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04013 for ; Tue, 10 Feb 2004 02:38:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSTc-0003bO-00 for manet-web-archive@ietf.org; Tue, 10 Feb 2004 02:38:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSSf-0003WA-00 for manet-web-archive@ietf.org; Tue, 10 Feb 2004 02:37:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqSSB-0003RW-00 for manet-web-archive@ietf.org; Tue, 10 Feb 2004 02:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSS5-0002lA-PU; Tue, 10 Feb 2004 02:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSRk-0002jh-Ke for manet@optimus.ietf.org; Tue, 10 Feb 2004 02:36:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03985 for ; Tue, 10 Feb 2004 02:36:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqSRg-0003R2-00 for manet@ietf.org; Tue, 10 Feb 2004 02:36:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqSQm-0003Mi-00 for manet@ietf.org; Tue, 10 Feb 2004 02:35:41 -0500 Received: from venus.uos.ac.kr ([203.249.110.25]) by ietf-mx with esmtp (Exim 4.12) id 1AqSPz-0003D3-00 for manet@ietf.org; Tue, 10 Feb 2004 02:34:51 -0500 Received: from LocalHost (blhole.uos.ac.kr [203.249.110.30]) (authenticated bits=0) by venus.uos.ac.kr (8.12.3/8.12.3/Debian -4) with ESMTP id i1A7YCUb018771 for ; Tue, 10 Feb 2004 16:34:13 +0900 Message-Id: <200402100734.i1A7YCUb018771@venus.uos.ac.kr> From: "Youngmin Kim" To: Date: Tue, 10 Feb 2004 16:32:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: AcPvp/vNfMdQ34ooQICmiGgFwQpolQ== Content-Transfer-Encoding: 7bit Subject: [manet] Ad hoc mode in IEEE 802.11b 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There are 2 or 3 modes available in IEEE 802.11b wireless LAN. 1. ad hoc mode 2. infrastructure mode 3. AP mode I don't find a part referring to these modes in IEEE 802.11(b) std. What is "ad hoc mode" from the viewpoint of 802.11? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:22:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29471 for ; Tue, 30 Mar 2004 18:22:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006ZK-Ka for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QLQMJC021284 for manet-archive@odin.ietf.org; Thu, 26 Feb 2004 16:26:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwT1S-0005XD-AG for manet-web-archive@optimus.ietf.org; Thu, 26 Feb 2004 16:26:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10170 for ; Thu, 26 Feb 2004 16:26:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwT1Q-0007cl-00 for manet-web-archive@ietf.org; Thu, 26 Feb 2004 16:26:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwT0S-0007SU-00 for manet-web-archive@ietf.org; Thu, 26 Feb 2004 16:25:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AwSzc-0007IT-00 for manet-web-archive@ietf.org; Thu, 26 Feb 2004 16:24:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwSzO-0004aD-4H; Thu, 26 Feb 2004 16:24:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwSGO-0001h2-60 for manet@optimus.ietf.org; Thu, 26 Feb 2004 15:37:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08672 for ; Thu, 26 Feb 2004 15:37:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwSGM-0002oy-00 for manet@ietf.org; Thu, 26 Feb 2004 15:37:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwSFO-0002f5-00 for manet@ietf.org; Thu, 26 Feb 2004 15:36:43 -0500 Received: from che.ojctech.com ([209.254.133.74]) by ietf-mx with esmtp (Exim 4.12) id 1AwSER-0002Sa-00 for manet@ietf.org; Thu, 26 Feb 2004 15:35:43 -0500 Received: from che.ojctech.com (localhost [127.0.0.1]) by che.ojctech.com (8.12.8/8.12.8) with ESMTP id i1QKZCRG019822 for ; Thu, 26 Feb 2004 14:35:12 -0600 Received: (from dyoung@localhost) by che.ojctech.com (8.12.8/8.12.8/Submit) id i1QKZCln019820 for manet@ietf.org; Thu, 26 Feb 2004 14:35:12 -0600 Date: Thu, 26 Feb 2004 14:35:12 -0600 From: David Young To: manet@ietf.org Message-ID: <20040226203512.GD17009@che.ojctech.com> Mail-Followup-To: manet@ietf.org References: <40369ED3.9020603@olsr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40369ED3.9020603@olsr.org> User-Agent: Mutt/1.4.1i Subject: [manet] hello protocols inappropriate for link sensing? 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 The discussion of OLSR link hysteresis & OLSR hello protocol reminds me of my misgivings about using hello protocols for link-sensing. My experience with the OSPF Hello protocol on 802.11b networks has been that it is not effective for link sensing. The multicast Hello packets get "clobbered" (to use the technical term) by the unicast packets. Routes are quite stable until the network sees prolonged unicast traffic. For example, during an FTP download, hellos do not get through, and OSPF detects that links are down in spite of their ability to bear traffic. My network is static, so I "solved" the problem by raising the OSPF Dead Interval. That is no solution for a mobile network. Note that in my example, the FTP stream will produce ample evidence of the link's bearing ability, if only OSPF will "eavesdrop" on it. It will depend on the link layer whether or not hello messages help fulfill the link-sensing role, so I question whether it is appropriate for a layer-3 routing protocol to define link-sensing as a role for the hello protocol. It seems that a layer-3 routing protocol should define an abstract link-sensing module, only. A link-sensing module will provide link indications (up/down, percentage BER/PER, S/N, "goodness") to a routing module (OLSR, AODV, whatever). A routing module can assist the link-sensing module by registering as a beacon-producing/expecting agent. In Java-like pseudocode, the abstract interface might look like this abstract class link_sense_listener { link_sense(neighbor, link_quality); } abstract class link_sense_module { registration register_listener(link_sense_listener listener); unregister_listener(registration r); registration register_beacon(integer interval, integer jitter, integer pkt_length, boolean does_produce, boolean does_expect); unregister_beacon(registration r); } class router extends link_sense_listener { registration link_listen_registration, beacon_registration; link_sense(neighbor n, link_quality q) { /* update link database here */ } router constructor(ip_address my_ip, integer hello_rate, link_sense_module lm) { self.link_listen_registration = lm.register_listener(self); self.beacon_registration = lm.register_beacon(hello_rate, .1 * hello_rate, 128, true, true); } } Thoughts? 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 exim@www1.ietf.org Tue Mar 30 18:23:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29575 for ; Tue, 30 Mar 2004 18:23:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjP-0006WI-4h for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MHWiNa020588 for manet-archive@odin.ietf.org; Mon, 22 Mar 2004 12:32:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TI2-0005Ls-2j for manet-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 12:32:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07700 for ; Mon, 22 Mar 2004 12:32:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5TI0-0000ZY-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 12:32:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5THA-0000SZ-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 12:31:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5TGX-0000MN-00 for manet-web-archive@ietf.org; Mon, 22 Mar 2004 12:31:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TGR-00058w-2m; Mon, 22 Mar 2004 12:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TG6-00057q-GO for manet@optimus.ietf.org; Mon, 22 Mar 2004 12:30:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07602 for ; Mon, 22 Mar 2004 12:30:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5TG4-0000L5-00 for manet@ietf.org; Mon, 22 Mar 2004 12:30:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5TF9-0000FV-00 for manet@ietf.org; Mon, 22 Mar 2004 12:29:44 -0500 Received: from smtp003.bizmail.yahoo.com ([216.136.130.195]) by ietf-mx with smtp (Exim 4.12) id 1B5TEW-00009h-00 for manet@ietf.org; Mon, 22 Mar 2004 12:29:04 -0500 Received: from unknown (HELO truck1) (akucheria@metricsystems.com@67.89.211.170 with plain) by smtp003.bizmail.yahoo.com with SMTP; 22 Mar 2004 17:28:59 -0000 Subject: Re: [manet] Association in IBSS? From: Amit Kucheria To: gawlin Cc: IETF Manet In-Reply-To: <003901c40e7f$e10bd120$8b000b0a@gawlin> References: <003901c40e7f$e10bd120$8b000b0a@gawlin> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-abnUlMO9EpySfnolI4/V" Organization: Metric Systems Corporation Message-Id: <1079976460.1159.1.camel@amit.metricsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Date: 22 Mar 2004 09:27:40 -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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --=-abnUlMO9EpySfnolI4/V Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2004-03-20 at 05:33, gawlin wrote: > Hi, >=20 > I'd like to ask if there exists association process in IBSS mode in 802.1= 1? >=20 > 802.11 specification says that only STA services applay to an IBSS and > association belongs to distribution system services, so it seems thet in > IBSS there shouldn't be association. I want to make sure if I'm right. >=20 > Thanks > M. Gawlinski You are right. A node joining an IBSS will simply 'adopt' the parameters of the IBSS such as beacon interval and then participate in the distributed beacon generation algorithm. Regards, Amit --=20 .| Amit Kucheria |. ...| Wireless Systems Engineer |... .....| Metric Systems Corp., San Diego, CA |..... ......| www.metricsystems.com |...... --=-abnUlMO9EpySfnolI4/V Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBAXyIMtLg6PvU36DYRAqfeAKCxWA/joacO2708f2yePyNLVNO5VQCfTPyU Mhg/cJGIWFPGrqZ/RDB5N0A= =GH4W -----END PGP SIGNATURE----- --=-abnUlMO9EpySfnolI4/V-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:28:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00824 for ; Tue, 30 Mar 2004 18:28:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjN-0006WI-2e for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H7cOgQ001292 for manet-archive@odin.ietf.org; Wed, 17 Mar 2004 02:38:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Vd9-0000KT-Lk for manet-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 02:38:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22839 for ; Wed, 17 Mar 2004 02:38:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vd5-0002km-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 02:38:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3VcF-0002ed-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 02:37:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Vbv-0002YH-00 for manet-web-archive@ietf.org; Wed, 17 Mar 2004 02:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VbJ-00087y-Ky; Wed, 17 Mar 2004 02:36:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3VaA-00080V-7v for manet@optimus.ietf.org; Wed, 17 Mar 2004 02:35:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21080 for ; Wed, 17 Mar 2004 02:35:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Va6-0002NC-00 for manet@ietf.org; Wed, 17 Mar 2004 02:35:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3VZ8-0002Fs-00 for manet@ietf.org; Wed, 17 Mar 2004 02:34:15 -0500 Received: from bay8-f3.bay8.hotmail.com ([64.4.27.3] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1B3VYD-00024t-00 for manet@ietf.org; Wed, 17 Mar 2004 02:33:17 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Mar 2004 23:32:47 -0800 Received: from 155.69.5.123 by by8fd.bay8.hotmail.msn.com with HTTP; Wed, 17 Mar 2004 07:32:46 GMT X-Originating-IP: [155.69.5.123] X-Originating-Email: [liugenping@hotmail.com] X-Sender: liugenping@hotmail.com From: "genping liu" To: manet@ietf.org Date: Wed, 17 Mar 2004 15:32:46 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Mar 2004 07:32:47.0190 (UTC) FILETIME=[0B3F3760:01C40BF2] Subject: [manet] Local Recovery of AODV 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 hi, I was using ns2.1b8a to simulate of the peformance of AODV with and without local recovery. it is expected that AODV with local recovery should outperform AODV without. however, our simulation results shows that the local recovery decreased the performance of AODV. our simulation scenario is map of 2000mx1600m, node number=100, transmission range of 350, random way point with medium mobility. anyone know that reason that local recovery decreased the performance of AODV? Thanks Rdgs Genping _________________________________________________________________ Keep track of Singapore & Malaysia stock prices. http://www.msn.com.sg/money/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:29:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01133 for ; Tue, 30 Mar 2004 18:29:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjL-0006WI-7A for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N7r5Pp029779 for manet-archive@odin.ietf.org; Mon, 23 Feb 2004 02:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvAtk-0007kE-P2 for manet-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 02:53:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12233 for ; Mon, 23 Feb 2004 02:53:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvAtg-0002T6-00 for manet-web-archive@ietf.org; Mon, 23 Feb 2004 02:53:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvAsn-0002Ow-00 for manet-web-archive@ietf.org; Mon, 23 Feb 2004 02:52:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvAs2-0002LV-00 for manet-web-archive@ietf.org; Mon, 23 Feb 2004 02:51:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvArp-0007Rg-IC; Mon, 23 Feb 2004 02:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvAqu-0007ND-Rk for manet@optimus.ietf.org; Mon, 23 Feb 2004 02:50:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12165 for ; Mon, 23 Feb 2004 02:50:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvAqr-0002Gs-00 for manet@ietf.org; Mon, 23 Feb 2004 02:50:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvApy-0002DY-00 for manet@ietf.org; Mon, 23 Feb 2004 02:49:10 -0500 Received: from web8301.mail.in.yahoo.com ([203.199.122.31]) by ietf-mx with smtp (Exim 4.12) id 1AvApK-00028T-00 for manet@ietf.org; Mon, 23 Feb 2004 02:48:31 -0500 Message-ID: <20040223074759.93535.qmail@web8301.mail.in.yahoo.com> Received: from [202.141.69.9] by web8301.mail.in.yahoo.com via HTTP; Mon, 23 Feb 2004 07:47:59 GMT Date: Mon, 23 Feb 2004 07:47:59 +0000 (GMT) From: =?iso-8859-1?q?Ash=20Mohammad=20Abbas?= Subject: Re: [manet] Size of Traces To: Karun Verma , 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, FROM_HAS_ULINE_NUMS,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit The number of connections is too high, it should also be around 10. Abbas --- Karun Verma wrote: > Hello everybody, > > After reading ur views on the size of tora traces > due to high mobility. i > have reduced the mobility to 10m/s but increased the > number of connections > during simulation time which is 200 sec and 200 > connections in between. used > cbrgen.tcl fro generating the traffic. now the > traces are coming with size > more than 300MB. Please also suggest me another > script for generating > traffic automatically for the simulation > environment. > > Thanx in Advance > > ############################################ > > # Karun Verma > > # > > ########################################### > > _________________________________________________________________ > Contact brides & grooms FREE! > http://www.shaadi.com/ptnr.php?ptnr=hmltag > Only on www.shaadi.com. Register now! > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet ===== Ash Mohammad Abbashttp://www.cse.iitd.ernet.in/~abbas ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:30:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01196 for ; Tue, 30 Mar 2004 18:30:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjL-0006a4-N6 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i259RC48030746 for manet-archive@odin.ietf.org; Fri, 5 Mar 2004 04:27:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBbl-0007pu-QF for manet-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 04:27:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27830 for ; Fri, 5 Mar 2004 04:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzBbQ-0001T2-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 04:26:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzBaR-0001DO-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 04:25:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzBZL-0000yn-00 for manet-web-archive@ietf.org; Fri, 05 Mar 2004 04:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzBZ7-00073n-4W; Fri, 05 Mar 2004 04:24:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzAZD-0000q6-Hl for manet@optimus.ietf.org; Fri, 05 Mar 2004 03:20:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25589 for ; Fri, 5 Mar 2004 03:20:21 -0500 (EST) From: Duc.Tran@notes.udayton.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzAZB-0003b1-00 for manet@ietf.org; Fri, 05 Mar 2004 03:20:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzAYR-0003Qi-00 for manet@ietf.org; Fri, 05 Mar 2004 03:19:36 -0500 Received: from facstaff03.udayton.edu ([131.238.75.127]) by ietf-mx with esmtp (Exim 4.12) id 1AzAXi-0003F1-00 for manet@ietf.org; Fri, 05 Mar 2004 03:18:50 -0500 In-Reply-To: <000001c4027a$e6157c90$ae70fe81@jafywinxp> To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 Message-ID: Date: Fri, 5 Mar 2004 03:18:43 -0500 X-MIMETrack: Serialize by Router on FacStaff03/SVR/UDayton(Release 6.0.3|September 26, 2003) at 03/05/2004 03:18:52 AM, Serialize complete at 03/05/2004 03:18:52 AM Content-Type: multipart/alternative; boundary="=_alternative 002D9F1E85256E4E_=" Subject: [manet] updated CFP: Multimedia Streaming 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 This is a multipart message in MIME format. --=_alternative 002D9F1E85256E4E_= Content-Type: text/plain; charset="US-ASCII" CALL FOR PAPERS Complete CFP at http://academic.udayton.edu/DucTran/research/dms2004.htm Special Session on MULTIMEDIA STREAMING IN AD HOC NETWORKS at the 2004 International Conference on Distributed Multimedia Systems (DMS '04) Hotel Sofitel, San Francisco Bay, California September 8 - 10, 2004 Important Dates March 31, 2004 Paper submission due June 1, 2004 Notification of acceptance July 1, 2004 Final manuscript due July 1, 2004 Early conference registration due --=_alternative 002D9F1E85256E4E_= Content-Type: text/html; charset="US-ASCII"
    <Apologies if you receive this message multiple times>

    CALL FOR PAPERS

    Complete CFP at http://academic.udayton.edu/DucTran/research/dms2004.htm

    Special Session on MULTIMEDIA STREAMING IN AD HOC NETWORKS
    at the 2004 International Conference on Distributed Multimedia Systems (DMS '04)
    Hotel Sofitel, San Francisco Bay, California
    September 8 - 10, 2004

    Important Dates
       
            March 31, 2004   Paper submission due
               June 1, 2004     Notification of acceptance
               July 1, 2004     Final manuscript due
               July 1, 2004     Early conference registration due

    --=_alternative 002D9F1E85256E4E_=-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:31:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01560 for ; Tue, 30 Mar 2004 18:31:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjJ-0006YH-BM for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B9p25H016501 for manet-archive@odin.ietf.org; Thu, 11 Mar 2004 04:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MqB-0004Ht-OX for manet-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 04:50:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22160 for ; Thu, 11 Mar 2004 04:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Mq7-0004vA-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 04:50:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Mp5-0004iR-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 04:49:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1MoS-0004Wn-00 for manet-web-archive@ietf.org; Thu, 11 Mar 2004 04:49:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1MoI-0003w6-OJ; Thu, 11 Mar 2004 04:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Mni-0003uf-Tp for manet@optimus.ietf.org; Thu, 11 Mar 2004 04:48:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22086 for ; Thu, 11 Mar 2004 04:48:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Mnf-0004Tj-00 for manet@ietf.org; Thu, 11 Mar 2004 04:48:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Mmi-0004LX-00 for manet@ietf.org; Thu, 11 Mar 2004 04:47:24 -0500 Received: from web21111.mail.yahoo.com ([216.136.129.233]) by ietf-mx with smtp (Exim 4.12) id 1B1MmI-0004EF-00 for manet@ietf.org; Thu, 11 Mar 2004 04:46:58 -0500 Message-ID: <20040311094658.37542.qmail@web21111.mail.yahoo.com> Received: from [193.95.33.18] by web21111.mail.yahoo.com via HTTP; Thu, 11 Mar 2004 10:46:58 CET Date: Thu, 11 Mar 2004 10:46:58 +0100 (CET) From: =?iso-8859-1?q?amine=20elabidi?= To: manet@ietf.org In-Reply-To: <20040310170007.25768.51362.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA22087 Subject: [manet] mesh 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I m looking for some references about mesh networks thank you =09 =09 =09 Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout !=20 Cr=E9ez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Dialoguez en direct avec vos amis gr=E2ce =E0 Yahoo! Messenger !T=E9l=E9c= hargez Yahoo! Messenger sur http://fr.messenger.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:32:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01633 for ; Tue, 30 Mar 2004 18:32:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjI-0006WI-Es for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i29K8wEb019707 for manet-archive@odin.ietf.org; Tue, 9 Mar 2004 15:08:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nX8-00057c-7F for manet-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 15:08:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19317 for ; Tue, 9 Mar 2004 15:08:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nX5-00029p-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 15:08:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nWB-0001zQ-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 15:08:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0nVQ-0001og-00 for manet-web-archive@ietf.org; Tue, 09 Mar 2004 15:07:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nVI-0003kv-VB; Tue, 09 Mar 2004 15:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0nVB-0003fN-O1 for manet@optimus.ietf.org; Tue, 09 Mar 2004 15:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19019 for ; Tue, 9 Mar 2004 15:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0nV8-0001ms-00 for manet@ietf.org; Tue, 09 Mar 2004 15:06:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0nUJ-0001d5-00 for manet@ietf.org; Tue, 09 Mar 2004 15:06:04 -0500 Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 1B0nTf-0001Qj-00 for manet@ietf.org; Tue, 09 Mar 2004 15:05:24 -0500 Received: (qmail 24372 invoked by uid 510); 9 Mar 2004 20:04:50 -0000 Date: 9 Mar 2004 20:04:50 -0000 Message-ID: <20040309200450.24371.qmail@webmail31.rediffmail.com> Received: from unknown (202.63.168.34) by rediffmail.com via HTTP; 09 mar 2004 20:04:50 -0000 MIME-Version: 1.0 From: "Punit Ashok Rathod" Reply-To: "Punit Ashok Rathod" To: manet@ietf.org Content-type: multipart/alternative; boundary="Next_1078862690---0-202.54.124.130-24369" Subject: [manet] AODV doubt 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,HTML_20_30, HTML_IMAGE_ONLY_10,HTML_MESSAGE,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 This is a multipart mime message --Next_1078862690---0-202.54.124.130-24369 Content-type: text/html; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

    =0AHi,
    =0A
    =0AThere is a limit in AODV for the max number of RREQ'= s that can be sent by a given node in unit time. The default value of this = limit (RREQ_RATELIMIT) is given as 10 in RFC 3561 [page no 31].
    =0A
    = =0AIs there any logic that goes into determining the RATELIMIT ? If yes the= n what parameters need to be considered to fix up a value for RATELIMIT ? W= ill this value change depending on the implementation scenario ?
    =0A
    = =0A-
    =0APunit=0A

    =0A=0A=0A

    =0A=0A --Next_1078862690---0-202.54.124.130-24369 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=0A=0AThere is a limit in AODV for the max number of RREQ's that can be = sent by a given node in unit time. The default value of this limit (RREQ_RA= TELIMIT) is given as 10 in RFC 3561 [page no 31].=0A=0AIs there any logic t= hat goes into determining the RATELIMIT ? If yes then what parameters need = to be considered to fix up a value for RATELIMIT ? Will this value change d= epending on the implementation scenario ?=0A=0A-=0APunit=0A=0A --Next_1078862690---0-202.54.124.130-24369-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:33:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01918 for ; Tue, 30 Mar 2004 18:33:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjH-0006YH-SX for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALL9L65019105 for manet-archive@odin.ietf.org; Fri, 21 Nov 2003 16:09:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIWn-0004y2-Co for manet-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 16:09:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03050 for ; Fri, 21 Nov 2003 16:09:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIWl-0000vk-00 for manet-web-archive@ietf.org; Fri, 21 Nov 2003 16:09:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANIWk-0000vV-00 for manet-web-archive@ietf.org; Fri, 21 Nov 2003 16:09:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIWV-0004tI-M9; Fri, 21 Nov 2003 16:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIVf-0004ft-VG for manet@optimus.ietf.org; Fri, 21 Nov 2003 16:08:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02997 for ; Fri, 21 Nov 2003 16:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIVe-0000uX-00 for manet@ietf.org; Fri, 21 Nov 2003 16:08:10 -0500 Received: from [128.196.29.23] (helo=tiquini.ece.arizona.edu) by ietf-mx with esmtp (Exim 4.12) id 1ANIVd-0000uT-00 for manet@ietf.org; Fri, 21 Nov 2003 16:08:09 -0500 Received: from tiquini (tiquini [128.196.29.23]) by tiquini.ece.arizona.edu (8.12.10/8.12.10) with ESMTP id hALL5V4S002948 for ; Fri, 21 Nov 2003 14:05:31 -0700 (MST) Received: from DHCP-162.ece.arizona.edu ([150.135.222.162]) by tiquini.ece.arizona.edu (MailMonitor for SMTP v1.2.2 ) ; Fri, 21 Nov 2003 14:05:29 -0700 (MST) Message-ID: <000e01c3b073$8f4b4bf0$a2de8796@ecedom.coem.arizona.edu> Reply-To: "Alaa Muqattash" From: "Alaa Muqattash" To: "'MANET'" References: <000001c3b050$4ad19fb0$67f57b80@IEngr.ad.nmsu.edu> Date: Fri, 21 Nov 2003 14:08:06 -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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [manet] typical values carrier sense threshold ?? 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 would appreciate it if someone can direct me to references (e.g., wireless cards data sheets) that show the carrier sense threshold for a typical 802.11 wireless interface card. Also, it would be great if you know about a reference that talks about how exactly this carrier sense mechanism is designed/implemented. Thanks a lot in advance. Best, Alaa ----- Original Message ----- From: "John Mullen" To: "'Richard Ogier'" Cc: "'MANET'" Sent: Friday, November 21, 2003 9:55 AM Subject: RE: [manet] Question regarding Mobility > Hi Richard, > > You are correct in the matter of non-independent speed, however, I am > unaware of any result that takes this into consideration. In "The > spatial node distribution of the random waypoint mobility model." (1st > German Workshop on Mobile Ad-Hoc Networks (WMAN'02), Ulm, Germany, > 2002.), Christian Bettstetter discusses this problem at length and > develops a couple of approximate distributions. He also performed some > simulations which seem to indicate the approximations are pretty close. > Bettstetter has published more on this topic, so you may want to check > out his web page: > > http://www.lkn.ei.tum.de/~chris/#Publications > > John Mullen > > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of > Richard Ogier > Sent: Friday, November 21, 2003 9:38 AM > To: Philippe Jacquet > Cc: MANET > Subject: Re: [manet] Question regarding Mobility > > > Philippe Jacquet wrote: > > >Yes, Peter, the distribution changes if you introduce mobility and it > >depends on the mobility model. Take the random way point model where > >each node has a distinct a random destination point selected uniformly > >in a square, and each node moves to this destination at constant speed. > > >In this case, the stationary density at point (x,y) (assuming a 1x1 > >square) is *( x* log x+(1-x)*log(1-x))*(y*log y +(1-y)*log(1-y)) which > >differs from uniform density (which is equal to 1 at any point in the > >1x1 square). > > > >Philippe > > > Philippe, > > Your result implies that you can consider the x and y directions > independently. I don't think this is the case, because the speed in the > x direction depends on the (x,y) direction of movement. > I did some calculations, and I think your result assumes that the time > to go from one random point to the next random point is constant (thus, > if the distance between the 2 points is greater, the speed must be > greater). > > Just for fun I tried to derive the steady state distribution in one > dimension for a unit interval [0,1] and got the following result > (assuming constant speed and zero pause time): > > C * x*(1-x) (C is a normalization constant) > > The x*(1-x) term is simply the probability that the point x lies between > two random numbers uniformly distributed in [0,1]. I ran a simulation on > the unit interval [0,1] which confirms this result. In particular, the > probability that the node is near x = 0.25 is 0.75 times the probability > that the node is near x = 0.50. > > Unfortunately, this result cannot be extended to 2 dimensions by taking > the product of this term for the x and y directions, because the x and y > components of the node speed are not independent. > > Richard > > > > >----- Original Message ----- > >From: Peter Pham > >To: MANET > >Sent: Thursday, November 20, 2003 2:03 AM > >Subject: [manet] Question regarding Mobility > > > > > >>Hi all > >>I am interested in modelling ad hoc networks. In the stationary > >>scenario (nodes do not move), I can assume that the mobile nodes are > >>distributed randomly according to Poisson distribution (many assumed > >>so). However, is this assumption still valid under the mobility ? Can > >>anyone give me some advice ? > >> > >>Peter Pham > >> > >> > >> > >>_______________________________________________ > >>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 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:33:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02021 for ; Tue, 30 Mar 2004 18:33:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjG-0006a4-Li for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIA0QSx024630 for manet-archive@odin.ietf.org; Tue, 18 Nov 2003 05:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2ej-0006KJ-87 for manet-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05:00:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12260 for ; Tue, 18 Nov 2003 05:00:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2ef-0001bZ-00 for manet-web-archive@ietf.org; Tue, 18 Nov 2003 05:00:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM2ef-0001bW-00 for manet-web-archive@ietf.org; Tue, 18 Nov 2003 05:00:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2eR-0006Hn-Vy; Tue, 18 Nov 2003 05:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2dy-0006GO-E7 for manet@optimus.ietf.org; Tue, 18 Nov 2003 04:59:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12236 for ; Tue, 18 Nov 2003 04:59:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2dv-0001b7-00 for manet@ietf.org; Tue, 18 Nov 2003 04:59:31 -0500 Received: from csiges9.insa-lyon.fr ([134.214.79.200] helo=mail.insa-lyon.fr) by ietf-mx with esmtp (Exim 4.12) id 1AM2du-0001ax-00 for manet@ietf.org; Tue, 18 Nov 2003 04:59:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.insa-lyon.fr (Postfix) with ESMTP id 55C7F4B4BE; Tue, 18 Nov 2003 10:58:41 +0100 (CET) Received: from [134.214.144.152] (ares-chaudet-1.insa-lyon.fr [134.214.144.152]) by mail.insa-lyon.fr (Postfix) with ESMTP id 7E3374B4F0; Tue, 18 Nov 2003 10:58:39 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: manet@ietf.org From: Claude Chaudet Subject: Re: [manet] Simulating 802.11b and g Date: Tue, 18 Nov 2003 10:59:04 +0100 To: Emmanuel Agu X-Mailer: Apple Mail (2.606) X-Virus-Scanned: by amavisd 0.1 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, That's true, NS (at least version 2.26) simulates 2Mbps 802.11. Nevertheless, you can change this by simply putting in your script the following lines : Mac/802_11 set bandwidth_ 11e6 Mac/802_11 set dataRate_ 11e6 Mac/802_11 set basicRate_ 2e6 This only changes the rate at which data is sent. This can be useful for simulating 802.11b protocol, for which only the physical layer changes. But simulating 802.11a will need at least some timings modifications in the mac/mac-802_11.* files. Concerning the physical layer parameters, I tried to update some parameters based on the specification of an Avaya card. Nevertheless, being no expert in physical layers, I cannot guarantee this will be the exact parameters. Here they are : Phy/WirelessPhy set CPThresh_ 10.0 Phy/WirelessPhy set CSThresh_ 5.011872e-12 Phy/WirelessPhy set RXThresh_ 1.15209e-10 Phy/WirelessPhy set Rb_ 11e6 Phy/WirelessPhy set bandwidth_ 11e6 Phy/WirelessPhy set Pt_ 0.031622777 Phy/WirelessPhy set freq_ 2457e+6 Phy/WirelessPhy set L_ 1.0 Concerning this, I wondered if anyone on this list could provide good values once and for all, so that we can use ns, opnet and any other simulator on the same basis. I am especially interested in the CPThresh parameter, i.e. the signal over noise ratio (in dB) required to understand a frame. I found no value in any NIC specification. I suppose it depends on the physical layer. 10 dB was used for early 802.11, is it still the good value for newer ones ? Claude Chaudet. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:34:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02332 for ; Tue, 30 Mar 2004 18:34:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjG-0006WI-5o for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPHK979008742 for manet-archive@odin.ietf.org; Tue, 25 Nov 2003 12:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgrA-0002Gt-Pv for manet-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 12:20:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28076 for ; Tue, 25 Nov 2003 12:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgr7-0001R1-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 12:20:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgr7-0001Qy-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 12:20:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgr5-0002Co-Ip; Tue, 25 Nov 2003 12:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgqx-0002C8-64 for manet@optimus.ietf.org; Tue, 25 Nov 2003 12:19:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28072 for ; Tue, 25 Nov 2003 12:19:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgqv-0001Qs-00 for manet@ietf.org; Tue, 25 Nov 2003 12:19:53 -0500 Received: from rainer.bnt.com ([12.4.218.18]) by ietf-mx with esmtp (Exim 4.12) id 1AOgqv-0001Qp-00 for manet@ietf.org; Tue, 25 Nov 2003 12:19:53 -0500 Received: from tom ([198.70.230.133]) by rainer.bnt.com (8.12.8p2/8.12.8) with SMTP id hAPHJZsG078302; Tue, 25 Nov 2003 12:19:36 -0500 (EST) (envelope-from taolin@vt.edu) Message-ID: <002501c3b378$5a3e8500$2502a8c0@triplecom.net> From: "Tao Lin" To: "Richard Ogier" , "Philippe Jacquet" Cc: "MANET" References: <3FBC12F3.2010808@spri.levels.unisa.edu.au> <00ab01c3af68$6baa7a60$1f175d80@inria.fr> <3FBE3F54.9000602@erg.sri.com> <024a01c3b35e$45229d60$1f175d80@inria.fr> <3FC38B35.9070004@erg.sri.com> Subject: Re: [manet] Question regarding Mobility Date: Tue, 25 Nov 2003 12:19:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Glad to see the increasing interests in mobility models. Random waypoint model is not a good model from simulation theory point of view since some statistical features may not reach steady state easily. Here are two papers discussing the statistical features in some mobility models. I think the random-walk billiards model and the torus model (wrap-around model) are both discussed in the first one. 1. C. Bettstetter, "Mobility Modeling in Wireless Networks: Categorization, Smooth Movement, and Border Effects," ACM Mobile Computing and Communications Review, Vol. 5, No. 3, pp. 55-67, July 2001. 2. C. Bettstetter and C. Wagner. "The Spatial Node Distribution of the Random WaypointMobilityModel" In Proc. of the 1st GermanWorkshop on Mobile Ad-Hoc Networks, Ulm, Germany, GI Lecture Notes in Informatics, No. P-11, pp. 41-58, March 2002. Thanks, Tao Lin Ph.D. Candidate ECE Department Virginia Tech ----- Original Message ----- From: "Richard Ogier" To: "Philippe Jacquet" Cc: "MANET" Sent: Tuesday, November 25, 2003 12:02 PM Subject: Re: [manet] Question regarding Mobility > Philippe, > > Thanks for computing the formula for the probability density of node > position > for random waypoint. I also started to compute the formula for 2 > dimensions, > but quit when I saw how complicated it is. In actual simulations, to > start out > with the steady state density, it might be easiest to just generate two > random > points in the square and then choose a random point uniformly > distributed on the > line connecting the two points. > > Someone asked me about a proof that the random-walk billiards model results > in uniformly distributed node positions. (This is the model in which a node > moves in a random direction for T seconds, bouncing off boundaries > like a billiards ball, and choosing a new random direction after T seconds.) > I think this is fairly intuitive, by considering what happens if the > node instead > goes straight through the boundary into an equivalent region adjacent to > the original region. But is this result well known? Can anyone point > to a reference for this? > > Richard > > > > Philippe Jacquet wrote: > > >Richard, > > > >My mistake, you are right. I was considering the case where the node reaches > >its way point in a constant time. With a constant speed, zero pause time, > >the density is your result: C (1-x)*x in dimension one. To be forgiven I > >tried to compute the formula for the density in two dimensions. Not really > >fun. For x>y and (1-x)>y it should be proportional to j(x,y)+j(1-x,y) with a > >normalizing factor, with > >j(x,y)=(1-x)*y*(2+log(x/y)-log((1-x)/(1-y))). > > > >For the other cases for (x,y) one makes use of symmetries and finally: > >density(x,y)=C*(j(max(x,y),min(x,y))+j(max(1-x,y),min(1-x,y))) > > > >I made the integration over all angle of the product of the two distances of > >the point (x,y) to the border of the square within a given angle. I used > >Maple. It needs to be cross checked. > >. > > > >The plot looks like a very eroded pyramid: null density on the border and > >top on the square center. The result should be the same when the speed is > >randomly selected on finite distribution. > > > >Best regards, > >Philipe > > > >----- Original Message ----- > >From: Richard Ogier > >To: Philippe Jacquet > >Cc: MANET > >Sent: Friday, November 21, 2003 5:37 PM > >Subject: Re: [manet] Question regarding Mobility > > > > > >>Philippe Jacquet wrote: > >> > >>>Yes, Peter, the distribution changes if you introduce mobility and it > >>>depends on the mobility model. Take the random way point model where each > >>>node has a distinct a random destination point selected uniformly in a > >>>square, and each node moves to this destination at constant speed. In > >>> > >this > > > >>>case, the stationary density at point (x,y) (assuming a 1x1 square) is > >>>*( x* log x+(1-x)*log(1-x))*(y*log y +(1-y)*log(1-y)) which differs from > >>>uniform density (which is equal to 1 at any point in the 1x1 square). > >>> > >>>Philippe > >>> > >>Philippe, > >> > >>Your result implies that you can consider the x and y directions > >>independently. I don't think this is the case, because the speed > >>in the x direction depends on the (x,y) direction of movement. > >>I did some calculations, and I think your result assumes that > >>the time to go from one random point to the next random point > >>is constant (thus, if the distance between the 2 points is > >>greater, the speed must be greater). > >> > >>Just for fun I tried to derive the steady state distribution in one > >>dimension for a unit interval [0,1] and got the following result > >>(assuming constant speed and zero pause time): > >> > >> C * x*(1-x) (C is a normalization constant) > >> > >>The x*(1-x) term is simply the probability that the point x > >>lies between two random numbers uniformly distributed in [0,1]. > >>I ran a simulation on the unit interval [0,1] which confirms this result. > >>In particular, the probability that the node is near x = 0.25 > >>is 0.75 times the probability that the node is near x = 0.50. > >> > >>Unfortunately, this result cannot be extended to 2 dimensions by > >>taking the product of this term for the x and y directions, because > >>the x and y components of the node speed are not independent. > >> > >>Richard > >> > >>>----- Original Message ----- > >>>From: Peter Pham > >>>To: MANET > >>>Sent: Thursday, November 20, 2003 2:03 AM > >>>Subject: [manet] Question regarding Mobility > >>> > >>> > >>>>Hi all > >>>>I am interested in modelling ad hoc networks. In the stationary scenario > >>>>(nodes do not move), I can assume that the mobile nodes are distributed > >>>>randomly according to Poisson distribution (many assumed so). However, > >>>>is this assumption still valid under the mobility ? > >>>>Can anyone give me some advice ? > >>>> > >>>>Peter Pham > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:36:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02599 for ; Tue, 30 Mar 2004 18:36:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjD-0006WI-W4 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPH4lfq002079 for manet-archive@odin.ietf.org; Tue, 25 Nov 2003 12:04:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgcI-0000XS-S2 for manet-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 12:04:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27303 for ; Tue, 25 Nov 2003 12:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgcH-00017I-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 12:04:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgcH-00017D-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 12:04:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgbZ-0000MN-BB; Tue, 25 Nov 2003 12:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgad-0000IU-O1 for manet@optimus.ietf.org; Tue, 25 Nov 2003 12:03:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27181 for ; Tue, 25 Nov 2003 12:02:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgac-00015D-00 for manet@ietf.org; Tue, 25 Nov 2003 12:03:02 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1AOgaa-00014u-00 for manet@ietf.org; Tue, 25 Nov 2003 12:03:01 -0500 Received: from user-2ivfmiq.dialup.mindspring.com ([165.247.218.90] helo=erg.sri.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1AOgaM-0004KU-00; Tue, 25 Nov 2003 09:02:47 -0800 Message-ID: <3FC38B35.9070004@erg.sri.com> Date: Tue, 25 Nov 2003 09:02:45 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202) X-Accept-Language: en-us MIME-Version: 1.0 To: Philippe Jacquet CC: MANET Subject: Re: [manet] Question regarding Mobility References: <3FBC12F3.2010808@spri.levels.unisa.edu.au> <00ab01c3af68$6baa7a60$1f175d80@inria.fr> <3FBE3F54.9000602@erg.sri.com> <024a01c3b35e$45229d60$1f175d80@inria.fr> 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 Philippe, Thanks for computing the formula for the probability density of node position for random waypoint. I also started to compute the formula for 2 dimensions, but quit when I saw how complicated it is. In actual simulations, to start out with the steady state density, it might be easiest to just generate two random points in the square and then choose a random point uniformly distributed on the line connecting the two points. Someone asked me about a proof that the random-walk billiards model results in uniformly distributed node positions. (This is the model in which a node moves in a random direction for T seconds, bouncing off boundaries like a billiards ball, and choosing a new random direction after T seconds.) I think this is fairly intuitive, by considering what happens if the node instead goes straight through the boundary into an equivalent region adjacent to the original region. But is this result well known? Can anyone point to a reference for this? Richard Philippe Jacquet wrote: >Richard, > >My mistake, you are right. I was considering the case where the node reaches >its way point in a constant time. With a constant speed, zero pause time, >the density is your result: C (1-x)*x in dimension one. To be forgiven I >tried to compute the formula for the density in two dimensions. Not really >fun. For x>y and (1-x)>y it should be proportional to j(x,y)+j(1-x,y) with a >normalizing factor, with >j(x,y)=(1-x)*y*(2+log(x/y)-log((1-x)/(1-y))). > >For the other cases for (x,y) one makes use of symmetries and finally: >density(x,y)=C*(j(max(x,y),min(x,y))+j(max(1-x,y),min(1-x,y))) > >I made the integration over all angle of the product of the two distances of >the point (x,y) to the border of the square within a given angle. I used >Maple. It needs to be cross checked. >. > >The plot looks like a very eroded pyramid: null density on the border and >top on the square center. The result should be the same when the speed is >randomly selected on finite distribution. > >Best regards, >Philipe > >----- Original Message ----- >From: Richard Ogier >To: Philippe Jacquet >Cc: MANET >Sent: Friday, November 21, 2003 5:37 PM >Subject: Re: [manet] Question regarding Mobility > > >>Philippe Jacquet wrote: >> >>>Yes, Peter, the distribution changes if you introduce mobility and it >>>depends on the mobility model. Take the random way point model where each >>>node has a distinct a random destination point selected uniformly in a >>>square, and each node moves to this destination at constant speed. In >>> >this > >>>case, the stationary density at point (x,y) (assuming a 1x1 square) is >>>*( x* log x+(1-x)*log(1-x))*(y*log y +(1-y)*log(1-y)) which differs from >>>uniform density (which is equal to 1 at any point in the 1x1 square). >>> >>>Philippe >>> >>Philippe, >> >>Your result implies that you can consider the x and y directions >>independently. I don't think this is the case, because the speed >>in the x direction depends on the (x,y) direction of movement. >>I did some calculations, and I think your result assumes that >>the time to go from one random point to the next random point >>is constant (thus, if the distance between the 2 points is >>greater, the speed must be greater). >> >>Just for fun I tried to derive the steady state distribution in one >>dimension for a unit interval [0,1] and got the following result >>(assuming constant speed and zero pause time): >> >> C * x*(1-x) (C is a normalization constant) >> >>The x*(1-x) term is simply the probability that the point x >>lies between two random numbers uniformly distributed in [0,1]. >>I ran a simulation on the unit interval [0,1] which confirms this result. >>In particular, the probability that the node is near x = 0.25 >>is 0.75 times the probability that the node is near x = 0.50. >> >>Unfortunately, this result cannot be extended to 2 dimensions by >>taking the product of this term for the x and y directions, because >>the x and y components of the node speed are not independent. >> >>Richard >> >>>----- Original Message ----- >>>From: Peter Pham >>>To: MANET >>>Sent: Thursday, November 20, 2003 2:03 AM >>>Subject: [manet] Question regarding Mobility >>> >>> >>>>Hi all >>>>I am interested in modelling ad hoc networks. In the stationary scenario >>>>(nodes do not move), I can assume that the mobile nodes are distributed >>>>randomly according to Poisson distribution (many assumed so). However, >>>>is this assumption still valid under the mobility ? >>>>Can anyone give me some advice ? >>>> >>>>Peter Pham >>>> >>>> >>>> >>>>_______________________________________________ >>>>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 exim@www1.ietf.org Tue Mar 30 18:37:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02942 for ; Tue, 30 Mar 2004 18:37:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjC-0006Yx-Dw for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i147hOp1024249 for manet-archive@odin.ietf.org; Wed, 4 Feb 2004 02:43:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHgv-0006J2-6E for manet-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 02:43:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23606 for ; Wed, 4 Feb 2004 02:43:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHgr-0000AF-00 for manet-web-archive@ietf.org; Wed, 04 Feb 2004 02:43:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHfv-000018-00 for manet-web-archive@ietf.org; Wed, 04 Feb 2004 02:42:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoHex-0007j2-00 for manet-web-archive@ietf.org; Wed, 04 Feb 2004 02:41:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHeo-0005Vx-PT; Wed, 04 Feb 2004 02:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHee-0005TY-HA for manet@optimus.ietf.org; Wed, 04 Feb 2004 02:41:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23513 for ; Wed, 4 Feb 2004 02:40:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHea-0007hL-00 for manet@ietf.org; Wed, 04 Feb 2004 02:40:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHdg-0007cR-00 for manet@ietf.org; Wed, 04 Feb 2004 02:40:01 -0500 Received: from web60603.mail.yahoo.com ([216.109.118.223]) by ietf-mx with smtp (Exim 4.12) id 1AoHdD-0007X5-00 for manet@ietf.org; Wed, 04 Feb 2004 02:39:31 -0500 Message-ID: <20040204073902.7953.qmail@web60603.mail.yahoo.com> Received: from [220.73.165.14] by web60603.mail.yahoo.com via HTTP; Tue, 03 Feb 2004 23:39:02 PST Date: Tue, 3 Feb 2004 23:39:02 -0800 (PST) From: Jaehoon Jeong To: manet@ietf.org Cc: fenner@research.att.com, zinin@psg.com, autonet@ipv6.or.kr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] [Re] Possible no MANET meeting in Seoul 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dear Manet chairs, As you know, for Manet deployment, some services are necessary, such as MANET address autoconf, MANET DNS and Internet connectivity. I think the Industry really wants these services along with MANET unicast routing protocols for manet network products. Since the 57th IETF meeting, we have dicussed these topics actively both at on-site and on-line. In this Seoul meeting, the ADs can handle these three topics shortly for our next steps on site with many interested engineers. Thanks. Regards, Jaehoon Paul Jeong ---------------------------------------------------- From: Joe Macker MANETers: Scott Corson and I (WG chairs) cannot attend the Seoul meeting and are recommended we skip this round and concentrate on firming up next step action items on the mailing list. If enough participants feel there should be a meeting with specific agenda items the ADs could possibly host a short meeting. -Joe __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:37:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03052 for ; Tue, 30 Mar 2004 18:37:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjC-0006WI-Dv for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i147hOpI024255 for manet-archive@odin.ietf.org; Wed, 4 Feb 2004 02:43:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHgv-0006J8-UV for manet-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 02:43:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23609 for ; Wed, 4 Feb 2004 02:43:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHgs-0000AK-00 for manet-web-archive@ietf.org; Wed, 04 Feb 2004 02:43:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHfw-00001G-00 for manet-web-archive@ietf.org; Wed, 04 Feb 2004 02:42:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoHex-0007j3-00 for manet-web-archive@ietf.org; Wed, 04 Feb 2004 02:41:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHej-0005Ui-TA; Wed, 04 Feb 2004 02:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHec-0005TO-Mu for manet@optimus.ietf.org; Wed, 04 Feb 2004 02:40:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23495 for ; Wed, 4 Feb 2004 02:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHeY-0007h3-00 for manet@ietf.org; Wed, 04 Feb 2004 02:40:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHdf-0007c9-00 for manet@ietf.org; Wed, 04 Feb 2004 02:39:59 -0500 Received: from web60603.mail.yahoo.com ([216.109.118.223]) by ietf-mx with smtp (Exim 4.12) id 1AoHd2-0007S6-00 for manet@ietf.org; Wed, 04 Feb 2004 02:39:20 -0500 Message-ID: <20040204073851.7923.qmail@web60603.mail.yahoo.com> Received: from [220.73.165.14] by web60603.mail.yahoo.com via HTTP; Tue, 03 Feb 2004 23:38:51 PST Date: Tue, 3 Feb 2004 23:38:51 -0800 (PST) From: Jaehoon Jeong To: manet@ietf.org Cc: fenner@research.att.com, zinin@psg.com, autonet@ipv6.or.kr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] [Re] Possible no MANET meeting in Seoul 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dear Manet chairs, As you know, for Manet deployment, some services are necessary, such as MANET address autoconf, MANET DNS and Internet connectivity. I think the Industry really wants these services along with MANET unicast routing protocols for manet network products. Since the 57th IETF meeting, we have dicussed these topics actively both at on-site and on-line. In this Seoul meeting, the ADs can handle these three topics shortly for our next steps on site with many interested engineers. Thanks. Regards, Jaehoon Paul Jeong ---------------------------------------------------- From: Joe Macker MANETers: Scott Corson and I (WG chairs) cannot attend the Seoul meeting and are recommended we skip this round and concentrate on firming up next step action items on the mailing list. If enough participants feel there should be a meeting with specific agenda items the ADs could possibly host a short meeting. -Joe __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:37:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03092 for ; Tue, 30 Mar 2004 18:37:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjD-0006ZK-2b for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i147hOsv024261 for manet-archive@odin.ietf.org; Wed, 4 Feb 2004 02:43:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHgw-0006JE-IZ for manet-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 02:43:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23612 for ; Wed, 4 Feb 2004 02:43:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHgs-0000AP-00 for manet-web-archive@ietf.org; Wed, 04 Feb 2004 02:43:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHfx-00001O-00 for manet-web-archive@ietf.org; Wed, 04 Feb 2004 02:42:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoHex-0007j4-00 for manet-web-archive@ietf.org; Wed, 04 Feb 2004 02:41:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHei-0005UW-1w; Wed, 04 Feb 2004 02:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoHec-0005TI-0U for manet@optimus.ietf.org; Wed, 04 Feb 2004 02:40:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23492 for ; Wed, 4 Feb 2004 02:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoHeY-0007gy-00 for manet@ietf.org; Wed, 04 Feb 2004 02:40:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoHde-0007c1-00 for manet@ietf.org; Wed, 04 Feb 2004 02:39:58 -0500 Received: from web60607.mail.yahoo.com ([216.109.118.245]) by ietf-mx with smtp (Exim 4.12) id 1AoHcl-0007S2-00 for manet@ietf.org; Wed, 04 Feb 2004 02:39:03 -0500 Message-ID: <20040204073834.94215.qmail@web60607.mail.yahoo.com> Received: from [220.73.165.14] by web60607.mail.yahoo.com via HTTP; Tue, 03 Feb 2004 23:38:34 PST Date: Tue, 3 Feb 2004 23:38:34 -0800 (PST) From: Jaehoon Jeong To: manet@ietf.org Cc: fenner@research.att.com, zinin@psg.com, autonet@ipv6.or.kr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] [Re] Possible no MANET meeting in Seoul 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dear Manet chairs, As you know, for Manet deployment, some services are necessary, such as MANET address autoconf, MANET DNS and Internet connectivity. I think the Industry really wants these services along with MANET unicast routing protocols for manet network products. Since the 57th IETF meeting, we have dicussed these topics actively both at on-site and on-line. In this Seoul meeting, the ADs can handle these three topics shortly for our next steps on site with many interested engineers. Thanks. Regards, Jaehoon Paul Jeong ---------------------------------------------------- From: Joe Macker MANETers: Scott Corson and I (WG chairs) cannot attend the Seoul meeting and are recommended we skip this round and concentrate on firming up next step action items on the mailing list. If enough participants feel there should be a meeting with specific agenda items the ADs could possibly host a short meeting. -Joe __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:37:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03112 for ; Tue, 30 Mar 2004 18:37:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjC-0006ZK-EX for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFaEVC029742 for manet-archive@odin.ietf.org; Fri, 14 Nov 2003 10:36:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfzZ-0007hx-Ih for manet-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 10:36:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16062 for ; Fri, 14 Nov 2003 10:35:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfzC-0007EN-00 for manet-web-archive@ietf.org; Fri, 14 Nov 2003 10:35:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKfzC-0007DW-00 for manet-web-archive@ietf.org; Fri, 14 Nov 2003 10:35:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfyZ-0007HJ-DP; Fri, 14 Nov 2003 10:35:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfyK-0007AT-3Z for manet@optimus.ietf.org; Fri, 14 Nov 2003 10:34:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16012 for ; Fri, 14 Nov 2003 10:34:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfyH-0007Cj-00 for manet@ietf.org; Fri, 14 Nov 2003 10:34:53 -0500 Received: from blaze.cs.jhu.edu ([128.220.13.50]) by ietf-mx with esmtp (Exim 4.12) id 1AKfyG-0007Cg-00 for manet@ietf.org; Fri, 14 Nov 2003 10:34:52 -0500 Received: from Mercury (pelican.cs.jhu.edu [128.220.13.57]) by blaze.cs.jhu.edu (8.12.9/8.12.9) with ESMTP id hAEFZtrI001834; Fri, 14 Nov 2003 10:35:55 -0500 (EST) Reply-To: From: "David Holmer" To: , "'Miguel Sanchez'" Subject: RE: [Fwd: Re: [manet] Power Saving in 802.11] Date: Fri, 14 Nov 2003 10:34:45 -0500 Organization: Johns Hopkins University Message-ID: <006601c3aac4$d4e3b2b0$e6dddc80@Mercury> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.1165 Importance: Normal In-reply-to: <3FB39896.1070804@disca.upv.es> Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable The several available power levels you are talking about for the Cisco cards (that are discussed in the paper) are the different TRANSMIT power levels. The power levels being discussed in the Intersil document are different levels of SLEEP. While most wireless drivers I've looked at can control transmit power levels, probably even on a per packet basis, I have yet to find a driver that seems to be aware of the multiple sleep levels. The only sleep related settings that seem to be wide spread are related to configuring the built in PSM power saving modes. This is the case in the Atheros drivers as well (transmit power settable, but no sleep power settings beyond PSM). - David Holmer -----Original Message----- From: Miguel Sanchez [mailto:misan@disca.upv.es]=20 Sent: Thursday, November 13, 2003 9:44 AM To: dholmer@cs.jhu.edu Cc: manet@ietf.org; 'Peter Pham' Subject: Re: [Fwd: Re: [manet] Power Saving in 802.11] Hi, You may want to look for tech specs of Aironet Cisco 340 and 350 series adapters. I think 340 allow 4 power levels and 350 six different power levels, software selectable. I haven't researched how long does a power change to become effective though. I think this paper [http://black1.csl.uiuc.edu/~prkumar/ps_files/compow.pdf] uses these cards to adapt transmission power level. They did a real implementation using Linux. I guess the paper will give you some of the details my answer is lacking. Best regards, Miguel S=E1nchez Polytechnic University of Valencia, Spain dholmer wrote: >... > >Now for your other question on how feasible is it to control the power >saving state of an actual NIC card. I haven't had that much experience >with attempting that yet. The real question is if that functionality is >available at the driver level, or if it is only a firmware controlled >feature. A quick search through the Linux open source orinoco driver >(which actually supports many types of cards) yielded no promising leads >for manual power control. However many options for enabling the default >802.11 PSM and tweaking its parameters were available. In a pinch, it >may be possible to switch the card in and out of PSM with very long >beacon intervals, but some in depth experimentation would be necessary >to test this out. > >David Holmer > >PS I had trouble locating a link to the Intersil application note. If it >has been removed, people can email me directly for a copy. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:38:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03204 for ; Tue, 30 Mar 2004 18:38:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjB-0006WI-Ng for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALA8Saa015324 for manet-archive@odin.ietf.org; Fri, 21 Nov 2003 05:08:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8DA-0003z4-J9 for manet-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 05:08:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07961 for ; Fri, 21 Nov 2003 05:08:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8D7-0007T4-00 for manet-web-archive@ietf.org; Fri, 21 Nov 2003 05:08:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN8D6-0007Sz-00 for manet-web-archive@ietf.org; Fri, 21 Nov 2003 05:08:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8Cq-0003uO-KQ; Fri, 21 Nov 2003 05:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN8Bp-0003Yb-Pr for manet@optimus.ietf.org; Fri, 21 Nov 2003 05:07:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07876 for ; Fri, 21 Nov 2003 05:06:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN8Bm-0007RB-00 for manet@ietf.org; Fri, 21 Nov 2003 05:06:58 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1AN8Bl-0007Qv-00 for manet@ietf.org; Fri, 21 Nov 2003 05:06:57 -0500 Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id hALA6I117252; Fri, 21 Nov 2003 11:06:18 +0100 (MET) Message-ID: <007201c3b017$021d0ae0$1f175d80@inria.fr> From: "Philippe Jacquet" To: "Peter Pham" Cc: "MANET" References: <3FBC12F3.2010808@spri.levels.unisa.edu.au> <00ab01c3af68$6baa7a60$1f175d80@inria.fr> <3FBD5847.4040708@spri.levels.unisa.edu.au> Subject: Re: [manet] Question regarding Mobility Date: Fri, 21 Nov 2003 11:05:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 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 Basically I am not aware of publications, these are easy derviations, you can write the proof on the corner of a table... Philippe ----- Original Message ----- From: Peter Pham To: Philippe Jacquet Cc: MANET Sent: Friday, November 21, 2003 1:11 AM Subject: Re: [manet] Question regarding Mobility > Dear Philippe > > I am really intersted in the result. Is there any papers on this that > you can refer to ?...Can you let me know ? > > Cheers > Peter Pham > > Philippe Jacquet wrote: > > >Yes, Peter, the distribution changes if you introduce mobility and it > >depends on the mobility model. Take the random way point model where each > >node has a distinct a random destination point selected uniformly in a > >square, and each node moves to this destination at constant speed. In this > >case, the stationary density at point (x,y) (assuming a 1x1 square) is > >*( x* log x+(1-x)*log(1-x))*(y*log y +(1-y)*log(1-y)) which differs from > >uniform density (which is equal to 1 at any point in the 1x1 square). > > > >Philippe > >----- Original Message ----- > >From: Peter Pham > >To: MANET > >Sent: Thursday, November 20, 2003 2:03 AM > >Subject: [manet] Question regarding Mobility > > > > > > > > > >>Hi all > >>I am interested in modelling ad hoc networks. In the stationary scenario > >>(nodes do not move), I can assume that the mobile nodes are distributed > >>randomly according to Poisson distribution (many assumed so). However, > >>is this assumption still valid under the mobility ? > >>Can anyone give me some advice ? > >> > >>Peter Pham > >> > >> > >> > >>_______________________________________________ > >>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 exim@www1.ietf.org Tue Mar 30 18:39:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21201 for ; Tue, 30 Mar 2004 17:53:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjf-0006YH-BD for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i239hxF0021625 for manet-archive@odin.ietf.org; Wed, 3 Mar 2004 04:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySuy-0005cb-Rz for manet-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 04:43:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14545 for ; Wed, 3 Mar 2004 04:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySu7-00027q-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 04:43:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySsc-0001lH-00 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 04:41:31 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AySry-0001bg-03 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 04:40:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AySlq-00080x-G5 for manet-web-archive@ietf.org; Wed, 03 Mar 2004 04:34:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySlQ-0003bD-Ep; Wed, 03 Mar 2004 04:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySkx-0003Xm-Ni for manet@optimus.ietf.org; Wed, 03 Mar 2004 04:33:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14227 for ; Wed, 3 Mar 2004 04:33:13 -0500 (EST) From: Paal.Engelstad@telenor.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySka-0000Za-00 for manet@ietf.org; Wed, 03 Mar 2004 04:33:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySji-0000RL-00 for manet@ietf.org; Wed, 03 Mar 2004 04:32:19 -0500 Received: from virus-out.ttyl.com ([193.212.240.200] helo=virus-out-st.online.no) by ietf-mx with esmtp (Exim 4.12) id 1AySiv-0000Aa-00 for manet@ietf.org; Wed, 03 Mar 2004 04:31:29 -0500 Received: from tns-fbu-22-208.corp.telenor.no ([134.47.162.90] [134.47.162.90]) by scan.telenor.net with ESMTP; Wed, 3 Mar 2004 10:30:47 +0100 Received: from moffice2.nsc.no ([10.122.115.82]) by tns-fbu-22-208.corp.telenor.no with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Mar 2004 10:30:44 +0100 Message-Id: <12767107.1078306244548.JavaMail.adm-moff@moffice2.nsc.no> To: Ryuji Wakikawa Cc: Cc: Cc: In-Reply-To: X-Priority: 3 (Normal) X-Mailer: Mobile Office v1.0 (Telenor Business Solutions) References: <005301c40025$0235b280$6de325da@jafymobile> X-OriginalArrivalTime: 03 Mar 2004 09:30:44.0552 (UTC) FILETIME=[33E67480:01C40102] Date: 3 Mar 2004 10:30:44 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_701_15886558.1078306244547" Subject: [manet] Default Routes (WAS: Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt) (Intern) 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 ------=_Part_701_15886558.1078306244547 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Ryuji, I think your preferred tunneling method (using the routing header) is good. Using default routes, on the contrary, might lead to problems and should be removed as an option: If you have two gateways announcing the same default route, the MANET node has no control of which gateway the packet is routed out through. You might get problems with: - Stateless firewalls: E.g. The first packet of your (TCP-) session might go out through another gateway than the one corresponding to the selected source IP address. Thus, the return inbound packets will not reach the gateway corresponding to the MANET node's source IP address if the gateway is behind i firewall because no state is set in the firewall. - Ingress filtering: Outbound packets escaping out through "wrong" gateways are filtered out. In addition to this, every time a MANEWT node moves e.g. on an OLSR MANET, until the routing converges, internal packets destined for this node might probably be sent out on the Internet along a default route. In fact, my comment in the WG meetings against the use of default routes was mainly targeted at the possible use of NATs with a IPv4 MANET. Here you have the additional problem that some GWs will probably implement NATs as a gateway enabling technology. But after second thoughts, I think my comment also applies well to IPv6. Paal > From: Ryuji Wakikawa [ryuji@sfc.wide.ad.jp] > Sent: 2004-03-03 07:58:37 CET > To: jafy@etri.re.kr > Cc: manet@ietf.org, autonet@ipv6.or.kr > Subject: Re: [manet] Request of Comments on the i-d ietf-cha-manet-aodv-internet-00.txt > > > I think the first step is MANET WG should make decision whether the WG > includes internet connectivity stuff in manet charter or > not. Otherwise, many similar drafts are submitted without any progress > at IETF. > > BTW, the statement to our global6 is wrong in > draft-cha-manet-aodv-internet. > > You said > [1 global6] which do not use next hop forwarding and require that a > sender specifies a gateway in routing header. > > In appendix D. of global6, we describe AODV operations and it said > "When the node sends packets to the internet, it MAY use any of the two > methods specified in section 7.1 and appendix C." > Section7.1 is for next-hop forwarding. > Appendix C is for the routing w/routing header > > ryuji > > > At Tue, 2 Mar 2004 16:07:17 +0900, > HyunWook Cha wrote: > > > > Hello, all. > > > > After my presentation is finished, I got two comments. Although Paal's > > comments which are more technical seem to be resolved(I guess. If wrong, > > please correct me, Paal), I think that I must tell what is different > > with existing solutions for MANET Internet connectivity in my draft. > > > > As I mentioned at my presentation, my draft consists of two component. > > Route determination algorithm and Forwarding algorithm. As you know, > > these are critical parts in this area(Int. Connectivity) and all > > existing solutions address with their own way. > > > > Firstly, route optimization is not mentioned at existing drafts > > referenced by mine (If wrong, please correct me.) > > > > As for proposed forwarding algorithm, forwarding using default route can > > be done for packets without routing header. I.E, after look up of > > routing table with destination address fails, forwarding decision is > > based on source global address of the packet. That is, gw_info list is > > searched with source prefix. If matched gw_info is found, the packet is > > forwarded through host route entry for the gw advertising the prefix. > > Thus, multiple addresses from multiple gateways can be configured in a > > node and intermediate nodes can forward packets without routing header > > only if gateway info list is maintained in the node. > > > > I request valuable comments on my draft from authors of previous drafts > > including C. Perkins, Wakikawa, C. Jelger, Pekka. Personally I also > > believe that this area is very important and it is time to make > > progress. How about requirement document or merged solution document? > > Please let me know what is in your mind. Whoever is interested in this > > topic may be welcomed in this thread. > > > > Kindly Regards, > > > > HyunWook Cha > > > > > > > > > > _______________________________________________ > > 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 ------=_Part_701_15886558.1078306244547-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:39:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03654 for ; Tue, 30 Mar 2004 18:39:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjA-0006YH-RT for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC0BFPA005829 for manet-archive@odin.ietf.org; Thu, 11 Dec 2003 19:11:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUatn-0001Vw-Le for manet-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 19:11:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04217 for ; Thu, 11 Dec 2003 19:11:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUatk-0006AT-00 for manet-web-archive@ietf.org; Thu, 11 Dec 2003 19:11:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUatj-0006AQ-00 for manet-web-archive@ietf.org; Thu, 11 Dec 2003 19:11:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUata-0001LI-Su; Thu, 11 Dec 2003 19:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUat7-0001Fg-Tf for manet@optimus.ietf.org; Thu, 11 Dec 2003 19:10:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04042 for ; Thu, 11 Dec 2003 19:10:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUat4-00069W-00 for manet@ietf.org; Thu, 11 Dec 2003 19:10:30 -0500 Received: from mailhost.cs.auc.dk ([130.225.194.6] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AUat3-00069S-00 for manet@ietf.org; Thu, 11 Dec 2003 19:10:30 -0500 Received: from armada (voop@borg.cs.auc.dk [130.225.194.22]) by mailhost.cs.auc.dk (8.12.10/8.12.10) with SMTP id hBC0ALAW006862; Fri, 12 Dec 2003 01:10:21 +0100 (MET) Date: Fri, 12 Dec 2003 01:10:21 +0100 From: Thomas Heide Clausen To: "Mona" Cc: manet@ietf.org, ronan.de_renesse@kcl.ac.uk, audsindev@ieee.org Subject: Re: [manet] Ad hoc routing protocols -Testbed codes Message-Id: <20031212011021.7b86ec38.T.Clausen@computer.org> In-Reply-To: <009301c3c00c$a3204f10$730a4989@MONA> References: <009301c3c00c$a3204f10$730a4989@MONA> X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-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 On Thu, 11 Dec 2003 17:31:39 -0000 "Mona" wrote: > Dear all, > > I want to set up testbed for ad hoc networks. > > I am only aware of some of the implementation codes from Uppsala > university (AODV-UU), LUNAR , Mad-hoc - AODV implementation and OLSR > implementation from INRIA. > > I want to choose one of the existing protocols and extend it for QoS > routing analysis and also for Internet connectivity. > > Does any body know any other implementations or have experience with ad > hoc testbeds that can be useful for my research? > > Thanks in advance, > > Mona I am sure others will speak up for general testbeds and for code for AODV, so I will just mention that we do maintain a list of OLSR implementations (some of which support QoS already) at this www-page: http://menetou.inria.fr/olsr/ If you need additional information regarding OLSR, please do not hessitate to ask away ;) --thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:40:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03767 for ; Tue, 30 Mar 2004 18:40:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjA-0006ZK-7J for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFOPaU032652 for manet-archive@odin.ietf.org; Tue, 25 Nov 2003 10:24:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf3B-0008UZ-BO for manet-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:24:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22377 for ; Tue, 25 Nov 2003 10:24:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf39-0006m3-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 10:24:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOf38-0006m0-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 10:24:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf2o-0008GH-Pz; Tue, 25 Nov 2003 10:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf2H-0008F0-Uf for manet@optimus.ietf.org; Tue, 25 Nov 2003 10:23:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22328 for ; Tue, 25 Nov 2003 10:23:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf2F-0006kL-00 for manet@ietf.org; Tue, 25 Nov 2003 10:23:27 -0500 Received: from nestor.nmsu.edu ([128.123.34.146] helo=mail.nmsu.edu) by ietf-mx with esmtp (Exim 4.12) id 1AOf2E-0006kI-00 for manet@ietf.org; Tue, 25 Nov 2003 10:23:26 -0500 Received: from PCMullen2 (pc-mullen-2.NMSU.Edu [128.123.245.103]) by mail.nmsu.edu (Postfix) with ESMTP id 665322022; Tue, 25 Nov 2003 08:23:24 -0700 (MST) From: "John Mullen" To: "'Philippe Jacquet'" Cc: "'MANET'" Subject: RE: [manet] Question regarding Mobility Date: Tue, 25 Nov 2003 08:23:25 -0700 Message-ID: <000201c3b368$11a766a0$67f57b80@IEngr.ad.nmsu.edu> 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <025a01c3b35f$f8d85ce0$1f175d80@inria.fr> Importance: 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 Philippe, I recently published an approximation to the distance between random pairs of nodes that is robust over a large number of situations, but the most interesting one was the counterexample. I described a situation in which almost all nodes were distributed around the periphery of the area and few were in the middle. As a practical example, I suggested a crew fighting a forest fire. This situation gave my model fits and I suspect it would probably do the same for a MANET protocol. The torus model is interesting, but when would it describe node behavior? At a donut convention? :-) John Mullen -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Philippe Jacquet Sent: Tuesday, November 25, 2003 7:25 AM To: John Mullen; 'Richard Ogier' Cc: 'MANET' Subject: Re: [manet] Question regarding Mobility John, Amir Qayyum, developped a simulator model which use the billard model. It was called movinet. This may be good to model people moving on an exhibition field. The way point model is better for modeling players on a soccer field;-) An interesting model is when the map is a torus: nodes disappearing on one end reappear on the other end. This would really put the route control under stress ! To be more realistic nodes should change identity when reappearing, therefore simulating an open network. Philippe ----- Original Message ----- From: John Mullen To: 'Richard Ogier' Cc: 'MANET' Sent: Monday, November 24, 2003 4:44 PM Subject: RE: [manet] Question regarding Mobility > Hi Richard, > > Well, we can argue mobility models, but in the end, it is how well > they reflect node behavior in a real situation that matters. The > "choose a location and move to it" model is attractive because that is > how people move around. The "bounce off the boundary" model is not so > attractive because people don't usually move this way. People will > choose different models because they are thinking of different > contexts. > > However, the mobility model may not be that important. Because of > shadowing and fading, received signals can easily vary by a factor of > 100 to 1 from their expected values and will tend to do so as a > function of the rate at which the environment is changing. (Not just > the one node's speed, by that of all other objects and nodes in the > vicinity.) As a result, it may be the node's speed, together with data > rate, packet length, transmission frequency, etc. that are the greater > factors and the differences among many of the various mobility models > may just be a moot point. > > John Mullen > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:40:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03903 for ; Tue, 30 Mar 2004 18:40:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj9-0006YH-V4 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCDKOfg006835 for manet-archive@odin.ietf.org; Fri, 12 Dec 2003 08:20:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUnDS-0001mA-Ez for manet-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 08:20:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07726 for ; Fri, 12 Dec 2003 08:20:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUnDR-0004Qt-00 for manet-web-archive@ietf.org; Fri, 12 Dec 2003 08:20:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUnDQ-0004Qq-00 for manet-web-archive@ietf.org; Fri, 12 Dec 2003 08:20:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUnDB-0001hz-2D; Fri, 12 Dec 2003 08:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUnCx-0001h1-0p for manet@optimus.ietf.org; Fri, 12 Dec 2003 08:19:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07723 for ; Fri, 12 Dec 2003 08:19:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUnCv-0004QD-00 for manet@ietf.org; Fri, 12 Dec 2003 08:19:49 -0500 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1AUnCv-0004QA-00 for manet@ietf.org; Fri, 12 Dec 2003 08:19:49 -0500 Received: from kenai.cs.ucsb.edu (csil [128.111.41.12]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id hBCDJY213840; Fri, 12 Dec 2003 05:19:34 -0800 (PST) From: Ian Chakeres MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16345.49251.259928.270404@gargle.gargle.HOWL> Date: Fri, 12 Dec 2003 05:19:31 -0800 To: "Mona" Cc: , "ronan" , "Dev" Subject: RE:[manet] Ad hoc routing protocols -Testbed codes In-Reply-To: <009301c3c00c$a3204f10$730a4989@MONA> References: <009301c3c00c$a3204f10$730a4989@MONA> X-Mailer: VM 7.15 under Emacs 21.3.1 Reply-To: idc@cs.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 At http://moment.cs.ucsb.edu/aodv a list of publicly available AODV implementations is maintained. In regard to testbed experience you may want to see our publications page, http://moment.cs.ucsb.edu/publications.php. One other testbed experiment is aodv@ietf. See http://moment.cs.ucsb.edu/aodv-ietf/. Ian Chakeres >Mona wrote: >Dear all, > >I want to set up testbed for ad hoc networks. > >I am only aware of some of the implementation codes from Uppsala >university (AODV-UU), LUNAR , Mad-hoc - AODV implementation and OLSR >implementation from INRIA. > >I want to choose one of the existing protocols and extend it for QoS >routing analysis and also for Internet connectivity. > >Does any body know any other implementations or have experience with >ad hoc testbeds that can be useful for my research? > >Thanks in advance, > >Mona > >----------------------------------------------------------- >Mona Ghassemian, PhD student >Centre for Telecommunications Research >King's College London >Strand, London WC2R 2LS >T: +44 20 7848 2596 >F: +44 20 7848 2664 >E: Mona.Ghassemian@kcl.ac.uk >----------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:40:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03904 for ; Tue, 30 Mar 2004 18:40:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjA-0006ZK-3O for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PI1xK5028093 for manet-archive@odin.ietf.org; Wed, 25 Feb 2004 13:01:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3M7-0007J2-OP for manet-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 13:01:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03006 for ; Wed, 25 Feb 2004 13:01:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3M5-0007hm-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 13:01:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw3LA-0007Zy-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 13:01:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3KK-0007U1-00 for manet-web-archive@ietf.org; Wed, 25 Feb 2004 13:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3KI-0006y4-0b; Wed, 25 Feb 2004 13:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw3JR-0006vG-7P for manet@optimus.ietf.org; Wed, 25 Feb 2004 12:59:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02910 for ; Wed, 25 Feb 2004 12:59:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw3JP-0007MT-00 for manet@ietf.org; Wed, 25 Feb 2004 12:59:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw3Ih-0007Ed-00 for manet@ietf.org; Wed, 25 Feb 2004 12:58:28 -0500 Received: from web12822.mail.yahoo.com ([216.136.174.203]) by ietf-mx with smtp (Exim 4.12) id 1Aw3Hb-000757-00 for manet@ietf.org; Wed, 25 Feb 2004 12:57:19 -0500 Message-ID: <20040225175718.38602.qmail@web12822.mail.yahoo.com> Received: from [63.202.186.34] by web12822.mail.yahoo.com via HTTP; Wed, 25 Feb 2004 09:57:18 PST Date: Wed, 25 Feb 2004 09:57:18 -0800 (PST) From: balan h To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Handling failures 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS autolearn=no version=2.60 Can anyone point out how aodv handles partitions and router failures. any tutorials? b __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:41:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04018 for ; Tue, 30 Mar 2004 18:41:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj9-0006ZK-Jw for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOIqH4a031457 for manet-archive@odin.ietf.org; Mon, 24 Nov 2003 13:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLom-0008AD-TL for manet-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 13:52:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21100 for ; Mon, 24 Nov 2003 13:51:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLoi-0002Dr-00 for manet-web-archive@ietf.org; Mon, 24 Nov 2003 13:52:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOLoe-0002Di-00 for manet-web-archive@ietf.org; Mon, 24 Nov 2003 13:52:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLoW-000845-Vo; Mon, 24 Nov 2003 13:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLno-000814-TE for manet@optimus.ietf.org; Mon, 24 Nov 2003 13:51:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21068 for ; Mon, 24 Nov 2003 13:51:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLnm-0002Cx-00 for manet@ietf.org; Mon, 24 Nov 2003 13:51:14 -0500 Received: from nestor.nmsu.edu ([128.123.34.146] helo=mail.nmsu.edu) by ietf-mx with esmtp (Exim 4.12) id 1AOLnl-0002Co-00 for manet@ietf.org; Mon, 24 Nov 2003 13:51:13 -0500 Received: from PCMullen2 (pc-mullen-2.NMSU.Edu [128.123.245.103]) by mail.nmsu.edu (Postfix) with ESMTP id 46B1B201E for ; Mon, 24 Nov 2003 11:51:13 -0700 (MST) From: "John Mullen" To: Subject: RE: [manet] MAC layer Date: Mon, 24 Nov 2003 11:51:13 -0700 Message-ID: <000501c3b2bb$eee43eb0$67f57b80@IEngr.ad.nmsu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 think the answer is simpler than that. For CDMA to work, someone has to decide which channel each user should use. This is managed by the base station in a cellular system, but in a MANET, could be a big headache. An exception to this could be MANETs associated with specific organizations, such as the military, police, EMT, etc., in which channel assignments could be made and managed via some network plan. In general, however, it would just be too unwieldy to manage. John Mullen -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Manfredi, Albert E Sent: Monday, November 24, 2003 7:48 AM To: Ioannis C. Avramopoulos; manet@ietf.org Subject: RE: [manet] MAC layer Hi Guys, I think Yannis is asking something different. CDMA, exactly as implemented in 2G and 3G cellular networks, is of course not used in IEEE 802.11. For one thing, IEEE 802.11 is not a circuit-based technique. But the fundamentals of the scheme, i.e. use of direct sequence spread spectrum, are indeed used in IEEE 802.11b. I think what Yannis was asking is why aren't individual 802.11 LANs differentiated by the spreading sequence used in creating chips out of bits, as done in CDMA cellular phones. Instead of differentiating purely on the basis of the carrier frequency. You don't use perfectly orthogonal codes in CDMA, as that would require synchronized transmissions, impossible to achieve when mobile hosts move about. But that doesn't stop 2G and 3G from working. What happens is, as more and more users share the same frequncy band, the noise level for each user increases, until the noise overwhelms the channel. So you have a soft ceiling on number of users that can share a frequncy band, unlike TDMA where the limit is hard. I don't know why 802.11 doesn't use differnt spreading sequences as well as different frequency bands to differentiate LANs. One reason might be to simplify the design. Another might be that allowing multiple spreading sequences in the same frequency band will increase the noise level and reduce performance in umpredictable ways. Bert > -----Original Message----- > From: #LI ZHIFEI# [mailto:zhifeili@pmail.ntu.edu.sg] > Sent: Monday, November 24, 2003 12:13 AM > To: Ioannis C. Avramopoulos; manet@ietf.org > Subject: RE: [manet] MAC layer > > > Hi, > > I think your question is: why CDMA is not used in ad hoc > networks? I also try to figure out the reasons. > I have the following reasons: > (1) since ad hoc network is fully distributed, how to make > the code orthogonal, and how to make the sender be aware of > the code it should use before transmitting? > (2) again, due to the distributed nature, how to do the power > control to cope with the inteference which is ensential for > cdma system? > > However, the above difficulties do not mean that we should > not try to apply CDMA into ad hoc networks. In fact, there is > a paper talking about CDMA in ad hoc networks > in mobihoc 2003. The author is also on this list, and maybe > he can give us his understanding. > > Also, it seems that in the literature about packet radio > networks ( ad hoc networks developed for military use during > 1970s), they normally use CDMA for security reason (i.e., > jamming as you have mentioned). However, now there are very > few papers talking about CDMA in ad hoc networks. Reasearch > is really a little bit strange :). > > > Best regards > Li zhifei > > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org]On > Behalf Of Ioannis C. Avramopoulos > Sent: dissabte, 22 / novembre / 2003 12:33 > To: manet@ietf.org > Subject: [manet] MAC layer > > Dear fellows, > > I have a question on the MAC layer used in ad hoc networks. > > In 802.11 nodes share the medium, i.e. they use the same frequency > hopping pattern or chip sequence. Had nodes used orthogonal hopping > patterns, spectrum utilization would significantly increase and, > furthermore, the impact of malicious nodes with respect to jamming > would be severely mitigated. > > I am interested in the reasons that schemes of the latter type are not > considered in the ad hoc community. I would appreciate it if you could > point me to any papers discussing such issues. > > Kind regards, > Yannis > > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Mar 30 18:42:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04267 for ; Tue, 30 Mar 2004 18:42:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj7-0006WI-Bk for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFaEGd029741 for manet-archive@odin.ietf.org; Fri, 14 Nov 2003 10:36:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfzZ-0007hw-Ig for manet-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 10:36:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16061 for ; Fri, 14 Nov 2003 10:35:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfzC-0007EM-00 for manet-web-archive@ietf.org; Fri, 14 Nov 2003 10:35:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKfzC-0007DV-00 for manet-web-archive@ietf.org; Fri, 14 Nov 2003 10:35:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfyR-0007Ay-8p; Fri, 14 Nov 2003 10:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfy8-0007AD-7c for manet@optimus.ietf.org; Fri, 14 Nov 2003 10:34:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15998 for ; Fri, 14 Nov 2003 10:34:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfy5-0007CM-00 for manet@ietf.org; Fri, 14 Nov 2003 10:34:41 -0500 Received: from aun.it.uu.se ([130.238.12.36] ident=0) by ietf-mx with esmtp (Exim 4.12) id 1AKfy4-0007CC-00 for manet@ietf.org; Fri, 14 Nov 2003 10:34:41 -0500 Received: from nebulosa.it.uu.se (nebulosa.it.uu.se [130.238.8.24]) by aun.it.uu.se (8.12.10/8.12.10) with ESMTP id hAEFYVnU010169; Fri, 14 Nov 2003 16:34:32 +0100 (MET) Subject: RE: [manet] AODV Question From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: DANIEL BYRNE Cc: manet@ulfius.com, manet@ietf.org In-Reply-To: <39B01E2189D99F4B8C9612462DB3922A0CEBA940@srv-exchange.adtran.com> References: <39B01E2189D99F4B8C9612462DB3922A0CEBA940@srv-exchange.adtran.com> Content-Type: text/plain Message-Id: <1068824071.27237.67.camel@nebulosa.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 14 Nov 2003 16:34:31 +0100 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 On Fri, 2003-11-14 at 16:13, DANIEL BYRNE wrote: > I forgot about the IPv4 TTL. Good point. Sounds like the limitations in AODV goes beyond what can be fixed within the protocol itself. > > However, to the point that "who would want to connect to a station 255 hops away?" well I would, but maybe not with AODV. > I guess the point is not whether you would like to or not, but rather if it is feasible with 255+ hops. And we did talk about AODV... In the Internet I guess that an average hop count would be 20-30 hops (with max around 60, correct me if I am wrong). So why would one assume that 255+ hops would be within reach in networks that do not have bandwidth and scaling capabilities that are even close that of the Internet? Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:43:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04676 for ; Tue, 30 Mar 2004 18:43:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj5-0006ZK-24 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAJ7E5n032042 for manet-archive@odin.ietf.org; Wed, 10 Dec 2003 14:07:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9g0-0008Jz-3m for manet-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 14:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10148 for ; Wed, 10 Dec 2003 14:07:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9dB-0005pi-00 for manet-web-archive@ietf.org; Wed, 10 Dec 2003 14:04:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU9dA-0005pf-00 for manet-web-archive@ietf.org; Wed, 10 Dec 2003 14:04:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9cx-0007cx-RF; Wed, 10 Dec 2003 14:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9cc-0007aN-JU for manet@optimus.ietf.org; Wed, 10 Dec 2003 14:03:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24775 for ; Wed, 10 Dec 2003 12:12:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU7sb-00039H-00 for manet@ietf.org; Wed, 10 Dec 2003 12:12:05 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx with esmtp (Exim 4.12) id 1AU7sa-0002YF-00 for manet@ietf.org; Wed, 10 Dec 2003 12:12:04 -0500 Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id hBAHBTr13972; Wed, 10 Dec 2003 18:11:29 +0100 (MET) Message-ID: <00ae01c3bf40$6af29200$1f175d80@inria.fr> From: "Philippe Jacquet" To: "Louise Lamont" Cc: References: <3FD5D727.87CFCA6B@crc.ca> Date: Wed, 10 Dec 2003 18:09:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [manet] Re: OLSR interop 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, Louise, You are also enlisted too. I am currently collecting infos for fixing the best time. We can envision sometime between end of spring and beginning of summer 2004. We should have two interop sessions: one on IPv4 and another one on IPv6. Best regards, Philippe ----- Original Message ----- From: Louise Lamont To: ; ; Cc: ; ; ; Sent: Tuesday, December 09, 2003 3:07 PM Subject: OLSR interop > Hi, > > At CRC we are also implementing a version of OLSR IPv6 draft > 11compliant. Last year, we ported the INRIA/NRL OLSR (version 3) code > to IPv6 and added HNA capabilities. We continued upgading the code to > support the new message types and MID support. The code should be ready > in a couple of months for testing. We would also be interested in > performing interopability tests. > > Regards, Louise > -- > > --------------------------------------------------------------- > Louise Lamont > Project Leader: Mobile Networking > 3701 Carling avenue > P.O. box 11490 > Station H, Ottawa, Tel: (613) 991-9635 > Ontario, Canada Fax: (613) 998-9648 > K2H-8S2 Internet: louise.lamont@crc.ca > > Centre de Recherches sur les Communications, Industrie Canada > ------------------------------------------------------------ > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:44:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04817 for ; Tue, 30 Mar 2004 18:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006a4-Qw for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP9tPjJ027579 for manet-archive@odin.ietf.org; Tue, 25 Nov 2003 04:55:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZum-0007Ak-JH for manet-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 04:55:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10478 for ; Tue, 25 Nov 2003 04:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZuj-00015l-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 04:55:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOZui-00015i-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 04:55:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZuS-00079X-Nv; Tue, 25 Nov 2003 04:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZuA-000794-9j for manet@optimus.ietf.org; Tue, 25 Nov 2003 04:54:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10471 for ; Tue, 25 Nov 2003 04:54:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZu5-00015N-00 for manet@ietf.org; Tue, 25 Nov 2003 04:54:41 -0500 Received: from london.unik.no ([193.156.97.32]) by ietf-mx with esmtp (Exim 4.12) id 1AOZu5-00015D-00 for manet@ietf.org; Tue, 25 Nov 2003 04:54:41 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [manet] Simulating 802.11b and g Date: Tue, 25 Nov 2003 10:54:10 +0100 Message-ID: Thread-Topic: [manet] Simulating 802.11b and g thread-index: AcOtu2xOu/bT6oxEQxuyARTjNBUdtgABXIyQASJYYAAAEVBTEAAgXQhgAAkr4LA= From: "Frank Li" To: "#LI ZHIFEI#" Cc: "Mineo Takai" , Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Zhifei, >However, for the standard itself, the condition PMD_CS < PMD_ED should = be true, at least=20 >for IEEE 802.11a where the PMD_ED is 20 DB greater than PMD_CS. Are you sure that PMD_ED is 20 dB greater than PMD_CS? Is the difference = between PMD_CS and PMD_ED the same for all datarates? In the paper = posted to the same discussion by Mineo Takai last week, the two = thresholds are set as CST =3D - 78 dBm and RXT =3D - 64 dBm for WaveLan = card. But maybe they don't correspond to PMD_CS and PMD_ED? Any further = comments here, Mineo? =20 >I think the receiver-sensitivity is used to calculate the transmission = range, while the CCA >sensitivity (or CS threshold) is used to calculate = the sensing range. No, I think receiver-sensivity (or CS threshold in ns2) should be used = to calculate the sensing range, another threshold (PMD_ED?) which is = greater than receiver-sensivity, should be used to calculate the = tansmission range.=20 List below are the sensing ranges for outdoor environment I calculated = based on Agere Wireless LAN World PC Card (Extended) specification. Here = Pt=3D15 dBm , receiver-sensitivity and transmission ranges are directly = from the specification, and I used two-ray model=20 with Gt=3DGr=3D1, ht=3Dhr=3D1.5, L=3D1 to obtain the sensing ranges.=20 Datarate 11 Mbps 5.5 Mbps 2 Mbps = 1 Mbps Transmission range 160 m 270 m 400 m = 550 m Receiver sensitivity -82 dBm -87 dBm -91 dBm = -94 dBm sensing range 399 m 532 m 670 m = 796 m Any comments are welcome.=20 Frank=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:45:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04973 for ; Tue, 30 Mar 2004 18:45:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006WI-PC for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AAKIX6023753 for manet-archive@odin.ietf.org; Fri, 10 Oct 2003 06:20:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uNb-00069P-8Q for manet-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 06:20: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 GAA17246 for ; Fri, 10 Oct 2003 06:20:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7uNT-0005V7-00 for manet-web-archive@ietf.org; Fri, 10 Oct 2003 06:20:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7uNT-0005V4-00 for manet-web-archive@ietf.org; Fri, 10 Oct 2003 06:20:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uNR-000635-N3; Fri, 10 Oct 2003 06:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7uNM-00061y-D0 for manet@optimus.ietf.org; Fri, 10 Oct 2003 06:20: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 GAA17240 for ; Fri, 10 Oct 2003 06:19:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7uNI-0005Ua-00 for manet@ietf.org; Fri, 10 Oct 2003 06:19:56 -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 1A7uNH-0005UR-00 for manet@ietf.org; Fri, 10 Oct 2003 06:19:55 -0400 Received: from ms195.net.ie.niigata-u.ac.jp (ms195.net.ie.niigata-u.ac.jp [133.35.156.195]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with SMTP id 5658111DE2 for ; Fri, 10 Oct 2003 19:19:14 +0900 (JST) Date: Fri, 10 Oct 2003 19:27:52 +0900 From: Sota Yoshida To: manet@ietf.org Message-Id: <20031010192752.6d9fd0cf.syoshida@net.ie.niigata-u.ac.jp> X-Mailer: Sylpheed version 0.8.6 (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 difference between AODV and 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: 7bit Content-Transfer-Encoding: 7bit Hi Manet. I am new to GloMoSim. I have a question about "difference between AODV and DSR" My simulation scenario are as bellows. Config.in: SIMULATION-TIME 1200S SEED 1 TERRAIN-DIMENSIONS (1500, 300) NUMBER-OF-NODES 50 NODE-PLACEMENT RANDOM MOBILITY RANDOM-WAYPOINT MOBILITY-WP-PAUSE 0S MOBILITY-WP-MIN-SPEED 0 MOBILITY-WP-MAX-SPEED 20 MOBILITY-POSITION-GRANULARITY 0.5 PROPAGATION-LIMIT -111.0 PROPAGATION-PATHLOSS TWO-RAY NOISE-FIGURE 10.0 TEMPARATURE 290.0 RADIO-TYPE RADIO-ACCNOISE RADIO-FREQUENCY 2.4e9 RADIO-BANDWIDTH 11000000 RADIO-RX-TYPE SNR-BOUNDED RADIO-RX-SNR-THRESHOLD 10.0 RADIO-TX-POWER 7.87395 RADIO-ANTENNA-GAIN 0.0 RADIO-RX-SENSITIVITY -91.0 RADIO-RX-THRESHOLD -81.0 MAC-PROTOCOL 802.11 NETWORK-PROTOCOL IP NETWORK-OUTPUT-QUEUE-SIZE-PER-PRIORITY 100 #ROUTING-PROTOCOL AODV ROUTING-PROTOCOL DSR #ROUTING-PROTOCOL OLSR #ROUTING-PROTOCOL TBRPF APP-CONFIG-FILE ./app.conf APPLICATION-STATISTICS YES TCP-STATISTICS YES UDP-STATISTICS YES ROUTING-STATISTICS YES NETWORK-LAYER-STATISTICS YES MAC-LAYER-STATISTICS YES RADIO-LAYER-STATISTICS YES CHANNEL-LAYER-STATISTICS YES MOBILITY-STATISTICS YES GUI-OPTION NO GUI-RADIO NO GUI-ROUTING NO app.conf: CBR 28 25 0 80 0.020000S 3.071873S 25.036951S CBR 28 17 0 80 0.020000S 41.824254S 226.618457S CBR 28 27 0 80 0.020000S 270.816335S 451.788076S CBR 28 23 0 80 0.020000S 455.033018S 835.924075S CBR 28 12 0 80 0.020000S 857.034140S 1000.000000S When I run this simulation with DSR ,paket delivery fraction = about 60%. On the other hand, with AODV,paket delivery fraction = about 99%. Why this two results are much different !? How about in NS? Similar result? Maybe my understanding is not enough. Please tell me ! regards syoshida. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:45:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05114 for ; Tue, 30 Mar 2004 18:45:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj3-0006a4-Bk for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i249Yj5T006739 for manet-archive@odin.ietf.org; Thu, 4 Mar 2004 04:34:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypFc-0001kc-NM for manet-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 04:34:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03348 for ; Thu, 4 Mar 2004 04:34:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypFZ-0006if-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:34:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypEb-0006VK-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:33:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AypE0-0006IA-00 for manet-web-archive@ietf.org; Thu, 04 Mar 2004 04:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypDy-0001OG-PI; Thu, 04 Mar 2004 04:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AypDE-0001K9-3k for manet@optimus.ietf.org; Thu, 04 Mar 2004 04:32:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03180 for ; Thu, 4 Mar 2004 04:32:13 -0500 (EST) From: zinin@psg.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypDB-00065m-00 for manet@ietf.org; Thu, 04 Mar 2004 04:32:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypC4-0005mU-00 for manet@ietf.org; Thu, 04 Mar 2004 04:31:05 -0500 Received: from [203.129.220.117] (helo=aaaa) by ietf-mx with smtp (Exim 4.12) id 1AypAu-0005SX-00 for manet@ietf.org; Thu, 04 Mar 2004 04:29:53 -0500 Date: Thu, 04 Mar 2004 14:59:55 +0530 To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------uxdhgyuwmbunfxbrulle" Subject: [manet] Hey, ya! =)) 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME,YOU_WON autolearn=no version=2.60 ----------uxdhgyuwmbunfxbrulle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.GEN-1 in file TextDocument.zip The file is deleted. --------------------------------------------------------- ----------uxdhgyuwmbunfxbrulle Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You have won!!! pass: 14465 ----------uxdhgyuwmbunfxbrulle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) TextDocument.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------uxdhgyuwmbunfxbrulle-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:47:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05514 for ; Tue, 30 Mar 2004 18:47:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj2-0006a4-4g for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NC0EP9027192 for manet-archive@odin.ietf.org; Thu, 23 Oct 2003 08:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACe8T-00072W-AP for manet-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 08:00:13 -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 IAA14569 for ; Thu, 23 Oct 2003 08:00:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACe8S-000658-00 for manet-web-archive@ietf.org; Thu, 23 Oct 2003 08:00:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACe8R-000655-00 for manet-web-archive@ietf.org; Thu, 23 Oct 2003 08:00:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACe8O-0006yZ-K1; Thu, 23 Oct 2003 08:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACe7S-0006oC-Eu for manet@optimus.ietf.org; Thu, 23 Oct 2003 07:59: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 HAA14496 for ; Thu, 23 Oct 2003 07:59:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACe7Q-00063C-00 for manet@ietf.org; Thu, 23 Oct 2003 07:59:08 -0400 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx with esmtp (Exim 4.12) id 1ACe7P-00062S-00 for manet@ietf.org; Thu, 23 Oct 2003 07:59:07 -0400 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp3.clb.oleane.net with SMTP id h9NBwaTa010075 for ; Thu, 23 Oct 2003 13:58:36 +0200 Message-ID: <01ac01c3995d$669a43a0$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Thu, 23 Oct 2003 14:01:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A9_01C3996E.29E917E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [manet] New Mobile Technologies Forum 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: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_01A9_01C3996E.29E917E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The New Mobile Technologies Forum will be taking place in 5 weeks from = the 2nd to the 5th of December 2003 at the Hotel Sofitel Paris Bercy - = France.=20 The Forum includes the IP Based Cellular Networks'03 Conference, the = Deploying IPv6 Networks'03 Conference and the Ultra Wide Band Summit'03. = (http://www.upperside.fr/newmobtech/newmobtech03intro.htm)=20 We remind you that you can benefit from different Team passes. For more details and to register please visit: = http://www.upperside.fr/newmobtech/newmobtech03term.htm ------=_NextPart_000_01A9_01C3996E.29E917E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    The = New Mobile=20 Technologies Forum will be taking place in 5 weeks=20 from the 2nd to the 5th of December 2003 at the = Hotel=20 Sofitel Paris Bercy - France.=20
    The Forum = includes the IP Based Cellular Networks'03 = Conference,=20 the Deploying = IPv6=20 Networks'03 Conference and the Ultra=20 Wide Band Summit'03. (http://= www.upperside.fr/newmobtech/newmobtech03intro.htm)=20
    We remind you that you can = benefit=20 from different Team passes.
    For more details and to = register=20 please visit: http://w= ww.upperside.fr/newmobtech/newmobtech03term.htm<= /DIV> ------=_NextPart_000_01A9_01C3996E.29E917E0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:47:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05528 for ; Tue, 30 Mar 2004 18:47:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj2-0006ZK-56 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8T3ODqw000464 for manet-archive@odin.ietf.org; Sun, 28 Sep 2003 23:24:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3odw-00007P-U0 for manet-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 23:24: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 XAA10670 for ; Sun, 28 Sep 2003 23:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3odu-0007n9-00 for manet-web-archive@ietf.org; Sun, 28 Sep 2003 23:24:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3odu-0007n6-00 for manet-web-archive@ietf.org; Sun, 28 Sep 2003 23:24:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3odm-0008V1-Bk; Sun, 28 Sep 2003 23:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3od4-0008PZ-RA for manet@optimus.ietf.org; Sun, 28 Sep 2003 23:23: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 XAA10651 for ; Sun, 28 Sep 2003 23:23:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3od2-0007mM-00 for manet@ietf.org; Sun, 28 Sep 2003 23:23:16 -0400 Received: from sea2-f50.sea2.hotmail.com ([207.68.165.50] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1A3od2-0007mC-00 for manet@ietf.org; Sun, 28 Sep 2003 23:23:16 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 28 Sep 2003 20:22:47 -0700 Received: from 192.122.134.249 by sea2fd.sea2.hotmail.msn.com with HTTP; Mon, 29 Sep 2003 03:22:46 GMT X-Originating-IP: [192.122.134.249] X-Originating-Email: [blue_pion@hotmail.com] From: "Scott Summers" To: manet@ietf.org Date: Mon, 29 Sep 2003 03:22:46 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Sep 2003 03:22:47.0305 (UTC) FILETIME=[F464E790:01C38638] Subject: [manet] 802.11 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 all, I got a couple of questions regarding the 802.11 mac protocol. 1. Is there a cap on the maximum number of retransmissions. if yes, how many attempts? 2. if say suppose, the current transmission fails due to some reasons such as unreceived ack reply etc, and has to start a new transmission attempt, does the node starts a transmission immediately or it goes into the backoff phase? Scotts "Find a job you love and you'll never have to work a day in your life - Stefan Sagmeister" _________________________________________________________________ Keep track of Singapore & Malaysia stock prices. http://www.msn.com.sg/money/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:48:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05750 for ; Tue, 30 Mar 2004 18:48:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006ZK-2D for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA79gtIT014299 for manet-archive@odin.ietf.org; Fri, 7 Nov 2003 04:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI38o-0003iP-Db for manet-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 04:42:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07766 for ; Fri, 7 Nov 2003 04:42:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI38k-00025M-00 for manet-web-archive@ietf.org; Fri, 07 Nov 2003 04:42:50 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI38i-00024H-00 for manet-web-archive@ietf.org; Fri, 07 Nov 2003 04:42:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI37G-0003QA-SE; Fri, 07 Nov 2003 04:41:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI36d-0003J5-WE for manet@optimus.ietf.org; Fri, 07 Nov 2003 04:40:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07668 for ; Fri, 7 Nov 2003 04:40:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI36a-00022m-00 for manet@ietf.org; Fri, 07 Nov 2003 04:40:36 -0500 Received: from smtp5.clb.oleane.net ([213.56.31.25]) by ietf-mx with esmtp (Exim 4.12) id 1AI36Z-00022A-00 for manet@ietf.org; Fri, 07 Nov 2003 04:40:36 -0500 Received: from oleane ([194.250.212.114]) by smtp5.clb.oleane.net with SMTP id hA79e6pR031368 for ; Fri, 7 Nov 2003 10:40:06 +0100 Message-ID: <01f801c3a513$a63d4220$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Fri, 7 Nov 2003 10:43:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F5_01C3A51C.07ADBDC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [manet] WiMAX Summit 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: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_01F5_01C3A51C.07ADBDC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Are WiMAX and WiFi complementary (local vs. metropolitan area = networking)?=20 When and how will WiMAX evolve towards mobility?=20 Can WiMAX be considered as a migration path to 4G?=20 How is addressed the interoperability challenge?=20 These questions, among others, will be addressed during the WiMAX = Summit, to be held in Paris on May 25 to 28, 2004.=20 A call for papers has been launched on-line at: http://www.upperside.fr/wimax04/wimax04intro.htm ------=_NextPart_000_01F5_01C3A51C.07ADBDC0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Are WiMAX and WiFi complementary (local vs. = metropolitan=20 area networking)?
    When and how will WiMAX evolve towards = mobility?=20
    Can WiMAX be considered as a migration path to 4G?
    How is = addressed the=20 interoperability challenge?

    These questions, among others, will = be=20 addressed during the WiMAX = Summit, to=20 be held in Paris on May 25 to 28, 2004. =

    A=20 call for papers has been launched on-line at:
    http://www.uppe= rside.fr/wimax04/wimax04intro.htm
    ------=_NextPart_000_01F5_01C3A51C.07ADBDC0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:48:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05906 for ; Tue, 30 Mar 2004 18:48:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj0-0006ZK-QX for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPHSDwt012239 for manet-archive@odin.ietf.org; Tue, 25 Nov 2003 12:28:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgyv-000386-EJ for manet-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 12:28:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28512 for ; Tue, 25 Nov 2003 12:27:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgyr-0001au-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 12:28:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgyr-0001ar-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 12:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgyo-00033e-2z; Tue, 25 Nov 2003 12:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgyJ-00032B-CN for manet@optimus.ietf.org; Tue, 25 Nov 2003 12:27:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28499 for ; Tue, 25 Nov 2003 12:27:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgyH-0001aW-00 for manet@ietf.org; Tue, 25 Nov 2003 12:27:29 -0500 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 1AOgyH-0001ZX-00 for manet@ietf.org; Tue, 25 Nov 2003 12:27:29 -0500 Received: from SRCATL-MTA by mail.scires.com with Novell_GroupWise; Tue, 25 Nov 2003 12:25:40 -0500 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Tue, 25 Nov 2003 12:25:00 -0500 From: "Andreas Yankopolus" To: "<" Subject: Re: [manet] Glomosim question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: quoted-printable Content-Transfer-Encoding: quoted-printable Justin, I've done something similar in QualNet, which is the commercial version of = GloMoSim. You'll need to write an application within GloMoSim that reads = the timestamped data and transmits it when the simulation time matches the = data's timestamp. One way to accomplish this is to set timers containing = the data to transmit during simulation initialization. You'll obviously = want to set each timer on the node that will transmit that particular = packet. Suppose your trace has two packets: a 500-byte packet from A to C at 10s = and a 1000-byte packet from B to C at 15s. During initialization, you'd = set a timer on A for 10s containing the 500-byte packet and C's address = and a timer on B containing the 1000-byte packet and C's address. The = timers would be received by the new application you've written, and the = data associated with each timer used to generate the actual packet for = transmission. Cheers, Andreas >>> "Justin" 11/25/03 12:09PM >>> Hello, I am researching in the area of wireless sensor networks. I have an ad hoc hardware Development Kit that I can use to gather data from various sensors. Inside of Glomosim, is there a way that I can inject this real raw data that has been collected from a network into the simulator? Then analyze how system (e.g. Execution time using various routing and Mac layer techniques). Or is there no way to simulate this using Glomosim? Any suggestions would be greatly appreciated. =20 Have a good day, =20 Justin =20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:49:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06219 for ; Tue, 30 Mar 2004 18:49:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riz-0006ZK-OJ for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAJ8GUo001185 for manet-archive@odin.ietf.org; Wed, 10 Dec 2003 14:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9h1-0000HR-Cu for manet-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 14:08:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10462 for ; Wed, 10 Dec 2003 14:08:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9gw-000654-00 for manet-web-archive@ietf.org; Wed, 10 Dec 2003 14:08:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU9gw-00064y-00 for manet-web-archive@ietf.org; Wed, 10 Dec 2003 14:08:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9gt-00007n-NQ; Wed, 10 Dec 2003 14:08:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU9fz-0008K0-SZ for manet@optimus.ietf.org; Wed, 10 Dec 2003 14:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10131 for ; Wed, 10 Dec 2003 14:07:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU9de-0005qK-00 for manet@ietf.org; Wed, 10 Dec 2003 14:04:46 -0500 Received: from gehenna.ece.cornell.edu ([128.84.95.235]) by ietf-mx with esmtp (Exim 4.12) id 1AU9de-0005qG-00 for manet@ietf.org; Wed, 10 Dec 2003 14:04:46 -0500 Received: from verdi (verdi.ece.cornell.edu [128.84.210.27]) by gehenna.ece.cornell.edu (Postfix) with ESMTP id AFF881E8008; Wed, 10 Dec 2003 14:04:43 -0500 (EST) Date: Wed, 10 Dec 2003 14:02:54 -0500 (EST) From: "haas@ece.cornell.edu" To: jian wu Cc: manet@ietf.org Subject: Re: [manet] cross layer design 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 Jian, You may want to take a look at: J. Li, Z.J. Haas, M. Sheng, and Y. Chen ``Performance Evaluation of Modified IEEE 802.11 MAC for Multi-channel Multi-hop ad hoc networks,'' Journal of Interconnection Networks, vol.4, no.3, 2003, pp.45-359 downloadable from: http://wnl.ece.cornell.edu/wnlprojects.html 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, 10 Dec 2003, jian wu wrote: > Dear all > > I wonder if there is any paper/work on using network (routing) layer to > improve 802.11 MAC layer performance. Any suggestions would be appreciated. > > Jian > > _________________________________________________________________ > Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Mar 30 18:50:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06383 for ; Tue, 30 Mar 2004 18:50:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riy-0006WI-M4 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI9tP44022729 for manet-archive@odin.ietf.org; Tue, 18 Nov 2003 04:55:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2Zx-0005uW-9K for manet-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 04:55:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12146 for ; Tue, 18 Nov 2003 04:55:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2Zu-0001Y6-00 for manet-web-archive@ietf.org; Tue, 18 Nov 2003 04:55:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM2Zt-0001Y3-00 for manet-web-archive@ietf.org; Tue, 18 Nov 2003 04:55:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2Zd-0005ma-Sn; Tue, 18 Nov 2003 04:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2ZV-0005ly-A6 for manet@optimus.ietf.org; Tue, 18 Nov 2003 04:54:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12136 for ; Tue, 18 Nov 2003 04:54:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2ZS-0001Xd-00 for manet@ietf.org; Tue, 18 Nov 2003 04:54:54 -0500 Received: from staff.cs.usyd.edu.au ([129.78.8.1]) by ietf-mx with smtp (Exim 4.12) id 1AM2ZR-0001Xa-00 for manet@ietf.org; Tue, 18 Nov 2003 04:54:53 -0500 Received: from staff.cs.usyd.edu.au. by staff.cs.usyd.edu.au.; Tue, 18 Nov 2003 20:54:49 +1100 Date: Tue, 18 Nov 2003 20:54:49 +1100 (EST) From: "Corbett; Derek James" X-Sender: dcorbett@staff.cs.usyd.edu.au To: manet@ietf.org Subject: [manet] Geography Based Routing in MANETs In-Reply-To: <001c01c3adb8$21861950$c4feffcb@cglee> 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: , I am interested to know the MANET working group's position is on Geography based routing protocols such as: LAR - www.eecg.toronto.edu/~bli/papers/globecom01.pdf and GRID - citeseer.nj.nec.com/liao01grid.html and their use in MANETs. "Who controls the past controls the future. Who controls the present controls the past. But who controls the spice controls the Universe!" --------------- Derek J Corbett PhD Student Smart Internet Technology Research Group The University of Sydney http://www.cs.usyd.edu.au/~dcorbett _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:51:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06778 for ; Tue, 30 Mar 2004 18:51:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riy-0006Yx-Ck for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA2wRDZ022183 for manet-archive@odin.ietf.org; Tue, 9 Dec 2003 21:58:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATuYU-0005li-OQ for manet-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 21:58:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29535 for ; Tue, 9 Dec 2003 21:58:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATuYR-0007kU-00 for manet-web-archive@ietf.org; Tue, 09 Dec 2003 21:58:23 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATuYR-0007kR-00 for manet-web-archive@ietf.org; Tue, 09 Dec 2003 21:58:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATuY5-0005he-Ay; Tue, 09 Dec 2003 21:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATuXA-0005fP-U7 for manet@optimus.ietf.org; Tue, 09 Dec 2003 21:57:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29522 for ; Tue, 9 Dec 2003 21:56:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATuX7-0007iZ-00 for manet@ietf.org; Tue, 09 Dec 2003 21:57:01 -0500 Received: from web20027.mail.yahoo.com ([216.136.225.40]) by ietf-mx with smtp (Exim 4.12) id 1ATuX7-0007iU-00 for manet@ietf.org; Tue, 09 Dec 2003 21:57:01 -0500 Message-ID: <20031210025702.26919.qmail@web20027.mail.yahoo.com> Received: from [155.69.5.222] by web20027.mail.yahoo.com via HTTP; Wed, 10 Dec 2003 13:57:02 EST Date: Wed, 10 Dec 2003 13:57:02 +1100 (EST) From: =?iso-8859-1?q?minh=20tam?= 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] Help me ! 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 am doing the simulation with NS2 , the integration of MobileIPv4 and AODV. Anyone has any informations about this , please help me ! I really appreciate your help! http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 18:52:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06980 for ; Tue, 30 Mar 2004 18:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riy-0006ZK-1x for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIA0QrQ024705 for manet-archive@odin.ietf.org; Tue, 18 Nov 2003 05:00:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2ej-0006KK-Hz for manet-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 05:00:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12266 for ; Tue, 18 Nov 2003 05:00:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2eg-0001bk-00 for manet-web-archive@ietf.org; Tue, 18 Nov 2003 05:00:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM2ef-0001bg-00 for manet-web-archive@ietf.org; Tue, 18 Nov 2003 05:00:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2eY-0006I0-CH; Tue, 18 Nov 2003 05:00:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2eF-0006H4-0M for manet@optimus.ietf.org; Tue, 18 Nov 2003 04:59:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12242 for ; Tue, 18 Nov 2003 04:59:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2eB-0001bP-00 for manet@ietf.org; Tue, 18 Nov 2003 04:59:47 -0500 Received: from web25203.mail.ukl.yahoo.com ([217.12.10.63]) by ietf-mx with smtp (Exim 4.12) id 1AM2eB-0001b4-00 for manet@ietf.org; Tue, 18 Nov 2003 04:59:47 -0500 Message-ID: <20031118095917.12017.qmail@web25203.mail.ukl.yahoo.com> Received: from [193.95.41.229] by web25203.mail.ukl.yahoo.com via HTTP; Tue, 18 Nov 2003 10:59:17 CET Date: Tue, 18 Nov 2003 10:59:17 +0100 (CET) From: =?iso-8859-1?q?xavier=20manavite?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-966080314-1069149557=:11508" Subject: [manet] scalability to size 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-966080314-1069149557=:11508 Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA12243 Content-Transfer-Encoding: quoted-printable Hi every body, =20 I'm preparing a master about "proposing a routing protocol scalable to ne= twork size and supporting a QoS" since 4 months ago, but when I find a no= vel idea to propose, there are a lot of proposals about the same idea. So= , please help, to find a novel idea before a deadline. I would to notice that I'm interesting to stochastic models (to permit sc= alability to mobility) and thier application with clustering methods (sca= lability to size). =20 Thanks in advance. --------------------------------- Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran=E7ais ! Testez le nouveau Yahoo! Mail --0-966080314-1069149557=:11508 Content-Type: text/html; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA12243 Content-Transfer-Encoding: quoted-printable
    Hi every body,
     
    I'm preparing a master about "proposing a routing protocol scal= able to network size and supporting a QoS" since 4 months ago, but w= hen I find a novel idea to propose, there are a lot of proposals about th= e same idea. So, please help, to find a novel idea before a deadline.
    I would to notice that I'm interesting to stochastic models (to perm= it scalability to mobility) and thier application with clustering me= thods (scalability to size).
     
    Thanks in advance.


    Do You Yahoo!? -- Une ad= resse @yahoo.fr gratuite et en fran=E7ais !
    Testez le nouveau Yahoo! Mail --0-966080314-1069149557=:11508-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 19:05:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10118 for ; Tue, 30 Mar 2004 19:05:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rio-0006Yx-Vj for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NBqLIt020818 for manet-archive@odin.ietf.org; Thu, 23 Oct 2003 07:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACe0q-0005Ph-W1 for manet-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 07:52: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 HAA14147 for ; Thu, 23 Oct 2003 07:52:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACe0q-0005tK-00 for manet-web-archive@ietf.org; Thu, 23 Oct 2003 07:52:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACe0p-0005tH-00 for manet-web-archive@ietf.org; Thu, 23 Oct 2003 07:52:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACe0Z-0005JS-DD; Thu, 23 Oct 2003 07:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACe0H-0005H5-SH for manet@optimus.ietf.org; Thu, 23 Oct 2003 07:51: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 HAA14113 for ; Thu, 23 Oct 2003 07:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACe0G-0005sh-00 for manet@ietf.org; Thu, 23 Oct 2003 07:51:44 -0400 Received: from [150.204.254.209] (helo=exch5.jmu.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 1ACe0G-0005sH-00 for manet@ietf.org; Thu, 23 Oct 2003 07:51:44 -0400 Received: from mail pickup service by exch5.jmu.ac.uk with Microsoft SMTPSVC; Thu, 23 Oct 2003 12:49:25 +0100 Received: from rbl ([150.204.254.42]) by exch-gateway.jmu.ac.uk with Microsoft SMTPSVC(5.0.2195.5329); Wed, 22 Oct 2003 19:22:01 +0100 Received: from 128.59.16.73 by 150.204.254.42 (LogSat Software SMTP Server) Wed, 22 Oct 2003 19:22:01 +0100 Received: from cs.columbia.edu ([128.59.16.20]) by rogue.cs.columbia.edu with esmtp (Exim 4.12) id 1ACMxY-0001YH-00; Wed, 22 Oct 2003 13:39:48 -0400 Received: from reserv2.univ-lille1.fr (root@reserv2.univ-lille1.fr [193.49.225.90]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id h9MHdNLZ023686 for ; Wed, 22 Oct 2003 13:39:24 -0400 (EDT) Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) h9MHX5Va005601 ; Wed, 22 Oct 2003 19:33:05 +0200 Received: from KRIEKOLD (diaoul.lifl.fr [134.206.11.140]) by malonne.lifl.fr with ESMTP id h9MHWXB03785 ; Wed, 22 Oct 2003 19:32:35 +0200 (MEST) From: "David Simplot" To: , , , , , Date: Wed, 22 Oct 2003 19:35:13 +0200 Organization: IRCICA/LIFL, Univ. Lille 1 Message-ID: <00ee01c398c2$ec283040$8c0bce86@lifl.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MailScanner: Found to be clean X-MIME-Autoconverted: from quoted-printable to 8bit by cs.columbia.edu id h9MHdNLZ023686 cc: com-info@lifl.fr X-BeenThere: tccc@cs.columbia.edu X-Mailman-Version: 2.1.1 Precedence: list X-Server: LogSat Software SMTP Server X-OriginalArrivalTime: 22 Oct 2003 18:22:01.0849 (UTC) FILETIME=[634F3690:01C398C9] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA14114 Subject: [manet] [Tccc] Immediate postdoctoral position in Wireless Mobile Networking and Embedded Systems Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Please accept our apologies in case you receive this information from multiple sources.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D POSTDOCTORAL POSITION AVAILABLE IN WIRELESS MOBILE NETWORKING AND EMBEDDE= D SYSTEM Universit=E9 des Sciences et Technologies de Lille Lille, France A postdoctoral position at the Fundamental Computer Science Labs (LIFL), Univ. Lille 1, France, is open to immediately hire a qualified individual. The interested research areas are wireless mobile ad hoc networks and embedded system. The appointment is for one year (possibly renewable). For more information about research program, see: http://www.lifl.fr/RD2P Interested applicants should send a detailed resume including a list of publications, research statement with three references to: David.Simplot@lifl.fr, FAX: +33 3 20 43 65 66 (attn: David SIMPLOT-RYL), = or address given below Please feel free to distribute the information about this postdoctoral position to all colleagues who might be interested in. -- David SIMPLOT-RYL, PhD IRCICA/LIFL, Univ. Lille 1, CNRS UMR 8022 INRIA Futurs, POPS research group B=E2t. M3, Cit=E9 Scientifique 59655 Villeneuve d'Ascq Cedex, FRANCE http://www.lifl.fr/RD2P - http://www-futurs.inria.fr _______________________________________________ Tccc mailing list Tccc@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/tccc _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 19:29:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03766 for ; Tue, 30 Mar 2004 18:40:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjA-0006YH-9C for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJvJNl014546 for manet-archive@odin.ietf.org; Tue, 25 Nov 2003 14:57:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjJG-0003mX-Qc for manet-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 14:57:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05282 for ; Tue, 25 Nov 2003 14:57:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjJD-0004EP-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 14:57:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjJD-0004EM-00 for manet-web-archive@ietf.org; Tue, 25 Nov 2003 14:57:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjJ0-0003g9-G5; Tue, 25 Nov 2003 14:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjIS-0003fa-FD for manet@optimus.ietf.org; Tue, 25 Nov 2003 14:56:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05265 for ; Tue, 25 Nov 2003 14:56:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjIP-0004DN-00 for manet@ietf.org; Tue, 25 Nov 2003 14:56:25 -0500 Received: from nestor.nmsu.edu ([128.123.34.146] helo=mail.nmsu.edu) by ietf-mx with esmtp (Exim 4.12) id 1AOjIN-0004DI-00 for manet@ietf.org; Tue, 25 Nov 2003 14:56:24 -0500 Received: from PCMullen2 (pc-mullen-2.NMSU.Edu [128.123.245.103]) by mail.nmsu.edu (Postfix) with ESMTP id C5EEA201D; Tue, 25 Nov 2003 12:56:22 -0700 (MST) From: "John Mullen" To: "'Philippe Jacquet'" Cc: "'MANET'" Subject: RE: [manet] Question regarding Mobility Date: Tue, 25 Nov 2003 12:56:22 -0700 Message-ID: <000001c3b38e$33907920$67f57b80@IEngr.ad.nmsu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <001e01c3b388$1b16a960$1f175d80@inria.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Philippe, The (two-dimensional) Poisson assumes that, for a very small area within a region, the probability of a node being in an area is proportional to the area plus something that becomes insignificant as the area become extremely small. If you use the Poisson on a bounded region, the number of nodes within that region will be a random variable. If you apply a Poisson distribution to a region when the number of nodes within the region is known in advance, the result is a uniform distribution. If the number of nodes is fixed, then eventually, the node density will drop to zero on the infinite plane. The Poisson keeps the local density constant, so any piece of the plain will appear to be distributed uniformly, but the expected number of nodes on the plane will be infinite, since the expected value of the Poisson is the expected node density times the node area. So, I'm not quite sure what you are saying. Are you saying the number of nodes in the finite region is a random variable (Poisson) or that the number of nodes is fixed, but the positions are random (Uniform)? John Mullen -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Philippe Jacquet Sent: Tuesday, November 25, 2003 12:13 PM To: Richard Ogier Cc: MANET Subject: Re: [manet] Question regarding Mobility There is likely a proof for the invariance of the Poisson distribution under the billard model. There is a general result that tells that on an infinite plane, an initial Poisson distribution of nodes remains Poisson at any time given simple conditions on node motions, i.e. move are indendent of nodes and position. I think it is easily extendable to the billard model, one just have to clone the square and cover the whole the plane by mirror effect, so that bouncing is just equivalent to going straight through the border between two mirror images. And then we distribute nodes indifferently in the original square and in its mirror images as if it was a Poisson distribution on the whole plane. After letting the node moving, we apply the general result. Notice that the result remains valid even when the motions are complicated (pause times, distance travelled, changes of direction, curves, etc), given they are independent of nodes and locations. Random change of direction at the border may not satisfy this rule. Philippe ----- Original Message ----- From: Richard Ogier To: Philippe Jacquet Cc: MANET Sent: Tuesday, November 25, 2003 6:02 PM Subject: Re: [manet] Question regarding Mobility > Philippe, > > Thanks for computing the formula for the probability density of node > position for random waypoint. I also started to compute the formula > for 2 dimensions, > but quit when I saw how complicated it is. In actual simulations, to > start out > with the steady state density, it might be easiest to just generate two > random > points in the square and then choose a random point uniformly > distributed on the > line connecting the two points. > > Someone asked me about a proof that the random-walk billiards model results > in uniformly distributed node positions. (This is the model in which > a node > moves in a random direction for T seconds, bouncing off boundaries > like a billiards ball, and choosing a new random direction after T seconds.) > I think this is fairly intuitive, by considering what happens if the > node instead goes straight through the boundary into an equivalent > region adjacent to > the original region. But is this result well known? Can anyone point > to a reference for this? > > Richard > > > > Philippe Jacquet wrote: > > >Richard, > > > >My mistake, you are right. I was considering the case where the node reaches > >its way point in a constant time. With a constant speed, zero pause > >time, the density is your result: C (1-x)*x in dimension one. To be > >forgiven I tried to compute the formula for the density in two > >dimensions. Not really > >fun. For x>y and (1-x)>y it should be proportional to j(x,y)+j(1-x,y) with a > >normalizing factor, with > >j(x,y)=(1-x)*y*(2+log(x/y)-log((1-x)/(1-y))). > > > >For the other cases for (x,y) one makes use of symmetries and > >finally: > >density(x,y)=C*(j(max(x,y),min(x,y))+j(max(1-x,y),min(1-x,y))) > > > >I made the integration over all angle of the product of the two > >distances of > >the point (x,y) to the border of the square within a given angle. I > >used Maple. It needs to be cross checked. . > > > >The plot looks like a very eroded pyramid: null density on the border > >and top on the square center. The result should be the same when the > >speed is randomly selected on finite distribution. > > > >Best regards, > >Philipe > > > >----- Original Message ----- > >From: Richard Ogier > >To: Philippe Jacquet > >Cc: MANET > >Sent: Friday, November 21, 2003 5:37 PM > >Subject: Re: [manet] Question regarding Mobility > > > > > >>Philippe Jacquet wrote: > >> > >>>Yes, Peter, the distribution changes if you introduce mobility and > >>>it depends on the mobility model. Take the random way point model > >>>where each > >>>node has a distinct a random destination point selected uniformly > >>>in a square, and each node moves to this destination at constant > >>>speed. In > >>> > >this > > > >>>case, the stationary density at point (x,y) (assuming a 1x1 square) > >>>is *( x* log x+(1-x)*log(1-x))*(y*log y +(1-y)*log(1-y)) which > >>>differs from > >>>uniform density (which is equal to 1 at any point in the 1x1 > >>>square). > >>> > >>>Philippe > >>> > >>Philippe, > >> > >>Your result implies that you can consider the x and y directions > >>independently. I don't think this is the case, because the speed in > >>the x direction depends on the (x,y) direction of movement. I did > >>some calculations, and I think your result assumes that the time to > >>go from one random point to the next random point is constant (thus, > >>if the distance between the 2 points is greater, the speed must be > >>greater). > >> > >>Just for fun I tried to derive the steady state distribution in one > >>dimension for a unit interval [0,1] and got the following result > >>(assuming constant speed and zero pause time): > >> > >> C * x*(1-x) (C is a normalization constant) > >> > >>The x*(1-x) term is simply the probability that the point x lies > >>between two random numbers uniformly distributed in [0,1]. I ran a > >>simulation on the unit interval [0,1] which confirms this result. > >>In particular, the probability that the node is near x = 0.25 is > >>0.75 times the probability that the node is near x = 0.50. > >> > >>Unfortunately, this result cannot be extended to 2 dimensions by > >>taking the product of this term for the x and y directions, because > >>the x and y components of the node speed are not independent. > >> > >>Richard > >> > >>>----- Original Message ----- > >>>From: Peter Pham > >>>To: MANET > >>>Sent: Thursday, November 20, 2003 2:03 AM > >>>Subject: [manet] Question regarding Mobility > >>> > >>> > >>>>Hi all > >>>>I am interested in modelling ad hoc networks. In the stationary scenario > >>>>(nodes do not move), I can assume that the mobile nodes are distributed > >>>>randomly according to Poisson distribution (many assumed so). > >>>>However, is this assumption still valid under the mobility ? Can > >>>>anyone give me some advice ? > >>>> > >>>>Peter Pham > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 21:04:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17014 for ; Tue, 30 Mar 2004 21:04:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8V5A-0004Aa-J8 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 21:03:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V23u2M016029 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 21:03:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8V5A-0004AS-CH for manet-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 21:03:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17001 for ; Tue, 30 Mar 2004 21:03:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8V57-0000ai-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 21:03:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8V4G-0000WO-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 21:03:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8V3a-0000Sc-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 21:02:18 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8V3b-0003nA-7z for manet-web-archive@ietf.org; Tue, 30 Mar 2004 21:02:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8V3J-0003pm-QL; Tue, 30 Mar 2004 21:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8V2L-0003ms-3P for manet@optimus.ietf.org; Tue, 30 Mar 2004 21:01:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16915 for ; Tue, 30 Mar 2004 21:00:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8V2I-0000Oi-00 for manet@ietf.org; Tue, 30 Mar 2004 21:00:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8V1N-0000Kl-00 for manet@ietf.org; Tue, 30 Mar 2004 21:00:02 -0500 Received: from gehenna.ece.cornell.edu ([128.84.95.235]) by ietf-mx with esmtp (Exim 4.12) id 1B8V0e-0000Fv-00 for manet@ietf.org; Tue, 30 Mar 2004 20:59:16 -0500 Received: from verdi (verdi.ece.cornell.edu [128.84.210.27]) by gehenna.ece.cornell.edu (Postfix) with ESMTP id 58AB31E8005; Tue, 30 Mar 2004 20:59:17 -0500 (EST) Date: Tue, 30 Mar 2004 20:57:14 -0500 (EST) From: "haas@ece.cornell.edu" To: mohannraj krishnamurthy Cc: manet@ietf.org Subject: Re: [manet] hello sir In-Reply-To: <20040330180247.8875.qmail@webmail35.rediffmail.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Mohannraj, You can find some of our work in the area of MANET security at: http://wnl.ece.cornell.edu/wnlprojects.html#Publications2 Best, 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(at)ece(dot)cornell(dot)edu U.S.A WNL web page: http://wnl.ece.cornell.edu ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- On 30 Mar 2004, mohannraj krishnamurthy wrote: > hello sir, i am currently working in Security aspects of manet.. i would like to get information regarding the various routing algorithms available and different security schemes used in manet.. if possible please send me informations of the resources available regarding this.. i am a new user of glomosim and so if possible please give me tips on glomosim usage and if possible the useful resources.. thanks, bye. mohanraj _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Mar 30 22:44:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23274 for ; Tue, 30 Mar 2004 22:44:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8WeX-0003AH-0X for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 22:44:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V3iW3Z012165 for manet-archive@odin.ietf.org; Tue, 30 Mar 2004 22:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8WeW-0003A8-SJ for manet-web-archive@optimus.ietf.org; Tue, 30 Mar 2004 22:44:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23215 for ; Tue, 30 Mar 2004 22:44:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8WeT-0002Zf-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 22:44:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Wd8-0002OC-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 22:43:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8WcE-0002H7-00 for manet-web-archive@ietf.org; Tue, 30 Mar 2004 22:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Wc6-0002ml-BU; Tue, 30 Mar 2004 22:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Wbt-0002lQ-Ok for manet@optimus.ietf.org; Tue, 30 Mar 2004 22:41:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23017 for ; Tue, 30 Mar 2004 22:41:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Wbq-0002Db-00 for manet@ietf.org; Tue, 30 Mar 2004 22:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Waq-00027F-00 for manet@ietf.org; Tue, 30 Mar 2004 22:40:44 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 1B8WZx-0001yy-00 for manet@ietf.org; Tue, 30 Mar 2004 22:39:49 -0500 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id TAA21215; Tue, 30 Mar 2004 19:39:13 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id TAA14932; Tue, 30 Mar 2004 19:39:13 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i2V3bqo14872; Tue, 30 Mar 2004 19:37:52 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 30 Mar 2004 19:37:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Manet charter item Date: Tue, 30 Mar 2004 19:37:51 -0800 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406053D@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [manet] Manet charter item Thread-Index: AcQSsnhOlSEbCAIpR+W/RQfMk4GPrAEHezCw From: "Henderson, Thomas R" To: "Charles E.Perkins" , "Mobile Ad Hoc IETF working group" X-OriginalArrivalTime: 31 Mar 2004 03:37:52.0053 (UTC) FILETIME=[8BAC7E50:01C416D1] Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Charles E.Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, March 25, 2004 1:42 PM > To: Mobile Ad Hoc IETF working group > Subject: [manet] Manet charter item >=20 >=20 > I had always > thought that the point of the OSPF work would > be to enable OSPF routers to adjoin ad hoc > networks to infrastructure networks, and > Fred has made some presentations explaining > various thinking along these lines. >=20 Rather than adjoining, our interest in OSPF has been to=20 make it capable of more efficient operation as an ad hoc protocol itself, so as to avoid running different protocols in the two regions and redistributing between them. =20 As a first step, we explored whether we could modify OLSR so=20 that it could be implemented as a new interface type for the=20 OSPF protocol: http://www.ietf.org/internet-drafts/draft-spagnolo-manet-ospf-wireless-in= terface-00.txt Tom _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 31 00:42:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29913 for ; Wed, 31 Mar 2004 00:42:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8YUK-0003v2-Hw for manet-archive@odin.ietf.org; Wed, 31 Mar 2004 00:42:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2V5g8kN015060 for manet-archive@odin.ietf.org; Wed, 31 Mar 2004 00:42:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8YUK-0003up-AS for manet-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 00:42:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29767 for ; Wed, 31 Mar 2004 00:42:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8YUH-0006nZ-00 for manet-web-archive@ietf.org; Wed, 31 Mar 2004 00:42:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8YSs-0006VZ-00 for manet-web-archive@ietf.org; Wed, 31 Mar 2004 00:40:39 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8YRm-0006Lp-04 for manet-web-archive@ietf.org; Wed, 31 Mar 2004 00:39:30 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B8YDO-0006Yl-7B for manet-web-archive@ietf.org; Wed, 31 Mar 2004 00:24:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8YCo-0001ly-Jj; Wed, 31 Mar 2004 00:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8X8a-00060W-IG for manet@optimus.ietf.org; Tue, 30 Mar 2004 23:15:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25224 for ; Tue, 30 Mar 2004 23:15:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8X8Y-0005jC-00 for manet@ietf.org; Tue, 30 Mar 2004 23:15:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8X6s-0005YB-00 for manet@ietf.org; Tue, 30 Mar 2004 23:13:51 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 1B8X4x-0005LD-00 for manet@ietf.org; Tue, 30 Mar 2004 23:11:51 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id UAA03923; Tue, 30 Mar 2004 20:11:21 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id UAA14302; Tue, 30 Mar 2004 20:11:20 -0800 (PST) X-Authentication-Warning: slb-av-01.boeing.com: iscan owned process doing -bs Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i2V49Io11732; Tue, 30 Mar 2004 20:09:18 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Tue, 30 Mar 2004 20:09:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Comments on "Problem Statement for OSPF Extensions ..." draft Date: Tue, 30 Mar 2004 20:09:17 -0800 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406053E@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [manet] Comments on "Problem Statement for OSPF Extensions ..." draft Thread-Index: AcQSwH6Hua89Kr8WT4SMaWgGVLzO1wEESnrg From: "Henderson, Thomas R" To: "Charles E.Perkins" , "Mobile Ad Hoc IETF working group" X-OriginalArrivalTime: 31 Mar 2004 04:09:18.0355 (UTC) FILETIME=[EFFF5630:01C416D5] Content-Transfer-Encoding: quoted-printable 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Charlie, thanks for your comments (responses inline) > -----Original Message----- > From: Charles E.Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, March 25, 2004 1:28 PM > To: Mobile Ad Hoc IETF working group > Subject: [manet] Comments on "Problem Statement for OSPF=20 > Extensions ..." > draft >=20 >=20 >=20 > Hello folks, >=20 > During the recent meeting, the abovementioned draft > was discussed. The draft has been submitted for a > long time, but after finally reading the draft, and > motivated by the recent WG discussion, I have a few > comments. >=20 > - In section 2.1, it is stated that mobility makes > the use of directional antennas into a pointless > exercise. There are numerous studies that conclude > otherwise. It seems likely that, given sufficient > justification, a workable system can be built. > Whether or not the additional cost is justified > compared to other expenses is debatable. Overall, > however, I would say that "pointless" is far too > strong an adjective in this sentence. agreed-- maybe "difficult" instead >=20 > - In section 2.3, the acronym "VC" is left undefined. virtual circuit >=20 > - In section 2.5, the misconception is promulgated > that receiving takes less power than transmitting. > While it is typically true per message, the fact is > that receiving is often more power-consuming > when the receiver has to be always powered up. > In contrast, typically the transmitter can be > powered down during most of the timm. agreed, although the point that power management is a=20 concern is still applicable (but this should be reworded) >=20 > - In section 2.7, if a node's ability to support new > neighbors is exhausted, then one can truly say that > the number of neighbors is numerically limited, > so that the nodal degree is limited. Said another > way, geographic proximity may not result in network > adjacency. agreed (I don't think you are arguing the text?). Fred Baker's "outsider's view of MANET" draft explored the possibility of limiting the nodal degree. >=20 > - In section 2.8, replace "should not thrash" by > "should avoid thrashing" >=20 > - In section 2.9, last paragraph: the suggested > strategy requires too much binding between a node's > IPv4 addressability and its IPv6 addressability. > This issue may not need solution in this document > anyway. In fact, I question the need for binding > even separate network interfaces to the same nodal > identifier, but again that is a separate issue. This section alludes to a draft in the OSPF WG suggesting that multiple addressing families could be supported by a single protocol (OSPFv3). The point is that, if we are doing ad hoc routing at layer 3, we should concern ourselves with handling both v4 and v6 efficiently. >=20 > - Section 2.10 gets to the heart of a crucial > problem. I would suggest that it be taken as > a requirement to outfit the OSPF implementations > so that unreliable flooding is acceptable, > otherwise I just don't believe the solution > will be scalable. >=20 I agree with you that this is a crucial problem, and the way that this is solved is going to affect the=20 scalability. =20 Our studies have indicated that flooding is by far the=20 dominant contributor to overhead. We have looked at a number of the proposals for reliable but optimized flooding, and found that they can improve the situation, but a reduction in overhead by half seems to be a rough bound on the achievable improvement. However, in some highly mobile environments, unreliable flooding does significantly better (order of magnitude) than reliable flooding. =20 We'll put out a draft on this topic shortly, but suffice it to say that reliable flooding doesn't seem capable of approaching the overhead reduction offered by unreliable flooding, as mobility increases. =20 But whether or not a reliable flooding protocol can be=20 scalable or not scalable is debatable. "Doesn't scale" is frequently a dismissive term that is not qualified enough. The working group may decide that, in the case of OSPF, it is willing to trade some scalability to=20 retain reliable (but optimized) flooding. The design=20 decision that I believe is the true non-starter is to=20 decide a priori that OSPF flooding should not be optimized, period. =20 Tom _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 31 09:26:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23711 for ; Wed, 31 Mar 2004 09:26:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gfA-0005cx-6U for manet-archive@odin.ietf.org; Wed, 31 Mar 2004 09:25:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VEPq74021627 for manet-archive@odin.ietf.org; Wed, 31 Mar 2004 09:25:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gf8-0005ck-RN for manet-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 09:25:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23704 for ; Wed, 31 Mar 2004 09:25:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8gf7-0001OB-00 for manet-web-archive@ietf.org; Wed, 31 Mar 2004 09:25:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8gcE-0001Ir-00 for manet-web-archive@ietf.org; Wed, 31 Mar 2004 09:22:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8gc9-0001I3-00 for manet-web-archive@ietf.org; Wed, 31 Mar 2004 09:22:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gbV-0005BP-T3; Wed, 31 Mar 2004 09:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8gap-0005A9-AF for manet@optimus.ietf.org; Wed, 31 Mar 2004 09:21:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23651 for ; Wed, 31 Mar 2004 09:21:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8gan-0001CM-00 for manet@ietf.org; Wed, 31 Mar 2004 09:21:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8gYP-00014e-00 for manet@ietf.org; Wed, 31 Mar 2004 09:18:54 -0500 Received: from itc100.adtran.com ([66.0.238.100] helo=srv-exchange1.adtran.com) by ietf-mx with esmtp (Exim 4.12) id 1B8gXO-0000z1-00 for manet@ietf.org; Wed, 31 Mar 2004 09:17:50 -0500 Received: by srv-exchange1.adtran.com with Internet Mail Service (5.5.2657.72) id ; Wed, 31 Mar 2004 08:17:43 -0600 Message-ID: <39B01E2189D99F4B8C9612462DB3922A153B8B5B@srv-exchange.adtran.com> From: DANIEL BYRNE To: manet@ietf.org Date: Wed, 31 Mar 2004 08:17:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Subject: [manet] Lunar question 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-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In LUNAR what happens when the xrp layer receives a frame from tcp/ip stack and it is a data frame with a specific dest. MAC address but we've already purged the table entry for that MAC address? Is an automatic XRP RREQ sent to determine what the MAC address is for the given IP address? Or, is some sort of message sent back up the TCP/IP stack telling it that this MAC is invalid so it knows to create an ARP request to get the MAC address for the destination? To me, it seems like we would do that second of the two choices. This keeps the upper layers doing what they are suppose to do and keeps us from having to be too smart, ya know. So with that said, does anyone know what the special message is that we send back to the TCP/IP stack telling it a MAC doesn't exist, or the packet be trashed and let the TCP/IP logic timeout and create an ARP request on its own? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Mar 31 17:22:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16493 for ; Wed, 31 Mar 2004 17:22:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8o5t-00048f-8a for manet-archive@odin.ietf.org; Wed, 31 Mar 2004 17:21:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2VMLvFh015910 for manet-archive@odin.ietf.org; Wed, 31 Mar 2004 17:21:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8o5s-00048X-Sj for manet-web-archive@optimus.ietf.org; Wed, 31 Mar 2004 17:21:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16480 for ; Wed, 31 Mar 2004 17:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8o5q-0006Di-00 for manet-web-archive@ietf.org; Wed, 31 Mar 2004 17:21:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8o4w-00069e-00 for manet-web-archive@ietf.org; Wed, 31 Mar 2004 17:20:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8o4S-000630-00 for manet-web-archive@ietf.org; Wed, 31 Mar 2004 17:20:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8nvK-0002hP-MM; Wed, 31 Mar 2004 17:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8nuw-0002fB-4W for manet@optimus.ietf.org; Wed, 31 Mar 2004 17:10:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15671 for ; Wed, 31 Mar 2004 17:10:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8nut-0005GP-00 for manet@ietf.org; Wed, 31 Mar 2004 17:10:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8nu1-0005DG-00 for manet@ietf.org; Wed, 31 Mar 2004 17:09:42 -0500 Received: from balu1.urz.unibas.ch ([131.152.1.51]) by ietf-mx with esmtp (Exim 4.12) id 1B8nto-0005BH-00 for manet@ietf.org; Wed, 31 Mar 2004 17:09:28 -0500 Received: from igor.urz.unibas.ch (igor.urz.unibas.ch [131.152.1.3]) by balu1.urz.unibas.ch (8.12.10/8.12.10) with ESMTP id i2VM8rfL018811; Thu, 1 Apr 2004 00:08:53 +0200 Date: Thu, 1 Apr 2004 00:08:53 +0200 (MET DST) From: Christian Tschudin To: DANIEL BYRNE cc: manet@ietf.org Subject: Re: [manet] Lunar question In-Reply-To: <39B01E2189D99F4B8C9612462DB3922A153B8B5B@srv-exchange.adtran.com> Message-ID: References: <39B01E2189D99F4B8C9612462DB3922A153B8B5B@srv-exchange.adtran.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Daniel, we are in the process of setting up a LUNAR distribution list where such question will best be handled. I will soon annouce it and will also come back to your previous questions there. Regarding your question below: The answer depends on how closely your LUNAR implementation can touch the IP stack: - When a MAC-to-LUNARpath entry expires, you should also invalidate the IP stack's ARP cache (simple remove the ARP entry, so a next data packet will trigger a new ARP request). - in case the LUNAR implementation can only use ARP replies to talk to the IP stack, you are out of luck: There is no ARP message for "undoing" an IP-to-MAC mapping, for obvious security reasons. The best thing then is to set the ARP timer of the IP stack to low values, 3 to 6 seconds instead of the usual 60 seconds. Note that although the IP stack now emits frequent ARP requests, this is no extra burden for the ether because the LUNAR implementation traps all ARP messages and can return IP-to-MAC mappings based on its table. christian. --- Christian Tschudin, University of Basel http://cn.cs.unibas.ch/ Computer Science Dept, Bernoullistr. 16, CH - 4056 Basel, Switzerland On Wed, 31 Mar 2004, DANIEL BYRNE wrote: > In LUNAR what happens when the xrp layer receives a frame from tcp/ip stack > and it is a data frame with a specific dest. MAC address but we've already > purged the table entry for that MAC address? Is an automatic XRP RREQ sent > to determine what the MAC address is for the given IP address? Or, is some > sort of message sent back up the TCP/IP stack telling it that this MAC is > invalid so it knows to create an ARP request to get the MAC address for the > destination? To me, it seems like we would do that second of the two > choices. This keeps the upper layers doing what they are suppose to do and > keeps us from having to be too smart, ya know. So with that said, does > anyone know what the special message is that we send back to the TCP/IP > stack telling it a MAC doesn't exist, or the packet be trashed and let the > TCP/IP logic timeout and create an ARP request on its own? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet