From exim@www1.ietf.org Tue Sep 2 09:33:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22972 for ; Tue, 2 Sep 2003 09:33:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u9eZ-0002sK-P9 for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 07:48:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Bmtif011045 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 07:48:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u7QP-0000zt-5x for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 05:26:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03096 for ; Tue, 2 Sep 2003 05:26:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u7QK-00028i-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 05:26:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u7QK-00028f-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 05:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u56A-0005lm-Mu; Tue, 02 Sep 2003 02:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u0nK-0008N3-9k for manet@optimus.ietf.org; Mon, 01 Sep 2003 22:21:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24475 for ; Mon, 1 Sep 2003 22:21:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u0dV-00057g-00 for manet@ietf.org; Mon, 01 Sep 2003 22:11:13 -0400 Received: from sunlight.wichita.edu ([156.26.1.5]) by ietf-mx with esmtp (Exim 4.12) id 19twT2-0005Ev-00 for manet@ietf.org; Mon, 01 Sep 2003 17:44:08 -0400 Received: from CONVERSION-DAEMON.sunlight.wichita.edu by sunlight.wichita.edu (PMDF V6.2 #30772) id <0HKK00I011OJBQ@sunlight.wichita.edu> for manet@ietf.org; Mon, 01 Sep 2003 16:43:31 -0500 (CDT) Received: from webmail.wichita.edu (BIERSTADT.WICHITA.EDU [156.26.1.165]) by sunlight.wichita.edu (PMDF V6.2 #30772) with ESMTP id <0HKK00IFV1OI6K@sunlight.wichita.edu> for manet@ietf.org; Mon, 01 Sep 2003 16:43:31 -0500 (CDT) Date: Mon, 01 Sep 2003 16:43:32 -0500 From: jhchauhan To: manet@ietf.org Message-id: <3F4DAC93@webmail.wichita.edu> MIME-version: 1.0 X-Mailer: WebMail (Hydra) SMTP v3.62 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-WebMail-UserID: jhchauhan@wichita.edu X-EXP32-SerialNo: 00003023, 00003770 Content-Transfer-Encoding: 7bit Subject: [manet] Value for CTSTimeout Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, The IEEE 802.11 PHY and MAC Specifications state that "After transmitting an RTS frame, the STA shall wait for a CTSTimeout interval, starting at the PHYTXEND.confirm." If the station does not receive a CTS frame within this time period, it considers that the transmission of RTS has failed and starts retransmitting the RTS. I am looking for a typical value for the CTSTimeout interval. It would be helpful if someone can inform me about it or tell me a mathematical equation in terms of aSIFSTime or aSlotTime or some other parameter. Any suggestions are appreciated. Regards, Jasmina Jasmina Chauhan Graduate Assistant Wichita State University Kansas. Voice : 316-682-6133 (Res) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 2 09:38:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24003 for ; Tue, 2 Sep 2003 09:38:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u8yN-0005GK-Ap for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 07:05:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82B5JNd020227 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 07:05:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6LY-0001Ut-UU for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 04:17:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28770 for ; Tue, 2 Sep 2003 04:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u6LV-0007eG-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 04:17:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u6LU-0007eB-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 04:17:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u5Ml-0000DV-Lv; Tue, 02 Sep 2003 03:14:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1DE-0002BY-Qy for manet@optimus.ietf.org; Mon, 01 Sep 2003 22:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00946 for ; Mon, 1 Sep 2003 22:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1DA-0002Cr-00 for manet@ietf.org; Mon, 01 Sep 2003 22:48:04 -0400 Received: from www3.mail.lycos.com ([209.202.220.160] helo=lycos.com) by ietf-mx with smtp (Exim 4.12) id 19tqYY-0001Ih-00 for manet@ietf.org; Mon, 01 Sep 2003 11:25:26 -0400 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon, 01 Sep 2003 15:24:52 -0000 To: manet@ietf.org, "Manish Karir" Date: Mon, 01 Sep 2003 11:24:52 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Re: [manet] The Problem of Alien Node X-Sender-Ip: 134.117.61.61 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, That is exactly my point. Ad-hoc nodes may not always have a MANET_PREFIX IP address due to possibilities of nodes roaming with a static IP, and the chances of ad-hoc network getting partitioned or merged. Therefore, it is not possible for ad-hoc nodes to rely merely on MANET_PREFIX IP address to distinguish local nodes (LAA). The gateway also will asume nodes that don't have MANET_PREFIX IP address are external, and will forward packets outside the ad-hoc. While in fact some nodes that don't have MANET_PREFIX IP address are local nodes, with global static IP (I call it alien nodes). Therefore, I believe, there should be a registration mechanism for all alien nodes at the gateway. Any comments? any reason why not? yasser ---------------------------------------------- I'm sorry but the point that you are trying to get across is not very clear, and your terminology is quite confusing... perhaps it would become clearer if we knew what your references were...[047-01] and [048-01]. when building a scenario that incorportes both terrestrial and ad hoc nodes, it is best to use address in MANET_PREFIX to identify ad hoc nodes. this way the gateway knows which address are in manet and which are in terrestrial network. These address spaces should be mutually exclusive, or you are going to run into the problems that you describe(atleast thats what I think you are talking about). alternately, if you decide that the two address spaces can intermingle, then you need to run complex registration/deregistration protocols at the gateway to inform the gateway which addresses(nodes) are in the manet.(some hybrid form of MIP). -manish Yasser A. Lotfy wrote: > Hi, > > I hope you read the attached (word) document which raises awareness of the > problem of alien node. Sorry I have to make it in MS-Word since some of the symbols > can not be done as text. > > The problem is simply due to the confusion that takes place when gateways announce > there ability to forward packets to generic addresses. Some local ad-hoc nodes may fall > in this generic address range. Therefore, packets may (incorrectly) be forwarded to GW. > I hope to get feedback if any solution currently exist to this problem. > > yasser > --- *********************************************** A train station is the place where trains stop, A bus station is the place where buses stop, On my desk they installed a workstation !! *********************************************** ____________________________________________________________ Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 2 09:38:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24142 for ; Tue, 2 Sep 2003 09:38:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBMO-00025u-Jd for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 09:38:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DcGML008044 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 09:38:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBMM-00025O-UO for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:38:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23984 for ; Tue, 2 Sep 2003 09:38:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uBML-0007ct-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 09:38:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uBMK-0007cq-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 09:38:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uB6i-0006Le-GI; Tue, 02 Sep 2003 09:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u7Ib-0008MO-GK for manet@optimus.ietf.org; Tue, 02 Sep 2003 05:18:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02609 for ; Tue, 2 Sep 2003 05:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u7IX-0000wn-00 for manet@ietf.org; Tue, 02 Sep 2003 05:18:01 -0400 Received: from bay2-f48.bay2.hotmail.com ([65.54.247.48] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19u7IW-0000o0-00 for manet@ietf.org; Tue, 02 Sep 2003 05:18:00 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Sep 2003 02:17:32 -0700 Received: from 195.12.26.4 by by2fd.bay2.hotmail.msn.com with HTTP; Tue, 02 Sep 2003 09:17:31 GMT X-Originating-IP: [195.12.26.4] X-Originating-Email: [jianwu53@hotmail.com] From: "jian wu" To: manet@ietf.org Date: Tue, 02 Sep 2003 09:17:31 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Sep 2003 09:17:32.0187 (UTC) FILETIME=[0A04E6B0:01C37133] Subject: [manet] manet qos Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Dear all I am currenly studying QoS in manets. I wonder how to reserve resources (bandwidth) in an 802.11-type network. While in TDMA or CDMA MAC, you can reserve time slots for flows, but for a 2 Mbps 802.11 link, how do you reserve 200 Kbps for a flow? Any suggestions would be appreciated. Regards J. _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 2 09:38:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24199 for ; Tue, 2 Sep 2003 09:38:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBMW-00029W-Ct for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 09:38:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DcOBX008264 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 09:38:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAR2-0001QK-P9 for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 08:39: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 IAA17593 for ; Tue, 2 Sep 2003 08:38:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uAQx-0001hW-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 08:38:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uAQm-0001gG-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 08:38:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6B0-000807-B0; Tue, 02 Sep 2003 04:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4T2-00088m-Ss for manet@optimus.ietf.org; Tue, 02 Sep 2003 02:16:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18738 for ; Tue, 2 Sep 2003 02:16:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u4Sy-0001Tf-00 for manet@ietf.org; Tue, 02 Sep 2003 02:16:36 -0400 Received: from den.erg.sri.com ([128.18.100.23]) by ietf-mx with esmtp (Exim 4.12) id 19u4Sx-0001GQ-00 for manet@ietf.org; Tue, 02 Sep 2003 02:16:35 -0400 Received: from den.erg.sri.com (localhost [127.0.0.1]) by den.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id XAA22674; Mon, 1 Sep 2003 23:15:57 -0700 (PDT) Message-Id: <200309020615.XAA22674@den.erg.sri.com> To: "Christophe Jelger" cc: manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Comments on draft-jelger In-reply-to: Your message of "Thu, 28 Aug 2003 09:54:37 +0200." <014801c36d39$b93a8750$ac5a4f82@ustrasbg.fr> Date: Mon, 01 Sep 2003 23:15:57 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi Christophe, Regarding your new draft, I am not sure that "prefix continuity" is necessary. That is, I am not sure that the set of nodes having the same prefix needs to be contiguous. Please consider the following, and let me know if I am missing something. It is only necessary for each node to have a route to the gateway(s) it is affiliated with, and for each gateway to have a route to each node that is affiliated with it. One might argue that if the set of nodes with a given prefix is contiguous, then it is easier to flood a message to all nodes having that prefix, but I think it is sufficient for a gateway to be able to perform the following types of flooding: (a) Flooding to all nodes in the manet. (b) Flooding to all nodes in the manet that are within K hops of the gateway (where K is such that any node affiliated with the gateway is required to be within K hops of that gateway). Thus, I am not sure it is necessary to go through the trouble to ensure "prefix continuity". A node can simply select the nearest gateway (which can be determined from the information provided by a proactive routing protocol), and use the prefix advertised by that gateway. The node can keep that prefix until it no longer has a route to that gateway, or becomes more than K hops from that gateway, or finds another gateway that is much closer. My reasoning is influenced by the original paper on Landmark Routing (Paul Tsuchiya, 1987), which I re-read recently. A node can select any landmark node (a landmark is like a gateway) that is within a certain hop-radius of the node, and use the prefix advertised by that landmark. There is no requirement that the set of nodes affiliated with a given landmark be contiguous. A node would have to change its prefix only if it moves too far from the landmark it has selected. It could then select another landmark, or another landmark could be elected, or the hop-radius could be increased. (Note that I am not suggesting to use landmark routing to deal with internet-gateways in manets.) The idea of a hop-radius (or "routing scope") from Landmark routing can also be applied to the problem we are considering. For example, suppose there is one huge manet (say with a diameter of 100 hops), which has several internet-gateways. Thus, even though one manet node may be be able to reach another manet node using a 100-hop path, it would be desirable to limit the routing scope to K hops (where K might be 5), such that every node is within K hops of some internet-gateway. Then, each manet node would select a gateway that is within K hops and use the prefix advertised by that gateway. The node would have to change its prefix only if it moves more than K hops from the gateway it selected. It is also possible for a manet node to select multiple gateways that are within K hops, and to have multiple prefixes. Note that the above approach makes it unnecessary to divide the manet into well-defined areas or clusters: The set of all nodes affiliated with a given gateway need not be contiguous. All nodes within K hops of a gateway receive advertisements from the gateway, but may decide to use the prefix advertised by another gateway that is also within K hops. Regards, Richard > Hi everybody, > > I've just published a new Internet Draft on IPv6 gateway discovery and > address autoconfiguration in ad hoc networks. > > http://www.ietf.org/internet-drafts/draft-jelger-manet-gateway-autoconf-v6-00 .txt > > I am of course very interested by comments and suggestions which are very > welcome. For your information, we will have an implementation of the draft > in a few weeks. > > Sincerely, > > Christophe > > --------------------------------------------------------------- > Christophe Jelger - LSIIT jelger@dpt-info.u-strasbg.fr > Université Louis Pasteur > Strasbourg - France Tel: +33 (0)3 90 24 45 90 > > http://www-r2.u-strasbg.fr/~jelger > --------------------------------------------------------------- > > > _______________________________________________ > manet mailing 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 Sep 2 10:57:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04613 for ; Tue, 2 Sep 2003 10:57:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCas-0007xO-Qp for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 10:57:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82EvITP030582 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 10:57:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCas-0007x9-NI for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 10:57: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 KAA04459 for ; Tue, 2 Sep 2003 10:57:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCaq-0003Yz-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 10:57:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uCY0-0003DO-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 10:54:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCXk-0007EE-He; Tue, 02 Sep 2003 10:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCXe-0007CF-TW for manet@optimus.ietf.org; Tue, 02 Sep 2003 10:53:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03460 for ; Tue, 2 Sep 2003 10:53:52 -0400 (EDT) From: S.Sivavakeesar@connectfree.co.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCXc-000336-00 for manet@ietf.org; Tue, 02 Sep 2003 10:53:56 -0400 Received: from mk-smarthost-2.mail.uk.tiscali.com ([212.74.114.38]) by ietf-mx with esmtp (Exim 4.12) id 19uCNe-0002hs-00 for manet@ietf.org; Tue, 02 Sep 2003 10:43:39 -0400 Received: from [212.74.112.92] (helo=mk-webmail-2.b2b.uk.tiscali.com) by mk-smarthost-2.mail.uk.tiscali.com with esmtp (Exim 4.20) id 19uCN3-000OUa-1Z for manet@ietf.org; Tue, 02 Sep 2003 15:43:01 +0100 Received: from exim by mk-webmail-2.b2b.uk.tiscali.com with local (Exim 4.20) id 19uCN3-000O9u-At for manet@ietf.org; Tue, 02 Sep 2003 15:43:01 +0100 To: manet@ietf.org Reply-To: S.Sivavakeesar@connectfree.co.uk Date: Tue, 02 Sep 2003 15:43:01 +0100 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: Content-Transfer-Encoding: 7bit Subject: [manet] Hidden Terminal Problem Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Dear All : Can somebody tell me whether the IEEE 802.11 DCF can completely avoid 'Hidden-Terminal' problem with the use of RTS-CTS, physical carrier-sensing and NAV in multihop MANET ? Does it depends on distance between nodes and RTS & CTS duration ? Even if there is a chance for hidden terminal problem in multihop ad hoc networks, does IEEE 802.11 DCF mode operation in single hop environment completely avoid hidden-terminal problem. Cheers SIVA _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 2 11:16:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06464 for ; Tue, 2 Sep 2003 11:16:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCtB-0001EU-0R for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 11:16:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82FGCNf004731 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 11:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCtA-0001EE-SL for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 11:16: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 LAA06367 for ; Tue, 2 Sep 2003 11:16:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCt9-0004VQ-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 11:16:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uCt9-0004VN-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 11:16:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCt0-00019M-6J; Tue, 02 Sep 2003 11:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uCsC-0000sr-MD for manet@optimus.ietf.org; Tue, 02 Sep 2003 11:15: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 LAA06014 for ; Tue, 2 Sep 2003 11:15:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uCsB-0004MS-00 for manet@ietf.org; Tue, 02 Sep 2003 11:15:11 -0400 Received: from web8201.mail.in.yahoo.com ([203.199.70.114]) by ietf-mx with smtp (Exim 4.12) id 19uCrf-0004CI-00 for manet@ietf.org; Tue, 02 Sep 2003 11:14:39 -0400 Message-ID: <20030902151404.17214.qmail@web8201.mail.in.yahoo.com> Received: from [202.134.200.4] by web8201.mail.in.yahoo.com via HTTP; Tue, 02 Sep 2003 16:14:04 BST Date: Tue, 2 Sep 2003 16:14:04 +0100 (BST) From: =?iso-8859-1?q?Vishal=20Sisodia?= 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] Hi everbody.. Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 working for telecomm company in India, and I have lot of exp. in telecomm field,I want to do research in manet field, can anybody tell me how I can proceed... I have studied some papers in manet field already but not getting any direction. I am also interested for applying in US universities for MS or PhD. I will be very thankful to you all. Best, Vishal Sisodia Hughes Software Systems Gurgaon,India voice: 09811808307 ________________________________________________________________________ Yahoo! India Promos: Win TVs, Bikes, DVD players & more! Go to http://in.promos.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 2 12:43:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13439 for ; Tue, 2 Sep 2003 12:43:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEFN-0007fP-Dg for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 12:43:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82GhDCs029467 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 12:43:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEFN-0007fC-87 for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 12:43: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 MAA13409 for ; Tue, 2 Sep 2003 12:43:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEFL-0007Pp-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 12:43:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uEFK-0007Pm-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 12:43:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEFB-0007dh-EM; Tue, 02 Sep 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEEZ-0007bb-Sn for manet@optimus.ietf.org; Tue, 02 Sep 2003 12:42:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13360 for ; Tue, 2 Sep 2003 12:42:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEEY-0007Ov-00 for manet@ietf.org; Tue, 02 Sep 2003 12:42:22 -0400 Received: from barrichello.cs.ucr.edu ([138.23.169.5]) by ietf-mx with esmtp (Exim 4.12) id 19uEEX-0007Nq-00 for manet@ietf.org; Tue, 02 Sep 2003 12:42:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id C718EAB571B0; Tue, 2 Sep 2003 09:40:29 -0700 (PDT) Received: from io.cs.ucr.edu (io.cs.ucr.edu [138.23.174.180]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id 68DB8AB571A5; Tue, 2 Sep 2003 09:40:28 -0700 (PDT) Received: by io.cs.ucr.edu (Postfix, from userid 7296) id 4191526594; Tue, 2 Sep 2003 09:41:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by io.cs.ucr.edu (Postfix) with ESMTP id 3B28125847; Tue, 2 Sep 2003 09:41:43 -0700 (PDT) Date: Tue, 2 Sep 2003 09:41:43 -0700 (PDT) From: "Zhenqiang(Frank) Ye" To: jhchauhan Cc: Subject: Re: [manet] Value for CTSTimeout In-Reply-To: <3F4DAC93@webmail.wichita.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,SIGNATURE_LONG_DENSE,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by AMaViS perl-11 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi Jasmina, If the RTS-CTS handshake is successful, the RTS sender should recieve a CTS frame after it sends out its RTS and waits for SIFS + tranmission time of a CTS. Otherwise, it means the RTS fails. By the way, you need to include some propagation delay. In ns-2 802.11 code, the RTS timeout value is set to be: propagation dalay (of RTS) + SIFS +Tx(CTS) + propagation delay (of CTS). On Mon, 1 Sep 2003, jhchauhan wrote: > Hello, > > The IEEE 802.11 PHY and MAC Specifications state that "After transmitting an > RTS frame, the STA shall wait for a CTSTimeout interval, starting at the > PHYTXEND.confirm." If the station does not receive a CTS frame within this > time period, it considers that the transmission of RTS has failed and starts > retransmitting the RTS. > > I am looking for a typical value for the CTSTimeout interval. It would be > helpful if someone can inform me about it or tell me a mathematical equation > in terms of aSIFSTime or aSlotTime or some other parameter. > Any suggestions are appreciated. > > Regards, > Jasmina > > Jasmina Chauhan > Graduate Assistant > Wichita State University > Kansas. > > Voice : 316-682-6133 (Res) > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- **************************************** Zhenqiang(Frank) Ye Ph.D Student Department of Electrical Engineering University of California, Riverside Phone: (909)-787-2434 email: zye@cs.ucr.edu **************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 2 12:59:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14801 for ; Tue, 2 Sep 2003 12:59:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEUs-0001Pc-AL for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 12:59:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82GxE7k005421 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 12:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEUs-0001PM-6i for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 12:59:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14599 for ; Tue, 2 Sep 2003 12:59:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEUq-00000h-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 12:59:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uEUp-00000e-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 12:59:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEUg-0001KD-Lt; Tue, 02 Sep 2003 12:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEUQ-0001IT-WC for manet@optimus.ietf.org; Tue, 02 Sep 2003 12:58:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14489 for ; Tue, 2 Sep 2003 12:58:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEUP-0007nn-00 for manet@ietf.org; Tue, 02 Sep 2003 12:58:45 -0400 Received: from barrichello.cs.ucr.edu ([138.23.169.5]) by ietf-mx with esmtp (Exim 4.12) id 19uEUO-0007nV-00 for manet@ietf.org; Tue, 02 Sep 2003 12:58:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id 017EFAB571B0; Tue, 2 Sep 2003 09:56:58 -0700 (PDT) Received: from io.cs.ucr.edu (io.cs.ucr.edu [138.23.174.180]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id A0AB1AB571AF; Tue, 2 Sep 2003 09:56:57 -0700 (PDT) Received: by io.cs.ucr.edu (Postfix, from userid 7296) id 606EA26594; Tue, 2 Sep 2003 09:58:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by io.cs.ucr.edu (Postfix) with ESMTP id 599E625847; Tue, 2 Sep 2003 09:58:12 -0700 (PDT) Date: Tue, 2 Sep 2003 09:58:12 -0700 (PDT) From: "Zhenqiang(Frank) Ye" To: Cc: Subject: Re: [manet] Hidden Terminal Problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-38.0 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,SIGNATURE_LONG_DENSE,USER_AGENT_PINE autolearn=ham version=2.53 X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) X-Virus-Scanned: by AMaViS perl-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: , IEEE 802.11 DCF can not completely avoid "hidden terminal problem". If all the mobile nodes are within the sensing range of each other (not necessarily within one hop), hidden terminal problem will not occur. On Tue, 2 Sep 2003 S.Sivavakeesar@connectfree.co.uk wrote: > Dear All : > > Can somebody tell me whether the IEEE 802.11 DCF can completely avoid > 'Hidden-Terminal' problem with the use of RTS-CTS, physical carrier-sensing > and NAV in multihop MANET ? Does it depends on distance between nodes and > RTS & CTS duration ? Even if there is a chance for hidden terminal problem > in multihop ad hoc networks, does IEEE 802.11 DCF mode operation in single > hop environment completely avoid hidden-terminal problem. > > > Cheers > > SIVA > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- **************************************** Zhenqiang(Frank) Ye Ph.D Student Department of Electrical Engineering University of California, Riverside Phone: (909)-787-2434 email: zye@cs.ucr.edu **************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 2 18:17:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13208 for ; Tue, 2 Sep 2003 18:17:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJSl-0003xq-6J for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 18:17:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82MHNbu015236 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 18:17:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJSl-0003xf-2J for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 18:17:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13097 for ; Tue, 2 Sep 2003 18:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uJSi-0001JD-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 18:17:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uJSh-0001JA-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 18:17:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJSQ-0003sl-Pm; Tue, 02 Sep 2003 18:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJRQ-0003qp-Kn for manet@optimus.ietf.org; Tue, 02 Sep 2003 18:16: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 SAA12916 for ; Tue, 2 Sep 2003 18:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uJRN-0001FZ-00 for manet@ietf.org; Tue, 02 Sep 2003 18:15:57 -0400 Received: from puppet.cs.toronto.edu ([128.100.3.169] helo=cs.toronto.edu) by ietf-mx with esmtp (Exim 4.12) id 19uJRN-0001FO-00 for manet@ietf.org; Tue, 02 Sep 2003 18:15:57 -0400 Received: from localhost (delara@localhost) by cs.toronto.edu (8.11.6/8.11.6) with ESMTP id h82MFtH06793 for ; Tue, 2 Sep 2003 18:15:57 -0400 Date: Tue, 2 Sep 2003 18:15:54 -0400 (EDT) From: Eyal de Lara X-X-Sender: delara@puppet.cs To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] MobiCom 2003 additional hotel available Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Please excuse us if you get multiple copies of this announcement. ---------------------------------------------------------------------- MobiCom 2003 additional hotel available Rooms at the main hotel for MobiCom 2003, the Ninth Annual International Conference on Mobile Computing and Networking, are now fully sold out on some nights of the conference, and we have arranged an additional nearby hotel to handle the overflow. MobiCom 2003 will be held September 14-19, 2003, at the Westin Horton Plaza Hotel in San Diego, California. We have now arranged an additional block of rooms for MobiCom attendees at the same rate at the U.S. Grant, a Wyndham Historic Hotel, which is located one block from the Westin Horton Plaza. MobiCom is the premier international forum addressing research in all areas of mobile computing and wireless and mobile networking at the link layer and above. For more information on MobiCom 2003, including hotel details and details on how to register to attend, please see the MobiCom 2003 web pages at http://www.sigmobile.org/mobicom/2003/ We have a very strong program this year, including 27 technical papers describing the best of recent research in mobile computing and networking, plus exciting research demos, a panel discussion on security and privacy in mobile and wireless systems, a student poster session, and a conference dinner banquet cruise. MobiCom 2003 will also feature 2 invited talks: - Keynote Speaker: Dr. Paul J. Kolodzy, Director of the Wireless Network Security Center (WiNSeC) at Stevens Institute of Technology, and previously Senior Spectrum Policy Advisor and Director of the Spectrum Policy Task Force at the United States FCC, and Program Manager at DARPA. - Luncheon Speaker: Dr. Ian F. Akyildiz, Ken Byers Distinguished Chair Professor in Telecommunications, School of Electrical and Computer Engineering, Georgia Institute of Technology. Professor Akyildiz will speak on "InterPlaNetary Internet: State-of-the-Art and Research Challenges". The conference will also include 5 tutorials on the latest research areas and background topics in mobile computing and networking: - Secure Routing in Ad Hoc Networks - Public-Area Wireless Networks - Mobile Ad Hoc Networking - IP Mobility Support in a Mobile Internet - Topology Control in Wireless Ad Hoc Networks MobiCom will also have 6 full-day workshops on emerging topics related to mobile computing and networking: - DIALM-POMC 2003 Joint Workshop on Foundations of Mobile Computing - MobiDE 2003: The Third ACM International Workshop on Data Engineering for Wireless and Mobile Access - MSWiM 2003: The Sixth ACM International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems - WiSe 2003: The Second ACM International Workshop on Wireless Security - WMASH 2003: The First ACM International Workshop on Wireless Mobile Applications and Services on WLAN Hotspots - WSNA 2003: The Second ACM International Workshop on Wireless Sensor Networks and Applications We look forward to seeing you in San Diego for MobiCom 2003! ---------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 2 20:20:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18844 for ; Tue, 2 Sep 2003 20:20:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uLNu-0000m4-1z for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 20:20:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h830KT8a002969 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 20:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uLNr-0000le-8b for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 20:20:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18755 for ; Tue, 2 Sep 2003 20:20:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uLNo-0004ES-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 20:20:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uLNm-0004EN-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 20:20:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uLNU-0000jg-KY; Tue, 02 Sep 2003 20:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uLND-0000iy-2s for manet@optimus.ietf.org; Tue, 02 Sep 2003 20:19:47 -0400 Received: from pit.erg.sri.com (pit.erg.sri.com [128.18.100.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18712 for ; Tue, 2 Sep 2003 20:19:41 -0400 (EDT) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id RAA23612; Tue, 2 Sep 2003 17:19:12 -0700 (PDT) Message-Id: <200309030019.RAA23612@pit.erg.sri.com> To: jelger@clarinet.u-strasbg.fr cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Comments on draft-jelger In-reply-to: Your message of "Tue, 02 Sep 2003 13:27:57 PDT." <200309022027.NAA22727@pit.erg.sri.com> Date: Tue, 02 Sep 2003 17:19:11 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Christophe, I want to add one thought regarding how to handle nodes that are too far from all gateways. These can be treated like "drifters" in LANMAR (where gateways assume the role of landmarks): http://www.watersprings.org/pub/id/draft-ietf-manet-lanmar-05.txt Thus, a node that is too far from all gateways can select the nearest gateway (since gateway advertisements can be propagated such that every node knows at least one gateway), and the method in the above draft can be used to maintain a path from the selected gateway to the faraway node, using distance-vector routing. The other method (mentioned below) is for the faraway node to increase the number of hops that its routing advertisements propagate, to ensure that the gateway knows a route to the node. The LANMAR "drifter" approach might be more efficient, but the other method might be simpler and more robust, and can use the underlying proactive routing protocol instead of introducing an additional distance-vector mechanism. Note that, unlike in the LANMAR draft, we do not expect a "drifter" to very far from the gateway, since it can select the nearest gateway. Regards, Richard > > > The idea of a hop-radius (or "routing scope") from Landmark routing > > > can also be applied to the problem we are considering. > > > For example, suppose there is one huge manet (say with a diameter > > > of 100 hops), which has several internet-gateways. > > > Thus, even though one manet node may be be able to reach another > > > manet node using a 100-hop path, it would be desirable to limit > > > the routing scope to K hops (where K might be 5), such that > > > every node is within K hops of some internet-gateway. > > > Then, each manet node would select a gateway that is within > > > K hops and use the prefix advertised by that gateway. > > > The node would have to change its prefix only if it moves > > > more than K hops from the gateway it selected. > > > > This idea is also quite good, we thought about such thing but finally decided > > not to incorporate this in this version of the draft, mainly because we could > > not find a solution for nodes that were "too far" from all gateways. If we > > limit the distance to, say K hops, what happens for a node that is K+1 hops > > from all possible gateways ? I think it is not acceptable to ignore such a > > node, so the "K hops" rule has to be broken ... and if we can find exceptions, > > maybe it is because the rule is too strict. Well I cannot find an easy > > solution for the K+1 node ... :-( > > I agree that we should not ignore a node that is too far from all > gateways, but I don't think it is difficult to handle such exceptions. > For example, a manet node that is not within range of any gateway can > increase its routing scope (distance that its routing advertisements > propagate, whether link-state or distance-vector) until it is within > range of some gateway, so that the gateway will know a route to the node. > In the reverse direction, gateway advertisements can be propagated in a > manner that ensures every node knows about at least one gateway > (no matter how far), but also knows all gateways that are within K hops. > > Regards, > Richard > > > > It is also possible for a manet node to select multiple gateways > > > that are within K hops, and to have multiple prefixes. > > > Note that the above approach makes it unnecessary to divide > > > the manet into well-defined areas or clusters: > > > The set of all nodes affiliated with a given gateway need > > > not be contiguous. All nodes within K hops of a gateway receive > > > advertisements from the gateway, but may decide to use the prefix > > > advertised by another gateway that is also within K hops. > > > > > > Regards, > > > Richard > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 2 20:56:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20733 for ; Tue, 2 Sep 2003 20:56:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uLwR-0002SV-2d for manet-archive@odin.ietf.org; Tue, 02 Sep 2003 20:56:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h830uBO6009445 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 20:56:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uLwQ-0002Rg-PI for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 20:56: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 UAA20680 for ; Tue, 2 Sep 2003 20:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uLwO-0005Mq-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 20:56:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uLwN-0005Mn-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 20:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uLwI-0002Nf-Aw; Tue, 02 Sep 2003 20:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uLvX-0002MZ-TS for manet@optimus.ietf.org; Tue, 02 Sep 2003 20:55:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20646 for ; Tue, 2 Sep 2003 20:55:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uLvV-0005LJ-00 for manet@ietf.org; Tue, 02 Sep 2003 20:55:13 -0400 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 19uLvU-0005KJ-00 for manet@ietf.org; Tue, 02 Sep 2003 20:55:12 -0400 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.2656.59) id SBCR3SLZ; Wed, 3 Sep 2003 09:54:11 +0900 Reply-To: From: "HyunWook Cha" To: , , "'Manish Karir'" Cc: "????????" Subject: RE: [manet] The Problem of Alien Node Date: Wed, 3 Sep 2003 09:54:43 +0900 Message-ID: <000001c371b5$f6873060$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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Yasser, I think "registration" is necessary for communications which are not only manet local but also across Internet. I mentioned this point at my previous posting. But I think the "registration" can not be an solution for the "Alien Node Problem". Please think about this case. There are multiple gateways and a manet. Manet nodes may have different sets of gateways because of partitions. And, if a gateway chosen by souce node does not belong to the gateway set of destination node, it will forward packets destined to desination toward Internet. I think a global static ip which you are considering is not globally routable(reachable) since a manet node with globally routable global ip is also reachable across Internet althogh it is local manet node. If so, evenually souce node will be notified by ICMP destination unreachable and do route discovery again in case of reactive protocols. I think this is enough for destination node with the "global static ip" which is not globally routable. Regards, ++++++++++++++++++++++++++++++++++++++++++++++++++++ HyunWook Cha Researcher NGI Standards Research Team Protocol Engineering Center, ETRI 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, KOREA (Tel) +82-42-860-1076 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Yasser A. Lotfy > Sent: Tuesday, September 02, 2003 12:25 AM > To: manet@ietf.org; Manish Karir > Subject: Re: [manet] The Problem of Alien Node > > > > Hi, > That is exactly my point. Ad-hoc nodes may not always have a > MANET_PREFIX IP address due to possibilities of nodes roaming > with a static IP, and the chances of ad-hoc network getting > partitioned or merged. > > Therefore, it is not possible for ad-hoc nodes to rely merely > on MANET_PREFIX IP address to distinguish local nodes (LAA). > The gateway also will asume nodes that don't have > MANET_PREFIX IP address are external, and will forward > packets outside the ad-hoc. While in fact some nodes that > don't have MANET_PREFIX IP address are local nodes, with > global static IP (I call it alien nodes). > > Therefore, I believe, there should be a registration > mechanism for all alien nodes at the gateway. > > Any comments? any reason why not? > > yasser > ---------------------------------------------- > I'm sorry but the point that you are trying to get across is not very > clear, and your terminology is quite confusing... > perhaps it would become clearer if we knew what your references > were...[047-01] and [048-01]. > > when building a scenario that incorportes both terrestrial > and ad hoc nodes, it is best to use address in MANET_PREFIX > to identify ad hoc nodes. this way the gateway knows which > address are in manet and which are in terrestrial network. > These address spaces should be mutually exclusive, or you are > going to run into the problems that you describe(atleast > thats what I think you are talking about). > > alternately, if you decide that the two address spaces can > intermingle, then you need to run complex > registration/deregistration protocols at the gateway to > inform the gateway which addresses(nodes) are in the > manet.(some hybrid form of MIP). > > -manish > > > > Yasser A. Lotfy wrote: > > Hi, > > > > I hope you read the attached (word) document which raises > awareness of > > the > > > problem of alien node. Sorry I have to make it in MS-Word > since some > > of the symbols > > > can not be done as text. > > > > The problem is simply due to the confusion that takes place when > > gateways announce > > > there ability to forward packets to generic addresses. Some local > > ad-hoc nodes may fall > > > in this generic address range. Therefore, packets may > (incorrectly) be > > forwarded to GW. > > > I hope to get feedback if any solution currently exist to this > > problem. > > > > yasser > > --- > *********************************************** > A train station is the place where trains stop, > A bus station is the place where buses stop, > On my desk they installed a workstation !! > *********************************************** > > > > > > > > ____________________________________________________________ > Get advanced SPAM filtering on Webmail or POP Mail ... Get > Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005 > > _______________________________________________ > manet mailing 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 Sep 3 03:51:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11852 for ; Wed, 3 Sep 2003 03:51:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSQI-00066Y-9f for manet-archive@odin.ietf.org; Wed, 03 Sep 2003 03:51:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h837pQDR023460 for manet-archive@odin.ietf.org; Wed, 3 Sep 2003 03:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSQH-00066I-Aw for manet-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 03:51:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11750 for ; Wed, 3 Sep 2003 03:51:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uSQE-0000dU-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 03:51:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uSQC-0000dM-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 03:51:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSPy-00060a-4U; Wed, 03 Sep 2003 03:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSPM-0005yL-Nm for manet@optimus.ietf.org; Wed, 03 Sep 2003 03:50:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11608 for ; Wed, 3 Sep 2003 03:50:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uSPK-0000Zk-00 for manet@ietf.org; Wed, 03 Sep 2003 03:50:26 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19uSPI-0000YD-00 for manet@ietf.org; Wed, 03 Sep 2003 03:50:25 -0400 Received: from fonoll.ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h837nrZv011283 for ; Wed, 3 Sep 2003 09:49:53 +0200 (MET DST) Received: (from ew2004@localhost) by fonoll.ac.upc.es (8.12.8/8.12.8) id h837nrwD000613 for manet@ietf.org; Wed, 3 Sep 2003 09:49:53 +0200 (MET DST) Date: Wed, 3 Sep 2003 09:49:53 +0200 From: Conferencia ew2004 To: manet@ietf.org Message-ID: <20030903074952.GA610@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by roura.ac.upc.es id h837nrZv011283 Content-Transfer-Encoding: quoted-printable Subject: [manet] European Wireless'04 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- Dear Colleague, We would like to remind you that the submission deadline for EW2004 is 10th of September, 2003! All the details about the conference can be found at: http://www.ac.upc.es/EW2004 Best regards, EW2004 organizing committee. ------------------------------------------------------------------------- EW2004 The 5th European Wireless Conference Mobile and Wireless Systems beyond 3G http://www.ac.upc.es/EW2004=20 February 24-27, 2004 Technical University of Catalonia (UPC) - Barcelona, Spain CONFERENCE SCOPE In order to be able to be connected anywhere and at anytime a seamless ac= cess to the various access technologies is needed providing the adequate QoS t= o=20 diverse applications.=20 The 5th European Wireless Conference focuses on technologies, protocols,=20 services and applications that will enable a full seamless and nomadic us= er=20 access to new classes of person to person, device to device and device=20 to person applications. TOPICS Technical papers describing original, previously unpublished research are= solicited.=20 Specific topics of interest include, but are not limited to, the followin= g: * Adaptive Antennas * Base Station Technology * Indoor Channel Modeling( Wave Propagation and Measurements * Integration of Radio Localization Systems into Wireless User Terminals * Integration of Terrestrial and Satellite Networks * Interference Mitigation and Management Techniques * Power and Interference Control * Power Management for small terminals * Protocols for Air Interfaces and Networks * Short Range Communication Systems * Signal Processing Techniques for Communications * Analysis( Simulation and Measurements of Mobile and Wireless Systems * High Altitude Platforms and Satellites * Internetworking between Different Access Technologies * Mobile Agents * Mobile and Wireless Applications * Mobility Management * Multiple Access Schemes * Positioning=20 * QoS in Mobile and Wireless Networks * Routing in Ad hoc Networks * Security and robustness in wireless networks * Sensor Network Planning and Deployment * Wireless Ad hoc Networks * Wireless LANs PAPER SUBMISSION INSTRUCTIONS Papers for the conference should be written in English and with a limit o= f 12 double=20 spaced pages. All paper submissions will be handled electronically, following the instr= uctions at: http://www.ac.upc.es/EW2004 All papers will be reviewed by the program committee members. Accepted papers will be published in the conference proceedings.=20 IMPORTANT DATES Full papers due: September 10th 2003 Notification of Acceptance: November 14th 2003 Camera Ready due: December 12th 2003 GENERAL CHAIR:=20 Olga Casals, (Technical University of Catalonia, UPC, Spain) Jorge Garcia-Vidal (Technical University of Catalonia, UPC, Spain) STEERING COMMITTEE CHAIR:=20 Bernhard Walke (Aachen University of Technology, Germany) TECHNICAL PROGRAM CO-CHAIRS: Miguel A. Lagunas (CTTC, Spain) Ioannis Stavrakakis (University of Athens, Greece) TUTORIAL CHAIR: Jorge Garc=EDa-Vidal (UPC, Spain) LOCAL ARRANGEMENTS CO-CHAIRS: Carles Ant=F3n (CTTC, Spain) Jose M. Barcel=F3 (UPC, Spain) Lloren=E7 Cerd=E0 (UPC, Spain) TECHNICAL PROGRAM COMMITTEE: R. Agust=ED (UPC, Spain) I. Akyildiz (Georgia Ins. of Technology, USA) E. Altman (INRIA, France) A. Art=E9s (Univ. Carlos III, Spain) S. Benedetto (Politecnico de Torino, Italy) C. Blondia (Univ. of Antwerp, Belgium) E. Bonek (TU of Viena, Austria) A. Campbell (Columbia University, USA) V. Casares (UPV, Spain) E. Casilari (Univ. de Malaga, Spain) L. Castedo (Univ. de La Coru=F1a, Spain) M. Conti (IIT/CNR, Italy) L. Correia (IST, Portugal) L. Cuthbert (Univ. of London, UK) J. Dunlop (Univ. of Strathclyde, UK) S. Giordano (EPFL, Switzerland) H. Kawashima (Tokio Univ. of Agriculture & Technology, Japan) U. K=F6rner (Univ. of Lund, Sweden) P. Kuehn (Univ. of Stuttgart, Germany) L. Lenzini (Univ. of Pisa, Italy) J. M. Paez Borrallo (UPM, Spain) J. Paradells (UPC, Spain) C. Rosenberg (Purdue University, USA) H. St=FCttgen (NEC, Germany) A. Svensson (Chalmers, Sweden) R. Tafazolli (Univ. of Surrey, UK) Y. Takahashi (Kyoto University, Japan) L. Tassiulas (Univ. of Maryland, USA) S. Tohme (ENST, France) P. Tran-Gia (Univ. of W=FCrzburg, Germany) M. Uylat (Univ. of Waterloo, Canada) A. Valko (Ericsson, Sweden) A. Vilavaara (Nokia Research Center, Finland) A. Wolisz (Univ. of Berlin, Germany) J. Zander (KTH Stockholm, Sweden) M. Zukerman (Univ. of Melbourne, Australia) EW2004 CONTACT e-mail: ew2004@ac.upc.es FINANCE CHAIR Volker Schanz, VDE/ITG, Germany CONFERENCE SECRETARIAT VDE-Conference Department Stresemannallee 1560596 Frankfurt-Main Germany Phone: +49-69-6308-202 Fax: +49-69-97315213 e-mail: vde-conferences@vde.com URL: www.vde.com=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Sep 3 04:28:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13846 for ; Wed, 3 Sep 2003 04:28:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSzx-0000Cm-25 for manet-archive@odin.ietf.org; Wed, 03 Sep 2003 04:28:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h838SGgU000782 for manet-archive@odin.ietf.org; Wed, 3 Sep 2003 04:28:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSzw-0000CX-8e for manet-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 04:28:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13816 for ; Wed, 3 Sep 2003 04:28:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uSzt-0002ZW-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 04:28:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uSzs-0002ZS-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 04:28:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSzi-00008C-BV; Wed, 03 Sep 2003 04:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSz8-00007D-E0 for manet@optimus.ietf.org; Wed, 03 Sep 2003 04:27:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13762 for ; Wed, 3 Sep 2003 04:27:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uSz5-0002WI-00 for manet@ietf.org; Wed, 03 Sep 2003 04:27:23 -0400 Received: from pri-dns.cs.iitm.ernet.in ([202.141.25.89] helo=cello.cs.iitm.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 19uSz2-0002VW-00 for manet@ietf.org; Wed, 03 Sep 2003 04:27:21 -0400 Received: from rts.cs.iitm.ernet.in (rts.cs.iitm.ernet.in [10.6.6.3]) by cello.cs.iitm.ernet.in (8.12.5/8.12.5) with ESMTP id h838vQNW002017 for ; Wed, 3 Sep 2003 14:27:26 +0530 Date: Wed, 3 Sep 2003 13:17:08 +0530 (IST) From: "T. Bheemarjuna Reddy" To: manet@ietf.org In-Reply-To: <20030830160003.13801.55294.Mailman@www1.ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] doubt regarding 802.11 IFSs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, In 802.11 MAC protocol, the "slot time" id defined as aSlotTime = aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + aMACProcessingDelay. My doubt is why above all parameters be considered for determining "slot time" value. In otherwords, in 802.11b protocol, SIFS is set to 9 microsec, why cannot it be someother value say 5 microsec? Further, SIFS is defined as aSIFS = aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + aRxTxTurnaround time. My doubt is why "aAirPropagationTime" used in aSlotTime is not taken into consideration during calculation of aSIFS value? and WHY aDIFS = aSIFS + 2 x aSlotTime ? why cannot it be someother value say 30 microsec instead of 34 microsec in 802.11b protocol? If anybody knows, please clarify my doubts. Thanx inadvannce. -----arjun -- ============================ Bheemarjuna Reddy Tamma = Chennai -600036 = PHNO: 044-2257 9071(Hostel)= ============================ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Sep 3 05:39:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18101 for ; Wed, 3 Sep 2003 05:39:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uU6u-0004Nq-8Q for manet-archive@odin.ietf.org; Wed, 03 Sep 2003 05:39:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h839dWfU016847 for manet-archive@odin.ietf.org; Wed, 3 Sep 2003 05:39:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uU6t-0004Ne-Vc for manet-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 05:39:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18062 for ; Wed, 3 Sep 2003 05:39:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uU6q-0006yl-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 05:39:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uU6p-0006yi-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 05:39:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uU6Q-0004JT-D3; Wed, 03 Sep 2003 05:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uU61-0004Go-7u for manet@optimus.ietf.org; Wed, 03 Sep 2003 05:38:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18026 for ; Wed, 3 Sep 2003 05:38:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uU5x-0006xO-00 for manet@ietf.org; Wed, 03 Sep 2003 05:38:33 -0400 Received: from wasp.ece.queensu.ca ([130.15.22.4]) by ietf-mx with esmtp (Exim 4.12) id 19uU5w-0006xG-00 for manet@ietf.org; Wed, 03 Sep 2003 05:38:32 -0400 Received: from Yeh ([24.226.76.199]) by wasp.ECE.QUEENSU.CA with Microsoft SMTPSVC(5.0.2195.6713); Wed, 3 Sep 2003 05:39:09 -0400 From: "Chi-Hsiang Yeh" To: "'Zhenqiang\(Frank\) Ye'" , Cc: Subject: RE: [manet] Hidden Terminal Problem Date: Wed, 3 Sep 2003 05:38:07 -0400 Organization: Queen's Message-ID: <000001c371ff$14f70cc0$c74ce218@Yeh> 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 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 03 Sep 2003 09:39:09.0750 (UTC) FILETIME=[39D70D60:01C371FF] 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 IEEE 802.11 adaptors are typically able to transmit packets at multiple power levels. When some nodes/packets use lower power levels and some = other nodes/packets use higher power levels, the IEEE 802.11 DCF mode cannot completely avoid the hidden terminal problem even if it's a single hop environment or all the nodes are within the sensing range of each other = (for transmissions at maximum/higher power levels). DBTMA (based on busy tone) can completely avoid the hidden terminal = problem, but it assumes fixed transmission power. Some CDMA-based MAC schemes can completely avoid the problem. A scheme in the following paper (based on = what we call "collision prevention") can also completely avoid the hidden terminal problem in either single-hop or multihop environments. Yeh, C.-H., "High-throughput Interference-aware MAC Protocols for Heterogeneous Ad Hoc Networks and Multihop Wireless LANs," Proc. IEEE Globecom'03, Dec. 2003, to appear. Chihsiang ___________________________________________________________ Chi-Hsiang Yeh (Mr./Dr./Prof.) Dept. of Electrical & Computer Eng. Queen's University Kingston, Ontario, K7L 3N6 Canada phone: now: 1-702-730-7777 ext 30205=20 (+1 613-533-6368 office) 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 Zhenqiang(Frank) Ye Sent: Tuesday, September 02, 2003 12:58 PM To: S.Sivavakeesar@connectfree.co.uk Cc: manet@ietf.org Subject: Re: [manet] Hidden Terminal Problem IEEE 802.11 DCF can not completely avoid "hidden terminal problem". If all the mobile nodes are within the sensing range of each other (not necessarily within one hop), hidden terminal problem will not occur. On Tue, 2 Sep 2003 S.Sivavakeesar@connectfree.co.uk wrote: > Dear All : > > Can somebody tell me whether the IEEE 802.11 DCF can completely avoid > 'Hidden-Terminal' problem with the use of RTS-CTS, physical carrier-sensing > and NAV in multihop MANET ? Does it depends on distance between nodes = and > RTS & CTS duration ? Even if there is a chance for hidden terminal = problem > in multihop ad hoc networks, does IEEE 802.11 DCF mode operation in = single > hop environment completely avoid hidden-terminal problem. > > > Cheers > > SIVA > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > --=20 **************************************** Zhenqiang(Frank) Ye Ph.D Student Department of Electrical Engineering University of California, Riverside Phone: (909)-787-2434 email: zye@cs.ucr.edu **************************************** _______________________________________________ manet mailing 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 Sep 3 11:13:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14234 for ; Wed, 3 Sep 2003 11:13:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZJu-00061W-D8 for manet-archive@odin.ietf.org; Wed, 03 Sep 2003 11:13:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83FDIQV023148 for manet-archive@odin.ietf.org; Wed, 3 Sep 2003 11:13:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZJu-00061H-9F for manet-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 11:13: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 LAA14140 for ; Wed, 3 Sep 2003 11:13:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uZJt-0001MU-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 11:13:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uZJs-0001MR-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 11:13:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZJd-0005zm-EX; Wed, 03 Sep 2003 11:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZJV-0005zH-6L for manet@optimus.ietf.org; Wed, 03 Sep 2003 11:12:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14099 for ; Wed, 3 Sep 2003 11:12:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uZJU-0001Lb-00 for manet@ietf.org; Wed, 03 Sep 2003 11:12:52 -0400 Received: from metatron.isr.umd.edu ([128.8.111.5] helo=isrmail.isr.umd.edu ident=mirapoint) by ietf-mx with esmtp (Exim 4.12) id 19uZJT-0001LI-00 for manet@ietf.org; Wed, 03 Sep 2003 11:12:51 -0400 Received: from isr.umd.edu (doh.isr.umd.edu [128.8.140.151]) by isrmail.isr.umd.edu (Mirapoint Messaging Server MOS 3.3.5-GR) with ESMTP id AJT51871; Wed, 3 Sep 2003 11:12:29 -0400 (EDT) Message-ID: <3F5604DC.4000109@isr.umd.edu> Date: Wed, 03 Sep 2003 11:12:28 -0400 From: Manish Karir User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: manet@ietf.org Subject: Re: [manet] The Problem of Alien Node References: <000001c371b5$f6873060$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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit routing protocols in the two domains(ad hoc and terrestrial) play very different roles, terrestrial routing protocols(most) are generally proactive in nature, and they spread information regarding the availability of a "subnet" to the rest of the world. ad hoc routing protocols(lets just focus on AODV for now) are on-demand and they convey the reachability of "individual" nodes. Now when you try to build gateways, you have to be careful in how you translate these two very different semantics. first thing you want to consider is that you dont want the mobility of nodes in the manet to be propagated to the Internet, this lead us to the approach were you try to represent the entire manet subnet as a single prefix. This approach also makes entities like the IANA happy, as the "manet provider" is the responsible party for this manet subnet, and they dont have to hand out 5million IP's to individual manet nodes. now this approach work fine as long as you have a single gateway. The real problem is when we allow for multiple gateways. In this case you end up with all kinds of problems due to the different between the nature of the two protocols. For example, you can end up with inefficient routing paths, as hop count information from within the ad hoc network is not propagated to the terrestrial routing protocol. You can also end up with unreachable nodes, as partitioning in the ad hoc network, can create scenarios where some gateways can only reach some nodes and not the entire manet prefix. there are a few possible directions one can take to try to fix this problem: - dont do it: dont allow for multiple gateways, most subnets ususually have only a single point of attachment to the higher network, and since allowing for multiple gateways is a prickly problem, why bother, and complexity only adds more ways in which the system can fail anyways...etc. etc. - make up a complex protocol: this approach tries to basically undo the effects of the on-demand protocol being run in the manet, you propagate hop count information, to the gateway nodes, you propagate which nodes are present/reachable by the gateway for each node(registeration), etc. one possible candidate for this has been the use of mobile IP(there are various references on this approach) - run a proactive routing protocol: this approach would probably work a little bit better than making up a new protocol, but there are still a lot of corner cases to consider, and the jury is still out on whether proactive protocols are a good solution for ad hoc networks(please lets not start another thread on this argument and get distracted). bottom line: yes multiple gateways create a problem, and no there is no easy solution, the only point I think I'm trying to get across is that "alien node problem" is a problem only under certain assumptions of what you are allowing in the network(s). It is not a general problem with acheiving interoperability between ad hoc and terrestrial routing protocols. we currently have a paper under submission regarding some of these issues, but I hesitate to post non peer reviewed work to the list(who knows the work might be completely wrong in assumptions and approach) -manish karir PS: dont forget the problem of multicast routing and building a gateway to support that. HyunWook Cha wrote: > Hi Yasser, > I think "registration" is necessary for communications which are not > only manet local but also across Internet. > I mentioned this point at my previous posting. > But I think the "registration" can not be an solution for the "Alien > Node Problem". > Please think about this case. There are multiple gateways and a manet. > Manet nodes may have different sets of gateways because of partitions. > And, if a gateway chosen by souce node does not belong to the gateway > set of destination node, it will forward packets destined to desination > toward Internet. > I think a global static ip which you are considering is not globally > routable(reachable) since a manet node with globally routable global ip > is also reachable across Internet althogh it is local manet node. > If so, evenually souce node will be notified by ICMP destination > unreachable and do route discovery again in case of reactive protocols. > I think this is enough for destination node with the "global static ip" > which is not globally routable. > > Regards, > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > HyunWook Cha > > Researcher > NGI Standards Research Team > Protocol Engineering Center, ETRI > 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, KOREA > (Tel) +82-42-860-1076 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Sep 3 15:03:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29986 for ; Wed, 3 Sep 2003 15:03:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ucuR-0008Ky-6l for manet-archive@odin.ietf.org; Wed, 03 Sep 2003 15:03:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83J3Fo8032042 for manet-archive@odin.ietf.org; Wed, 3 Sep 2003 15:03:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ucuR-0008Kj-1s for manet-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 15:03: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 PAA29952 for ; Wed, 3 Sep 2003 15:03:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ucuM-0007VR-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 15:03:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ucuM-0007VO-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 15:03:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ucuE-0008JP-H7; Wed, 03 Sep 2003 15:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ucu4-0008Id-Oo for manet@optimus.ietf.org; Wed, 03 Sep 2003 15:02:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29931 for ; Wed, 3 Sep 2003 15:02:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ucu1-0007Ul-00 for manet@ietf.org; Wed, 03 Sep 2003 15:02:49 -0400 Received: from [203.199.83.39] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 19ucu0-0007Ui-00 for manet@ietf.org; Wed, 03 Sep 2003 15:02:49 -0400 Received: (qmail 7519 invoked by uid 510); 3 Sep 2003 19:02:04 -0000 Date: 3 Sep 2003 19:02:04 -0000 Message-ID: <20030903190204.7518.qmail@webmail29.rediffmail.com> Received: from unknown (202.9.176.135) by rediffmail.com via HTTP; 03 sep 2003 19:02:04 -0000 MIME-Version: 1.0 From: "kani mozhi" Reply-To: "kani mozhi" To: manet@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [manet] gateway configuration Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 friends could anyone tell me the factors to be considered while designing a gateway node in a manet which is satellite capable so it can access the fixed infrastructures via satellite ___________________________________________________ Law meets Electronics; Veena Weds Sanjay. Rediff Matchmaker strikes another interesting match !! Visit http://rediff.com/matchmaker?1 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Sep 3 20:33:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20745 for ; Wed, 3 Sep 2003 20:33:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ui42-0004v1-Kh for manet-archive@odin.ietf.org; Wed, 03 Sep 2003 20:33:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h840XUOt018901 for manet-archive@odin.ietf.org; Wed, 3 Sep 2003 20:33:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ui42-0004ul-CY for manet-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 20:33:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20700 for ; Wed, 3 Sep 2003 20:33:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ui40-0007Q4-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 20:33:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ui3z-0007Q1-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 20:33:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ui3a-0004t0-12; Wed, 03 Sep 2003 20:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ui3C-0004sS-FH for manet@optimus.ietf.org; Wed, 03 Sep 2003 20:32:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20648 for ; Wed, 3 Sep 2003 20:32:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ui3A-0007Ov-00 for manet@ietf.org; Wed, 03 Sep 2003 20:32:36 -0400 Received: from imo-d02.mx.aol.com ([205.188.157.34]) by ietf-mx with esmtp (Exim 4.12) id 19ui39-0007O7-00 for manet@ietf.org; Wed, 03 Sep 2003 20:32:35 -0400 Received: from samkshahnet@netscape.net by imo-d02.mx.aol.com (mail_out_v36_r1.1.) id l.2.a057031 (22683) for ; Wed, 3 Sep 2003 20:32:03 -0400 (EDT) Received: from netscape.net (dhcp-207-19.njit.edu [128.235.207.19]) by air-in04.mx.aol.com (v95.12) with ESMTP id MAILININ44-589b3f56880210c; Wed, 03 Sep 2003 20:32:03 -0400 Message-ID: <3F568800.5090401@netscape.net> Date: Wed, 03 Sep 2003 20:32:00 -0400 From: Shah 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: manet@ietf.org References: <20030903190204.7518.qmail@webmail29.rediffmail.com> In-Reply-To: <20030903190204.7518.qmail@webmail29.rediffmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 128.235.207.19 X-Mailer: Unknown (No Version) Content-Transfer-Encoding: 7bit Subject: [manet] Re: delay Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi all, i have a very basic question. can any one guide me what is the difference between wireless lan delay and end-to-end delay for mobile ad-hoc networks ? though it's very basic question, i am a bit confused. thanks, regards, shah --- kani_11@rediffmail.com wrote: > > > hi friends > could anyone tell me the factors to be considered while designing a > gateway node in a manet which is satellite capable so it can access > the fixed infrastructures via satellite > ___________________________________________________ > Law meets Electronics; Veena Weds Sanjay. > Rediff Matchmaker strikes another interesting match !! > Visit http://rediff.com/matchmaker?1 > > > _______________________________________________ > manet mailing 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 Sep 3 21:59:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25344 for ; Wed, 3 Sep 2003 21:59:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ujP8-0000PV-0M for manet-archive@odin.ietf.org; Wed, 03 Sep 2003 21:59:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h841xLc0001571 for manet-archive@odin.ietf.org; Wed, 3 Sep 2003 21:59:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ujP7-0000PG-TB for manet-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 21:59: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 VAA25308 for ; Wed, 3 Sep 2003 21:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ujP4-0002WV-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 21:59:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ujP4-0002WS-00 for manet-web-archive@ietf.org; Wed, 03 Sep 2003 21:59:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ujOn-0000LU-FE; Wed, 03 Sep 2003 21:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ujO6-0000Ha-VU for manet@optimus.ietf.org; Wed, 03 Sep 2003 21:58:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25255 for ; Wed, 3 Sep 2003 21:58:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ujO3-0002VS-00 for manet@ietf.org; Wed, 03 Sep 2003 21:58:15 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 19ujO2-0002UX-00 for manet@ietf.org; Wed, 03 Sep 2003 21:58:14 -0400 Received: from jafymobile (6ants5.etri.re.kr [129.254.112.239]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id SBCR340X; Thu, 4 Sep 2003 10:57:09 +0900 Reply-To: From: "HyunWook Cha" To: "'Manish Karir'" Cc: , "???????" Subject: RE: [manet] The Problem of Alien Node Date: Thu, 4 Sep 2003 10:57:45 +0900 Organization: ETRI Message-ID: <000001c37287$ef81abb0$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 Importance: Normal In-Reply-To: <3F5604DC.4000109@isr.umd.edu> 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 Manish, Please see inline comments. > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Manish Karir > Sent: Thursday, September 04, 2003 12:12 AM > Cc: manet@ietf.org > Subject: Re: [manet] The Problem of Alien Node > > > > > routing protocols in the two domains(ad hoc and terrestrial) > play very different roles, terrestrial routing protocols(most) are generally > proactive in nature, and they spread information regarding the > availability of a "subnet" to the rest of the world. ad hoc routing > protocols(lets just focus on AODV for now) are on-demand and they > convey the reachability of "individual" nodes. Now when you try to > build gateways, you have to be careful in how you translate these two > very different semantics. > > first thing you want to consider is that you dont want the > mobility of nodes in the manet to be propagated to the Internet, this > lead us to the approach were you try to represent the entire manet subnet as > a single prefix. This approach also makes entities like the IANA > happy, as the "manet provider" is the responsible party for this manet subnet, and > they dont have to hand out 5million IP's to individual manet nodes. Right. In Mobile IP, only HA has knowledge of current attach points of its cared MNs. > now this approach work fine as long as you have a single > gateway. The real problem is when we allow for multiple gateways. In this > case you end up with all kinds of problems due to the different between the > nature of the two protocols. For example, you can end up with > inefficient routing paths, as hop count information from > within the ad hoc network is not propagated to the terrestrial routing > protocol. You know, the purpose of Internet connectivity of MANET we are considering is that manet nodes can start(initiate) communication with locally unreachable but globally reachable nodes. To do so, a manet node has to configure its global address with the prefix of a gateway or gateways known to it in the stateful or stateless manner. And the manet node uses newly configured global ip as source address when it initiates communication with peer node. Since general MANET node is not equipped with MIPv6, it cannot perform procedure like RR in MIPv6. So, peer node can see only global ip used as source address by the manet node when the communication is started. Althogh the manet node has multiple globla IPs from multiple gateways and gateways which do not have same prefix as the ip used for the communication has route entry or some registration information for the ip, inbound traffic always arrives the gateway with the same prefix as ip which is chosen as source ip by the manet node. If so, what makes inefficient routing paths problem under multiple gateways? > You can also end up with unreachable nodes, as partitioning in the ad hoc > network, can create scenarios where some gateways can only reach some > nodes and not the entire manet prefix. This also happens in single gateway condition because of the nature of MANET. This is not specific to the multiple gateways case. > there are a few possible directions one can take to try to > fix this problem: > > - dont do it: dont allow for multiple gateways, most subnets > ususually have only a single point of attachment to the higher network, > and since allowing for multiple gateways is a prickly problem, why bother, and > complexity only adds more ways in which the system can fail > anyways...etc. etc. See the charter of IETF Multi6 wg. I think the use of multiple gateways can help Internet connectivity of MANET which has extremely dynamic topology by its nature. > - make up a complex protocol: this approach tries to basically undo the effects of the on-demand protocol being run in the manet, you > propagate hop count information, to the gateway nodes, you propagate which nodes are present/reachable by the gateway for each > node(registeration), etc. one possible candidate for this has been the use of mobile IP(there are various references on this approach) I also think the reachability informaiton for manet node should not propagate in proactive manner when reacive routing protocol is used. As I mentioned above, this kind of registration does not help. Could you point which approaches use Mobile IP? I also read a few papers including MIP-MANET. I am considering registration scheme of Mobile IP can help address unreachable manet node and developing ns2 simulation codes. What do you think of this approach? > - run a proactive routing protocol: this approach would > probably work a > little bit better than making up a new protocol, but there > are still a > lot of corner cases to consider, and the jury is still out on whether > proactive protocols are a good solution for ad hoc > networks(please lets > not start another thread on this argument and get distracted). Regardless of the type of routing protocol, reachability information of another addresses of destination manet node do not help in a gateway. > bottom line: yes multiple gateways create a problem, and no > there is no > easy solution, the only point I think I'm trying to get > across is that > "alien node problem" is a problem only under certain > assumptions of what > you are allowing in the network(s). It is not a general problem with > acheiving interoperability between ad hoc and terrestrial > routing protocols. IMO, the use of multiple gateways does not generate any issue which does not happen in the use of single gateway. Could you tell me how all manet nodes can choose the same one gateway when multiple gateways is available? > we currently have a paper under submission regarding some of these > issues, but I hesitate to post non peer reviewed work to the list(who > knows the work might be completely wrong in assumptions and approach) > I am interested in your idea and hope we can handle many issues of this area successfully. HyunWook Cha > -manish karir > > PS: dont forget the problem of multicast routing and building > a gateway > to support that. > > > HyunWook Cha wrote: > > Hi Yasser, > > I think "registration" is necessary for communications > which are not > > only manet local but also across Internet. I mentioned this > point at > > my previous posting. But I think the "registration" can not be an > > solution for the "Alien Node Problem". > > > > Please think about this case. There are multiple gateways > and a manet. > > Manet nodes may have different sets of gateways because of > partitions. > > And, if a gateway chosen by souce node does not belong to > the gateway > > set of destination node, it will forward packets destined to > > desination toward Internet. > > > > I think a global static ip which you are considering is not globally > > routable(reachable) since a manet node with globally > routable global > > ip is also reachable across Internet althogh it is local manet node. > > > > If so, evenually souce node will be notified by ICMP destination > > unreachable and do route discovery again in case of reactive > > protocols. I think this is enough for destination node with the > > "global static ip" which is not globally routable. > > > > Regards, > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > HyunWook Cha > > > > Researcher > > NGI Standards Research Team > > Protocol Engineering Center, ETRI > > 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, KOREA > > (Tel) +82-42-860-1076 > > > > > > > _______________________________________________ > manet mailing 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 Sep 4 21:30:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08221 for ; Thu, 4 Sep 2003 21:30:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v5Qd-0000oz-7m for manet-archive@odin.ietf.org; Thu, 04 Sep 2003 21:30:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h851UNE4003151 for manet-archive@odin.ietf.org; Thu, 4 Sep 2003 21:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v5Qd-0000ok-2Y for manet-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 21:30:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08193 for ; Thu, 4 Sep 2003 21:30:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v5Qa-0003Fv-00 for manet-web-archive@ietf.org; Thu, 04 Sep 2003 21:30:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v5QZ-0003Fs-00 for manet-web-archive@ietf.org; Thu, 04 Sep 2003 21:30:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v5QJ-0000kV-Uc; Thu, 04 Sep 2003 21:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v5Pb-0000jD-0P for manet@optimus.ietf.org; Thu, 04 Sep 2003 21:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08156 for ; Thu, 4 Sep 2003 21:29:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v5PY-0003Ef-00 for manet@ietf.org; Thu, 04 Sep 2003 21:29:16 -0400 Received: from web20004.mail.yahoo.com ([216.136.225.49]) by ietf-mx with smtp (Exim 4.12) id 19v5PX-0003Ec-00 for manet@ietf.org; Thu, 04 Sep 2003 21:29:15 -0400 Message-ID: <20030905012915.89774.qmail@web20004.mail.yahoo.com> Received: from [203.106.64.249] by web20004.mail.yahoo.com via HTTP; Thu, 04 Sep 2003 18:29:15 PDT Date: Thu, 4 Sep 2003 18:29:15 -0700 (PDT) From: Pan Zheng To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] what is a good start of research on 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: , what is a good start of research on MANET? i am new to MANET, just join this maillist. anyone can give me an idea on what is a good start of research on MANET? what is the basic knowledges requirements before heading in reseach of MANET? i did read some about MANET, currenty i had some basic idea of MANET. i plan to do some research on MANET for my master degree. so any suggestions? appreciate. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 4 22:48:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13046 for ; Thu, 4 Sep 2003 22:48:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6e4-0004T3-0f for manet-archive@odin.ietf.org; Thu, 04 Sep 2003 22:48:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h852mJ07017167 for manet-archive@odin.ietf.org; Thu, 4 Sep 2003 22:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6e3-0004So-SS for manet-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 22:48:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12961 for ; Thu, 4 Sep 2003 22:48:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v6dx-0005k7-00 for manet-web-archive@ietf.org; Thu, 04 Sep 2003 22:48:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v6dw-0005k4-00 for manet-web-archive@ietf.org; Thu, 04 Sep 2003 22:48:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6dm-0004Jr-05; Thu, 04 Sep 2003 22:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v6d1-0004IF-Q4 for manet@optimus.ietf.org; Thu, 04 Sep 2003 22:47: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 WAA12892 for ; Thu, 4 Sep 2003 22:47:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v6cy-0005ie-00 for manet@ietf.org; Thu, 04 Sep 2003 22:47:12 -0400 Received: from mailb.its.uidaho.edu ([129.101.155.251]) by ietf-mx with esmtp (Exim 4.12) id 19v6cx-0005gZ-00 for manet@ietf.org; Thu, 04 Sep 2003 22:47:11 -0400 Received: from uidaho.edu (mailB [129.101.155.251]) by mailB.its.uidaho.edu (Go Vandals!) with ESMTP id <0HKP00DOSZPUD6@mailB.its.uidaho.edu> for manet@ietf.org; Thu, 04 Sep 2003 19:46:42 -0700 (PDT) Received: from [129.101.80.136] by mailB.its.uidaho.edu (mshttpd); Thu, 04 Sep 2003 19:46:42 -0700 Date: Thu, 04 Sep 2003 19:46:42 -0700 From: Jianqiang Zeng To: manet@ietf.org Message-id: <6ab10b6adabe.6adabe6ab10b@uidaho.edu> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.12 (built Feb 13 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal Content-Transfer-Encoding: 7BIT Subject: [manet] applying MANETs into the underwater vehicle communication network? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, are there anybody doing the research on applying MANETs into the underwater vehicle communication network? The constrains in underwater communication network are extremely low data rates, many nodes, high volume per node, and variable node to node connectivity. I am concerning about what kind of routing protocol of MANETs is appropriate to address these constrains? Proactive, reactive or some other kind of protocols? I am new to MANETs, any advice will be most appreciated. Thanks! Best Regards Jianqiang Zeng _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 6 11:40:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20789 for ; Sat, 6 Sep 2003 11:40:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vfAm-0001Zp-CO for manet-archive@odin.ietf.org; Sat, 06 Sep 2003 11:40:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h86FeOAR006055 for manet-archive@odin.ietf.org; Sat, 6 Sep 2003 11:40:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vfAm-0001Za-94 for manet-web-archive@optimus.ietf.org; Sat, 06 Sep 2003 11:40:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20745 for ; Sat, 6 Sep 2003 11:40:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vfAl-0002ZG-00 for manet-web-archive@ietf.org; Sat, 06 Sep 2003 11:40:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vfAk-0002ZD-00 for manet-web-archive@ietf.org; Sat, 06 Sep 2003 11:40:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vfAS-0001YA-8H; Sat, 06 Sep 2003 11:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vf9z-0001X5-A7 for manet@optimus.ietf.org; Sat, 06 Sep 2003 11:39:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20726 for ; Sat, 6 Sep 2003 11:39:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vf9y-0002YU-00 for manet@ietf.org; Sat, 06 Sep 2003 11:39:34 -0400 Received: from den.erg.sri.com ([128.18.100.23]) by ietf-mx with esmtp (Exim 4.12) id 19vf9x-0002YF-00 for manet@ietf.org; Sat, 06 Sep 2003 11:39:33 -0400 Received: from den.erg.sri.com (localhost [127.0.0.1]) by den.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id IAA07089; Sat, 6 Sep 2003 08:38:59 -0700 (PDT) Message-Id: <200309061538.IAA07089@den.erg.sri.com> To: jelger@clarinet.u-strasbg.fr, manet@ietf.org cc: ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Comments on draft-jelger In-reply-to: Your message of "Tue, 02 Sep 2003 11:20:31 +0200." <1062494431.3f5460df0bf7c@clarinet.u-strasbg.fr> Date: Sat, 06 Sep 2003 08:38:59 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , To Christophe and all, I thought more about the solution in your draft, and the benefits of "prefix continuity". One of the benefits of prefix continuity that I did not consider before is that it allows hop-by-hop default routing, without using a routing header to specify the gateway. (This is because the default next-hop router has the same prefix and thus has a consistent default route.) Also, I understand that your method minimizes the number of prefix changes, given that you want to maintain prefix continuity. (For example, it requires fewer changes than if a manet node was required to always select a nearest gateway and use its prefix.) I think it would be better to allow changing the prefix if another gateway becomes *much* closer, but my main point in this message is whether or not prefix continuity should be required. I see three possible solutions, depending on whether prefix continuity is required, and on whether a packet routed to the internet must go thru a gateway having the same prefix as the sender. I hope people will comment on which of these three solution is preferable, and whether any of them (particularly the first one) is unacceptable. 1. The default route always uses the nearest gateway, regardless of its prefix. Prefix continuity is not maintained. Benefit: Hop-by-hop default routing is easy (without routing header). Benefit: A manet node does not need to change its prefix to maintain prefix continuity. Drawback: Gateway prefix may be different from sender prefix, which could cause a problem with source address filtering, and the reverse route could go thru a different gateway with a different prefix. (Are these drawbacks acceptable?) 2. The default route is required to use a gateway with the same prefix as the sending node, even if there is a closer gateway, but prefix continuity is not maintained. Benefit: Gateway prefix is same as sender prefix. Benefit: A manet node does not need to change its prefix to maintain prefix continuity. Drawback: A routing header (to reach gateway) is required for default routing. Hop-by-hop default routing is not possible. 3. Same as 2, but prefix continuity is maintained. Benefit: Gateway prefix is same as sender prefix. Benefit: Hop-by-hop default routing is possible (without routing header). Drawback: A manet node may need to change its prefix to maintain prefix continuity, unlike the first two solutions. In my opinion, the first solution is best if it is OK to route the packet thru a gateway with a different prefix, otherwise the second solution is best if using a routing header is not considered a significant drawback, otherwise the third solution is best. Regards, Richard _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Sep 7 13:30:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20154 for ; Sun, 7 Sep 2003 13:30:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w3MQ-0002oj-C0 for manet-archive@odin.ietf.org; Sun, 07 Sep 2003 13:30:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h87HU2u9010818 for manet-archive@odin.ietf.org; Sun, 7 Sep 2003 13:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w3MP-0002oL-FL for manet-web-archive@optimus.ietf.org; Sun, 07 Sep 2003 13:30:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19898 for ; Sun, 7 Sep 2003 13:29:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w3MM-0006uM-00 for manet-web-archive@ietf.org; Sun, 07 Sep 2003 13:29:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19w3MM-0006uI-00 for manet-web-archive@ietf.org; Sun, 07 Sep 2003 13:29:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w3LU-0002cj-Ho; Sun, 07 Sep 2003 13:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19w3Kf-0002Wd-4Q for manet@optimus.ietf.org; Sun, 07 Sep 2003 13:28: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 NAA19216 for ; Sun, 7 Sep 2003 13:28:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19w1kg-00006r-00 for manet@ietf.org; Sun, 07 Sep 2003 11:46:58 -0400 Received: from www5.mail.lycos.com ([209.202.220.85] helo=lycos.com) by ietf-mx with smtp (Exim 4.12) id 19w1kg-0007ju-00 for manet@ietf.org; Sun, 07 Sep 2003 11:46:58 -0400 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sun, 07 Sep 2003 15:46:11 -0000 To: manet@ietf.org Date: Sun, 07 Sep 2003 11:46:11 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] The Problem of Alien Node X-Sender-Ip: 134.117.61.61 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Great replies from both of you. I have three points to make: 1) The "alien node problem" may exist on proactive routing algorithm. Since the gateway is associated with generic addresses, a node will search it's lookup table for destination address, then it finds the destination (alien address) and the gateway (generic address). Based on the decision src node will make, we may have the "alien node problem" 2) By registration I mean that an alien node (a node that doesn't follow the MANET_PREFIX address) will have to register it's address with the gateway. Then periodically refresh this registration, otherwise, the gateway will periodically remove unrefreshed registration. In this way, The gateway will have to check destination address of pkts, and forward out of the network only pkts with unregistered address at alien table. In case of partition, the registration will be removed after a while. In multiple gateways, all of them will receive the registration msg. 3) Iagree it is confusing, because if an alien node (with globaly routable static ip) needs to be reachable from the Internet, it has to use a gateway as a c/o address. This the dynamics of the MANET environment, it is hard to maintain this info. Some co-ordination between the gateways (multiple gw) has to be done. Well, for now, there seem to be an agreement on a missing role the gw has to do on registration. The assumptions of the ad-hoc environment is still vague in this respect. I believe we need to define the basic assumptions of the ad-hoc gateways, and how they may connect to the Internet. Regards, yasser --------------------------------------------- Hi Yasser, I think "registration" is necessary for communications which are not only manet local but also across Internet. I mentioned this point at my previous posting. But I think the "registration" can not be an solution for the "Alien Node Problem". Please think about this case. There are multiple gateways and a manet. Manet nodes may have different sets of gateways because of partitions. And, if a gateway chosen by souce node does not belong to the gateway set of destination node, it will forward packets destined to desination toward Internet. I think a global static ip which you are considering is not globally routable(reachable) since a manet node with globally routable global ip is also reachable across Internet althogh it is local manet node. If so, evenually souce node will be notified by ICMP destination unreachable and do route discovery again in case of reactive protocols. I think this is enough for destination node with the "global static ip" which is not globally routable. Regards, ++++++++++++++++++++++++++++++++++++++++++++++++++++ HyunWook Cha Researcher NGI Standards Research Team Protocol Engineering Center, ETRI 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, KOREA (Tel) +82-42-860-1076 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Yasser A. Lotfy > Sent: Tuesday, September 02, 2003 12:25 AM > To: manet@ietf.org; Manish Karir > Subject: Re: [manet] The Problem of Alien Node > > > > Hi, > That is exactly my point. Ad-hoc nodes may not always have a > MANET_PREFIX IP address due to possibilities of nodes roaming > with a static IP, and the chances of ad-hoc network getting > partitioned or merged. > > Therefore, it is not possible for ad-hoc nodes to rely merely > on MANET_PREFIX IP address to distinguish local nodes (LAA). > The gateway also will asume nodes that don't have > MANET_PREFIX IP address are external, and will forward > packets outside the ad-hoc. While in fact some nodes that > don't have MANET_PREFIX IP address are local nodes, with > global static IP (I call it alien nodes). > > Therefore, I believe, there should be a registration > mechanism for all alien nodes at the gateway. > > Any comments? any reason why not? > > yasser > ---------------------------------------------- > I'm sorry but the point that you are trying to get across is not very > clear, and your terminology is quite confusing... > perhaps it would become clearer if we knew what your references > were...[047-01] and [048-01]. > > when building a scenario that incorportes both terrestrial > and ad hoc nodes, it is best to use address in MANET_PREFIX > to identify ad hoc nodes. this way the gateway knows which > address are in manet and which are in terrestrial network. > These address spaces should be mutually exclusive, or you are > going to run into the problems that you describe(atleast > thats what I think you are talking about). > > alternately, if you decide that the two address spaces can > intermingle, then you need to run complex > registration/deregistration protocols at the gateway to > inform the gateway which addresses(nodes) are in the > manet.(some hybrid form of MIP). > > -manish > > > > Yasser A. Lotfy wrote: > > Hi, > > > > I hope you read the attached (word) document which raises > awareness of > > the > > > problem of alien node. Sorry I have to make it in MS-Word > since some > > of the symbols > > > can not be done as text. > > > > The problem is simply due to the confusion that takes place when > > gateways announce > > > there ability to forward packets to generic addresses. Some local > > ad-hoc nodes may fall > > > in this generic address range. Therefore, packets may > (incorrectly) be > > forwarded to GW. > > > I hope to get feedback if any solution currently exist to this > > problem. > > > > yasser > > --- > *********************************************** > A train station is the place where trains stop, > A bus station is the place where buses stop, > On my desk they installed a workstation !! > *********************************************** > > > > > > > ____________________________________________________________ Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 8 00:06:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04544 for ; Mon, 8 Sep 2003 00:06:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wDHZ-0005yD-0d for manet-archive@odin.ietf.org; Mon, 08 Sep 2003 00:05:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8845egP022948 for manet-archive@odin.ietf.org; Mon, 8 Sep 2003 00:05:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wDHY-0005y3-SF for manet-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 00:05:40 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04457 for ; Mon, 8 Sep 2003 00:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wDGh-0005Xc-OX; Mon, 08 Sep 2003 00:04:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wBHX-0001pe-Jt for manet@optimus.ietf.org; Sun, 07 Sep 2003 21:57:32 -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 VAA26842 for ; Sun, 7 Sep 2003 21:57:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wBHU-0007SH-00 for manet@ietf.org; Sun, 07 Sep 2003 21:57:28 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 19wBHT-0007NU-00 for manet@ietf.org; Sun, 07 Sep 2003 21:57:28 -0400 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.2656.59) id SBCR38ZL; Mon, 8 Sep 2003 10:56:11 +0900 Reply-To: From: "HyunWook Cha" To: , Cc: "????????" Subject: RE: [manet] The Problem of Alien Node Date: Mon, 8 Sep 2003 10:57:07 +0900 Message-ID: <000001c375ac$8225b5c0$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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Yasser, Please see inline comments. > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Yasser A. Lotfy > Sent: Monday, September 08, 2003 12:46 AM > To: manet@ietf.org > Subject: RE: [manet] The Problem of Alien Node > > > > Great replies from both of you. I have three points to make: > 1) The "alien node problem" may exist on proactive routing > algorithm. Since the gateway is associated with generic > addresses, a node will search it's lookup table for > destination address, then it finds the destination (alien > address) and the gateway (generic address). Based on the > decision src node will make, we may have the "alien node problem" In proactive routing protocol, sourc looks up its routing table to forward its packets and it will use default route for a Internet gateway if the corresponding host route entry (/128) does not exist. If you are focusing on the static global ip which is not globally reachable, it has same semantic as manet local ip with MANET_PREFIX. Anyway, if source node can not discover host route for the static global ip, it can not but forward toward its default gateway since it only knows that destination ip is global one. As I said in my previous reply, after receiving ICMP, souce node does host route discovery in case of reactive routing protocols or simply discards packets with the static global destination ip until it finally finds host route for the destination or some timer is expired in case of proactive ones. IMO, this is enough for "alien node problem" that you defined. The "registration" scheme can be also helpful because time and some packet loss which is taken until src node is notified that destination is not globally reachable can be reduced. But, it can not be the ultimate solution. Manet nodes may have different sets of gateways because of partitions. So, the gateway chosen by src node may not have "the registration entry" for the static global destination ip. > 2) By registration I mean that an alien node (a node that > doesn't follow the MANET_PREFIX address) will have to > register it's address with the gateway. Then periodically > refresh this registration, otherwise, the gateway will > periodically remove unrefreshed registration. In this way, > The gateway will have to check destination address of pkts, > and forward out of the network only pkts with unregistered > address at alien table. In case of partition, the > registration will be removed after a while. In multiple > gateways, all of them will receive the registration msg. Because of frequent partitioning in MANET, you cannot guarantee that all nodes with static global ip can register its address with all gateways. > 3) Iagree it is confusing, because if an alien node (with > globaly routable static ip) needs to be reachable from the > Internet, it has to use a gateway as a c/o address. This the > dynamics of the MANET environment, it is hard to maintain > this info. Some co-ordination between the gateways (multiple > gw) has to be done. You seem to consider cases like mip-manet. I do not want to see this case as special one because the only difference is "home registration" through which the node registers its CoA with the prefix from a gateway with its HA. Difficulty caused by the nature of MANET also exists in incoming traffic packets of the communication between a manet node(not MIP node) and Internet node. For optimization using multiple gateways, some co-ordination or other methods can be applied. > > Well, for now, there seem to be an agreement on a missing > role the gw has to do on registration. The assumptions of the > ad-hoc environment is still vague in this respect. I believe > we need to define the basic assumptions of the ad-hoc > gateways, and how they may connect to the Internet. > Basically, I do not think that "the registaration" you meant is not essential for the reason which is mentioned repeatedly. I think route informations obtained by routing protocols and ICMP messages are enough for "the alien node problem". For the communication between a manet node and Internet one, I propose a manet node registers its permanent(or quite stable) ip with MANET_PREFIX and its dynamically configured global IP with prefix from a gateway with the corresponding gateway. As I said in the previouse reply, this information can be useful for incoming traffic from Internet to MANET. What do you think about this? Regards, Hyunwook Cha. > Regards, > yasser > --------------------------------------------- > Hi Yasser, > I think "registration" is necessary for communications which > are not only manet local but also across Internet. I > mentioned this point at my previous posting. But I think the > "registration" can not be an solution for the "Alien Node > Problem". Please think about this case. There are multiple > gateways and a manet. Manet nodes may have different sets of > gateways because of partitions. And, if a gateway chosen by > souce node does not belong to the gateway set of destination > node, it will forward packets destined to desination toward > Internet. I think a global static ip which you are > considering is not globally routable(reachable) since a manet > node with globally routable global ip is also reachable > across Internet althogh it is local manet node. If so, > evenually souce node will be notified by ICMP destination > unreachable and do route discovery again in case of reactive > protocols. I think this is enough for destination node with > the "global static ip" which is not globally routable. > > Regards, > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > HyunWook Cha > > Researcher > NGI Standards Research Team > Protocol Engineering Center, ETRI > 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, KOREA > (Tel) +82-42-860-1076 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > -----Original Message----- > > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > > Behalf Of Yasser A. Lotfy > > Sent: Tuesday, September 02, 2003 12:25 AM > > To: manet@ietf.org; Manish Karir > > Subject: Re: [manet] The Problem of Alien Node > > > > > > > > Hi, > > That is exactly my point. Ad-hoc nodes may not always have a > > MANET_PREFIX IP address due to possibilities of nodes roaming > > with a static IP, and the chances of ad-hoc network getting > > partitioned or merged. > > > > Therefore, it is not possible for ad-hoc nodes to rely merely > > on MANET_PREFIX IP address to distinguish local nodes (LAA). > > The gateway also will asume nodes that don't have > > MANET_PREFIX IP address are external, and will forward > > packets outside the ad-hoc. While in fact some nodes that > > don't have MANET_PREFIX IP address are local nodes, with > > global static IP (I call it alien nodes). > > > > Therefore, I believe, there should be a registration > > mechanism for all alien nodes at the gateway. > > > > Any comments? any reason why not? > > > > yasser > > ---------------------------------------------- > > I'm sorry but the point that you are trying to get across > is not very > > clear, and your terminology is quite confusing... > > perhaps it would become clearer if we knew what your references > > were...[047-01] and [048-01]. > > > > when building a scenario that incorportes both terrestrial > > and ad hoc nodes, it is best to use address in MANET_PREFIX > > to identify ad hoc nodes. this way the gateway knows which > > address are in manet and which are in terrestrial network. > > These address spaces should be mutually exclusive, or you are > > going to run into the problems that you describe(atleast > > thats what I think you are talking about). > > > > alternately, if you decide that the two address spaces can > > intermingle, then you need to run complex > > registration/deregistration protocols at the gateway to > > inform the gateway which addresses(nodes) are in the > > manet.(some hybrid form of MIP). > > > > -manish > > > > > > > > Yasser A. Lotfy wrote: > > > Hi, > > > > > > I hope you read the attached (word) document which raises > > awareness of > > > the > > > > > problem of alien node. Sorry I have to make it in MS-Word > > since some > > > of the symbols > > > > > can not be done as text. > > > > > > The problem is simply due to the confusion that takes place when > > > gateways announce > > > > > there ability to forward packets to generic addresses. Some local > > > ad-hoc nodes may fall > > > > > in this generic address range. Therefore, packets may > > (incorrectly) be > > > forwarded to GW. > > > > > I hope to get feedback if any solution currently exist to this > > > problem. > > > > > > yasser > > > --- > > *********************************************** > > A train station is the place where trains stop, > > A bus station is the place where buses stop, > > On my desk they installed a workstation !! > > *********************************************** > > > > > > > > > > > > > > > > > > ____________________________________________________________ > Get advanced SPAM filtering on Webmail or POP Mail ... Get > Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005 > > _______________________________________________ > manet mailing 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 Sep 8 03:06:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26788 for ; Mon, 8 Sep 2003 03:06:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wG66-0005ks-6K for manet-archive@odin.ietf.org; Mon, 08 Sep 2003 03:06:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88761Pd022107 for manet-archive@odin.ietf.org; Mon, 8 Sep 2003 03:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wG65-0005kO-BW for manet-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 03:06:01 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26697 for ; Mon, 8 Sep 2003 03:05:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wG5O-0005Vu-F2; Mon, 08 Sep 2003 03:05:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wF4s-00025S-Tr for manet@optimus.ietf.org; Mon, 08 Sep 2003 02:00:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12004 for ; Mon, 8 Sep 2003 02:00:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wF4p-0007Ki-00 for manet@ietf.org; Mon, 08 Sep 2003 02:00:39 -0400 Received: from law15-f41.law15.hotmail.com ([64.4.23.41] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19wF4p-0007DG-00 for manet@ietf.org; Mon, 08 Sep 2003 02:00:39 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 Sep 2003 22:59:44 -0700 Received: from 203.129.220.115 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 08 Sep 2003 05:59:43 GMT X-Originating-IP: [203.129.220.115] X-Originating-Email: [karun8880@hotmail.com] From: "Karun Verma" To: manet@ietf.org Date: Mon, 08 Sep 2003 11:29:43 +0530 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 08 Sep 2003 05:59:44.0304 (UTC) FILETIME=[66B02B00:01C375CE] Subject: [manet] Help for Simulation of 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: ,


Hello Friends,

Could you please give me reference to any protocol that has been simulated in ns2. so that from its reference i could get some hint of the simulation environment. also help me in selecting the right version of ns2 on win32 platform.

Thanx in Advance

See you


Need a naukri? Your search ends here. 50,000 of the best jobs! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 8 03:13:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27376 for ; Mon, 8 Sep 2003 03:13:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wGCW-0006oU-CQ for manet-archive@odin.ietf.org; Mon, 08 Sep 2003 03:12:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h887Ce8T026184 for manet-archive@odin.ietf.org; Mon, 8 Sep 2003 03:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wGCV-0006oF-Cb for manet-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 03:12:39 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27284 for ; Mon, 8 Sep 2003 03:12:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wGBs-0006bu-2d; Mon, 08 Sep 2003 03:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wGBk-0006bQ-LI for manet@optimus.ietf.org; Mon, 08 Sep 2003 03:11:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27241 for ; Mon, 8 Sep 2003 03:11:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wGBg-0006Os-00 for manet@ietf.org; Mon, 08 Sep 2003 03:11:48 -0400 Received: from mail11.ntu.edu.sg ([155.69.5.163]) by ietf-mx with esmtp (Exim 4.12) id 19wGBg-0006Eb-00 for manet@ietf.org; Mon, 08 Sep 2003 03:11:48 -0400 Received: from mail01.student.main.ntu.edu.sg ([155.69.5.165]) by mail11.ntu.edu.sg with Microsoft SMTPSVC(5.0.2195.5576); Mon, 8 Sep 2003 15:10:27 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] doubt regarding 802.11 IFSs Date: Mon, 8 Sep 2003 15:10:26 +0800 Message-ID: <3D565922795545468AE3E3DA2881BEA901C73612@mail01.student.main.ntu.edu.sg> Thread-Topic: [manet] doubt regarding 802.11 IFSs Thread-Index: AcNyIzcdjYNBD3DcRmqc4B7kpycvVADrwCMg From: "#LI ZHIFEI#" To: "T. Bheemarjuna Reddy" Cc: X-OriginalArrivalTime: 08 Sep 2003 07:10:27.0158 (UTC) FILETIME=[47A04F60:01C375D8] 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, My answer to your questions are as follows: >aSlotTime =3D aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + >aMACProcessingDelay. The SotTime is specified as above to ensure that the transmission by the = winning node (say A) will be sensed within the same slot by the MAC = layer of all the other nodes(e.g., node B) .=20 Otherwise, even though nodes A and B choose different backoff values = (say 6 and 7 slots, respectively), node B will transmit after node A has = already begin to transmit, resulting in a collision. Note that even with = the above rule for the SlotTime, the collision between two nodes having = different backoff values may not be avoided when the time is not = synchronized. >aSlotTime =3D aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + >aMACProcessingDelay. To my knowledge, the SIFS should be 28 us for FHSS while it should be 10 = us for DSSS in IEEE 802.11b rather than being 9 us.=20 The SIFS (as well as the SlotTime) is determined by the physical layer = and thus you cannot set as you want. The SIFS is designed as above to ensure that it is equal to the minimum = time required by a node to turn from the receiving state to transmit = state (e.g., from receiving RTS to transmit CTS). That is also why it = needs not include the aAirPropagationTime. >>WHY aDIFS =3D aSIFS + 2 x aSlotTime ? why cannot it be someother value >>say 30 microsec instead of 34 microsec in 802.11b protocol? A->B=20 C Consider the above scenario where a frame exchange sequence is in = progress between nodes A and B while node C is deferring. After A transmited a RTS to B, before node B sends back a CTS, it takes = a SIFS time for B to turn from receiving node to transmitting node. Then, it may take a SlotTime for node C senses the transmission of CTS. = Therefore, to give priority for the ongoing transmission, the DIFS must = be greater than (aSIFS + aSlotTime). I think the reason that the standard chooses 2 x aSlotTime rather than = 1 x aSlotTime is just to make the protocol more relialbe. Moreover, the DIFS value should be 50 us in DSSS of IEEE 802.11b. Best regards Li zhifei -----Original Message----- From: T. Bheemarjuna Reddy [mailto:arjun@cs.iitm.ernet.in] Sent: dimecres, 3 / setembre / 2003 15:47 To: manet@ietf.org Subject: [manet] doubt regarding 802.11 IFSs Hi all, In 802.11 MAC protocol, the "slot time" id defined as aSlotTime =3D aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + aMACProcessingDelay. My doubt is why above all parameters be considered for determining "slot time" value. In otherwords, in 802.11b protocol, SIFS is set to 9 microsec, why cannot it be someother value say 5 microsec? Further, SIFS is defined as=20 aSIFS =3D aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + = aRxTxTurnaround time. My doubt is why "aAirPropagationTime" used in aSlotTime is not taken = into consideration during calculation of aSIFS value? and=20 WHY aDIFS =3D aSIFS + 2 x aSlotTime ? why cannot it be someother value say 30 microsec instead of 34 microsec in 802.11b protocol? If anybody knows, please clarify my doubts. Thanx inadvannce. -----arjun --=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 Bheemarjuna Reddy Tamma =3D Chennai -600036 =3D PHNO: 044-2257 9071(Hostel)=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 _______________________________________________ manet mailing 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 Sep 8 13:52:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11024 for ; Mon, 8 Sep 2003 13:52:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQBa-0006xO-6w for manet-archive@odin.ietf.org; Mon, 08 Sep 2003 13:52:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88HqMW7026736 for manet-archive@odin.ietf.org; Mon, 8 Sep 2003 13:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQBa-0006x9-3Q for manet-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 13:52:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11012 for ; Mon, 8 Sep 2003 13:52:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQBX-0004Vq-00 for manet-web-archive@ietf.org; Mon, 08 Sep 2003 13:52:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wQBX-0004Vk-00 for manet-web-archive@ietf.org; Mon, 08 Sep 2003 13: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 19wQBF-0006va-VU; Mon, 08 Sep 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQAj-0006uI-AO for manet@optimus.ietf.org; Mon, 08 Sep 2003 13:51:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10979 for ; Mon, 8 Sep 2003 13:51:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQAh-0004VG-00 for manet@ietf.org; Mon, 08 Sep 2003 13:51:27 -0400 Received: from www3.mail.lycos.com ([209.202.220.160] helo=lycos.com) by ietf-mx with smtp (Exim 4.12) id 19wQAg-0004U7-00 for manet@ietf.org; Mon, 08 Sep 2003 13:51:26 -0400 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon, 08 Sep 2003 17:50:49 -0000 To: manet@ietf.org, jafy@etri.re.kr Date: Mon, 08 Sep 2003 13:50:49 -0400 From: "Yasser A. Lotfy" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: yasser.lotfy@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: RE: [manet] The Problem of Alien Node X-Sender-Ip: 134.117.61.61 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Manish, you are generaly right, please read my comments below. yasser -----Original Message----- >Hi Yasser, >Please see inline comments. > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Yasser A. Lotfy > Sent: Monday, September 08, 2003 12:46 AM > To: manet@ietf.org > Subject: RE: [manet] The Problem of Alien Node > > > > Great replies from both of you. I have three points to make: > 1) The "alien node problem" may exist on proactive routing > algorithm. Since the gateway is associated with generic > addresses, a node will search it's lookup table for > destination address, then it finds the destination (alien > address) and the gateway (generic address). Based on the > decision src node will make, we may have the "alien node problem" In proactive routing protocol, sourc looks up its routing table to forward its packets and it will use default route for a Internet gateway if the corresponding host route entry (/128) does not exist. If you are focusing on the static global ip which is not globally reachable, it has same semantic as manet local ip with MANET_PREFIX. Anyway, if source node can not discover host route for the static global ip, it can not but forward toward its default gateway since it only knows that destination ip is global one. As I said in my previous reply, after receiving ICMP, souce node does host route discovery in case of reactive routing protocols or simply discards packets with the static global destination ip until it finally finds host route for the destination or some timer is expired in case of proactive ones. IMO, this is enough for "alien node problem" that you defined. The "registration" scheme can be also helpful because time and some packet loss which is taken until src node is notified that destination is not globally reachable can be reduced. But, it can not be the ultimate solution. Manet nodes may have different sets of gateways because of partitions. So, the gateway chosen by src node may not have "the registration entry" for the static global destination ip. [Yasser] Agree. > 2) By registration I mean that an alien node (a node that > doesn't follow the MANET_PREFIX address) will have to > register it's address with the gateway. Then periodically > refresh this registration, otherwise, the gateway will > periodically remove unrefreshed registration. In this way, > The gateway will have to check destination address of pkts, > and forward out of the network only pkts with unregistered > address at alien table. In case of partition, the > registration will be removed after a while. In multiple > gateways, all of them will receive the registration msg. Because of frequent partitioning in MANET, you cannot guarantee that all nodes with static global ip can register its address with all gateways. [Yasser] Not really, all gateways reachable by destination will be updated by alien node registration in timely manner (please re-read). > 3) Iagree it is confusing, because if an alien node (with > globaly routable static ip) needs to be reachable from the > Internet, it has to use a gateway as a c/o address. This the > dynamics of the MANET environment, it is hard to maintain > this info. Some co-ordination between the gateways (multiple > gw) has to be done. You seem to consider cases like mip-manet. I do not want to see this case as special one because the only difference is "home registration" through which the node registers its CoA with the prefix from a gateway with its HA. Difficulty caused by the nature of MANET also exists in incoming traffic packets of the communication between a manet node(not MIP node) and Internet node. For optimization using multiple gateways, some co-ordination or other methods can be applied. [Yasser] I agree, and think we need to start talking about gateway issues. > > Well, for now, there seem to be an agreement on a missing > role the gw has to do on registration. The assumptions of the > ad-hoc environment is still vague in this respect. I believe > we need to define the basic assumptions of the ad-hoc > gateways, and how they may connect to the Internet. > Basically, I do not think that "the registaration" you meant is not essential for the reason which is mentioned repeatedly. I think route informations obtained by routing protocols and ICMP messages are enough for "the alien node problem". For the communication between a manet node and Internet one, I propose a manet node registers its permanent(or quite stable) ip with MANET_PREFIX and its dynamically configured global IP with prefix from a gateway with the corresponding gateway. As I said in the previouse reply, this information can be useful for incoming traffic from Internet to MANET. What do you think about this? [Yasser] I agree, and believe manet node has to register with all reachable gateways, not with a selected one. Regards, Hyunwook Cha. > Regards, > yasser > --------------------------------------------- > Hi Yasser, > I think "registration" is necessary for communications which > are not only manet local but also across Internet. I > mentioned this point at my previous posting. But I think the > "registration" can not be an solution for the "Alien Node > Problem". Please think about this case. There are multiple > gateways and a manet. Manet nodes may have different sets of > gateways because of partitions. And, if a gateway chosen by > souce node does not belong to the gateway set of destination > node, it will forward packets destined to desination toward > Internet. I think a global static ip which you are > considering is not globally routable(reachable) since a manet > node with globally routable global ip is also reachable > across Internet althogh it is local manet node. If so, > evenually souce node will be notified by ICMP destination > unreachable and do route discovery again in case of reactive > protocols. I think this is enough for destination node with > the "global static ip" which is not globally routable. > > Regards, > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > HyunWook Cha > > Researcher > NGI Standards Research Team > Protocol Engineering Center, ETRI > 161 Kajong-Dong, Yusong-Gu, Taejon, 305-350, KOREA > (Tel) +82-42-860-1076 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > -----Original Message----- > > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > > Behalf Of Yasser A. Lotfy > > Sent: Tuesday, September 02, 2003 12:25 AM > > To: manet@ietf.org; Manish Karir > > Subject: Re: [manet] The Problem of Alien Node > > > > > > > > Hi, > > That is exactly my point. Ad-hoc nodes may not always have a > > MANET_PREFIX IP address due to possibilities of nodes roaming > > with a static IP, and the chances of ad-hoc network getting > > partitioned or merged. > > > > Therefore, it is not possible for ad-hoc nodes to rely merely > > on MANET_PREFIX IP address to distinguish local nodes (LAA). > > The gateway also will asume nodes that don't have > > MANET_PREFIX IP address are external, and will forward > > packets outside the ad-hoc. While in fact some nodes that > > don't have MANET_PREFIX IP address are local nodes, with > > global static IP (I call it alien nodes). > > > > Therefore, I believe, there should be a registration > > mechanism for all alien nodes at the gateway. > > > > Any comments? any reason why not? > > > > yasser > > ---------------------------------------------- > > I'm sorry but the point that you are trying to get across > is not very > > clear, and your terminology is quite confusing... > > perhaps it would become clearer if we knew what your references > > were...[047-01] and [048-01]. > > > > when building a scenario that incorportes both terrestrial > > and ad hoc nodes, it is best to use address in MANET_PREFIX > > to identify ad hoc nodes. this way the gateway knows which > > address are in manet and which are in terrestrial network. > > These address spaces should be mutually exclusive, or you are > > going to run into the problems that you describe(atleast > > thats what I think you are talking about). > > > > alternately, if you decide that the two address spaces can > > intermingle, then you need to run complex > > registration/deregistration protocols at the gateway to > > inform the gateway which addresses(nodes) are in the > > manet.(some hybrid form of MIP). > > > > -manish > > > > > > > > Yasser A. Lotfy wrote: > > > Hi, > > > > > > I hope you read the attached (word) document which raises > > awareness of > > > the > > > > > problem of alien node. Sorry I have to make it in MS-Word > > since some > > > of the symbols > > > > > can not be done as text. > > > > > > The problem is simply due to the confusion that takes place when > > > gateways announce > > > > > there ability to forward packets to generic addresses. Some local > > > ad-hoc nodes may fall > > > > > in this generic address range. Therefore, packets may > > (incorrectly) be > > > forwarded to GW. > > > > > I hope to get feedback if any solution currently exist to this > > > problem. > > > > > > yasser > > > --- > > *********************************************** > > A train station is the place where trains stop, > > A bus station is the place where buses stop, > > On my desk they installed a workstation !! > > *********************************************** > > > > > > > > > > > > > > > ____________________________________________________________ Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail! http://login.mail.lycos.com/r/referral?aid=27005 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 8 14:11:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11766 for ; Mon, 8 Sep 2003 14:11:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQTp-00085S-LK for manet-archive@odin.ietf.org; Mon, 08 Sep 2003 14:11:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88IBDs6031080 for manet-archive@odin.ietf.org; Mon, 8 Sep 2003 14:11:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQTp-00085D-HR for manet-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 14:11: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 OAA11755 for ; Mon, 8 Sep 2003 14:11:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQTm-0004q6-00 for manet-web-archive@ietf.org; Mon, 08 Sep 2003 14:11:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wQTm-0004q3-00 for manet-web-archive@ietf.org; Mon, 08 Sep 2003 14:11:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQTe-000812-3X; Mon, 08 Sep 2003 14:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQT0-000803-0z for manet@optimus.ietf.org; Mon, 08 Sep 2003 14:10:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11729 for ; Mon, 8 Sep 2003 14:10:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQSx-0004pS-00 for manet@ietf.org; Mon, 08 Sep 2003 14:10:19 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19wQSw-0004oz-00 for manet@ietf.org; Mon, 08 Sep 2003 14:10:18 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h88I9hS24173; Mon, 8 Sep 2003 11:09:43 -0700 X-mProtect: <200309081809> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.35, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoGZdoB; Mon, 08 Sep 2003 11:09:41 PDT Message-ID: <3F5CC5D9.3050500@iprg.nokia.com> Date: Mon, 08 Sep 2003 11:09:29 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: yasser.lotfy@lycos.com CC: manet@ietf.org, jafy@etri.re.kr Subject: Re: [manet] The Problem of Alien Node References: 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 Hello folks, It seems to me that if a gateway offers a prefix, then the mobile node could configure an address from that prefix. In particular: Yasser A. Lotfy wrote: >>3) Iagree it is confusing, because if an alien node (with >>globaly routable static ip) needs to be reachable from the >>Internet, it has to use a gateway as a c/o address. >> Not if it's running in co-located mode with the care-of address it derived from the gateway's prefix. This is especially true for IPv6. >> This the >>dynamics of the MANET environment, it is hard to maintain >>this info. Some co-ordination between the gateways (multiple >>gw) has to be done. >> Not necessarily. Not any more than in any other case where two routers advertise reachability to the same prefix. If only one gateway offers reachability to a particular prefix, then I don't think there is a problem. >[Yasser] I agree, and believe manet node has to register with all reachable gateways, not with a selected one. > I would not agree with that. Plus, it leads to major headaches as gateways come and go. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 8 14:50:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13834 for ; Mon, 8 Sep 2003 14:50:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wR5W-0001W0-05 for manet-archive@odin.ietf.org; Mon, 08 Sep 2003 14:50:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88Io94m005818 for manet-archive@odin.ietf.org; Mon, 8 Sep 2003 14:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wR5V-0001Vl-SA for manet-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 14:50:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13813 for ; Mon, 8 Sep 2003 14:50:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wR5S-0005c4-00 for manet-web-archive@ietf.org; Mon, 08 Sep 2003 14:50:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wR5S-0005c1-00 for manet-web-archive@ietf.org; Mon, 08 Sep 2003 14:50:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wR5N-0001Rj-MC; Mon, 08 Sep 2003 14:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wR4l-0001Qy-TD for manet@optimus.ietf.org; Mon, 08 Sep 2003 14:49:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13799 for ; Mon, 8 Sep 2003 14:49:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wR4i-0005bn-00 for manet@ietf.org; Mon, 08 Sep 2003 14:49:21 -0400 Received: from louie.udel.edu ([128.4.40.12] helo=mail.eecis.udel.edu) by ietf-mx with esmtp (Exim 4.12) id 19wR4i-0005bk-00 for manet@ietf.org; Mon, 08 Sep 2003 14:49:20 -0400 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id D0DF8328D5; Mon, 8 Sep 2003 14:49:20 -0400 (EDT) Received: from wheatgrass.cis.udel.edu (wheatgrass.cis.udel.edu [128.4.131.63]) by mail.eecis.udel.edu (Postfix) with ESMTP id 2E814328B8 for ; Mon, 8 Sep 2003 14:49:20 -0400 (EDT) Date: Mon, 8 Sep 2003 14:49:20 -0400 (EDT) From: Chien-Chung Shen X-X-Sender: To: Message-ID: X-Spam-Status: No, hits=-2.1 required=6.0 tests=DEPT_RCVD,SPAM_PHRASE_01_02,USER_AGENT_PINE version=2.43 X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" Subject: [manet] QualNet ad hoc protocol animations and simulation exercises Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Greetings, We are happy to announce the availability of a set of instruction aids developed using the QualNet simulator. The instruction aids consist of two components: o animations of ad hoc networking protocols, which let people visualize protocol operations to better comprehend the basic concepts, and o simulation exercises, which help people learn how to use existing and develop new simulation models, step-by-step, using the QualNet simulator. An initial set of animated ad hoc networking protocols (such as DSR, AODV, LAR, ODMRP, IEEE 802.11) have been developed. Although the QualNet simulator (and its academic version GloMoSim from UCLA) was originally developed for scalable simulation of mobile wireless networks, it does equally well for simulating (wired) Internet based protocols. Following Kurose and Ross' textbook "Computer Networking, a top down approach featuring the Internet" (2nd edition), we have developed a sequence of simulation exercises that use the QualNet simulator to help people learn the book materials, the simulator, and simulation model development methodology. The simulation exercises and protocol animations are publically available from http://www.cis.udel.edu/~degas/QUALNET Comments are welcome and could be sent to degas@cis.udel.edu. Chien-Chung Shen ps. Academic institutions could obtain QualNet for free by contacting www.qualnet.com or www.scalable-networks.com. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 9 11:14:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16317 for ; Tue, 9 Sep 2003 11:14:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkCE-0003Dm-Or for manet-archive@odin.ietf.org; Tue, 09 Sep 2003 11:14:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89FEM7X012381 for manet-archive@odin.ietf.org; Tue, 9 Sep 2003 11:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkCE-0003Dc-Jx for manet-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 11:14:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16278 for ; Tue, 9 Sep 2003 11:14:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wkCD-0005Jc-00 for manet-web-archive@ietf.org; Tue, 09 Sep 2003 11:14:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wkCD-0005JZ-00 for manet-web-archive@ietf.org; Tue, 09 Sep 2003 11:14:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkBu-0003CE-1R; Tue, 09 Sep 2003 11:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wkBf-0003Bh-8K for manet@optimus.ietf.org; Tue, 09 Sep 2003 11:13:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16248 for ; Tue, 9 Sep 2003 11:13:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wkBe-0005IG-00 for manet@ietf.org; Tue, 09 Sep 2003 11:13:46 -0400 Received: from web8203.mail.in.yahoo.com ([203.199.70.117]) by ietf-mx with smtp (Exim 4.12) id 19wkBc-0005Hp-00 for manet@ietf.org; Tue, 09 Sep 2003 11:13:45 -0400 Message-ID: <20030909151311.29192.qmail@web8203.mail.in.yahoo.com> Received: from [219.65.97.39] by web8203.mail.in.yahoo.com via HTTP; Tue, 09 Sep 2003 16:13:11 BST Date: Tue, 9 Sep 2003 16:13:11 +0100 (BST) From: =?iso-8859-1?q?Vanitha=20Sivasankaran?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1966767305-1063120391=:28391" Content-Transfer-Encoding: 8bit Subject: [manet] video over ad hoc simulation in glomism.. Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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-1966767305-1063120391=:28391 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear All, I am an engg. student doing my project on "Adaptive transmission of media files over MANET". For this I have decided to use glomosim simulator. I would be happy if anyone of u could send me a VBR video code that could be included in glomosim. As i have very little time for my project completion, I'm seeking your help. If anyone of u have already worked in glomosim with video, please provide me with the code with the steps to include the same in glomosim. This is the first step in our project and there is a lot of coding to be done in the application layer and the link layer. I would be obliged to receive ur responses. Thanks, Vanitha. Yahoo! India Matrimony: Find your partner online.Post your profile. --0-1966767305-1063120391=:28391 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dear All,
 
     I am an engg. student doing my project on "Adaptive transmission of media files over MANET".  For this I have decided to use glomosim simulator.  I would be happy if anyone of u could send me a VBR video code that could be included in  glomosim.  As i have very little time for my project completion, I'm seeking your help.  If anyone of u have already worked in glomosim with video, please provide me with the code with the steps to include the same in glomosim.  This is the first step in our project and there is a lot of coding to be done in the application layer and the link layer.
     I would be obliged to receive ur responses.
 
Thanks,
Vanitha.

Yahoo! India Matrimony: Find your partner online. Post your profile. --0-1966767305-1063120391=:28391-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 9 13:45:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25059 for ; Tue, 9 Sep 2003 13:45:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmXc-0001ej-Ji for manet-archive@odin.ietf.org; Tue, 09 Sep 2003 13:44:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89HiaaH006362 for manet-archive@odin.ietf.org; Tue, 9 Sep 2003 13:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmXc-0001eX-BC for manet-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 13:44:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25015 for ; Tue, 9 Sep 2003 13:44:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wmXa-0000Gp-00 for manet-web-archive@ietf.org; Tue, 09 Sep 2003 13:44:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wmXZ-0000Gm-00 for manet-web-archive@ietf.org; Tue, 09 Sep 2003 13:44:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmX4-0001ch-3y; Tue, 09 Sep 2003 13:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wmWc-0001cE-U1 for manet@optimus.ietf.org; Tue, 09 Sep 2003 13:43:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25005 for ; Tue, 9 Sep 2003 13:43:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wmWa-0000GP-00 for manet@ietf.org; Tue, 09 Sep 2003 13:43:32 -0400 Received: from smtp.eecs.umich.edu ([141.213.4.43]) by ietf-mx with esmtp (Exim 4.12) id 19wmWZ-0000GD-00 for manet@ietf.org; Tue, 09 Sep 2003 13:43:32 -0400 Received: from clueless.eecs.umich.edu (clueless.eecs.umich.edu [141.213.18.225]) by smtp.eecs.umich.edu (8.12.9/8.12.9) with ESMTP id h89HgU1L010795 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 9 Sep 2003 13:42:30 -0400 Date: Tue, 9 Sep 2003 13:42:23 -0400 (EDT) From: Mingyan Liu To: manet@ietf.org, , cc: matta@cs.bu.edu, , , In-Reply-To: <20030909151311.29192.qmail@web8203.mail.in.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No -- Hits: -0.5 Required: 6 X-Spam-Summary: IN_REP_TO,USER_AGENT_PINE X-Scanned-By: MIMEDefang 2.35 Subject: [manet] WWIC 2004 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: , Please accept our apologies if you receive multiple copies ... Call for Papers The 2nd International Conference on Wired/Wireless Internet Communications (WWIC'04) February 05-07, 2004 FRANKFURT (ODER), GERMANY http://www.wwic2004.de/ * Submission Deadline: October 10, 2003 * WWIC 2004 is the second annual conference dedicated to bridging the gap between wired and wireless Internet. The issue of integrating mobile devices in the Internet poses many challenges such as the design and evaluation of protocols,the dynamics of the integration, the performance trade-offs, the need for new performance metrics, and the cross-layer interactions. The goal of the conference is to present high-quality results in the field, and to provide a framework for research collaboration through focused discussions that will designate future research efforts and directions. In this context, the program committee will accept only a limited number of papers that meet the criteria of originality, presentation quality and topic relevance. All papers should be submitted electronically, in Portable Document Format (PDF) format. The paper should not exceed 12 pages. Conference proceedings will be published by Springer as LNCS. For formatting instructions see http://www.springer.de/comp/lncs/authors.html The program committee solicits research papers on the following issues: * Network Design Issues on Wireless Internet * Evaluation of Internet protocols over wireless networks * Design and evaluation of new protocols * Conflicting behavior of wired/wireless protocols/mechanisms * Error and Congestion Control * Quality of Service * Energy Efficiency of protocols and devices * Performance Trade-offs * Wired/Wireless Proxies * Web Computing * System Design and Evaluation * Cross-layer interactions * Applications and Application Performance * Middleware platforms * Evaluation Tools and Methods * Modeling and Simulation for wired/wireless networks IMPORTANT DATES Submission deadline: October 10, 2003 Notification of acceptance: November 12, 2003 Camera ready papers: November 26, 2003 ORGANIZATION General Chairs: Vassilis Tsaoussidis, Demokritos University, Greece Ibrahim Matta, Boston University, USA TPC Chairs: Peter Langendoerfer, IHP, Germany Mingyan Liu, University of Michigan, USA Technical Program Committee: Farooq Anjum, Telcordia Technologies, USA Xiuzhen Chen, George Washington University, USA Mark Crovella, Boston University, USA Klaus David, University of Kassel, Germany Olaf Droegehorn, University of Kassel, Germany Yuguang Fang, University of Florida, USA Yevgeni Koucheryavy, Tampere University of Technology, Finland Rolf Kraemer, IHP Microelectronics, Germany Srikanth Krishnamurthy, University of California, Riverside, USA Adrian Lahanas, Demokritos Research Center, Greece Peter Langendoerfer, IHP Microelectronics, Germany Victor Leung, Univeristy of British Columbia, Canada Mingyan Liu, University of Michigan, USA Qingchong Liu, University of Oakland, USA Petri Maehoenen, University Oulu, Finland Qusay Mahoud, Guelph University, Canada Christian Maihoefer, DaimlerChrysler, Germany Ibrahim Matta, Boston University, USA Ioanis Nikolaidis, University of Alberta, Canada Guevara Noubir, Northeastern University, USA George Polyzos, AUEB, Greece Jochen Schiller, FU Berlin, Germany Sherman Shen, University of Waterloo, Canada Ioannis Stavrakakis, University of Athens, Greece Vassilis Tsaoussidis, Demokritos University, Greece Dapeng Oliver Wu, University of Florida, USA Chi Zhang, Florida International University, USA Yongguang Zhang, Hughes Research Labs, USA Martina Zitterbart, TU Karlsruhe, Germany 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 Sep 9 16:42:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03783 for ; Tue, 9 Sep 2003 16:42:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wpJe-0007w7-Rl for manet-archive@odin.ietf.org; Tue, 09 Sep 2003 16:42:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h89KgMsq030504 for manet-archive@odin.ietf.org; Tue, 9 Sep 2003 16:42:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wpJe-0007vu-M3 for manet-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 16:42:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03762 for ; Tue, 9 Sep 2003 16:42:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wpJc-0002i0-00 for manet-web-archive@ietf.org; Tue, 09 Sep 2003 16:42:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wpJc-0002hw-00 for manet-web-archive@ietf.org; Tue, 09 Sep 2003 16:42:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wpJI-0007uD-S3; Tue, 09 Sep 2003 16:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wpIb-0007tg-D4 for manet@optimus.ietf.org; Tue, 09 Sep 2003 16:41:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03744 for ; Tue, 9 Sep 2003 16:41:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wpIZ-0002hl-00 for manet@ietf.org; Tue, 09 Sep 2003 16:41:15 -0400 Received: from mta7.algx.net ([67.92.168.236] helo=chimta02.algx.net) by ietf-mx with esmtp (Exim 4.12) id 19wpIY-0002hg-00 for manet@ietf.org; Tue, 09 Sep 2003 16:41:15 -0400 Received: from wireless-4 (ip67-89-211-170.z211-89-67.customer.algx.net [67.89.211.170]) by chimmx02.algx.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HKY009FQS3VGW@chimmx02.algx.net> for manet@ietf.org; Tue, 09 Sep 2003 15:40:44 -0500 (CDT) Date: Tue, 09 Sep 2003 13:41:08 -0700 From: Amit Kucheria In-reply-to: To: manet@ietf.org Message-id: <1063140068.1201.12.camel@amit.metricsystems.com> Organization: Metric Systems Corporation MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-type: multipart/signed; boundary="=-cCiqXlQzGkb5VJ/FhRe9"; protocol="application/pgp-signature"; micalg=pgp-sha1 References: Subject: [manet] OLSR implementations/models Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --=-cCiqXlQzGkb5VJ/FhRe9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I have downloaded the two OLSR implementations from NRL: 1. INRIA implementation with bugfixes (nolsrd_1.0a9) 2. NRL's implementation based on the Protean library (nrlolsrdv5.3) What version of the draft are these implementations based on? It seems that they don't support multiple interfaces yet. Is there any implementation that does? Thanks for your time. Regards, Amit --=20 ---------------------------------------------------------------------- Amit Kucheria akucheria@metricsystems.com Metric Systems Corp. 2320 Cousteau Court, Suite 201, Vista, CA 92083 ---------------------------------------------------------------------- --=-cCiqXlQzGkb5VJ/FhRe9 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) iD8DBQA/XjrktLg6PvU36DYRAl1RAJ9M9q0RnTDCAvMwvkIXvMQ61vXRgQCfVfAT bQ+zYLF3GGIP3WPUveydcYc= =TXqk -----END PGP SIGNATURE----- --=-cCiqXlQzGkb5VJ/FhRe9-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Sep 19 21:36:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00600 for ; Fri, 19 Sep 2003 21:36:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhAV020140 for ; Fri, 19 Sep 2003 21:36:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82KUZXA024820 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 16:30:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uHnP-0006SD-AF for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 16:30:35 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04890 for ; Tue, 2 Sep 2003 16:30:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uHmd-0006MB-1V; Tue, 02 Sep 2003 16:29:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uHll-0006J5-B9 for manet@optimus.ietf.org; Tue, 02 Sep 2003 16:28:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04792 for ; Tue, 2 Sep 2003 16:28:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uHlT-0006Kb-00 for manet@ietf.org; Tue, 02 Sep 2003 16:28:35 -0400 Received: from pit.erg.sri.com ([128.18.100.28]) by ietf-mx with esmtp (Exim 4.12) id 19uHlS-0006Jy-00 for manet@ietf.org; Tue, 02 Sep 2003 16:28:34 -0400 Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id NAA22727; Tue, 2 Sep 2003 13:27:58 -0700 (PDT) Message-Id: <200309022027.NAA22727@pit.erg.sri.com> To: jelger@clarinet.u-strasbg.fr cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Comments on draft-jelger In-reply-to: Your message of "Tue, 02 Sep 2003 11:20:31 +0200." <1062494431.3f5460df0bf7c@clarinet.u-strasbg.fr> Date: Tue, 02 Sep 2003 13:27:57 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Christophe, Thanks for your response. Please see my futher comments below. > Hi Richard and thanks for your comments, > > Please check below within your text for my comments. In general, your points > make sense and we already considered most of them but we decided to insist on > prefix continuity. There are of course pros and cons in any solution. We > decided to favor prefix continuity because the hop-by-hop propagation method > that we use naturaly leads to prefix continuity. I think there is no "best > method", because topological changes are unpredictable and it is difficult to > simulate and compare different solutions. Well it would be nice to gather > comments and ideas from other MANET members, so more comments are very > welcome ! > > Regards, > Christophe > > Quoting ogier@erg.sri.com: > > > > > Hi Christophe, > > > > Regarding your new draft, I am not sure that "prefix continuity" > > is necessary. That is, I am not sure that the set of nodes having > > the same prefix needs to be contiguous. Please consider the > > following, and let me know if I am missing something. > > > > It is only necessary for each node to have a route to the > > gateway(s) it is affiliated with, and for each gateway to have > > a route to each node that is affiliated with it. > > - I agree, but that means ad hoc routing must be allowed between nodes with > different prefixes. Well that seems ok for me, but in certain cases (for > administrative reasons) one might want to forbid routing between "ad hoc > subnets". >From previous discussions on the manet list, I think want to allow routing between nodes with different prefixes. > - Prefix continuity also impresses some sort of coherence in the network, with > contiguous "prefix islands", and I like organized networks ! ;-) > - Also when a network partition occurs, it means that nodes that are still on > the gateway side won't have to change their address. That's true. But I think that what I am proposing results in nodes changing their prefix less often, since nodes do not have to change their prefix in order to maintain prefix continuity. Also, what I am proposing might result in faster recovery from a partition, since a node will typically have information for multiple gateways, whereas in your method I think that a node typically knows only about one gateway unless it is on the boundary between two "prefix islands". Thus, in your method, a node that is not on the boundary might have to wait for gateway information to propagate via Hello messages. > > One might argue that if the set of nodes with a given prefix > > is contiguous, then it is easier to flood a message to all > > nodes having that prefix, but I think it is sufficient for a > > gateway to be able to perform the following types of flooding: > > > > (a) Flooding to all nodes in the manet. > > (b) Flooding to all nodes in the manet that are within K hops > > of the gateway (where K is such that any node affiliated with > > the gateway is required to be within K hops of that gateway). > > > > Thus, I am not sure it is necessary to go through the trouble to > > ensure "prefix continuity". > > A node can simply select the nearest gateway (which can be determined > > from the information provided by a proactive routing protocol), > > and use the prefix advertised by that gateway. The node can keep > > that prefix until it no longer has a route to that gateway, or becomes > > more than K hops from that gateway, or finds another gateway that is > > much closer. > > That's interesting, but with unpredictable topological changes we have > prefered to favor prefix stability : don't forget that each time a node > changes its address, all transport connections are lost (if nothing like > Mobile IPv6 is used). As I indicated above, it seems to me that prefix stability will be improved if nodes do not have to change their prefixes in order to maintain prefix continuity. It would be good to conduct simulations to compare the two different approaches (with and without prefix continuity). Also, it would be good to get comments from other MANET members! > > > My reasoning is influenced by the original paper on Landmark Routing > > (Paul Tsuchiya, 1987), which I re-read recently. > > A node can select any landmark node (a landmark is like a gateway) > > that is within a certain hop-radius of the node, and use the > > prefix advertised by that landmark. There is no requirement that > > the set of nodes affiliated with a given landmark be contiguous. > > A node would have to change its prefix only if it moves too far > > from the landmark it has selected. It could then select another > > landmark, or another landmark could be elected, or the hop-radius > > could be increased. (Note that I am not suggesting to use > > landmark routing to deal with internet-gateways in manets.) > > > > The idea of a hop-radius (or "routing scope") from Landmark routing > > can also be applied to the problem we are considering. > > For example, suppose there is one huge manet (say with a diameter > > of 100 hops), which has several internet-gateways. > > Thus, even though one manet node may be be able to reach another > > manet node using a 100-hop path, it would be desirable to limit > > the routing scope to K hops (where K might be 5), such that > > every node is within K hops of some internet-gateway. > > Then, each manet node would select a gateway that is within > > K hops and use the prefix advertised by that gateway. > > The node would have to change its prefix only if it moves > > more than K hops from the gateway it selected. > > This idea is also quite good, we thought about such thing but finally decided > not to incorporate this in this version of the draft, mainly because we could > not find a solution for nodes that were "too far" from all gateways. If we > limit the distance to, say K hops, what happens for a node that is K+1 hops > from all possible gateways ? I think it is not acceptable to ignore such a > node, so the "K hops" rule has to be broken ... and if we can find exceptions, > maybe it is because the rule is too strict. Well I cannot find an easy > solution for the K+1 node ... :-( I agree that we should not ignore a node that is too far from all gateways, but I don't think it is difficult to handle such exceptions. For example, a manet node that is not within range of any gateway can increase its routing scope (distance that its routing advertisements propagate, whether link-state or distance-vector) until it is within range of some gateway, so that the gateway will know a route to the node. In the reverse direction, gateway advertisements can be propagated in a manner that ensures every node knows about at least one gateway (no matter how far), but also knows all gateways that are within K hops. Regards, Richard > > It is also possible for a manet node to select multiple gateways > > that are within K hops, and to have multiple prefixes. > > Note that the above approach makes it unnecessary to divide > > the manet into well-defined areas or clusters: > > The set of all nodes affiliated with a given gateway need > > not be contiguous. All nodes within K hops of a gateway receive > > advertisements from the gateway, but may decide to use the prefix > > advertised by another gateway that is also within K hops. > > > > Regards, > > Richard > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Sep 19 21:37:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00982 for ; Fri, 19 Sep 2003 21:37:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBH020140 for ; Fri, 19 Sep 2003 21:36:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88E84ES015083 for manet-archive@odin.ietf.org; Mon, 8 Sep 2003 10:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wMgP-0003qf-Np for manet-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 10:07:57 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21967 for ; Mon, 8 Sep 2003 10:07:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wMfU-0003TN-Lj; Mon, 08 Sep 2003 10:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wK9P-0005oB-Nb for manet@optimus.ietf.org; Mon, 08 Sep 2003 07:25:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12048 for ; Mon, 8 Sep 2003 07:25:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wK9O-0000UT-00 for manet@ietf.org; Mon, 08 Sep 2003 07:25:42 -0400 Received: from pri-dns.cs.iitm.ernet.in ([202.141.25.89] helo=cello.cs.iitm.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 19wK9N-0000UL-00 for manet@ietf.org; Mon, 08 Sep 2003 07:25:41 -0400 Received: from rts.cs.iitm.ernet.in (rts.cs.iitm.ernet.in [10.6.6.3]) by cello.cs.iitm.ernet.in (8.12.5/8.12.5) with ESMTP id h88BuTT1002871; Mon, 8 Sep 2003 17:26:30 +0530 Date: Mon, 8 Sep 2003 16:14:43 +0530 (IST) From: "T. Bheemarjuna Reddy" To: #LI ZHIFEI# cc: manet@ietf.org Subject: RE: [manet] doubt regarding 802.11 IFSs In-Reply-To: <3D565922795545468AE3E3DA2881BEA901C73612@mail01.student.main.ntu.edu.sg> 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: , Dear Li, thanx for ur kind response. Based on ur reasoning i think the following is the reason for setting DIFS as SIFS + 2*slottime. A-->B AP(PC) C In the above scenario, nodes C and AP(PC) are in the Tx range of node B. Since AP has higher priority (in dual mode of 802.11 protocol) it should wait a minimum of PIFS (=SIFS + slottime) before transmitting Beacon to initiate CFP (contention free period). If at all a transmission is happening from B to A, AP detects it within PIFS period and defers. If node C wants to transmit, first it must ensure that transmission between A and B has finished and AP is not transmitting its Beacon. ASSUME THAT AP is NOT willing to TX a Beacon. Then, to know that node B has finished its transmission, node C takes (PIFS=SIFS + slotime) period. Further, node C takes one more "slottime" to confirm that AP is not willing to tx its Beacon (If willing, AP would have started Tx after PIFS and node C would have detected it in a slottime that follows PIFS). Hence DIFS = SIFS + 2*slottime. If dual mode is not there, for pure DCF mode, i think, it is enough to take DIFS = SIFS + slottime. Is it right? regards arjun On Mon, 8 Sep 2003, #LI ZHIFEI# wrote: > Hi, > > My answer to your questions are as follows: > > >aSlotTime = aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + > >aMACProcessingDelay. > > The SotTime is specified as above to ensure that the transmission by the winning node (say A) will be sensed within the same slot by the MAC layer of all the other nodes(e.g., node B) . > Otherwise, even though nodes A and B choose different backoff values (say 6 and 7 slots, respectively), node B will transmit after node A has already begin to transmit, resulting in a collision. Note that even with the above rule for the SlotTime, the collision between two nodes having different backoff values may not be avoided when the time is not synchronized. > > >aSlotTime = aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + > >aMACProcessingDelay. > > To my knowledge, the SIFS should be 28 us for FHSS while it should be 10 us for DSSS in IEEE 802.11b rather than being 9 us. > > The SIFS (as well as the SlotTime) is determined by the physical layer and thus you cannot set as you want. > > The SIFS is designed as above to ensure that it is equal to the minimum time required by a node to turn from the receiving state to transmit state (e.g., from receiving RTS to transmit CTS). That is also why it needs not include the aAirPropagationTime. > > > >>WHY aDIFS = aSIFS + 2 x aSlotTime ? why cannot it be someother value > >>say 30 microsec instead of 34 microsec in 802.11b protocol? > > A->B > C > > Consider the above scenario where a frame exchange sequence is in progress between nodes A and B while node C is deferring. > After A transmited a RTS to B, before node B sends back a CTS, it takes a SIFS time for B to turn from receiving node to transmitting node. > Then, it may take a SlotTime for node C senses the transmission of CTS. Therefore, to give priority for the ongoing transmission, the DIFS must be greater than (aSIFS + aSlotTime). > I think the reason that the standard chooses 2 x aSlotTime rather than 1 x aSlotTime is just to make the protocol more relialbe. > > Moreover, the DIFS value should be 50 us in DSSS of IEEE 802.11b. > > > > > Best regards > Li zhifei > > > > -----Original Message----- > From: T. Bheemarjuna Reddy [mailto:arjun@cs.iitm.ernet.in] > Sent: dimecres, 3 / setembre / 2003 15:47 > To: manet@ietf.org > Subject: [manet] doubt regarding 802.11 IFSs > > > Hi all, > > In 802.11 MAC protocol, the "slot time" id defined as > > aSlotTime = aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + > aMACProcessingDelay. > > My doubt is why above all parameters be considered for determining "slot > time" value. In otherwords, in 802.11b protocol, SIFS is set to 9 > microsec, why cannot it be someother value say 5 microsec? > > Further, SIFS is defined as > > aSIFS = aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + aRxTxTurnaround > time. > > My doubt is why "aAirPropagationTime" used in aSlotTime is not taken into > consideration during calculation of aSIFS value? > > and > > WHY aDIFS = aSIFS + 2 x aSlotTime ? why cannot it be someother value > say 30 microsec instead of 34 microsec in 802.11b protocol? > > If anybody knows, please clarify my doubts. > Thanx inadvannce. > > -----arjun > > -- ============================ Bheemarjuna Reddy Tamma = Room no: 271 = Cauvery Hostel = IIT Madras = Chennai -600036 = PHNO: 044-2257 9071(Hostel)= ============================ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Sep 19 21:37:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01205 for ; Fri, 19 Sep 2003 21:37:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhC5020140 for ; Fri, 19 Sep 2003 21:36:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PILECN017280 for manet-archive@odin.ietf.org; Mon, 25 Aug 2003 14:21:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLxl-0004UR-He for manet-web-archive@optimus.ietf.org; Mon, 25 Aug 2003 14:21:09 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07140 for ; Mon, 25 Aug 2003 14:21:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLx1-0004J1-QL; Mon, 25 Aug 2003 14:20:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLq5-0003Lh-S6 for manet@optimus.ietf.org; Mon, 25 Aug 2003 14:13:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06428 for ; Mon, 25 Aug 2003 14:13:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rLq2-0005O6-00 for manet@ietf.org; Mon, 25 Aug 2003 14:13:10 -0400 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 19rLq1-0005Nw-00 for manet@ietf.org; Mon, 25 Aug 2003 14:13:09 -0400 Received: from kenai.cs.ucsb.edu (csil [128.111.41.12]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.6) with ESMTP id h7PICvS09461; Mon, 25 Aug 2003 11:12:57 -0700 (PDT) From: Ian Chakeres MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16202.20903.435994.994255@gargle.gargle.HOWL> Date: Mon, 25 Aug 2003 11:12:55 -0700 To: "Koojana Kuladinithi" Cc: Subject: RE:[manet] Clarification on RFC 3561 (current time & updating route lifetime) In-Reply-To: <000401c36ae2$42df00d0$989b6686@scoobydoo> References: <000401c36ae2$42df00d0$989b6686@scoobydoo> 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 The draft is correct. It should be current time and not ExistingLifetime. ExistingLifetime refers to an absolute time. Regarding your idea to change the lifetime update of active routes, this may increase performance under certain conditions but can have an equal negative impact under other conditions. Personally I prefer updating the lifetime for each packet. I believe any minor performance increase would be offset by a more complex design and implementation. Ian Chakeres >Koojana Kuladinithi wrote: >Hello Ian, > >I would appreciate if you can clarify the following >to me. > >In the following formula in Section 6.5, > > MinimalLifetime = (current time + 2*NET_TRAVERSAL_TIME - > 2*HopCount*NODE_TRAVERSAL_TIME). > >What does current time refer to, in this formula? In other >places, current time refers to the current clock time. If we >assume that here, MinimalLifeTime will an absolute time. > >Shouldn't "current time" be "ExistingLifetime" ? > > >-------------------------------------------------- > >This is just an idea, which you might have discussed previously. > >According to the RFC 3561, each time a route is used to forward a data >packet, lifetime of the particular route should be extended. > >This, I believe is an overhead on the AODV protocol handler, as it has to >perform updates for every packet that uses every route. > >Can this be done in the following way? > >When a route is used, the lifetime of the route is extended by >ACTIVE_ROUTE_TIMEOUT. >Once this is done, we stop updating lifetime for every packet using >the route. We setup a timer to get activated at X, after which we start >again to check the route use. > >If a packet is received again, the route lifetime is updated and a timer is >setup for X. Else, route expiry occurs. > >X = 75% of ExistingLifeTime > >Kind regards > >Koojana > > > >University of Bremen >FB 1 - IKOM/ComNets >Koojana Kuladinithi BSc, MSc >Otto-Hahn-Allee NW 1 >28359 Bremen - Germany > >Tel.: +49 421 218 8264, Fax: +49 421 218 3601, Mobile: +49 160 2690070 >Email: kuladinithi@ikom.org >koo@comnets.uni-bremen.de > > > > > > >_______________________________________________ >manet mailing 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 Sep 19 21:37:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01688 for ; Fri, 19 Sep 2003 21:37:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhEn020140 for ; Fri, 19 Sep 2003 21:37:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DgOHt012670 for manet-archive@odin.ietf.org; Tue, 2 Sep 2003 09:42:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u9jE-0003bD-8p for manet-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 07:53:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13830 for ; Tue, 2 Sep 2003 07:53:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u9jB-0003D1-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 07:53:41 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u9jA-0003Cy-00 for manet-web-archive@ietf.org; Tue, 02 Sep 2003 07:53:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6He-0000xV-LF; Tue, 02 Sep 2003 04:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1he-0005On-D0 for manet@optimus.ietf.org; Mon, 01 Sep 2003 23:19:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08387 for ; Mon, 1 Sep 2003 23:19:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1ha-00025B-00 for manet@ietf.org; Mon, 01 Sep 2003 23:19:30 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 19tf5J-0005kf-00 for manet@ietf.org; Sun, 31 Aug 2003 23:10:29 -0400 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.2656.59) id R02JC0CR; Mon, 1 Sep 2003 12:09:34 +0900 Reply-To: From: "HyunWook Cha" To: "'Manish Karir'" , Subject: RE: [manet] The Problem of Alien Node Date: Mon, 1 Sep 2003 12:10:03 +0900 Message-ID: <000601c37036$89aa9a70$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 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3F4F8732.3030802@isr.umd.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 Hi, Manish. > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Manish Karir > Sent: Saturday, August 30, 2003 2:03 AM > To: manet@ietf.org > Subject: Re: [manet] The Problem of Alien Node > > > > > > I'm sorry but the point that you are trying to get across is not very > clear, and your terminology is quite confusing... > perhaps it would become clearer if we knew what your references > were...[047-01] and [048-01]. > > when building a scenario that incorportes both terrestrial and ad hoc > nodes, it is best to use address in MANET_PREFIX to identify ad hoc > nodes. this way the gateway knows which address are in manet > and which > are in terrestrial network. These address spaces should be mutually > exclusive, or you are going to run into the problems that you > describe(atleast thats what I think you are talking about). > Basically, I agree. But, some application which is not specific to MANET and not being using for only MANET can not give MANET_PREFIX address of the peer manet node to the source node. Think about present p2p applications. In addition, it is possible that peer manet node is also capable of MIPv6 and souce node initiates session using HoA of peer node. > alternately, if you decide that the two address spaces can > intermingle, > then you need to run complex registration/deregistration protocols at > the gateway to inform the gateway which addresses(nodes) are in the > manet.(some hybrid form of MIP). Right. I think this "registration" is necessary. Without the registaration information, in case of reactive routing protocols, an Internet gateway can generate unnecessary MANET broadcast RREQ for destination of downstream traffic packet, although the destination node is not manet one. Or, the gateway can perform unnecessary NDP stuff if destination is a manet node but is not reachable because of partitions. In the stateful address configuration for global addresses, a gateway can maintain this information efficiently. HyunWook Cha > > -manish > > > > Yasser A. Lotfy wrote: > > Hi, > > > > I hope you read the attached (word) document which raises > awareness of > > the > > > problem of alien node. Sorry I have to make it in MS-Word > since some > > of the symbols > > > can not be done as text. > > > > The problem is simply due to the confusion that takes place when > > gateways announce > > > there ability to forward packets to generic addresses. Some local > > ad-hoc nodes may fall > > > in this generic address range. Therefore, packets may > (incorrectly) be > > forwarded to GW. > > > I hope > > to get feedback if any solution currently exist to this problem. > > > > yasser > > --- > > > > _______________________________________________ > manet mailing 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 Sep 19 22:04:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01627 for ; Fri, 19 Sep 2003 21:37:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhDt020140 for ; Fri, 19 Sep 2003 21:37:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7P8RVt5018749 for manet-archive@odin.ietf.org; Mon, 25 Aug 2003 04:27:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rChH-0004sK-8t for manet-web-archive@optimus.ietf.org; Mon, 25 Aug 2003 04:27:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02655 for ; Mon, 25 Aug 2003 04:27:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rCgC-0004ZJ-OJ; Mon, 25 Aug 2003 04:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rCcH-00044Q-5L for manet@optimus.ietf.org; Mon, 25 Aug 2003 04:22: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 EAA02112 for ; Mon, 25 Aug 2003 04:22:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rCcE-0004Kr-00 for manet@ietf.org; Mon, 25 Aug 2003 04:22:18 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19rCcD-0004Ko-00 for manet@ietf.org; Mon, 25 Aug 2003 04:22:17 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h7P8MAK09071; Mon, 25 Aug 2003 10:22:10 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: "'Ian Chakeres'" Cc: Date: Mon, 25 Aug 2003 10:24:11 +0200 Message-ID: <000401c36ae2$42df00d0$989b6686@scoobydoo> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [manet] Clarification on RFC 3561 (current time & updating route lifetime) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Ian, I would appreciate if you can clarify the following to me. In the following formula in Section 6.5, MinimalLifetime = (current time + 2*NET_TRAVERSAL_TIME - 2*HopCount*NODE_TRAVERSAL_TIME). What does current time refer to, in this formula? In other places, current time refers to the current clock time. If we assume that here, MinimalLifeTime will an absolute time. Shouldn't "current time" be "ExistingLifetime" ? -------------------------------------------------- This is just an idea, which you might have discussed previously. According to the RFC 3561, each time a route is used to forward a data packet, lifetime of the particular route should be extended. This, I believe is an overhead on the AODV protocol handler, as it has to perform updates for every packet that uses every route. Can this be done in the following way? When a route is used, the lifetime of the route is extended by ACTIVE_ROUTE_TIMEOUT. Once this is done, we stop updating lifetime for every packet using the route. We setup a timer to get activated at X, after which we start again to check the route use. If a packet is received again, the route lifetime is updated and a timer is setup for X. Else, route expiry occurs. X = 75% of ExistingLifeTime Kind regards Koojana University of Bremen FB 1 - IKOM/ComNets Koojana Kuladinithi BSc, MSc Otto-Hahn-Allee NW 1 28359 Bremen - Germany Tel.: +49 421 218 8264, Fax: +49 421 218 3601, Mobile: +49 160 2690070 Email: kuladinithi@ikom.org koo@comnets.uni-bremen.de _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Sep 19 22:05:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01440 for ; Fri, 19 Sep 2003 21:37:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhD1020140 for ; Fri, 19 Sep 2003 21:36:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88E94QA016137 for manet-archive@odin.ietf.org; Mon, 8 Sep 2003 10:09:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wMgr-0003yd-01 for manet-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 10:08:25 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22067 for ; Mon, 8 Sep 2003 10:08:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wMgH-0003k4-0t; Mon, 08 Sep 2003 10:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wKIu-000603-F7 for manet@optimus.ietf.org; Mon, 08 Sep 2003 07:35:32 -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 HAA12535 for ; Mon, 8 Sep 2003 07:35:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wKIt-0001ls-00 for manet@ietf.org; Mon, 08 Sep 2003 07:35:31 -0400 Received: from mail11.ntu.edu.sg ([155.69.5.163]) by ietf-mx with esmtp (Exim 4.12) id 19wKIt-0001ku-00 for manet@ietf.org; Mon, 08 Sep 2003 07:35:31 -0400 Received: from mail01.student.main.ntu.edu.sg ([155.69.5.165]) by mail11.ntu.edu.sg with Microsoft SMTPSVC(5.0.2195.5576); Mon, 8 Sep 2003 19:34:58 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] doubt regarding 802.11 IFSs Date: Mon, 8 Sep 2003 19:34:57 +0800 Message-ID: <3D565922795545468AE3E3DA2881BEA901C73623@mail01.student.main.ntu.edu.sg> Thread-Topic: [manet] doubt regarding 802.11 IFSs Thread-Index: AcN1+//FUHXXar/1Qi6g3p6GLGThLAAALVLQ From: "#LI ZHIFEI#" To: "T. Bheemarjuna Reddy" Cc: X-OriginalArrivalTime: 08 Sep 2003 11:34:58.0039 (UTC) FILETIME=[3B689070:01C375FD] 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, I am not farmilar with PCF but what you have said seems reasonable: the = DIFS is designed in such a way to give priority for the Point Cordinator = (e.g., AP) which will defer by PIFS before transmission. Li zhifei -----Original Message----- From: T. Bheemarjuna Reddy [mailto:arjun@cs.iitm.ernet.in] Sent: dilluns, 8 / setembre / 2003 18:45 To: #LI ZHIFEI# Cc: manet@ietf.org Subject: RE: [manet] doubt regarding 802.11 IFSs Dear Li, thanx for ur kind response. Based on ur reasoning i think the following is the reason for setting DIFS as SIFS + 2*slottime. A-->B AP(PC) C=20 In the above scenario, nodes C and AP(PC) are in the Tx range of node B. Since AP has higher priority (in dual mode of 802.11 protocol) it should wait a minimum of PIFS (=3DSIFS + slottime) before transmitting Beacon = to initiate CFP (contention free period). If at all a transmission is happening from B to A, AP detects it within PIFS period and defers.=20 If node C wants to transmit, first it must ensure that transmission between A and B has finished and AP is not transmitting its Beacon. ASSUME THAT AP is NOT willing to TX a Beacon.=20 Then, to know that node B has finished its transmission, node C takes (PIFS=3DSIFS + slotime) period. Further, node C takes one more = "slottime" to confirm that AP is not willing to tx its Beacon (If willing, AP would = have started Tx after PIFS and node C would have detected it in a slottime = that follows PIFS). Hence DIFS =3D SIFS + 2*slottime. If dual mode is not there, for pure DCF mode, i think, it is enough to take DIFS =3D SIFS + slottime. Is it right? regards arjun=20 On Mon, 8 Sep 2003, #LI ZHIFEI# wrote: > Hi, >=20 > My answer to your questions are as follows: >=20 > >aSlotTime =3D aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + > >aMACProcessingDelay. >=20 > The SotTime is specified as above to ensure that the transmission by = the winning node (say A) will be sensed within the same slot by the MAC = layer of all the other nodes(e.g., node B) .=20 > Otherwise, even though nodes A and B choose different backoff values = (say 6 and 7 slots, respectively), node B will transmit after node A has = already begin to transmit, resulting in a collision. Note that even with = the above rule for the SlotTime, the collision between two nodes having = different backoff values may not be avoided when the time is not = synchronized. >=20 > >aSlotTime =3D aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + > >aMACProcessingDelay. >=20 > To my knowledge, the SIFS should be 28 us for FHSS while it should be = 10 us for DSSS in IEEE 802.11b rather than being 9 us.=20 >=20 > The SIFS (as well as the SlotTime) is determined by the physical layer = and thus you cannot set as you want. >=20 > The SIFS is designed as above to ensure that it is equal to the = minimum time required by a node to turn from the receiving state to = transmit state (e.g., from receiving RTS to transmit CTS). That is also = why it needs not include the aAirPropagationTime. >=20 >=20 > >>WHY aDIFS =3D aSIFS + 2 x aSlotTime ? why cannot it be someother = value > >>say 30 microsec instead of 34 microsec in 802.11b protocol? >=20 > A->B=20 > C >=20 > Consider the above scenario where a frame exchange sequence is in = progress between nodes A and B while node C is deferring. > After A transmited a RTS to B, before node B sends back a CTS, it = takes a SIFS time for B to turn from receiving node to transmitting = node. > Then, it may take a SlotTime for node C senses the transmission of = CTS. Therefore, to give priority for the ongoing transmission, the DIFS = must be greater than (aSIFS + aSlotTime). > I think the reason that the standard chooses 2 x aSlotTime rather = than 1 x aSlotTime is just to make the protocol more relialbe. >=20 > Moreover, the DIFS value should be 50 us in DSSS of IEEE 802.11b. >=20 >=20 >=20 >=20 > Best regards > Li zhifei >=20 >=20 >=20 > -----Original Message----- > From: T. Bheemarjuna Reddy [mailto:arjun@cs.iitm.ernet.in] > Sent: dimecres, 3 / setembre / 2003 15:47 > To: manet@ietf.org > Subject: [manet] doubt regarding 802.11 IFSs >=20 >=20 > Hi all, >=20 > In 802.11 MAC protocol, the "slot time" id defined as >=20 > aSlotTime =3D aCCATime +aRxTxTurnaroundTime + aAirPropagationTime + > aMACProcessingDelay. >=20 > My doubt is why above all parameters be considered for determining = "slot > time" value. In otherwords, in 802.11b protocol, SIFS is set to 9 > microsec, why cannot it be someother value say 5 microsec? >=20 > Further, SIFS is defined as=20 >=20 > aSIFS =3D aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + = aRxTxTurnaround > time. >=20 > My doubt is why "aAirPropagationTime" used in aSlotTime is not taken = into > consideration during calculation of aSIFS value? >=20 > and=20 >=20 > WHY aDIFS =3D aSIFS + 2 x aSlotTime ? why cannot it be someother value > say 30 microsec instead of 34 microsec in 802.11b protocol? >=20 > If anybody knows, please clarify my doubts. > Thanx inadvannce. >=20 > -----arjun >=20 >=20 --=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 Bheemarjuna Reddy Tamma =3D Room no: 271 =3D Cauvery Hostel =3D IIT Madras =3D Chennai -600036 =3D PHNO: 044-2257 9071(Hostel)=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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Sep 19 22:05:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01410 for ; Fri, 19 Sep 2003 21:37:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCp020140 for ; Fri, 19 Sep 2003 21:36:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7PI2Im1002696 for manet-archive@odin.ietf.org; Mon, 25 Aug 2003 14:02:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLfF-0000cB-VY for manet-web-archive@optimus.ietf.org; Mon, 25 Aug 2003 14:02:01 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05079 for ; Mon, 25 Aug 2003 14:01:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rLe8-0000Fa-Pt; Mon, 25 Aug 2003 14:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rJaB-0004tV-2b for manet@optimus.ietf.org; Mon, 25 Aug 2003 11:48:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24985 for ; Mon, 25 Aug 2003 11:48:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rJa9-0002qI-00 for manet@ietf.org; Mon, 25 Aug 2003 11:48:38 -0400 Received: from capella.nps.navy.mil ([131.120.254.83] helo=[140.32.132.66]) by ietf-mx with esmtp (Exim 4.12) id 19rJa9-0002qF-00 for manet@ietf.org; Mon, 25 Aug 2003 11:48:37 -0400 Received: from no.name.available by [140.32.132.66] via smtpd (for [132.151.6.1]) with ESMTP; Mon, 25 Aug 2003 08:44:40 -0700 Received: from ro178-30.ro.nps.navy.mil (ro178-30.ro.nps.navy.mil [131.120.178.30]) by capella.nps.navy.mil (8.12.9/8.12.9) with ESMTP id h7PFmXxK010288; Mon, 25 Aug 2003 08:48:34 -0700 (PDT) Subject: Re: [manet] Replication in wireless ad hoc networks From: Rex Buddenberg To: jw2000@excite.com Cc: manet@ietf.org In-Reply-To: <20030823145516.2C7E0B6C2@xmxpita.excite.com> References: <20030823145516.2C7E0B6C2@xmxpita.excite.com> Content-Type: text/plain Message-Id: <1061826490.3752.30.camel@ro178-30.ro.nps.navy.mil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 25 Aug 2003 08:48:11 -0700 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 my original response was perhaps a bit tart. CVS= concurrent version system. No, not a URL and not a mailing list. CVS is commonly used by distributed developments to keep the code base consistent -- FreeBSD and Linux developments are a couple good examples where there are dozens of people working on various parts of the OS. CVS keeps the discipline. It's evolved from the venerable unix RCS and SCCS (source code control system). CVS, under the hood, has a directory with base files and then a bunch of deltas to those files -- the 'current' file version may not actually exist. rsynch is a unix command (smaller scale than CVS which is several commands). shorthand for remote synchronization. You put an rsynch host on the network, work on a client, and then rsynch the target directory to the host. Updates. More sophisticated than a raw backup -- it only changes the things that changed (files with date changes and inside them only the changes, not the whole file). Both of these command sets work fine for maintaining consistency across text files (they're most heavily used for computer code). Work fine for a distributed document editing exercise -- particularly if you're editing in, say, HTML rather than Word (or, perish, PowerPoint). They don't work as well for binary files (incrementals are hard to ID). WRT manet issues, the salient drawback is that these are both centralized -- there has to be a central CVS or rsynch host. On Sat, 2003-08-23 at 07:55, Jack Wang wrote: > Could you please tell me the URL of the two lists? > > Thanks, > > Jack > > > > > --- On Fri 08/22, Rex Buddenberg < budden@nps.navy.mil > wrote: > From: Rex Buddenberg [mailto: budden@nps.navy.mil] > To: roybiv@hotmail.com > Cc: manet@ietf.org > Date: 22 Aug 2003 08:54:51 -0700 > Subject: Re: [manet] Replication in wireless ad hoc networks > > you're on the wrong list; look up 'cvs' and 'rsynch'

On Fri, 2003-08-22 at 02:36, Alistair Harris wrote:
> Hello everyone,
> I'm a new research student focussing on broadly on the area of data
> replication in wireless ad hoc networks. Specifically, I would like to
> investigate issues concerning the management of mutiple copies of a document
> and the subsequent requirement to reconcile any changes to produce a 'final'
> document.
>
> I would like to know if anyone is doing related work in this area or know of
> any good sources of information.
>
> Thanks
>
> Regards
>
> _________________________________________________________________
> Find a cheaper internet access deal - choose one to suit you.
> http://www.msn.co.uk/internetaccess
>
>
> _______________________________________________
> 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
> > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > _______________________________________________ > 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 Fri Sep 19 22:05:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01334 for ; Fri, 19 Sep 2003 21:37:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhCX020140 for ; Fri, 19 Sep 2003 21:36:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h899G7o8022797 for manet-archive@odin.ietf.org; Tue, 9 Sep 2003 05:16:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19webW-0005vc-U7 for manet-web-archive@optimus.ietf.org; Tue, 09 Sep 2003 05:16:06 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27480 for ; Tue, 9 Sep 2003 05:15:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19weac-0005sH-D8; Tue, 09 Sep 2003 05:15:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19weZn-0005Hj-W0 for manet@optimus.ietf.org; Tue, 09 Sep 2003 05:14:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27160 for ; Tue, 9 Sep 2003 05:14:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19weZf-00009H-00 for manet@ietf.org; Tue, 09 Sep 2003 05:14:11 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 19weZU-00005M-00 for manet@ietf.org; Tue, 09 Sep 2003 05:14:01 -0400 Received: from jafymobile (6ants5.etri.re.kr [129.254.112.239]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id SBCRPC2F; Tue, 9 Sep 2003 18:09:08 +0900 Reply-To: From: "HyunWook Cha" To: , Subject: RE: [manet] The Problem of Alien Node Date: Tue, 9 Sep 2003 18:09:57 +0900 Organization: ETRI Message-ID: <006001c376b2$241b96f0$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 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Yasser. Please, see my further comments. > -----Original Message----- > From: Yasser A. Lotfy [mailto:yasser.lotfy@lycos.com] > Sent: Tuesday, September 09, 2003 2:51 AM > To: manet@ietf.org; jafy@etri.re.kr > Subject: RE: [manet] The Problem of Alien Node > > > > Hi Manish, > you are generaly right, please read my comments below. > yasser You made a big mistake. I am not Manish, but Hyunwook. :-) > > 2) By registration I mean that an alien node (a node that > > doesn't follow the MANET_PREFIX address) will have to > > register it's address with the gateway. Then periodically > > refresh this registration, otherwise, the gateway will > > periodically remove unrefreshed registration. In this way, > > The gateway will have to check destination address of pkts, > > and forward out of the network only pkts with unregistered > > address at alien table. In case of partition, the > > registration will be removed after a while. In multiple > > gateways, all of them will receive the registration msg. > > Because of frequent partitioning in MANET, you cannot > guarantee that all nodes with static global ip can > register its address with all gateways. > > [Yasser] Not really, all gateways reachable by destination > will be updated by alien node registration in timely manner > (please re-read). Yeah, I read your explanation again. But I don't agree for the same reason. Although all gateways reachable by destination will be updated by alien node registration in timely manner, partitioning in the MANET can cause the expiration of "registration entry" for the dst in some of the gateways. Then, "The Alien node problem" may happen again. > Basically, I do not think that "the registaration" you meant > is not essential for the reason which is mentioned > repeatedly. I think route informations obtained by routing > protocols and ICMP messages are enough for "the alien node problem". > For the communication between a manet node and Internet one, > I propose a manet node registers its permanent(or quite > stable) ip with MANET_PREFIX and its dynamically configured > global IP with prefix from a gateway with the corresponding gateway. > As I said in the previouse reply, this information can be > useful for incoming traffic from Internet to MANET. > What do you think about this? > > [Yasser] I agree, and believe manet node has to register with > all reachable gateways, not with a selected one. Registration that I mentioned is different from your scheme in following points. What does a manet node register with Which gateway? In my "registration", a node registers keyed address i.e one with MANET_PREFIX and its autoconfigured global IP with the gateway who advertised the prefix of the global IP or assigned the global IP. This is very natural with stateful IP autoconfiguration. But in your scheme, a manet node registers its static global IP with all reachable gateways. "The Alien Node Problem" you defined arises because of the usage of static global IPs which are indistinguishable from globally routable global IPs in MANETs. IMO, global ip assigned to a manet node should be verified as unique like those assigned to non-manet nodes, because global IPs which are statically assinged without considering "duplidate address problem" can cause DoS atteck unintentionally in MANET with Internet connectivity. Please think about this case. Src node wants to communicate with an Internet server and address of another node is set to a static global IP which is same as the Internet server. Then, the traffic from src to the Internet server may be intercepted if src obtains host route for destination address through RREQ of the manet node possessing same address or any other means and src can not receive the service of the server any more. In order to avoid this problem, DAD for any global IP assigned to a manet node should be performed no matter how the address may assinged, too. In case of autoconfigured global IPs and HoA of MIP-node, DAD is required to be performed. IMO, manet node in MANET with Internet connectivity should not use static global IP except that it is MIP-node and static address is HoA since DAD for the static global IP can not be done. If we consider only MANET without Internet connectivity, DAD for any address can be performed in the same way i.e strong DAD, weak DAD etc. Then, what will happen when some nodes running routing protocol daemon which supports Internet connectivity and other nodes running daemon which does not coexist in MANET? Let's assume that node D in latter group is given a static global IP. Although its ip is unique in latter group, an Internet node D' communicating with node S in former group may have same ip. Then, the route entry for D' in S can be overwritten with the host route info for D by RREQ, RREP etc. How can we solve this problem? What do you think about this? Regards, Hyunwook Cha. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Sep 19 22:37:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04585 for ; Fri, 19 Sep 2003 22:37:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhFp020140 for ; Fri, 19 Sep 2003 21:37:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FGUnn010916 for manet-archive@odin.ietf.org; Wed, 9 Jul 2003 11:16:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGgI-0002pz-69 for manet-web-archive@optimus.ietf.org; Wed, 09 Jul 2003 11:16:30 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05253 for ; Wed, 9 Jul 2003 11:16:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aGd8-00016q-Cr; Wed, 09 Jul 2003 11:13:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aEfz-00078N-Vv for manet@optimus.ietf.org; Wed, 09 Jul 2003 09:08:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29599 for ; Wed, 9 Jul 2003 09:08:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aEfy-0006WV-00 for manet@ietf.org; Wed, 09 Jul 2003 09:08:02 -0400 Received: from x86unx3.comp.nus.edu.sg ([137.132.90.3]) by ietf-mx with esmtp (Exim 4.12) id 19aEfx-0006WK-00 for manet@ietf.org; Wed, 09 Jul 2003 09:08:01 -0400 Received: from e500b.comp.nus.edu.sg (e500b.comp.nus.edu.sg [137.132.90.26]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id VAA22287 for ; Wed, 9 Jul 2003 21:07:51 +0800 (GMT-8) From: Er Inn Inn Received: from se11.comp.nus.edu.sg(137.132.80.19) by e500b.comp.nus.edu.sg via csmap id 7834; Wed, 09 Jul 2003 21:07:31 +0800 (SGT) Received: (from http@localhost) by se11.comp.nus.edu.sg (8.12.2+Sun/8.12.5) id h69D7VlW012294; Wed, 9 Jul 2003 21:07:31 +0800 (SGT) X-Authentication-Warning: se11.comp.nus.edu.sg: http set sender to erinninn@comp.nus.edu.sg using -f Received: from noc.comp.nus.edu.sg ([137.132.80.35]) (proxying for 172.18.179.81) (SquirrelMail authenticated user erinninn) by mysoc.nus.edu.sg with HTTP; Wed, 9 Jul 2003 21:07:31 +0800 (SGT) Message-ID: <1316.137.132.80.35.1057756051.squirrel@mysoc.nus.edu.sg> Date: Wed, 9 Jul 2003 21:07:31 +0800 (SGT) To: In-Reply-To: <005b01c344a8$103243f0$70d5cdc1@science.unitn.it> References: <005b01c344a8$103243f0$70d5cdc1@science.unitn.it> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [manet] Problem installing tk8.3.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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi guys, I have downloaded tk8.3.2.tar.gz and tried to install it in my machine. However, I met the following problem when I tried to configure tk8.3.2: checking for X... (cached) no checking for X11 header files... couldn't find any! checking for X11 libraries... checking for XCreateWindow in -lXwindow... (cached) no couldn't find any! Using -lX11. And when I tried to make the files, the following error appeared: ... ... {standard input}: Assembler messages: {standard input}:661: Error: symbol `dy' is already defined {standard input}:667: Error: symbol `dx' is already defined {standard input}:714: Error: symbol `q' is already defined {standard input}:720: Error: symbol `p' is already defined {standard input}:726: Error: symbol `q' is already defined {standard input}:732: Error: symbol `q' is already defined make: *** [tk3d.o] Error 1 I guess the problem is with the X11 header files and libraries that I failed to find... But I don't know how to solve this problem. Forget to mention that my system is running on Redhat Linux 9.0. X11R6 folder is under /usr. There is a symbolic link named X11 in /usr/lib. Really need help badly! Thanks in advance! regards, inn inn _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 09:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03687 for ; Sat, 20 Sep 2003 09:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8k-00025k-Nj for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpAQn008032 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8k-00025M-Dm for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51: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 JAA03651 for ; Sat, 20 Sep 2003 09:51:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8i-0004Lb-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8c-0004L7-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i82-0001p6-Gr; Sat, 20 Sep 2003 09:50:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xuFL-0005Z6-Cn for manet@optimus.ietf.org; Fri, 12 Sep 2003 16:10:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13573 for ; Fri, 12 Sep 2003 16:10:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xuFI-0004pN-00 for manet@ietf.org; Fri, 12 Sep 2003 16:10:20 -0400 Received: from pit.erg.sri.com ([128.18.100.28]) by ietf-mx with esmtp (Exim 4.12) id 19xuFH-0004p5-00 for manet@ietf.org; Fri, 12 Sep 2003 16:10:19 -0400 Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id NAA14282; Fri, 12 Sep 2003 13:09:42 -0700 (PDT) Message-Id: <200309122009.NAA14282@pit.erg.sri.com> To: manet@ietf.org cc: ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Comments on draft-jelger In-reply-to: Your message of "Sun, 07 Sep 2003 05:14:58 +0200." <1062904498.3f5aa2b2d1b8d@clarinet.u-strasbg.fr> Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 13:09:41 -0700 Christophe and all, (I tried to post this message a few days ago but there was a problem with the list server.) I noticed that your message was not posted to the manet list even though you copied the list. However, your original message is included in this reply. > Richard and all, > > I think your assumtions make sense, but there is just one thing you don't > mention. If prefix continuity is maintained, it creates more coherence in the > topological (and geographical) organization of the network, i.e. "islands" of > sub-networks. I personaly appreciate this feature and think that most people > running a network would prefer something organized that something "messy". I agree that prefix continuity has some advantages, but it also has some disadvantages. As discussed below, I think it is contrary to the consensus of previous discussions on the manet list because it does not allow intra-manet routing to a destination having a different prefix (i.e., to reach a different prefix island, the packet must go through a gateway). > Now about the routing header ... I don't fully understand your point, > particularly why you need routing header in 2 but not in 1. Personnaly I think > you could get rid of the routing header in both cases, by using the link-local > address of the neighbor towards the gateway as the next hop for the default > route. But honestly I haven't really thought about that, so I may be missing > something. > > Regards, > > Christophe (Note: This is the end of Christophe Jelger's comments. The message that he is replying to appears at the end of this email.) This problem regarding the routing header was discussed in a post by Guillaume Chelius on 22 July 2002. Note that a packet sent on the default route without a packet header does not contain any information about the default gateway. (In solution 2 [see below] the default gateway is required to have the same prefix as the source node.) Thus, if prefix continuity is not maintained, the source router might have default gateway GW1, while the next hop on the shortest path to GW1 might have default gateway GW2 (which could result in a loop, or could send the packet to the wrong gateway). Therefore, since solution 2 requires a routing header for default routing, and solution 3 requires prefix continuity, my opinion is that solution 1 is the best approach, which simply finds the shortest path to each other manet node, including each gateway, and allows a node to select any nearby gateway (and use its prefix). I think it is best to use a solution that does not require using a routing header except for special cases. OSPF does not require a routing header for routing to an external network, so why should we require one? (Also, this allows the manet routing protocol to be an extension of OSPF.) I would like to make a few more points. Your method (which uses a DSDV-like protocol to select a gateway and maintain prefix continuity) results in default routing that does not use the min-hop path to the default gateway (since the min-hop path might use intermediate nodes having a different prefix), and therefore is not consistent with a proactive min-hop routing protocol, unless the routing protocol is restricted to finding routes only within each prefix island. For example, to reach a manet node in another prefix island (even if the other node is only 2 hops away), your method would send the packet to the default gateway. I think this is contrary to previous discussions on the manet list (e.g., if there is a manet node 2 hops away, the packet should be routed along a 2-hop path within the manet, even if the node has a different prefix). Another point I want to make has been made before on this list. 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 and having a node change its prefix only when it does not have a path to a gateway with the same 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 > > Quoting ogier@erg.sri.com: > > > > > To Christophe and all, > > > > I thought more about the solution in your draft, and the benefits > > of "prefix continuity". One of the benefits of prefix continuity > > that I did not consider before is that it allows hop-by-hop default > > routing, without using a routing header to specify the gateway. > > (This is because the default next-hop router has the same prefix > > and thus has a consistent default route.) > > > > Also, I understand that your method minimizes the number of prefix > > changes, given that you want to maintain prefix continuity. > > (For example, it requires fewer changes than if a manet node was > > required to always select a nearest gateway and use its prefix.) > > I think it would be better to allow changing the prefix if > > another gateway becomes *much* closer, but my main point in > > this message is whether or not prefix continuity should be > > required. > > > > I see three possible solutions, depending on whether prefix continuity > > is required, and on whether a packet routed to the internet must go > > thru a gateway having the same prefix as the sender. > > I hope people will comment on which of these three solution > > is preferable, and whether any of them (particularly the first one) > > is unacceptable. > > > > 1. The default route always uses the nearest gateway, regardless of > > its prefix. Prefix continuity is not maintained. > > > > Benefit: Hop-by-hop default routing is easy (without routing header). > > Benefit: A manet node does not need to change its prefix to > > maintain prefix continuity. > > Drawback: Gateway prefix may be different from sender prefix, > > which could cause a problem with source address filtering, and > > the reverse route could go thru a different gateway with a > > different prefix. (Are these drawbacks acceptable?) > > > > 2. The default route is required to use a gateway with the same prefix > > as the sending node, even if there is a closer gateway, but prefix > > continuity is not maintained. > > > > Benefit: Gateway prefix is same as sender prefix. > > Benefit: A manet node does not need to change its prefix to > > maintain prefix continuity. > > Drawback: A routing header (to reach gateway) is required for default > > routing. Hop-by-hop default routing is not possible. > > > > 3. Same as 2, but prefix continuity is maintained. > > > > Benefit: Gateway prefix is same as sender prefix. > > Benefit: Hop-by-hop default routing is possible (without routing header). > > Drawback: A manet node may need to change its prefix to maintain > > prefix continuity, unlike the first two solutions. > > > > In my opinion, the first solution is best if it is OK to route > > the packet thru a gateway with a different prefix, otherwise the > > second solution is best if using a routing header is not considered > > a significant drawback, otherwise the third solution is best. > > > > Regards, > > Richard > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 09:51:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03722 for ; Sat, 20 Sep 2003 09:51:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8m-00026C-A3 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpCPe008062 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8m-00025w-2Q for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51: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 JAA03630 for ; Sat, 20 Sep 2003 09:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8e-0004LC-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8Z-0004L1-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i85-0001pT-Cm; Sat, 20 Sep 2003 09:50:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xlXj-00088f-4Z for manet@optimus.ietf.org; Fri, 12 Sep 2003 06:52:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15952 for ; Fri, 12 Sep 2003 06:52:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xlXd-0004Yc-00 for manet@ietf.org; Fri, 12 Sep 2003 06:52:41 -0400 Received: from i4mail.informatik.rwth-aachen.de ([137.226.12.21]) by ietf-mx with esmtp (Exim 4.12) id 19xlXc-0004YA-00 for manet@ietf.org; Fri, 12 Sep 2003 06:52:41 -0400 Received: from i4mail (i4mail.informatik.rwth-aachen.de [137.226.12.21]) by i4mail.informatik.rwth-aachen.de (Postfix) with ESMTP id 47EE71848F for ; Fri, 12 Sep 2003 12:52:00 +0200 (CEST) Received: from canary.info-4.informatik.rwth-aachen.de ([137.226.12.209]) by i4mail.informatik.rwth-aachen.de (MailMonitor for SMTP v1.2.2 ) ; Fri, 12 Sep 2003 12:52:00 +0200 (CEST) Reply-To: From: =?iso-8859-2?Q?Mesut_G=FCnes?= To: Organization: RWTH-Aachen Message-ID: <005c01c3791b$e4fcb370$d10ce289@informatik.rwthaachen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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 Content-Transfer-Encoding: quoted-printable Subject: [manet] Mobility visualization tool for 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: , List-Archive: Date: Fri, 12 Sep 2003 12:52:00 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, we have published a tool which visualizes the mobility of ad-hoc networks. In contrast to other visualization tools, our tool uses directly the output of 'setdest' and allows so to get a feeling how the nodes will move in simulation. We think it is interesting to get an idea of the mobility pattern before performing simulations. The tool is written in Java. You can download the tool from our website=20 http://www.adhoc-nets.de -> Download The zip-file contains also two example scenario files. We will extent the tool to evaluate the mobility scenarios. sincerely Mesut G=FCne=BA ----------------------------------------------------------------- __ /\_\ __ =20 __\/_//\ \ =20 /\_\ /::\ \ Dipl.-Inform. =20 /:/ / /:/\:\ \ Mesut G=FCnes /:/ / /:/ /\:\_\ =20 /:/ / /:/ / _\/_/ Department of Computer Science =20 /:/ / /:/ / /\_\ Informatik 4 =20 _\/_/ /:/ / /:/ / RWTH-Aachen =20 /\ \ /:/ / /:/ / =20 \:\ \/:/ / /:/ / Office: 4108A =20 \:\/:/ / /:/ / _ =20 \::/ / \:\ \/\_\ Phone: +49 241 8021416 =20 \/_/ \:\/:/ / Fax: +49 241 8022220 =20 \::/ / =20 /::\ \ email: guenes@informatik.rwth-aachen.de /:/\:\_\ http://www-i4.informatik.rwth-aachen.de \/_/\/_/ ----------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 09:51:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03743 for ; Sat, 20 Sep 2003 09:51:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00027q-Og for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpDmr008120 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00026a-A5 for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51: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 JAA03637 for ; Sat, 20 Sep 2003 09:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8f-0004LL-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8Z-0004L3-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8B-0001qG-Vp; Sat, 20 Sep 2003 09:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yu4h-0006CG-Sw for manet@optimus.ietf.org; Mon, 15 Sep 2003 10:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01851 for ; Mon, 15 Sep 2003 10:11:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yu4f-0002t0-00 for manet@ietf.org; Mon, 15 Sep 2003 10:11:29 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193] helo=u-strasbg.fr) by ietf-mx with esmtp (Exim 4.12) id 19yu4e-0002ss-00 for manet@ietf.org; Mon, 15 Sep 2003 10:11:28 -0400 Received: from adhoc3net (adhoc3-net.u-strasbg.fr [130.79.90.124]) by u-strasbg.fr (8.12.3/8.12.3/Debian-6.4) with SMTP id h8FEKRPX009082; Mon, 15 Sep 2003 16:20:28 +0200 Message-ID: <029301c37b93$1a44a0a0$7c5a4f82@adhoc3net> From: "Christophe Jelger" To: Cc: References: <200309102256.PAA04981@pit.erg.sri.com> Subject: Re: [manet] Comments on draft-jelger 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: , List-Archive: Date: Mon, 15 Sep 2003 16:10:21 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Richard / all, Just to quickly reply to your comment below (part of your previous email). I'm afraid that your point is not correct, as with our proposal we don't use the gateway information to create a default route with reactive protocols. It is stated in the draft that we don't use a default route with reactive protocols because it prevents the protocol from being reactive (there is a default route!) and, as you state, it can prevent the use of shortest-path route. Of course, if the gateway is closer than the destination (which is in a different subnet), then the gateway will answer first and direct (maybe shorter) routing is not achieved. Waiting for some more time to select a (maybe possible) best answer is a solution, but it introduces a longe delay to establish the route, and many times the node will wait for nothing if there is no direct route. But this problem is the same with all proposals. For proactive the problem does not exist, as a node will have a view of the entire adhoc topology and will use the direct route to join an adhoc node with a different prefix (i.e. there will a /128 route for this destination in the routing table). Regards, Christophe > > I would like to make a few more points. Your method (which uses a > DSDV-like protocol to select a gateway and maintain prefix continuity) > results in default routing that does not use the min-hop path to the > default gateway (since the min-hop path might use intermediate nodes > having a different prefix), and therefore is not consistent with a > proactive min-hop routing protocol, unless the routing protocol is > restricted to finding routes only within each prefix island. > For example, to reach a manet node in another prefix island (even if > the other node is only 2 hops away), your method would send the packet > to the default gateway. I think this is contrary to previous discussions > on the manet list (e.g., if there is a manet node 2 hops away, the > packet should be routed along a 2-hop path within the manet, even if > the node has a different prefix). > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 09:51:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03741 for ; Sat, 20 Sep 2003 09:51:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00026t-E3 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpDuq008100 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00026N-32 for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51: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 JAA03633 for ; Sat, 20 Sep 2003 09:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8f-0004LQ-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8Z-0004L6-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i88-0001pv-Ts; Sat, 20 Sep 2003 09:50:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xnuQ-0004nx-Sh for manet@optimus.ietf.org; Fri, 12 Sep 2003 09:24:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21011 for ; Fri, 12 Sep 2003 09:24:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xnuO-0006IJ-00 for manet@ietf.org; Fri, 12 Sep 2003 09:24:20 -0400 Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 19xnuO-0006H8-00 for manet@ietf.org; Fri, 12 Sep 2003 09:24:20 -0400 Received: (qmail 24084 invoked by uid 510); 12 Sep 2003 13:22:44 -0000 Message-ID: <20030912132244.24083.qmail@webmail31.rediffmail.com> Received: from unknown (202.131.128.21) by rediffmail.com via HTTP; 12 sep 2003 13:22:44 -0000 MIME-Version: 1.0 From: "venkatachalam ramasamy" Reply-To: "venkatachalam ramasamy" To: manet@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [manet] research on 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: , List-Archive: Date: 12 Sep 2003 13:22:44 -0000 dear friends, i would like to do research on MANET . Kindly give your valuable sugessions. thanks ___________________________________________________ Meet your old school or college friends from 1 Million + database... Click here to reunite www.batchmates.com/rediff.asp _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 09:51:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03809 for ; Sat, 20 Sep 2003 09:51:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00027r-Pq for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpDnh008163 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-000272-Fg for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51: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 JAA03644 for ; Sat, 20 Sep 2003 09:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8f-0004LS-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8Z-0004L5-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i7z-0001oi-IJ; Sat, 20 Sep 2003 09:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xXyC-0006Hn-Va for manet@optimus.ietf.org; Thu, 11 Sep 2003 16:23: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 QAA12438 for ; Thu, 11 Sep 2003 16:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xXyB-0005xn-00 for manet@ietf.org; Thu, 11 Sep 2003 16:23:11 -0400 Received: from itanium.ece.ualberta.ca ([129.128.208.10] helo=itanium.ee.ualberta.ca) by ietf-mx with esmtp (Exim 4.12) id 19xXyA-0005xk-00 for manet@ietf.org; Thu, 11 Sep 2003 16:23:10 -0400 Received: from localhost (localhost [127.0.0.1]) by itanium.ee.ualberta.ca (Postfix) with ESMTP id 8F12517D8 for ; Thu, 11 Sep 2003 14:22:59 -0600 (MDT) From: Sumeeth Nagaraj To: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] CSMA Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Sep 2003 14:22:59 -0600 (MDT) Hi all, I was wondering how CSMA works for spread spectrum systems- a physical layer perspective or any pointers would be great. Best regards, Sumeeth _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 09:51:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03826 for ; Sat, 20 Sep 2003 09:51:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8t-00028h-7y for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpJfH008217 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8t-00028S-2C for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03662 for ; Sat, 20 Sep 2003 09:51:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8i-0004Lh-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8d-0004LR-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i83-0001pJ-Tn; Sat, 20 Sep 2003 09:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yhz3-00054u-BY for manet@optimus.ietf.org; Sun, 14 Sep 2003 21:16:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21573 for ; Sun, 14 Sep 2003 21:16:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yhz0-0002Af-00 for manet@ietf.org; Sun, 14 Sep 2003 21:16:50 -0400 Received: from smtp-send.myrealbox.com ([192.108.102.143]) by ietf-mx with esmtp (Exim 4.12) id 19yhz0-0002AX-00 for manet@ietf.org; Sun, 14 Sep 2003 21:16:50 -0400 Received: from nppham [130.220.36.141] by myrealbox.com with NetMail ModWeb Module; Mon, 15 Sep 2003 10:46:43 +0950 From: "Peter Pham" To: manet@ietf.org X-Mailer: NetMail ModWeb Module X-Sender: nppham MIME-Version: 1.0 Message-ID: <1063588603.c2ba1320nppham@myrealbox.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [manet] help on 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: , List-Archive: Date: Mon, 15 Sep 2003 10:46:43 +0950 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all I am working on the effect of RTS and CTS of 802.11 in ad hoc network using= NS2. I read some papers and their results on the effect or RTS/CTS are c= ontroversial...Some said having RTS/CTS improved the performance. Others = said the opposite. Can anyone tell me how to turn on/off the RTS/CTS operation in 802.11. >From my understanding through the first look of the code, there is no mecha= nism. However, I might be wrong...If this is the case, what can I do to t= urn it off... Cheers Peter Pham Peter Phuc Pham University of South Australia Institute for Telecommunication Research Phone: 61-883023869 Email: ppham@spri.levels.unisa.edu.au WWW: www.itr.unisa.edu.au/~ppham _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 09:51:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03846 for ; Sat, 20 Sep 2003 09:51:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i96-0002AX-Li for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpWxM008331 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i96-0002AH-Gv for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51:32 -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 JAA03674 for ; Sat, 20 Sep 2003 09:51:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8z-0004ML-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8k-0004LT-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i86-0001pd-OE; Sat, 20 Sep 2003 09:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xu3q-0004v4-Ac for manet@optimus.ietf.org; Fri, 12 Sep 2003 15:58:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13221 for ; Fri, 12 Sep 2003 15:58:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xu3o-0004j3-00 for manet@ietf.org; Fri, 12 Sep 2003 15:58:28 -0400 Received: from clavin.cs.tamu.edu ([128.194.130.106] helo=cs.tamu.edu ident=0) by ietf-mx with esmtp (Exim 4.12) id 19xu3o-0004j0-00 for manet@ietf.org; Fri, 12 Sep 2003 15:58:28 -0400 Received: from unix.cs.tamu.edu (unix [128.194.138.13]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id h8CJwR707119 for ; Fri, 12 Sep 2003 14:58:27 -0500 (CDT) Received: from localhost (b0l4549@localhost) by unix.cs.tamu.edu (8.10.2+Sun/8.10.2) with ESMTP id h8CJwRI00118 for ; Fri, 12 Sep 2003 14:58:27 -0500 (CDT) X-Authentication-Warning: unix.cs.tamu.edu: b0l4549 owned process doing -bs From: Bin Lu To: manet@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] real data? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Sep 2003 14:58:27 -0500 (CDT) Hi, I'm doing research in intrusion detection in ad hoc networks. Basically what I'm doing is to collect some data and then make a classifier to distinguish benign behaviors from intrusion. Due to the fact that we don't have access to a real ad hoc network, the only way for me to obtain data is to do some simulation. Based on the fact that real data is much more meaningful than simulated data, I'm wondering if there is a way for me to get some real data? It would also be fine if the data are not related to security stuff... I'd be very grateful if you can refer me to something... Regards, Bin Lu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 09:52:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03849 for ; Sat, 20 Sep 2003 09:51:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i96-0002Am-ON for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpWej008346 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i96-0002AJ-K1 for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51:32 -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 JAA03671 for ; Sat, 20 Sep 2003 09:51:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8z-0004MM-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8j-0004L9-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8F-0001qa-5O; Sat, 20 Sep 2003 09:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zNRx-0001eD-MZ for manet@optimus.ietf.org; Tue, 16 Sep 2003 17:33:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13929 for ; Tue, 16 Sep 2003 17:33:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zNRv-00039q-00 for manet@ietf.org; Tue, 16 Sep 2003 17:33:27 -0400 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 19zNRu-00039n-00 for manet@ietf.org; Tue, 16 Sep 2003 17:33:26 -0400 Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.7+Sun/8.11.7) with ESMTP id h8GLXNe16705; Tue, 16 Sep 2003 14:33:23 -0700 (PDT) From: "Elizabeth M. Belding-Royer" X-Sender: ebelding@saguaro To: ans-research@www1.ietf.org, manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] ANS RG Meeting 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: , List-Archive: Date: Tue, 16 Sep 2003 14:33:23 -0700 (PDT) Hi, Just a reminder - the IRTF ANS meeting will be held this Thursday at 5:30pm in the main Mobicom conference room. Please try to read the draft written by Zygmunt Haas before this meeting so that we can discuss it. Elizabeth _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 09:52:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03850 for ; Sat, 20 Sep 2003 09:51:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i96-0002B2-TV for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpWT8008362 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i96-0002An-Q1 for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51:32 -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 JAA03672 for ; Sat, 20 Sep 2003 09:51:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8z-0004MK-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8e-0004LY-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8I-0001qv-9G; Sat, 20 Sep 2003 09:50:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nez-0007E6-JI for manet@optimus.ietf.org; Fri, 19 Sep 2003 11:59: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 LAA01966 for ; Fri, 19 Sep 2003 11:58:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Nes-000222-00 for manet@ietf.org; Fri, 19 Sep 2003 11:58:58 -0400 Received: from mail03.gmu.edu ([129.174.0.113]) by ietf-mx with esmtp (Exim 4.12) id 1A0Nei-0001zI-00 for manet@ietf.org; Fri, 19 Sep 2003 11:58:48 -0400 Received: from Isovaio002 ([65.213.193.10]) by mserver3.gmu.edu (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPA id <0HLG0080ZXPG3E@mserver3.gmu.edu> for manet@ietf.org; Fri, 19 Sep 2003 11:58:28 -0400 (EDT) From: Ali Nabi Zadeh To: manet@ietf.org Reply-to: anabizad@gmu.edu Message-id: <000801c37ec6$d9725900$0ac1d541@Isovaio002> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [manet] MPLS2003 Call for participation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Sep 2003 11:58:21 -0400 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Apologies if you receive multiple copies of this Call-For-Participation. Sincerely, Ali Nabi Zadeh. ====================================== MPLS 2003 International Conference Omni Shoreham Hotel, Washington D.C. October 26-28, 2003 ====================================== http://www.mpls2003.com ====================================== You are cordially invited to attend the MPLS 2003 International Conference to be held in Washington D.C. October 26-28, 2003. The 3-day event consists of highly technical sessions, tutorials, panel discussions, and exhibits. Registration for the conference is now open. Early registration discounts are extremely lucrative and are valid for a limited time only. To register, go to: http://www.mpls2003.com/registration.htm A limited number of rooms are available at the Omni Shoreham Hotel at special rates for conference attendees. We suggest you make your reservation as soon as possible, since October is typically a busy period for hotels in Washington DC. Please MAKE SURE THAT YOU IDENTIFY YOURSELVES AS CONFERENCE ATTENDEES TO RECEIVE THE REDUCED RATES. Important Dates: --------------------- - Early Registration Rates Cut-Off Date: September 30 - Tutorials: October 26, 9:00am - 5:30 pm - Conference sessions: October 27-28, 8:45am-6:30pm - Exhibits: October 27-28, 8:45am-6:30pm Program (visit http://mpls2003.com/sessions.htm for details): Sunday October 26 ------------------ Tutorial 1: Introduction to MPLS Tutorial 2: VPNs Tutorial 3: Layer 2 VPNs/VPLS Tutorial 4: MPLS Security Monday October 27 ------------------ Opening remarks - Peter Hill (BellSouth Telecommunications) & Dr. Hamid Ahmadi (AT&T Labs) Introduction - Luca Martini (Level3 Communications) Keynote Session: Convergence (Service Provider's Perspective) - What is the Role of MPLS in Network Convergence? - R. Spencer, BT - MPLS Convergence Strategies - R. Moignard, France Telecom - MPLS: The Catalyst of Convergence? - C. Masiero, Equant Session: OAM - New Developments in MPLS and IP OAM - G. Swallow, Cisco Systems - Network Management of MPLS-based VPNs - K. Melden, Juniper Networks - MPLS Convergence, Control and OAM Implications - D. Allan, Nortel Networks - Service OA&M for MPLS VPNs - V. Kompella, Alcatel Session: Layer 2 Transport & Interworking over MPLS - VPLS - Remember LANE? - A. Sayeed, Cisco Systems - High Availability for MPLS LSRs - K. Kompella, Juniper Networks - Transitioning a Profitable Service Portfolio to an MPLS Core Network - M. Nielsen, Lucent Technologies - VPLS Provisioning, Performance and Scalability: Problems and Solutions - V. Radoaca, Nortel Networks Session: L2/L3 VPNs - BGP-VPN Services: Lessons Learned - R. Bonica, MCI - Design and Deploy Scalable Inter-AS MPLS VPNs - L. Fang, AT&T - L2-MPLS Networks - Y. Sato, NTT Communications - MPLS in Multi-AS Networks - R. Doukov, Flag Telecom PANEL: MPLS as a Fusing Technology - Chair: P. Hill, VP Technology Planning & Deployment, BellSouth Telecommunications - Members: D. McDysan (MCI), C. Kalmanek (ATT), R. Delavenne (LambdaNet), R. Wilder (Masergy), R. Doukov (Flag Telecom), McManus (Verizon), C. Liljenstolpe (Cable & Wireless), Y. Sato (NTT) Tuesday, October 28 ------------------- Keynote Lessons Learned - Yakov Rekhter (Juniper Networks) Critical Issues for Network Consolidation - Daniel Awduche (MCI) Session: Reliability - Next Generation Core Routers: Defining IP Reliability and Resiliency - L. Mamakos, Hyperchip - High Resiliency MPLS Network Design - S. Poretsky, Avici Systems - Hardening MPLS-based Networks - S. Vogelsang, Laurel Networks Session: IP Optical Integration - Optical Market Forces on GMPLS - K. Sage, Cisco Systems - Multiservice Metro Networks in Sweden and Their Plans to Go GMPLS - L. Andersson - Photonic Internet Laboratory: New Challenges for Future Photonic Network - N. Yamanaka, NTT - Generalized VPNs (GVPNs) - H. Ould-Brahim, Nortel Networks Session: New MPLS Features - Scalable Multicast MPLS Technology for Next Generation Broadband Services Network - S. Yasukawa, NTT - Multicast Traffic Engineering with MPLS - R. Aggarwal, Juniper Networks - LDP Fast Convergence - A. Atlas, Avici Systems - How to secure an MPLS/VPN network - M. Behringer, Cisco Systems - Integration of IPv6 and IPv6 VPN Services over MPLS - F. Le Faucheur, Cisco Systems Session: Traffic Engineering - Inter-area and Inter-AS MPLS Traffic Engineering - JP Vasseur, Cisco Systems - Traffic Engineering in Hierarchical Multiprovider Networks - G. Apostolopoulos, Redback Networks - Multi-Region (multiarea/multiAS) Traffic Engineering - A. Ayyangar, Juniper Networks - Advanced MPLS Application Testing - B. Miller, IXIA Session: Service & Provisioning Issues - MPLS Network Management: Enterprise Deployment Management - T. Nadeau, Cisco Systems - Attracting New Enterprise Customers with MPLS VPN Services - D. Christophe, Lucent Technologies - MPLS Beyond Service Provider Cores - A. Malis, Tellabs - Critical Quality of Service Issues in MPLS Networks - J. Brayley, Laurel Networks - Practical Implementation of Tools Allied to the Network Management of IP/MPLS-based Networks - P. Beaumont, WANDL We look forward to seeing you at the Conference. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 10:41:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03747 for ; Sat, 20 Sep 2003 09:51:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00027n-NA for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpDuG008125 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00026X-8j for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51: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 JAA03639 for ; Sat, 20 Sep 2003 09:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8f-0004LX-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8a-0004LU-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8G-0001ql-JJ; Sat, 20 Sep 2003 09:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYhY-0004MC-3v for manet@optimus.ietf.org; Wed, 17 Sep 2003 05:34:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02918 for ; Wed, 17 Sep 2003 05:34:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zYhU-0003FB-00 for manet@ietf.org; Wed, 17 Sep 2003 05:34:16 -0400 Received: from smtp1.voila.fr ([193.252.22.174] helo=mwinf4003.voila.fr) by ietf-mx with esmtp (Exim 4.12) id 19zYhU-0003ET-00 for manet@ietf.org; Wed, 17 Sep 2003 05:34:16 -0400 Received: from wwinf4003 (wwinf4003 [172.22.157.30]) by mwinf4003.voila.fr (SMTP Server) with ESMTP id DDE8A180008A for ; Wed, 17 Sep 2003 11:33:46 +0200 (CEST) Message-ID: <31581181.1063791226898.JavaMail.www@wwinf4003> From: "samir.chihi" Reply-To: samir.chihi@voila.fr To: manet@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] (no subject) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Sep 2003 11:33:46 +0200 (CEST) Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear sir, I want to know if rounting protocols manage the partition (disconnection) in ad hoc network ? Best regard. ------------------------------------------ Faites un voeu et puis Voila ! www.voila.fr _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 10:42:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03848 for ; Sat, 20 Sep 2003 09:51:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i97-0002BY-Kj for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpXFJ008394 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i97-0002BF-Gr for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03680 for ; Sat, 20 Sep 2003 09:51:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i95-0004MZ-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8z-0004MW-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8d-00024V-1m; Sat, 20 Sep 2003 09:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzVE-0002RI-1n for manet@optimus.ietf.org; Wed, 10 Sep 2003 03:35: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 DAA21043 for ; Wed, 10 Sep 2003 03:34:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wzVB-0001NR-00 for manet@ietf.org; Wed, 10 Sep 2003 03:34:57 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19wzVA-0001My-00 for manet@ietf.org; Wed, 10 Sep 2003 03:34:57 -0400 Received: from rogent.ac.upc.es (rogent.ac.upc.es [147.83.31.7]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h8A7YPZv004102 for ; Wed, 10 Sep 2003 09:34:25 +0200 (MET DST) Received: (from ew2004@localhost) by rogent.ac.upc.es (8.12.8/8.12.8) id h8A7YOgB026109 for manet@ietf.org; Wed, 10 Sep 2003 09:34:24 +0200 (MET DST) From: Conferencia ew2004 To: manet@ietf.org Message-ID: <20030910073424.GA26103@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [manet] European Wireless'04 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: , List-Archive: Date: Wed, 10 Sep 2003 09:34:24 +0200 Apologies if you receive multiple copies of this mail! ---------------------------------------------------------------------- Dear Colleague, We would like to let you that the submission deadline for The 5th European Wireless Conference (EW2004) "Mobile and Wireless Systems beyond 3G" February 24-27, 2004 Hosted at Technical University of Catalonia (UPC) - Barcelona, Spain has been extended to 17th of September, 2003. All the details about the conference can be found at: http://www.ac.upc.es/EW2004 Best regards, EW2004 organizing committee. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 10:42:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03744 for ; Sat, 20 Sep 2003 09:51:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00027s-QT for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpDsw008147 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00026o-CE for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51: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 JAA03647 for ; Sat, 20 Sep 2003 09:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8f-0004LP-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8Z-0004L4-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8D-0001qQ-KE; Sat, 20 Sep 2003 09:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zR5H-0001sR-6P for manet@optimus.ietf.org; Tue, 16 Sep 2003 21:26:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22680 for ; Tue, 16 Sep 2003 21:26:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zR5E-00060b-00 for manet@ietf.org; Tue, 16 Sep 2003 21:26:16 -0400 Received: from mailout1.samsung.com ([203.254.224.24] helo=mailout1) by ietf-mx with esmtp (Exim 4.12) id 19zR5D-00060W-00 for manet@ietf.org; Tue, 16 Sep 2003 21:26:15 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HLC008013YWZ6@mailout1.samsung.com> for manet@ietf.org; Wed, 17 Sep 2003 10:25:44 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLC00EPG3YWZ9@mailout1.samsung.com> for manet@ietf.org; Wed, 17 Sep 2003 10:25:44 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HLC00FEQ3YVAZ@mmp1.samsung.com> for manet@ietf.org; Wed, 17 Sep 2003 10:25:44 +0900 (KST) From: Soohong Daniel Park To: manet@ietf.org Cc: "'Soohong Daniel Park'" Message-id: <007b01c37cba$a08221b0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_DPO3oMJwEiFgERtrL1uUcg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [manet] DNS Discovery for global connectivity in IPv6 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: , List-Archive: Date: Wed, 17 Sep 2003 10:25:49 +0900 This is a multi-part message in MIME format. --Boundary_(ID_DPO3oMJwEiFgERtrL1uUcg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi all In order to provide global connectivity in manet, DNS Discovery should be considered at this area. http://www.ietf.org/internet-drafts/draft-park-manet-dns-discovery-globa lv6-00.txt Originally, my intent is from the draft-wakikawa-manet-globalv6-02.txt Any comments ? Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics --Boundary_(ID_DPO3oMJwEiFgERtrL1uUcg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT 메시지

Hi all

In order to provide global connectivity in manet, DNS Discovery
should be considered at this area.
http://www.ietf.org/internet-drafts/draft-park-manet-dns-discovery-globalv6-00.txt
Originally, my intent is from the draft-wakikawa-manet-globalv6-02.txt


Any comments ?


Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics


--Boundary_(ID_DPO3oMJwEiFgERtrL1uUcg)-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 10:42:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03739 for ; Sat, 20 Sep 2003 09:51:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00026Y-9A for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpDBA008082 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8n-00026H-1D for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51: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 JAA03635 for ; Sat, 20 Sep 2003 09:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8f-0004LJ-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8Z-0004L2-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8A-0001q6-C5; Sat, 20 Sep 2003 09:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zP3A-0006b4-TR for manet@optimus.ietf.org; Tue, 16 Sep 2003 19:16: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 TAA19537 for ; Tue, 16 Sep 2003 19:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zP39-0004qp-00 for manet@ietf.org; Tue, 16 Sep 2003 19:15:59 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 19zP38-0004qm-00 for manet@ietf.org; Tue, 16 Sep 2003 19:15:58 -0400 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HLB00A04XXRIT@mailout2.samsung.com> for manet@ietf.org; Wed, 17 Sep 2003 08:15:27 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLB001IWXXQ0E@mailout2.samsung.com> for manet@ietf.org; Wed, 17 Sep 2003 08:15:26 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HLB000KMXXQCT@mmp2.samsung.com> for manet@ietf.org; Wed, 17 Sep 2003 08:15:26 +0900 (KST) From: Soohong Daniel Park To: manet@ietf.org Message-id: <005301c37ca8$6ccb5240$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_3A9jcYiJag8fDKn78u8YCw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [manet] DNS Discovery for global connectivity in IPv6 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: , List-Archive: Date: Wed, 17 Sep 2003 08:15:31 +0900 This is a multi-part message in MIME format. --Boundary_(ID_3A9jcYiJag8fDKn78u8YCw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi all In order to provide global connectivity in manet, DNS Discovery should be considered at this area. http://www.ietf.org/internet-drafts/draft-park-manet-dns-discovery-globa lv6-00.txt Originally, my intent is from the draft-wakikawa-manet-globalv6-02.txt Any comments ? Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics --Boundary_(ID_3A9jcYiJag8fDKn78u8YCw) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT 메시지

Hi all

In order to provide global connectivity in manet, DNS Discovery
should be considered at this area.
http://www.ietf.org/internet-drafts/draft-park-manet-dns-discovery-globalv6-00.txt
Originally, my intent is from the draft-wakikawa-manet-globalv6-02.txt


Any comments ?



Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics


--Boundary_(ID_3A9jcYiJag8fDKn78u8YCw)-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 10:42:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03688 for ; Sat, 20 Sep 2003 09:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8k-00025n-OC for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KDpA54008033 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 09:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i8k-00025N-E1 for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 09:51: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 JAA03653 for ; Sat, 20 Sep 2003 09:51:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0i8i-0004Le-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0i8c-0004L8-00 for manet-web-archive@ietf.org; Sat, 20 Sep 2003 09:51:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0i80-0001os-TC; Sat, 20 Sep 2003 09:50:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xDtQ-0000bf-O6 for manet@optimus.ietf.org; Wed, 10 Sep 2003 18:56:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22137 for ; Wed, 10 Sep 2003 18:56:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xDtM-0006GS-00 for manet@ietf.org; Wed, 10 Sep 2003 18:56:52 -0400 Received: from pit.erg.sri.com ([128.18.100.28]) by ietf-mx with esmtp (Exim 4.12) id 19xDtK-0006DM-00 for manet@ietf.org; Wed, 10 Sep 2003 18:56:51 -0400 Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id PAA04981; Wed, 10 Sep 2003 15:56:08 -0700 (PDT) Message-Id: <200309102256.PAA04981@pit.erg.sri.com> To: jelger@clarinet.u-strasbg.fr cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Comments on draft-jelger In-reply-to: Your message of "Sun, 07 Sep 2003 05:14:58 +0200." <1062904498.3f5aa2b2d1b8d@clarinet.u-strasbg.fr> Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Sep 2003 15:56:07 -0700 Christophe and all, I noticed that your message was not posted to the manet list even though you copied the list. However, your original message is included in this reply. > Richard and all, > > I think your assumtions make sense, but there is just one thing you don't > mention. If prefix continuity is maintained, it creates more coherence in the > topological (and geographical) organization of the network, i.e. "islands" of > sub-networks. I personaly appreciate this feature and think that most people > running a network would prefer something organized that something "messy". I agree that prefix continuity has some advantages, but it also has some disadvantages. As discussed below, I think it is contrary to the consensus of previous discussions on the manet list because it does not allow intra-manet routing to a destination having a different prefix (i.e., to reach a different prefix island, the packet must go through a gateway). > Now about the routing header ... I don't fully understand your point, > particularly why you need routing header in 2 but not in 1. Personnaly I think > you could get rid of the routing header in both cases, by using the link-local > address of the neighbor towards the gateway as the next hop for the default > route. But honestly I haven't really thought about that, so I may be missing > something. > > Regards, > > Christophe (Note: This is the end of Christophe Jelger's comments. The message that he is replying to appears at the end of this email.) This problem regarding the routing header was discussed in a post by Guillaume Chelius on 22 July 2002. Note that a packet sent on the default route without a packet header does not contain any information about the default gateway. (In method 2, the default gateway is required to have the same prefix as the source node.) Thus, if prefix continuity is not maintained, the source router might have default gateway GW1, while the next hop on the shortest path to GW1 might have default gateway GW2 (which could result in a loop, or could send the packet to the wrong gateway). Therefore, since solution 2 requires a routing header for default routing, and solution 3 requires prefix continuity, my opinion is that solution 1 is the best approach, which simply finds the shortest path to each other manet node, including each gateway, and allows a node to select any nearby gateway (and use its prefix). I think it is best to use a solution that does not require using a routing header except for special cases. OSPF does not require a routing header for routing to an external network, so why should we require one? (Also, this allows the manet routing protocol to be an extension of OSPF.) I would like to make a few more points. Your method (which uses a DSDV-like protocol to select a gateway and maintain prefix continuity) results in default routing that does not use the min-hop path to the default gateway (since the min-hop path might use intermediate nodes having a different prefix), and therefore is not consistent with a proactive min-hop routing protocol, unless the routing protocol is restricted to finding routes only within each prefix island. For example, to reach a manet node in another prefix island (even if the other node is only 2 hops away), your method would send the packet to the default gateway. I think this is contrary to previous discussions on the manet list (e.g., if there is a manet node 2 hops away, the packet should be routed along a 2-hop path within the manet, even if the node has a different prefix). Another point I want to make has been made before on this list. 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 and having a node change its prefix only when it does not have a path to a gateway with the same 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 > > Quoting ogier@erg.sri.com: > > > > > To Christophe and all, > > > > I thought more about the solution in your draft, and the benefits > > of "prefix continuity". One of the benefits of prefix continuity > > that I did not consider before is that it allows hop-by-hop default > > routing, without using a routing header to specify the gateway. > > (This is because the default next-hop router has the same prefix > > and thus has a consistent default route.) > > > > Also, I understand that your method minimizes the number of prefix > > changes, given that you want to maintain prefix continuity. > > (For example, it requires fewer changes than if a manet node was > > required to always select a nearest gateway and use its prefix.) > > I think it would be better to allow changing the prefix if > > another gateway becomes *much* closer, but my main point in > > this message is whether or not prefix continuity should be > > required. > > > > I see three possible solutions, depending on whether prefix continuity > > is required, and on whether a packet routed to the internet must go > > thru a gateway having the same prefix as the sender. > > I hope people will comment on which of these three solution > > is preferable, and whether any of them (particularly the first one) > > is unacceptable. > > > > 1. The default route always uses the nearest gateway, regardless of > > its prefix. Prefix continuity is not maintained. > > > > Benefit: Hop-by-hop default routing is easy (without routing header). > > Benefit: A manet node does not need to change its prefix to > > maintain prefix continuity. > > Drawback: Gateway prefix may be different from sender prefix, > > which could cause a problem with source address filtering, and > > the reverse route could go thru a different gateway with a > > different prefix. (Are these drawbacks acceptable?) > > > > 2. The default route is required to use a gateway with the same prefix > > as the sending node, even if there is a closer gateway, but prefix > > continuity is not maintained. > > > > Benefit: Gateway prefix is same as sender prefix. > > Benefit: A manet node does not need to change its prefix to > > maintain prefix continuity. > > Drawback: A routing header (to reach gateway) is required for default > > routing. Hop-by-hop default routing is not possible. > > > > 3. Same as 2, but prefix continuity is maintained. > > > > Benefit: Gateway prefix is same as sender prefix. > > Benefit: Hop-by-hop default routing is possible (without routing header). > > Drawback: A manet node may need to change its prefix to maintain > > prefix continuity, unlike the first two solutions. > > > > In my opinion, the first solution is best if it is OK to route > > the packet thru a gateway with a different prefix, otherwise the > > second solution is best if using a routing header is not considered > > a significant drawback, otherwise the third solution is best. > > > > Regards, > > Richard > > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 20 19:36:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27034 for ; Sat, 20 Sep 2003 19:36:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0rGm-0008Ae-QC for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 19:36:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8KNa4Al031402 for manet-archive@odin.ietf.org; Sat, 20 Sep 2003 19:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0rGm-0008AP-LM for manet-web-archive@optimus.ietf.org; Sat, 20 Sep 2003 19:36:04 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27009 for ; Sat, 20 Sep 2003 19:35:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0rFn-00082u-Ks; Sat, 20 Sep 2003 19:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0rEt-00081h-DZ for manet@optimus.ietf.org; Sat, 20 Sep 2003 19:34:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26941 for ; Sat, 20 Sep 2003 19:33:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0rEm-0002iy-00 for manet@ietf.org; Sat, 20 Sep 2003 19:34:00 -0400 Received: from falcon.shiratori.riec.tohoku.ac.jp ([130.34.209.8]) by ietf-mx with esmtp (Exim 4.12) id 1A0rEb-0002gR-00 for manet@ietf.org; Sat, 20 Sep 2003 19:33:49 -0400 Received: from anpanman (YahooBB219171028249.bbtec.net [219.171.28.249]) (authenticated bits=0) by falcon.shiratori.riec.tohoku.ac.jp (8.12.10/8.12.10) with ESMTP id h8KNVkCw029331 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 21 Sep 2003 08:31:47 +0900 (JST) Message-ID: <002801c37fcf$6106cfa0$f91cabdb@anpanman> From: "Apichet Chayabejara" To: Cc: "Peter Pham" References: <1063588603.c2ba1320nppham@myrealbox.com> Subject: Re: [manet] help on 802.11 Date: Sun, 21 Sep 2003 08:31:54 +0900 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 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 Dear Pham, IEEE 802.11 only applies RTS/CTS handshakes to frames larger than RTSThreshold. So an easy way to turn it of is to set the RTSThreshold to a very large value. You may have to take a look in mac-802_11.h. Hope it helps. Apichet. ----- Original Message ----- From: "Peter Pham" To: Sent: Monday, September 15, 2003 9:56 AM Subject: [manet] help on 802.11 Hi all I am working on the effect of RTS and CTS of 802.11 in ad hoc network using NS2. I read some papers and their results on the effect or RTS/CTS are controversial...Some said having RTS/CTS improved the performance. Others said the opposite. Can anyone tell me how to turn on/off the RTS/CTS operation in 802.11. >From my understanding through the first look of the code, there is no mechanism. However, I might be wrong...If this is the case, what can I do to turn it off... Cheers Peter Pham Peter Phuc Pham University of South Australia Institute for Telecommunication Research Phone: 61-883023869 Email: ppham@spri.levels.unisa.edu.au WWW: www.itr.unisa.edu.au/~ppham _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Sep 21 22:07:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15587 for ; Sun, 21 Sep 2003 22:07:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1G6B-0005mZ-VN for manet-archive@odin.ietf.org; Sun, 21 Sep 2003 22:06:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8M26lLk022228 for manet-archive@odin.ietf.org; Sun, 21 Sep 2003 22:06:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1G6B-0005mR-Mt for manet-web-archive@optimus.ietf.org; Sun, 21 Sep 2003 22:06:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15583 for ; Sun, 21 Sep 2003 22:06:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1G68-00017N-00 for manet-web-archive@ietf.org; Sun, 21 Sep 2003 22:06:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1G63-00017K-00 for manet-web-archive@ietf.org; Sun, 21 Sep 2003 22:06:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1G5R-0005l3-Sa; Sun, 21 Sep 2003 22:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1G4e-0005kT-VZ for manet@optimus.ietf.org; Sun, 21 Sep 2003 22:05:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15569 for ; Sun, 21 Sep 2003 22:04:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1G4W-000175-00 for manet@ietf.org; Sun, 21 Sep 2003 22:05:05 -0400 Received: from tiquini.ece.arizona.edu ([128.196.29.23]) by ietf-mx with esmtp (Exim 4.12) id 1A1G4H-00016h-00 for manet@ietf.org; Sun, 21 Sep 2003 22:04:49 -0400 Received: from tiquini (tiquini [128.196.29.23]) by tiquini.ece.arizona.edu (8.12.9/8.12.9) with ESMTP id h8M22i66002302 for ; Sun, 21 Sep 2003 19:02:44 -0700 (MST) Received: from DHCP-105.ece.arizona.edu ([150.135.222.105]) by tiquini.ece.arizona.edu (MailMonitor for SMTP v1.2.2 ) ; Sun, 21 Sep 2003 19:02:44 -0700 (MST) Message-ID: <004401c380ad$e8312be0$69de8796@arizonaalaa> Reply-To: "Alaa Muqattash" From: "Alaa Muqattash" To: References: Date: Sun, 21 Sep 2003 19:04:50 -0700 Organization: The University of Arizona 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] RTS/CTS range Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, In [1], I believe that the RTS, CTS, Data and Ack packets are power controlled, and not only the Data packets as many people assume. This can be understood from the following authors statement in [1] "When the MAC times out while waiting for a CTS or DATA or ACK message from a node, we increment the transmit power level field by one and update the dr_pwr field" Thus, since if the MAC times out for a *CTS*, the node increments the transmit power level, that means that the *RTS* is sent at a controlled transmit power level and not at the maximum power level. This is quite different from the approach of PARO in [2], where the RTS/CTS packets are *always transmitted at maximum power*. The reason why I bring this up is that many papers refer to the two approaches as if they similar at the time that they are fundamentally different. Please correct me if I'm wrong. [1] Agarwal, S.; Katz, R.H.; Krishnamurthy, S.V.; Dao, S.K.; "Distributed power control in ad-hoc wireless networks" in PIMRC'01 [2] Javier Gomez, Andrew T. Campbell, "Conserving Transmission Power in Wireless Ad Hoc Networks" , ICNP'01 Best regards, Alaa Muqattash ================================================= Alaa Muqattash Ph.D. Student & Research Assistant Broadband Networking Laboratory Dept. of Electrical & Computer Engineering The University of Arizona Rm. 109, ECE Bldg. Tucson AZ 85721 Tel : (520) 626-9249 Fax : (520) 621-3862 Email : alaa@ece.arizona.edu Web: http://www.ece.arizona.edu/~alaa/ "Imagination is more important than knowledge" Albert Einstein ================================================= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 22 00:25:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18306 for ; Mon, 22 Sep 2003 00:25:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1IFr-0002kr-PJ for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 00:24:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8M4Otbs010586 for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 00:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1IFr-0002kf-JU for manet-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 00:24:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18297 for ; Mon, 22 Sep 2003 00:24:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1IFp-00027p-00 for manet-web-archive@ietf.org; Mon, 22 Sep 2003 00:24:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1IFj-00027m-00 for manet-web-archive@ietf.org; Mon, 22 Sep 2003 00:24:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1IEz-0002eL-MT; Mon, 22 Sep 2003 00:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1IEC-0002dq-EQ for manet@optimus.ietf.org; Mon, 22 Sep 2003 00:23: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 AAA18251 for ; Mon, 22 Sep 2003 00:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1IEA-00026i-00 for manet@ietf.org; Mon, 22 Sep 2003 00:23:10 -0400 Received: from law15-f66.law15.hotmail.com ([64.4.23.66] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1A1IDz-00025Z-00 for manet@ietf.org; Mon, 22 Sep 2003 00:22:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 21 Sep 2003 21:22:08 -0700 Received: from 203.129.220.117 by lw15fd.law15.hotmail.msn.com with HTTP; Mon, 22 Sep 2003 04:22:08 GMT X-Originating-IP: [203.129.220.117] X-Originating-Email: [karun8880@hotmail.com] From: "Karun Verma" To: manet@ietf.org Subject: Re: [manet] research on MANET Date: Mon, 22 Sep 2003 09:52:08 +0530 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 22 Sep 2003 04:22:08.0922 (UTC) FILETIME=[166447A0:01C380C1] Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: ,

Well,

I am also doing my thesis in this feild and i find it a good area for exploration. i am concentrating on Routing Algorithms. tell me your area of interests in this feild

Karun Verma

Punjab Engineering College

Chandigarh(U.T.)




See you
>From: "venkatachalam ramasamy"
>Reply-To: "venkatachalam ramasamy"
>To: manet@ietf.org
>Subject: [manet] research on MANET
>Date: 12 Sep 2003 13:22:44 -0000
>MIME-Version: 1.0
>Received: from mc9-f10.hotmail.com ([65.54.166.17]) by mc9-s3.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 20 Sep 2003 06:55:25 -0700
>Received: from optimus.ietf.org ([132.151.6.20]) by mc9-f10.hotmail.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 20 Sep 2003 06:55:01 -0700
>Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)by optimus.ietf.org with esmtp (Exim 4.20)id 1A0i88-0001ps-K0; Sat, 20 Sep 2003 09:50:32 -0400
>Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)by optimus.ietf.org with esmtp (Exim 4.20)id 19xnuQ-0004nx-Shfor manet@optimus.ietf.org; Fri, 12 Sep 2003 09:24:22 -0400
>Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21011for ; Fri, 12 Sep 2003 09:24:14 -0400 (EDT)
>Received: from ietf-mx ([132.151.6.1])by ietf-mx with esmtp (Exim 4.12)id 19xnuO-0006IJ-00for manet@ietf.org; Fri, 12 Sep 2003 09:24:20 -0400
>Received: from [202.54.124.130] (helo=rediffmail.com)by ietf-mx with smtp (Exim 4.12)id 19xnuO-0006H8-00for manet@ietf.org; Fri, 12 Sep 2003 09:24:20 -0400
>Received: (qmail 24084 invoked by uid 510); 12 Sep 2003 13:22:44 -0000
>Received: from unknown (202.131.128.21) by rediffmail.com via HTTP; 12 sep 2003 13:22:44 -0000
>X-Message-Info: g+YnDTwJTP44btJUkmCKn8LWv5FBazsybnbE+/6fosY=
>Message-ID: <20030912132244.24083.qmail@webmail31.rediffmail.com>
>Sender: manet-admin@ietf.org
>Errors-To: manet-admin@ietf.org
>X-BeenThere: manet@ietf.org
>X-Mailman-Version: 2.0.12
>Precedence: bulk
>List-Unsubscribe: ,
>List-Id: Mobile Ad-hoc Networks
>List-Post:
>List-Help:
>List-Subscribe: ,
>List-Archive:
>Return-Path: manet-admin@ietf.org
>X-OriginalArrivalTime: 20 Sep 2003 13:55:03.0755 (UTC) FILETIME=[CA9009B0:01C37F7E]
>
>dear friends,
>
>i would like to do research on MANET . Kindly give your valuable
>sugessions. thanks
>
>
>___________________________________________________
>Meet your old school or college friends from
>1 Million + database...
>Click here to reunite www.batchmates.com/rediff.asp
>
>
>
>_______________________________________________
>manet mailing list
>manet@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet

A chance to meet Aishwarya Rai. Win lucky prizes. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 22 03:14:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03941 for ; Mon, 22 Sep 2003 03:14:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1KtQ-0002xb-Gy for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 03:13:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8M7Du0Z011378 for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 03:13:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1KtP-0002xR-CQ for manet-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 03:13:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03928 for ; Mon, 22 Sep 2003 03:13:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1KtN-0003UC-00 for manet-web-archive@ietf.org; Mon, 22 Sep 2003 03:13:53 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1KtH-0003U9-00 for manet-web-archive@ietf.org; Mon, 22 Sep 2003 03:13:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1KsX-0002q4-4X; Mon, 22 Sep 2003 03:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Krh-0002om-EQ for manet@optimus.ietf.org; Mon, 22 Sep 2003 03:12:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03881 for ; Mon, 22 Sep 2003 03:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1Kra-0003Sj-00 for manet@ietf.org; Mon, 22 Sep 2003 03:12:02 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A1KrP-0003Sd-00 for manet@ietf.org; Mon, 22 Sep 2003 03:11:52 -0400 Received: from jafymobile (pd412g.etri.re.kr [129.254.112.173]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S878HL1S; Mon, 22 Sep 2003 16:09:06 +0900 Reply-To: From: "HyunWook Cha" To: , Cc: Subject: RE: [manet] Comments on draft-jelger Date: Mon, 22 Sep 2003 16:10:39 +0900 Organization: ETRI Message-ID: <004e01c380d8$a1097a30$ad70fe81@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 In-Reply-To: <200309102256.PAA04981@pit.erg.sri.com> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Richard and all, I have some questions and comments. Why are you guys thinking that only one gateway should be chosen and used by a manet node? If a node has "gw_info"s from multiple gateways, the node can configure multiple global addresses with prefixes in those infos in stateless manner as normal IPv6 does. I think that it is necessary to consider validity of global prefixes or gw_info as independent of reachability of corresponding gateways because the topology of manet is dynamically changeable. Please see my inline comments. > > I agree that prefix continuity has some advantages, but it also > has some disadvantages. As discussed below, I think it is contrary > to the consensus of previous discussions on the manet list because > it does not allow intra-manet routing to a destination having a > different prefix (i.e., to reach a different prefix island, the > packet must go through a gateway). > Manet node(sender) should sends its packets using default route (default gateway) only when it cannot obtain host route for destination. If destination in a different prefix island is reachable by source, source node forwards packets using the host route. > > > > > > 1. The default route always uses the nearest gateway, > regardless of > > > its prefix. Prefix continuity is not maintained. > > > > > > Benefit: Hop-by-hop default routing is easy (without > routing header). > > > Benefit: A manet node does not need to change its prefix to > > > maintain prefix continuity. > > > Drawback: Gateway prefix may be different from sender prefix, > > > which could cause a problem with source address > filtering, and > > > the reverse route could go thru a different gateway with a > > > different prefix. (Are these drawbacks acceptable?) > > > > > > 2. The default route is required to use a gateway with > the same prefix > > > as the sending node, even if there is a closer > gateway, but prefix > > > continuity is not maintained. > > > > > > Benefit: Gateway prefix is same as sender prefix. > > > Benefit: A manet node does not need to change its prefix to > > > maintain prefix continuity. > > > Drawback: A routing header (to reach gateway) is > required for default > > > routing. Hop-by-hop default routing is not possible. > > > I want to add an alternative schem for solution 2. How about source address based forwarding? Sender's upper layer chooses one source address with a prefix from a gw_info when a session is initiated. When ad hoc routing module processes packets of the session, it firstly looks up routing table and if no host route, forwards towards corresponding gateway according to source address. I think this is applicable to intermediate nodes. If an intermediate node has route entry as well as gw_info of corresponding gateway by any means, it can decide how to forward packets sent to a gateway by sender. 2.2 source address(prefix) based forwarding Benefit: Gateway prefix is same as sender prefix. Benefit: A manet node does not need to change its prefix to maintain prefix continuity. Benefit: Hop-by-hop default routing is possible (without routing header). Drawback: Unlikely solution 2(using routing header), all nodes including sender on the path to corresponding gateway must have both gw_info and route entry for the gateway. I think this drawback may degrade performance slightly(?) but this is also considerable. > > 3. Same as 2, but prefix continuity is maintained. > > > > > > Benefit: Gateway prefix is same as sender prefix. > > > Benefit: Hop-by-hop default routing is possible > (without routing header). > > > Drawback: A manet node may need to change its prefix to maintain > > > prefix continuity, unlike the first two solutions. > > > Regards, Hyunwook Cha _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 22 10:09:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15885 for ; Mon, 22 Sep 2003 10:09:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RNX-00055z-Vv for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 10:09:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ME9RDf019581 for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 10:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RNX-00055k-RX for manet-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 10:09:27 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15816 for ; Mon, 22 Sep 2003 10:09:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RMA-0004xs-Bf; Mon, 22 Sep 2003 10:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1RLj-0004pk-BO for manet@optimus.ietf.org; Mon, 22 Sep 2003 10:07:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15603 for ; Mon, 22 Sep 2003 10:07:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1RLc-0007OK-00 for manet@ietf.org; Mon, 22 Sep 2003 10:07:28 -0400 Received: from smtp-send.myrealbox.com ([192.108.102.143]) by ietf-mx with esmtp (Exim 4.12) id 1A1RLR-0007Ns-00 for manet@ietf.org; Mon, 22 Sep 2003 10:07:17 -0400 Received: from nppham [203.219.237.10] by myrealbox.com with NetMail ModWeb Module; Mon, 22 Sep 2003 23:36:11 +0950 Subject: Re: RE: [manet] help on 802.11 From: "Peter Pham" To: fli@unik.no, manet@ietf.org CC: apichet@shiratori.riec.tohoku.ac.jp Date: Mon, 22 Sep 2003 23:36:11 +0950 X-Mailer: NetMail ModWeb Module X-Sender: nppham MIME-Version: 1.0 Message-ID: <1064239571.3f95e140nppham@myrealbox.com> Content-Type: text/plain; charset="UTF-8" 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear all=20 Thank you very much for your response.=20 I know how to turn on/off RTS/CTS in ns2. However, I have another question.= By setting the RTSThreshold to a large value, we "at the beginning" can = permanently turn on/off RTS/CTS. However, I really want to control the tr= ansmission of RTS/CTS "on the fly", i.e. I can turn on/off RTS/CTS whenev= er I want (depending on the traffic condition, and the status of the othe= r nodes). Is this possible in NS2 ???... >From my understanding, I just add another control flag and turn on/off the = flag and modify the code so that in addition of checking the RTSThreshold= , it will check for that flag before transmitting RTS/CTS... However, I am worried that it will desrupt the operation of 802.11. =20 Can anyone shed any light on this please.=20 Peter Pham -----Original Message----- From: "Frank Li" To: "Apichet Chayabejara" Date: Mon, 22 Sep 2003 09:31:30 +0200 Subject: RE: [manet] help on 802.11 Hi Apichet, Pham, If you set the RTSThreshold to a NOT-very large value, packets smaller that= this value will be sent without RTS/CTS while larger packets will still = be using RTS/CTS in the same network. =20 Frank -----Original Message----- From: Apichet Chayabejara [mailto:apichet@shiratori.riec.tohoku.ac.jp] Sent: 21. september 2003 01:32 To: manet@ietf.org Cc: Peter Pham Subject: Re: [manet] help on 802.11 Dear Pham, IEEE 802.11 only applies RTS/CTS handshakes to frames larger than RTSThreshold. So an easy way to turn it of is to set the RTSThreshold to a very large value. You may have to take a look in mac-802_11.h. Hope it helps. Apichet. ----- Original Message -----=20 From: "Peter Pham" To: Sent: Monday, September 15, 2003 9:56 AM Subject: [manet] help on 802.11 Hi all I am working on the effect of RTS and CTS of 802.11 in ad hoc network using NS2. I read some papers and their results on the effect or RTS/CTS are controversial...Some said having RTS/CTS improved the performance. Others said the opposite. Can anyone tell me how to turn on/off the RTS/CTS operation in 802.11. >From my understanding through the first look of the code, there is no mechanism. However, I might be wrong...If this is the case, what can I do t= o turn it off... Cheers Peter Pham Peter Phuc Pham University of South Australia Institute for Telecommunication Research Phone: 61-883023869 Email: ppham@spri.levels.unisa.edu.au WWW: www.itr.unisa.edu.au/~ppham _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet Peter Phuc Pham University of South Australia Institute for Telecommunication Research Phone: 61-883023869 Email: ppham@spri.levels.unisa.edu.au WWW: www.itr.unisa.edu.au/~ppham _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 22 11:12:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19714 for ; Mon, 22 Sep 2003 11:12:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SM8-0000aO-5a for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 11:12:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MFC4vs002246 for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 11:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SM8-0000a9-0u for manet-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 11:12:04 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19687 for ; Mon, 22 Sep 2003 11:11:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SL7-0000RF-UG; Mon, 22 Sep 2003 11:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1SKk-0000Qg-Ga for manet@optimus.ietf.org; Mon, 22 Sep 2003 11:10:54 -0400 Received: from den.erg.sri.com (den.erg.sri.com [128.18.100.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19594 for ; Mon, 22 Sep 2003 11:10:28 -0400 (EDT) Received: from den.erg.sri.com (localhost [127.0.0.1]) by den.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id IAA28988; Mon, 22 Sep 2003 08:08:28 -0700 (PDT) Message-Id: <200309221508.IAA28988@den.erg.sri.com> To: "Christophe Jelger" cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Comments on draft-jelger In-reply-to: Your message of "Mon, 15 Sep 2003 16:10:21 +0200." <029301c37b93$1a44a0a0$7c5a4f82@adhoc3net> Date: Mon, 22 Sep 2003 08:08:28 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Christophe, > Just to quickly reply to your comment below (part of your previous email). > I'm afraid that your point is not correct, as with our proposal we don't use > the gateway information to create a default route with reactive protocols. > It is stated in the draft that we don't use a default route with reactive > protocols because it prevents the protocol from being reactive (there is a > default route!) and, as you state, it can prevent the use of shortest-path > route. That's fine for reactive routing. I was focusing on proactive routing, where you *do* propose using the gateway information to maintain a default route. > For proactive the problem does not exist, as a node will have a view of the > entire adhoc topology and will use the direct route to join an adhoc node > with a different prefix (i.e. there will a /128 route for this destination > in the routing table). I wasn't sure whether you wanted to allow direct (intra-manet) routing between nodes in different prefix islands, so my paragraph that you refer to considers both cases. Here is the paragraph again: > I would like to make a few more points. Your method (which uses a > DSDV-like protocol to select a gateway and maintain prefix continuity) > results in default routing that does not use the min-hop path to the > default gateway (since the min-hop path might use intermediate nodes > having a different prefix), and therefore is not consistent with a > proactive min-hop routing protocol, UNLESS the routing protocol is > restricted to finding routes only within each prefix island. > For example, to reach a manet node in another prefix island (even if > the other node is only 2 hops away), your method would send the packet > to the default gateway. I think this is contrary to previous discussions > on the manet list (e.g., if there is a manet node 2 hops away, the > packet should be routed along a 2-hop path within the manet, even if > the node has a different prefix). Although it may not have been clear, the example given in the last part of the paragraph assumes that direct routing is allowed only between nodes in the same prefix island (the "UNLESS" clause), so of course it is not valid if direct routing is allowed between different prefix islands. But the first part of the paragraph states that if direct routing is allowed between different prefix islands (the negation of the "UNLESS" clause), then your method of maintaining a default route for *proactive* routing is not consistent with the routes computed by the proactive routing protocol itself, since the proactive routing protocol will compute the min-hop path to the gateway, even if this path includes intermediate nodes that belong to a different prefix island. I'm not sure whether this inconsistency will cause any serious problems, but one way to avoid it, as I discussed in my previous email, is to simply let the routing protocol disseminate gateway information and maintain default routes to gateways (as in OSPF). (If the goal is to have a common gateway discovery mechanism for both proactive and reactive routing, I also discussed that in my previous email, but the gist is that, since the proactive routing protocol should already provide such a mechanism, it does not make sense to provide another such mechanism that can be used with both proactive and reactive routing, unless this common mechanism is already part of the proactive routing protocol.) Regards, Richard _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 22 12:03:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22500 for ; Mon, 22 Sep 2003 12:03:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1T9t-000457-Fy for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 12:03:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MG3ThQ015688 for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 12:03:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1T9t-00044x-Cj for manet-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 12:03:29 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22448 for ; Mon, 22 Sep 2003 12:03:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1T8V-0003bI-K3; Mon, 22 Sep 2003 12:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1T7b-0003Kx-UO for manet@optimus.ietf.org; Mon, 22 Sep 2003 12:01:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22329 for ; Mon, 22 Sep 2003 12:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1T7a-0000rE-00 for manet@ietf.org; Mon, 22 Sep 2003 12:01:06 -0400 Received: from den.erg.sri.com ([128.18.100.23]) by ietf-mx with esmtp (Exim 4.12) id 1A1T7J-0000om-00 for manet@ietf.org; Mon, 22 Sep 2003 12:00:50 -0400 Received: from den.erg.sri.com (localhost [127.0.0.1]) by den.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id IAA29138; Mon, 22 Sep 2003 08:58:56 -0700 (PDT) Message-Id: <200309221558.IAA29138@den.erg.sri.com> To: jafy@etri.re.kr cc: ogier@erg.sri.com, jelger@clarinet.u-strasbg.fr, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Comments on draft-jelger In-reply-to: Your message of "Mon, 22 Sep 2003 16:10:39 +0900." <004e01c380d8$a1097a30$ad70fe81@jafymobile> Date: Mon, 22 Sep 2003 08:58:55 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hello Hyunwook, > Richard and all, > > I have some questions and comments. > Why are you guys thinking that only one gateway should be chosen and > used by a manet node? > If a node has "gw_info"s from multiple gateways, the node can configure > multiple global addresses with prefixes in those infos > in stateless manner as normal IPv6 does. I agree. In fact, I mentioned in my post on 9/1 that a manet node can select multiple gateways and have multiple prefixes. > I think that it is necessary to consider validity of global prefixes or > gw_info as independent of reachability of corresponding gateways > because the topology of manet is dynamically changeable. > Please see my inline comments. > > > > > I agree that prefix continuity has some advantages, but it also > > has some disadvantages. As discussed below, I think it is contrary > > to the consensus of previous discussions on the manet list because > > it does not allow intra-manet routing to a destination having a > > different prefix (i.e., to reach a different prefix island, the > > packet must go through a gateway). > > > > Manet node(sender) should sends its packets using default route (default > gateway) only when it cannot obtain host route for destination. > If destination in a different prefix island is reachable by source, > source node forwards packets using the host route. I agree (and I discussed in my earlier message today). My above comment was based on the assumption that prefix continuity divides a manet into autonomous prefix islands/clusters (like "areas" in OSPF), because frankly I do not see any other good reason to maintain prefix continuity. > > > > > > > > 1. The default route always uses the nearest gateway, > > regardless of > > > > its prefix. Prefix continuity is not maintained. > > > > > > > > Benefit: Hop-by-hop default routing is easy (without > > routing header). > > > > Benefit: A manet node does not need to change its prefix to > > > > maintain prefix continuity. > > > > Drawback: Gateway prefix may be different from sender prefix, > > > > which could cause a problem with source address > > filtering, and > > > > the reverse route could go thru a different gateway with a > > > > different prefix. (Are these drawbacks acceptable?) > > > > > > > > 2. The default route is required to use a gateway with > > the same prefix > > > > as the sending node, even if there is a closer > > gateway, but prefix > > > > continuity is not maintained. > > > > > > > > Benefit: Gateway prefix is same as sender prefix. > > > > Benefit: A manet node does not need to change its prefix to > > > > maintain prefix continuity. > > > > Drawback: A routing header (to reach gateway) is > > required for default > > > > routing. Hop-by-hop default routing is not possible. > > > > > > I want to add an alternative schem for solution 2. > How about source address based forwarding? > Sender's upper layer chooses one source address with a prefix from a > gw_info when a session is initiated. > When ad hoc routing module processes packets of the session, > it firstly looks up routing table and if no host route, forwards towards > corresponding gateway according to source address. > I think this is applicable to intermediate nodes. If an intermediate > node has route entry as well as gw_info of corresponding gateway by any > means, > it can decide how to forward packets sent to a gateway by sender. Absolutely. This way a packet with no host route is forwarded (hop-by-hop) to the nearest gateway having the same prefix as the source, without requiring a routing header. I also considered this, but was concerned about requiring that source-address-based forwarding be supported. If we can assume source-address-based forwarding is supported, and if it is important to route to a gateway with the same prefix as the source, then this is the best solution. > > 2.2 source address(prefix) based forwarding > Benefit: Gateway prefix is same as sender prefix. > Benefit: A manet node does not need to change its prefix to maintain > prefix continuity. > Benefit: Hop-by-hop default routing is possible (without routing > header). > Drawback: Unlikely solution 2(using routing header), all nodes including > sender on the path to corresponding gateway must have both gw_info and > route entry for the gateway. > > I think this drawback may degrade performance slightly(?) but this is > also considerable. I don't think this "drawback" is a problem, since all intermediate nodes on the path to the gateway are closer to the gateway. If, as I suggested in my previous email, the gateway information is disseminated by the proactive routing protocol (as in OSPF), then this is certainly not a drawback. The only possible drawback I see is that source-address-based forwarding is required. Is this a significant drawback? Regards, Richard > > > > 3. Same as 2, but prefix continuity is maintained. > > > > > > > > Benefit: Gateway prefix is same as sender prefix. > > > > Benefit: Hop-by-hop default routing is possible > > (without routing header). > > > > Drawback: A manet node may need to change its prefix to maintain > > > > prefix continuity, unlike the first two solutions. > > > > > > Regards, > > Hyunwook Cha > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 22 12:21:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23370 for ; Mon, 22 Sep 2003 12:21:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TRB-0006aG-5M for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 12:21:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MGLLJ6025308 for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 12:21:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TRA-0006a6-W2 for manet-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 12:21:21 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23344 for ; Mon, 22 Sep 2003 12:21:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TPu-0006MP-HK; Mon, 22 Sep 2003 12:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1TOx-0006G7-VV for manet@optimus.ietf.org; Mon, 22 Sep 2003 12:19:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23238 for ; Mon, 22 Sep 2003 12:18:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1TOr-0002EG-00 for manet@ietf.org; Mon, 22 Sep 2003 12:18:57 -0400 Received: from isis.lip6.fr ([132.227.60.2] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A1TOg-00026E-00 for manet@ietf.org; Mon, 22 Sep 2003 12:18:46 -0400 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h8MGHACl013484 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Mon, 22 Sep 2003 18:17:10 +0200 X-pt: isis.lip6.fr Received: from localhost (iannone@localhost) by tibre.lip6.fr (8.11.6p3/8.11.6) with ESMTP id h8MGH9528618; Mon, 22 Sep 2003 18:17:10 +0200 (CEST) Date: Mon, 22 Sep 2003 18:17:09 +0200 (CEST) From: Luigi Iannone To: manet@ietf.org cc: nppham@myrealbox.com In-Reply-To: <20030922160003.12107.74306.Mailman@www1.ietf.org> Message-ID: References: <20030922160003.12107.74306.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: isis.lip6.fr Subject: [manet] Re: help on 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: , > --__--__-- > > Message: 4 > Subject: Re: RE: [manet] help on 802.11 > From: "Peter Pham" > To: fli@unik.no, manet@ietf.org > CC: apichet@shiratori.riec.tohoku.ac.jp > Date: Mon, 22 Sep 2003 23:36:11 +0950 > > Dear all=20 > Thank you very much for your response.=20 > > I know how to turn on/off RTS/CTS in ns2. However, I have another question.= > By setting the RTSThreshold to a large value, we "at the beginning" can = > permanently turn on/off RTS/CTS. However, I really want to control the tr= > ansmission of RTS/CTS "on the fly", i.e. I can turn on/off RTS/CTS whenev= > er I want (depending on the traffic condition, and the status of the othe= > r nodes). Is this possible in NS2 ???... Since each packet at L2 is independent from the others RTS/CTS can be adjusted "on the fly". > > >From my understanding, I just add another control flag and turn on/off the = > flag and modify the code so that in addition of checking the RTSThreshold= > , it will check for that flag before transmitting RTS/CTS... > Yes.. you have to change the code! > However, I am worried that it will desrupt the operation of 802.11. =20 I don't think so, if your coding is correct MAC won't be desrupted> Ciao Luigi > Can anyone shed any light on this please.=20 > > Peter Pham > > -----Original Message----- > From: "Frank Li" > To: "Apichet Chayabejara" > Date: Mon, 22 Sep 2003 09:31:30 +0200 > Subject: RE: [manet] help on 802.11 > > Hi Apichet, Pham, > > If you set the RTSThreshold to a NOT-very large value, packets smaller that= > this value will be sent without RTS/CTS while larger packets will still = > be using RTS/CTS in the same network. =20 > > Frank > > -----Original Message----- > From: Apichet Chayabejara [mailto:apichet@shiratori.riec.tohoku.ac.jp] > Sent: 21. september 2003 01:32 > To: manet@ietf.org > Cc: Peter Pham > Subject: Re: [manet] help on 802.11 > > > Dear Pham, > > IEEE 802.11 only applies RTS/CTS handshakes to frames larger than > RTSThreshold. So an easy way to turn it of is to set the RTSThreshold to a > very large value. You may have to take a look in mac-802_11.h. > > Hope it helps. > Apichet. > > ----- Original Message -----=20 > From: "Peter Pham" > To: > Sent: Monday, September 15, 2003 9:56 AM > Subject: [manet] help on 802.11 > > > Hi all > > I am working on the effect of RTS and CTS of 802.11 in ad hoc network using > NS2. I read some papers and their results on the effect or RTS/CTS are > controversial...Some said having RTS/CTS improved the performance. Others > said the opposite. > > Can anyone tell me how to turn on/off the RTS/CTS operation in 802.11. > > >From my understanding through the first look of the code, there is no > mechanism. However, I might be wrong...If this is the case, what can I do t= > o > turn it off... > > Cheers > Peter Pham > Peter Phuc Pham > University of South Australia > Institute for Telecommunication Research > Phone: 61-883023869 > Email: ppham@spri.levels.unisa.edu.au > WWW: www.itr.unisa.edu.au/~ppham > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > Peter Phuc Pham > University of South Australia > Institute for Telecommunication Research > Phone: 61-883023869 > Email: ppham@spri.levels.unisa.edu.au > WWW: www.itr.unisa.edu.au/~ppham > > > --__--__-- > > Message: 5 > To: "Christophe Jelger" > cc: ogier@erg.sri.com, manet@ietf.org > Reply-To: ogier@erg.sri.com > From: ogier@erg.sri.com > Subject: Re: [manet] Comments on draft-jelger > Date: Mon, 22 Sep 2003 08:08:28 -0700 > > > Christophe, > > > Just to quickly reply to your comment below (part of your previous email). > > I'm afraid that your point is not correct, as with our proposal we don't use > > the gateway information to create a default route with reactive protocols. > > It is stated in the draft that we don't use a default route with reactive > > protocols because it prevents the protocol from being reactive (there is a > > default route!) and, as you state, it can prevent the use of shortest-path > > route. > > That's fine for reactive routing. I was focusing on proactive routing, > where you *do* propose using the gateway information to maintain > a default route. > > > > > For proactive the problem does not exist, as a node will have a view of the > > entire adhoc topology and will use the direct route to join an adhoc node > > with a different prefix (i.e. there will a /128 route for this destination > > in the routing table). > > I wasn't sure whether you wanted to allow direct (intra-manet) routing > between nodes in different prefix islands, so my paragraph that you > refer to considers both cases. Here is the paragraph again: > > > I would like to make a few more points. Your method (which uses a > > DSDV-like protocol to select a gateway and maintain prefix continuity) > > results in default routing that does not use the min-hop path to the > > default gateway (since the min-hop path might use intermediate nodes > > having a different prefix), and therefore is not consistent with a > > proactive min-hop routing protocol, UNLESS the routing protocol is > > restricted to finding routes only within each prefix island. > > For example, to reach a manet node in another prefix island (even if > > the other node is only 2 hops away), your method would send the packet > > to the default gateway. I think this is contrary to previous discussions > > on the manet list (e.g., if there is a manet node 2 hops away, the > > packet should be routed along a 2-hop path within the manet, even if > > the node has a different prefix). > > Although it may not have been clear, the example given in the last part > of the paragraph assumes that direct routing is allowed only between > nodes in the same prefix island (the "UNLESS" clause), so of course > it is not valid if direct routing is allowed between different > prefix islands. > > But the first part of the paragraph states that if direct routing is > allowed between different prefix islands (the negation of the "UNLESS" > clause), then your method of maintaining a default route for *proactive* > routing is not consistent with the routes computed by the proactive > routing protocol itself, since the proactive routing protocol will > compute the min-hop path to the gateway, even if this path includes > intermediate nodes that belong to a different prefix island. > > I'm not sure whether this inconsistency will cause any serious problems, > but one way to avoid it, as I discussed in my previous email, is to > simply let the routing protocol disseminate gateway information and > maintain default routes to gateways (as in OSPF). > > (If the goal is to have a common gateway discovery mechanism for both > proactive and reactive routing, I also discussed that in my previous > email, but the gist is that, since the proactive routing protocol > should already provide such a mechanism, it does not make sense to > provide another such mechanism that can be used with both proactive > and reactive routing, unless this common mechanism is already part of > the proactive routing protocol.) > > Regards, > Richard > > > > > --__--__-- > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > End of manet Digest > ------------------------------------> Luigi Iannone - Laboratoire D'Informatique Paris 6 e.mail: luigi.iannone@lip6.fr Tel: +33 (0)1 44 27 88 48 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 22 22:16:14 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23703 for ; Mon, 22 Sep 2003 22:16:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ciW-0006x6-74 for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 22:15:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N2FqMJ026718 for manet-archive@odin.ietf.org; Mon, 22 Sep 2003 22:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1ciW-0006wr-3X for manet-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 22:15:52 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23611 for ; Mon, 22 Sep 2003 22:15:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1chj-0006lz-8w; Mon, 22 Sep 2003 22:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1cha-0006kV-Aa for manet@optimus.ietf.org; Mon, 22 Sep 2003 22:14:54 -0400 Received: from cms4.cms.etri.re.kr (cms4.etri.re.kr [129.254.16.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23291 for ; Mon, 22 Sep 2003 22:14:43 -0400 (EDT) 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.2656.59) id S878HN38; Tue, 23 Sep 2003 11:11:46 +0900 Reply-To: From: "HyunWook Cha" To: Cc: , Date: Tue, 23 Sep 2003 11:13:19 +0900 Message-ID: <000001c38178$418faf20$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: <200309221558.IAA29138@den.erg.sri.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [manet] Souce address based default forwarding Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Richard, Thanks for your reply. Please see inline comments. > > > > > 2. The default route is required to use a gateway with > > > the same prefix > > > > > as the sending node, even if there is a closer > > > gateway, but prefix > > > > > continuity is not maintained. > > > > > > > > > > Benefit: Gateway prefix is same as sender prefix. > > > > > Benefit: A manet node does not need to change its prefix to > > > > > maintain prefix continuity. > > > > > Drawback: A routing header (to reach gateway) is > > > required for default > > > > > routing. Hop-by-hop default routing is not possible. > > > > > > > > > I want to add an alternative schem for solution 2. > > How about source address based forwarding? > > Sender's upper layer chooses one source address with a prefix from a > > gw_info when a session is initiated. > > When ad hoc routing module processes packets of the session, > > it firstly looks up routing table and if no host route, > forwards towards > > corresponding gateway according to source address. > > I think this is applicable to intermediate nodes. If an intermediate > > node has route entry as well as gw_info of corresponding > gateway by any > > means, > > it can decide how to forward packets sent to a gateway by sender. > > Absolutely. This way a packet with no host route is forwarded > (hop-by-hop) to the nearest gateway having the same prefix as > the source, without requiring a routing header. > I also considered this, but was concerned about requiring > that source-address-based forwarding be supported. > If we can assume source-address-based forwarding is supported, and > if it is important to route to a gateway with the same prefix > as the source, then this is the best solution. > Right. For source address based forwarding, additional search procedures are needed in intermediate nodes. 1. lookup of route table for destination (/128) 2. search corresponding gateway with prefix (/64) of source ip in gateway cache 3. lookup of route table for the gateway found in step 2 (/128) In this scheme, another issue is about following case. After source node sends packets using default route, an intermediate node finds host route for destination. Then, the node forwards using this route information directly. I think this is ignorable in proactive routing protocols but how about reactive protocols? As long as sender does not find that destination is reachable directly, this problem can continue. I think address with MANET_PREFIX is helpful in solving this issue. If source node intends to forward packets through a gateway, then source ip of outgoing packets should be with global prefix and intermediate nodes forwards packets towards right gateway. But, if source node intends to forward packets using host route entry, then source ip of packets should be with MANET_PREFIX, intermediate nodes forwards packets using only host route entry for destination. If this is applied, above procedure can be reduced to 2 steps.(step 2, step 3) As for solution 2 with routing header, only step 1 is preformed. > > > > 2.2 source address(prefix) based forwarding > > Benefit: Gateway prefix is same as sender prefix. > > Benefit: A manet node does not need to change its prefix to > maintain > > prefix continuity. > > Benefit: Hop-by-hop default routing is possible (without routing > > header). > > Drawback: Unlikely solution 2(using routing header), all nodes > > including sender on the path to corresponding gateway must > have both > > gw_info and route entry for the gateway. > > > > I think this drawback may degrade performance slightly(?) > but this is > > also considerable. > > I don't think this "drawback" is a problem, since all intermediate > nodes on the path to the gateway are closer to the gateway. > If, as I suggested in my previous email, the gateway > information is disseminated by the proactive routing protocol > (as in OSPF), then this is certainly not a drawback. The > only possible drawback > I see is that source-address-based forwarding is required. > Is this a significant drawback? > > Regards, > Richard > I agree you for the case of proactive routing protocols. However, in reactive ones, gw_info and route entry are maintained indepently. For example, lifetime of active route entry is incremented by ACTIVE_ROUTE_LIFETIME whenever a packet is forwarded using this entry. This results that route entries can remain after gw_infos are expired. So, in case of solution 2 with routing header, sender node can recover path failure through simple RREQ for a gateway which does not require gw_info. However, in source address based forwarding, simple RREQ is not sufficient since all intermediate nodes are required to have route entry as well as gw_info while sender node needs only route entry. IMO, this can result in more control packets and packet delay. Regards, Hyunwook _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 23 13:20:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25464 for ; Tue, 23 Sep 2003 13:20:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qp6-0000RD-IN for manet-archive@odin.ietf.org; Tue, 23 Sep 2003 13:19:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NHJaQ2001679 for manet-archive@odin.ietf.org; Tue, 23 Sep 2003 13:19:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qp6-0000R0-DW for manet-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 13:19:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25433 for ; Tue, 23 Sep 2003 13:19:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1qp4-0003Tn-00 for manet-web-archive@ietf.org; Tue, 23 Sep 2003 13:19:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1qp3-0003Th-00 for manet-web-archive@ietf.org; Tue, 23 Sep 2003 13:19:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qoX-0000KP-IO; Tue, 23 Sep 2003 13:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1qnm-0000Hp-Jd for manet@optimus.ietf.org; Tue, 23 Sep 2003 13:18:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25275 for ; Tue, 23 Sep 2003 13:18:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1qnk-0003QR-00 for manet@ietf.org; Tue, 23 Sep 2003 13:18:12 -0400 Received: from den.erg.sri.com ([128.18.100.23]) by ietf-mx with esmtp (Exim 4.12) id 1A1qnj-0003PE-00 for manet@ietf.org; Tue, 23 Sep 2003 13:18:11 -0400 Received: from den.erg.sri.com (localhost [127.0.0.1]) by den.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id KAA02837; Tue, 23 Sep 2003 10:17:37 -0700 (PDT) Message-Id: <200309231717.KAA02837@den.erg.sri.com> To: jafy@etri.re.kr cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Souce address based default forwarding In-reply-to: Your message of "Tue, 23 Sep 2003 11:13:19 +0900." <000001c38178$418faf20$ae70fe81@jafywinxp> Date: Tue, 23 Sep 2003 10:17:37 -0700 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hello Hyunwook, Please see my comments below. > Hi Richard, > > Thanks for your reply. > Please see inline comments. > > > > > > > 2. The default route is required to use a gateway with > > > > the same prefix > > > > > > as the sending node, even if there is a closer > > > > gateway, but prefix > > > > > > continuity is not maintained. > > > > > > > > > > > > Benefit: Gateway prefix is same as sender prefix. > > > > > > Benefit: A manet node does not need to change its prefix to > > > > > > maintain prefix continuity. > > > > > > Drawback: A routing header (to reach gateway) is > > > > required for default > > > > > > routing. Hop-by-hop default routing is not possible. > > > > > > > > > > > > I want to add an alternative schem for solution 2. > > > How about source address based forwarding? > > > Sender's upper layer chooses one source address with a prefix from a > > > gw_info when a session is initiated. > > > When ad hoc routing module processes packets of the session, > > > it firstly looks up routing table and if no host route, > > forwards towards > > > corresponding gateway according to source address. > > > I think this is applicable to intermediate nodes. If an intermediate > > > node has route entry as well as gw_info of corresponding > > gateway by any > > > means, > > > it can decide how to forward packets sent to a gateway by sender. > > > > Absolutely. This way a packet with no host route is forwarded > > (hop-by-hop) to the nearest gateway having the same prefix as > > the source, without requiring a routing header. > > I also considered this, but was concerned about requiring > > that source-address-based forwarding be supported. > > If we can assume source-address-based forwarding is supported, and > > if it is important to route to a gateway with the same prefix > > as the source, then this is the best solution. > > > > Right. For source address based forwarding, additional search procedures > are needed in intermediate nodes. > 1. lookup of route table for destination (/128) > 2. search corresponding gateway with prefix (/64) of source ip in > gateway cache > 3. lookup of route table for the gateway found in step 2 (/128) Step 2 can be avoided if the routing table has a default route entry for each known prefix. Thus, step 2 is performed when the route is created, not for each packet. The following procedure is then taken for each packet: 1. lookup of route table for destination (host route) 2. if no host route, use the default route corresponding to the source address prefix. However, I am still not sure that it is necessary for the default gateway to have the same prefix as the source. (If it is not necessary, then method 1 works fine.) > In this scheme, another issue is about following case. > After source node sends packets using default route, an intermediate > node finds host route for destination. > Then, the node forwards using this route information directly. > I think this is ignorable in proactive routing protocols I would like to allow this for proactive routing, since it is useful for limited-scope routing (such as Landmark routing). Thus, if the source does not have a host route, it sends the packet using the default route, or if a gateway with the same prefix as the destination is known, it sends the packet toward that gateway. When the packet gets closer to the gateway, an intermediate node might have a source route, which should then be used. > but how about reactive protocols? > As long as sender does not find that destination is reachable directly, > this problem can continue. I assume you are saying that a routing loop can occur with reactive routing. (See my comments at the end of this message regarding this possibility.) > I think address with MANET_PREFIX is helpful in solving this issue. > If source node intends to forward packets through a gateway, then source > ip of outgoing packets should be with global prefix and > intermediate nodes forwards packets towards right gateway. This would not allow the solution I suggest above, which supports limited-scope routing. Also, I prefer to avoid requiring the use of a MANET_PREFIX, since I would rather have a solution that applies more generally (not just to manets). > But, if source node intends to forward packets using host route entry, > then source ip of packets should be with MANET_PREFIX, > intermediate nodes forwards packets using only host route entry for > destination. > If this is applied, above procedure can be reduced to 2 steps.(step 2, > step 3) > > As for solution 2 with routing header, only step 1 is preformed. > > > > > > > 2.2 source address(prefix) based forwarding > > > Benefit: Gateway prefix is same as sender prefix. > > > Benefit: A manet node does not need to change its prefix to > > > maintain prefix continuity. > > > Benefit: Hop-by-hop default routing is possible (without routing > > > header). > > > Drawback: Unlikely solution 2(using routing header), all nodes > > > including sender on the path to corresponding gateway must > > > have both gw_info and route entry for the gateway. > > > > > > I think this drawback may degrade performance slightly(?) > > > but this is also considerable. > > > > I don't think this "drawback" is a problem, since all intermediate > > nodes on the path to the gateway are closer to the gateway. > > If, as I suggested in my previous email, the gateway > > information is disseminated by the proactive routing protocol > > (as in OSPF), then this is certainly not a drawback. The > > only possible drawback > > I see is that source-address-based forwarding is required. > > Is this a significant drawback? > > > > Regards, > > Richard > > > > I agree you for the case of proactive routing protocols. > However, in reactive ones, gw_info and route entry are maintained > indepently. > For example, lifetime of active route entry is incremented by > ACTIVE_ROUTE_LIFETIME > whenever a packet is forwarded using this entry. This results that route > entries can remain after gw_infos are expired. > So, in case of solution 2 with routing header, sender node can recover > path failure through simple RREQ for a gateway > which does not require gw_info. > However, in source address based forwarding, simple RREQ is not > sufficient since all intermediate nodes are required to have > route entry as well as gw_info while sender node needs only route entry. > IMO, this can result in more control packets and packet delay. With the forwarding procedure I described above, where there is a default route entry for each known prefix, the lifetime of a default route can also be incremented by ACTIVE_ROUTE_LIFETIME, so maybe this fixes the problem. (Let me know if I am mistaken.) Regards, Richard > > Regards, > > Hyunwook > > > _______________________________________________ > manet mailing 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 Sep 23 22:19:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18961 for ; Tue, 23 Sep 2003 22:19:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zFL-0006s3-QG for manet-archive@odin.ietf.org; Tue, 23 Sep 2003 22:19:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O2JF0h026405 for manet-archive@odin.ietf.org; Tue, 23 Sep 2003 22:19:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zFL-0006ro-Ld for manet-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 22:19: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 WAA18945 for ; Tue, 23 Sep 2003 22:19:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zFF-0002lv-00 for manet-web-archive@ietf.org; Tue, 23 Sep 2003 22:19:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1zFE-0002lr-00 for manet-web-archive@ietf.org; Tue, 23 Sep 2003 22:19:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zF7-0006qg-AG; Tue, 23 Sep 2003 22:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1zEO-0006py-7l for manet@optimus.ietf.org; Tue, 23 Sep 2003 22:18:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18873 for ; Tue, 23 Sep 2003 22:18:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1zEK-0002lB-00 for manet@ietf.org; Tue, 23 Sep 2003 22:18:12 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A1zEJ-0002ki-00 for manet@ietf.org; Tue, 23 Sep 2003 22:18:12 -0400 Received: from jafymobile (pd412g.etri.re.kr [129.254.112.173]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S878HQVT; Wed, 24 Sep 2003 11:16:02 +0900 Reply-To: From: "HyunWook Cha" To: Cc: Subject: RE: [manet] Souce address based default forwarding Date: Wed, 24 Sep 2003 11:17:39 +0900 Organization: ETRI Message-ID: <004401c38242$06efb110$ad70fe81@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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200309231717.KAA02837@den.erg.sri.com> Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Richard, Thanks for your comments. Please see inline comments. > > Hello Hyunwook, > > Please see my comments below. > > > Hi Richard, > > > > Thanks for your reply. > > Please see inline comments. > > > > > > > > > 2. The default route is required to use a gateway with > > > > > the same prefix > > > > > > > as the sending node, even if there is a closer > > > > > gateway, but prefix > > > > > > > continuity is not maintained. > > > > > > > > > > > > > > Benefit: Gateway prefix is same as sender prefix. > > > > > > > Benefit: A manet node does not need to change > its prefix to > > > > > > > maintain prefix continuity. > > > > > > > Drawback: A routing header (to reach gateway) is > > > > > required for default > > > > > > > routing. Hop-by-hop default routing is not possible. > > > > > > > > > > > > > > > I want to add an alternative schem for solution 2. > > > > How about source address based forwarding? > > > > Sender's upper layer chooses one source address with a > prefix from > > > > a gw_info when a session is initiated. When ad hoc > routing module > > > > processes packets of the session, it firstly looks up routing > > > > table and if no host route, > > > forwards towards > > > > corresponding gateway according to source address. > > > > I think this is applicable to intermediate nodes. If an > > > > intermediate node has route entry as well as gw_info of > > > > corresponding > > > gateway by any > > > > means, > > > > it can decide how to forward packets sent to a gateway > by sender. > > > > > > Absolutely. This way a packet with no host route is forwarded > > > (hop-by-hop) to the nearest gateway having the same prefix as > > > the source, without requiring a routing header. > > > I also considered this, but was concerned about requiring > > > that source-address-based forwarding be supported. > > > If we can assume source-address-based forwarding is > supported, and > > > if it is important to route to a gateway with the same prefix > > > as the source, then this is the best solution. > > > > > > > Right. For source address based forwarding, additional search > > procedures are needed in intermediate nodes. 1. lookup of > route table > > for destination (/128) 2. search corresponding gateway with prefix > > (/64) of source ip in gateway cache > > 3. lookup of route table for the gateway found in step 2 (/128) > > Step 2 can be avoided if the routing table has a default > route entry for each known prefix. Thus, step 2 is performed > when the route is created, not for each packet. > The following procedure is then taken for each packet: > 1. lookup of route table for destination (host route) > 2. if no host route, use the default route corresponding > to the source address prefix. Ok. You mean two route entries (host route and prefix route) per one gateway are created and managed. > > However, I am still not sure that it is necessary for the > default gateway to have the same prefix as the source. (If it > is not necessary, then method 1 works fine.) > IMO, environment where multiple gateways are available is similar to that considered by Multi6 working group. Multi6 falks think that ingress filtering should be avoided (C. Huitema names site exit issue). What is your opinion? > > In this scheme, another issue is about following case. > > After source node sends packets using default route, an intermediate > > node finds host route for destination. > > Then, the node forwards using this route information directly. > > I think this is ignorable in proactive routing protocols > > I would like to allow this for proactive routing, since it is > useful for limited-scope routing (such as Landmark routing). > Thus, if the source does not have a host route, it sends the > packet using the default route, or if a gateway with the same > prefix as the destination is known, it sends the packet > toward that gateway. When the packet gets closer to the gateway, > an intermediate node might have a source route, which > should then be used. > Limited-scope routing seems to potato routing. I think that this idea aims to make proactive routing protocols more scalable. > > but how about reactive protocols? > > > As long as sender does not find that destination is reachable > > directly, this problem can continue. > > I assume you are saying that a routing loop can occur with > reactive routing. (See my comments at the end of this message > regarding this possibility.) No, let me explain more detail. Let's assume that destination node with global ip is inside different partion from one where source node resides. Since sender can not find host route and destination address is global, it sends packets using default route. During the session, two partitions may be connected and an intermediate node on the path from sender to the gateway may have host route information for destination whether it is active or reverse. As for proactive routing, not to mention limited scope routing, sender will get host route in little time. However, this can not be guranteed in reacive ones. > > > I think address with MANET_PREFIX is helpful in solving > this issue. If > > source node intends to forward packets through a gateway, > then source > > ip of outgoing packets should be with global prefix and > > intermediate nodes forwards packets towards right gateway. > > This would not allow the solution I suggest above, which > supports limited-scope routing. Also, I prefer to avoid > requiring the use of a MANET_PREFIX, since I would rather > have a solution that applies more generally > (not just to manets). Do you think that address with MANET_PREFIX can not be used as source ip? Manet nodes which can not configure their global IPs because no gateways are reachable can communicate each other. In this case, MANET_PREFIX address is only vailable. Thus, I think MANET_PREFIX address should not be deleted although global IPs can be configured. I think MANET_PREFIX can be useful to address above issue as I mentioned in previous comment. IMO, we should investigate MANET specific stuffs before we think about more general solutions. > > But, if source node intends to forward packets using host > route entry, > > then source ip of packets should be with MANET_PREFIX, intermediate > > nodes forwards packets using only host route entry for destination. > > If this is applied, above procedure can be reduced to 2 > steps.(step 2, > > step 3) > > > > As for solution 2 with routing header, only step 1 is preformed. > > > > > > > > > > 2.2 source address(prefix) based forwarding > > > > Benefit: Gateway prefix is same as sender prefix. > > > > Benefit: A manet node does not need to change its prefix to > > > > maintain prefix continuity. > > > > Benefit: Hop-by-hop default routing is possible > (without routing > > > > header). > > > > Drawback: Unlikely solution 2(using routing header), all nodes > > > > including sender on the path to corresponding gateway must > > > > have both gw_info and route entry for the gateway. > > > > > > > > I think this drawback may degrade performance slightly(?) > > > > but this is also considerable. > > > > > > I don't think this "drawback" is a problem, since all intermediate > > > nodes on the path to the gateway are closer to the gateway. > > > If, as I suggested in my previous email, the gateway > > > information is disseminated by the proactive routing protocol > > > (as in OSPF), then this is certainly not a drawback. The > > > only possible drawback > > > I see is that source-address-based forwarding is required. > > > Is this a significant drawback? > > > > > > Regards, > > > Richard > > > > > > > I agree you for the case of proactive routing protocols. > However, in > > reactive ones, gw_info and route entry are maintained indepently. > > For example, lifetime of active route entry is incremented by > > ACTIVE_ROUTE_LIFETIME > > whenever a packet is forwarded using this entry. This > results that route > > entries can remain after gw_infos are expired. > > So, in case of solution 2 with routing header, sender node > can recover > > path failure through simple RREQ for a gateway > > which does not require gw_info. > > However, in source address based forwarding, simple RREQ is not > > sufficient since all intermediate nodes are required to have > > route entry as well as gw_info while sender node needs only > route entry. > > IMO, this can result in more control packets and packet delay. > > With the forwarding procedure I described above, where there > is a default route entry for each known prefix, the > lifetime of a default route can also be incremented by > ACTIVE_ROUTE_LIFETIME, so maybe this fixes the problem. (Let > me know if I am mistaken.) > You point the cause of this issue. While lifetime of a default route and host route of corresponding gateway are incremented as packets are forwarded using the default route, gw_info lifetime is not. So, host route of gateway and corresponding default route can remain after gw_info for the gateway is expired. This holds whether node is sender or intermediate one. In solution 2 with routing header, sender only needs valid host route for gateway to forward packets using default route as long as gw_info is valid. So, while gw_info does not need to be refreshed, sender does route discovery if necessary. However, as I mentioned before, in source address based forwarding, sender's route discovery requires that only intermediate nodes which have valid gw_info or gateway itself should answer with route information as well as gw_info for requested gateway, whether gw_info needs to be refreshed or not. I am not sure how this can affect performance. I think two approaches should be compared through simulation work. Personally, I have a preference with source address based forwarding strategy since routing header hides actual destination ip not to mention security issue. Do you have any comments? > Regards, > Richard > > > > > > Regards, > > > > Hyunwook > > > > > > _______________________________________________ > > manet mailing 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 Sep 24 00:34:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25730 for ; Wed, 24 Sep 2003 00:34:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A21Lv-0006EM-MW for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 00:34:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O4YBft023944 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 00:34:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A21Lv-0006E7-HX for manet-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 00:34:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25706 for ; Wed, 24 Sep 2003 00:34:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A21Ls-0004gH-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 00:34:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A21Ls-0004gE-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 00:34:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A21Ll-0006Cv-Us; Wed, 24 Sep 2003 00:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A21LJ-0006CO-9G for manet@optimus.ietf.org; Wed, 24 Sep 2003 00:33:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25685 for ; Wed, 24 Sep 2003 00:33:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A21LF-0004fS-00 for manet@ietf.org; Wed, 24 Sep 2003 00:33:29 -0400 Received: from [211.91.220.4] (helo=ds20.nudt.edu.cn) by ietf-mx with esmtp (Exim 4.12) id 1A21LE-0004fP-00 for manet@ietf.org; Wed, 24 Sep 2003 00:33:28 -0400 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id 616015B74E; Wed, 24 Sep 2003 12:37:56 +0800 (HKT) From: Wanrong Yu To: manet@ietf.org Reply-To: Wanrong Yu MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 218.76.40.52 Message-Id: <20030924043756.616015B74E@ds20.nudt.edu.cn> Date: Wed, 24 Sep 2003 12:37:56 +0800 (HKT) Content-Transfer-Encoding: 8bit Subject: [manet] =?gb2312?B?cXVlc3Rpb24gYWJvdXQgTUFORVQgcmVzZWFyY2gh?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi,all Traditional MANET routing protocols focus on the behaviors of single node, does there any works on the following scenario(extending nodes in the MANET to subnets,wired or wireless): A group of nodes(through wired or wireless link) move as a unit, communications between these groups just as nodes in MANAT, that is without the help of fixed infrastructure. The NEMO WG is working on the extension of MIP to support mobile networks, but I don't think their work have covers all facets of the above scenario. my question is : does the above scenario is different from traditional MANET, such as in the routing and so on? does there any works on this? I am a jackeroo of MANET and want to do some works on this topic,any advice and comments are welcomed! Thanks a lot! Wanrong Yu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Sep 24 01:09:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26787 for ; Wed, 24 Sep 2003 01:09:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A21tp-0007xZ-Ka for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 01:09:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O59DMs030591 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 01:09:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A21tp-0007xK-F0 for manet-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 01:09: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 BAA26756 for ; Wed, 24 Sep 2003 01:09:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A21tm-000548-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 01:09:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A21tm-000545-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 01:09:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A21td-0007tN-Lw; Wed, 24 Sep 2003 01:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A21tH-0007t6-Ss for manet@optimus.ietf.org; Wed, 24 Sep 2003 01:08:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26737 for ; Wed, 24 Sep 2003 01:08:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A21tE-00053n-00 for manet@ietf.org; Wed, 24 Sep 2003 01:08:36 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A21tE-00053j-00 for manet@ietf.org; Wed, 24 Sep 2003 01:08:36 -0400 Received: from jafymobile (pd412g.etri.re.kr [129.254.112.173]) by cms4.cms.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id S878HRD1; Wed, 24 Sep 2003 14:06:30 +0900 Reply-To: From: "HyunWook Cha" To: Cc: Subject: [manet] Souce address based default forwarding Date: Wed, 24 Sep 2003 14:08:07 +0900 Organization: ETRI Message-ID: <005e01c38259$d75862e0$ad70fe81@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 Importance: Normal 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, Richard I add further comments to previous ones. I marked previous comments with "[]". Please see additional comments. > > Right. For source address based forwarding, additional search > > procedures are needed in intermediate nodes. 1. lookup of > route table > > for destination (/128) 2. search corresponding gateway with prefix > > (/64) of source ip in gateway cache > > 3. lookup of route table for the gateway found in step 2 (/128) > > Step 2 can be avoided if the routing table has a default route entry > for each known prefix. Thus, step 2 is performed when the route is > created, not for each packet. The following procedure is then taken > for each packet: > 1. lookup of route table for destination (host route) > 2. if no host route, use the default route corresponding > to the source address prefix. [Ok. You mean two route entries (host route and prefix route) per one gateway are created and managed. ] Your idea violates semantic of current route table because default route for a given prefix should be looked up for source ip. In my step 2, search of gateway cache is deployed for this reason. What is your opinion? You mentioned that if a gateway with the same prefix as the destination is known, it sends the packet toward that gateway. This works naturally with your scheme since this follows longest prefix match. However, is it safe with ingress filtering? I think that this forwarding policy is useful in reactive routing protocols because gateway can notifiy sender that destination is reachable not through gateway but directly when gateway has route entry for destination. In Wakikawa's draft, some redirect message is introduced for this purpose. I think prefix route entry is useful but we should treat it specially if normal forwarding using it is not safe with ingress filtering. Regards, Hyunwook Cha _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Sep 24 03:13:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27975 for ; Wed, 24 Sep 2003 03:13:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23pv-00088P-2D for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 03:13:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O7DJIK031263 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 03:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23pu-00088A-59 for manet-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 03:13: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 DAA27958 for ; Wed, 24 Sep 2003 03:13:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A23pr-0006k5-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 03:13:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A23pr-0006k2-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 03:13:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23pc-00084B-Qf; Wed, 24 Sep 2003 03:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23pD-00080u-L1 for manet@optimus.ietf.org; Wed, 24 Sep 2003 03:12:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27934 for ; Wed, 24 Sep 2003 03:12:29 -0400 (EDT) From: jelger@dpt-info.u-strasbg.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A23pB-0006jf-00 for manet@ietf.org; Wed, 24 Sep 2003 03:12:33 -0400 Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1A23pA-0006jc-00 for manet@ietf.org; Wed, 24 Sep 2003 03:12:32 -0400 Received: from dpt-info.u-strasbg.fr (localhost [127.0.0.1]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.6) with ESMTP id h8O7Li3Z016046 for ; Wed, 24 Sep 2003 09:21:49 +0200 Received: (from jelger@localhost) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.6) id h8O7Li3t016044 for manet@ietf.org; Wed, 24 Sep 2003 09:21:44 +0200 Date: Wed, 24 Sep 2003 09:21:44 +0200 Message-Id: <200309240721.h8O7Li3t016044@dpt-info.u-strasbg.fr> To: manet@ietf.org Subject: [manet] Gateway discovery Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Richard/all, Just to quickly mention that I will be away the next two weeks and won't be able to reply frequently. About multiple prefixes, I think maintaining multiple addresses (from different gateways) is interesting, but the question remains as how applications can choose among multiple addresses ... I don't think any application code can today make such a choice, so if we want to developp some working code I think maintaining multiple prefixes is maybe a "luxury" that is not really needed. Of course from a research point of you, this is different. ;-) Regards, Christophe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Sep 24 05:13:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03314 for ; Wed, 24 Sep 2003 05:13:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A25i3-0007xf-Lz for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 05:13:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O9DJLF030595 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 05:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A25i3-0007xN-Hh for manet-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 05:13:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03273 for ; Wed, 24 Sep 2003 05:13:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A25i0-0000bo-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 05:13:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A25hz-0000bl-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 05:13:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A25hl-0007sl-Sy; Wed, 24 Sep 2003 05:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A25hb-0007sK-6K for manet@optimus.ietf.org; Wed, 24 Sep 2003 05:12:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03256 for ; Wed, 24 Sep 2003 05:12:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A25hX-0000bR-00 for manet@ietf.org; Wed, 24 Sep 2003 05:12:47 -0400 Received: from [129.254.16.14] (helo=cms4.cms.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A25hX-0000aV-00 for manet@ietf.org; Wed, 24 Sep 2003 05:12:47 -0400 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.2656.59) id S878HRX3; Wed, 24 Sep 2003 18:10:40 +0900 Reply-To: From: "HyunWook Cha" To: , Subject: RE: [manet] Gateway discovery Date: Wed, 24 Sep 2003 18:12:19 +0900 Message-ID: <000001c3827b$f5004610$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: <200309240721.h8O7Li3t016044@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Christophe/all, As for implementation of selection among multilple global addresses, how about updating the Policy table of the default address selections algorithm ? I think that distance to gateway may be a good factor for preference parameter for a global ip. IMO, its implementation is not difficult and use of multiple global IPs is not "luxury" since it can support Internet connectivity for MANET. Regards, Hyunwook Cha > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of jelger@dpt-info.u-strasbg.fr > Sent: Wednesday, September 24, 2003 4:22 PM > To: manet@ietf.org > Subject: [manet] Gateway discovery > > > > Hi Richard/all, > > Just to quickly mention that I will be away the next two > weeks and won't be able to reply frequently. > > About multiple prefixes, I think maintaining multiple > addresses (from different gateways) is interesting, but the > question remains as how applications can choose among > multiple addresses ... I don't think any application code can > today make such a choice, so if we want to developp some > working code I think maintaining multiple prefixes is maybe a > "luxury" that is not really needed. Of course from a research > point of you, this is different. ;-) > > Regards, > 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 Wed Sep 24 06:35:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05843 for ; Wed, 24 Sep 2003 06:35:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26zH-0004c4-N9 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 06:35:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OAZB4i017726 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 06:35:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26zH-0004bp-If for manet-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 06:35:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05820 for ; Wed, 24 Sep 2003 06:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A26zD-0001Sp-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 06:35:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A26zD-0001Sm-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 06:35:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26z9-0004af-4z; Wed, 24 Sep 2003 06:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A26yG-0004Yl-0V for manet@optimus.ietf.org; Wed, 24 Sep 2003 06:34:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05794 for ; Wed, 24 Sep 2003 06:33:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A26yB-0001SM-00 for manet@ietf.org; Wed, 24 Sep 2003 06:34:03 -0400 Received: from anyida.tts.lth.se ([130.235.18.10]) by ietf-mx with esmtp (Exim 4.12) id 1A26yB-0001SI-00 for manet@ietf.org; Wed, 24 Sep 2003 06:34:03 -0400 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 MAA01988; Wed, 24 Sep 2003 12:33:16 +0200 (MET DST) Message-ID: <3F71731E.3040408@telecom.lth.se> Date: Wed, 24 Sep 2003 12:34:06 +0200 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: jelger@dpt-info.u-strasbg.fr, manet Subject: Re: [manet] Gateway discovery References: <200309240721.h8O7Li3t016044@dpt-info.u-strasbg.fr> In-Reply-To: <200309240721.h8O7Li3t016044@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I think it is possible to specify the address using (advanced?) socket options, at least in IPv6. Another question is how an application should retrieve information about the different available addresses, and permissions needed to do so. These are just implementation and design issues. So, I think the answer to your question is yes, it is possible. regards, Anders jelger@dpt-info.u-strasbg.fr wrote: >Hi Richard/all, > >Just to quickly mention that I will be away the next two weeks and won't be able to reply frequently. > >About multiple prefixes, I think maintaining multiple addresses (from different gateways) is interesting, but the question remains as how applications can choose among multiple addresses ... I don't think any application code can today make such a choice, so if we want to developp some working code I think maintaining multiple prefixes is maybe a "luxury" that is not really needed. Of course from a research point of you, this is different. ;-) > >Regards, >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 Wed Sep 24 07:53:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08786 for ; Wed, 24 Sep 2003 07:53:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Co-0003F3-FP for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 07:53:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OBrEQB012455 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 07:53:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Co-0003Eo-B7 for manet-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 07:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08764 for ; Wed, 24 Sep 2003 07:53:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28Cn-0002Sy-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 07:53:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A28Cm-0002Sv-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 07:53:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Ca-0003Ay-Sl; Wed, 24 Sep 2003 07:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A28Bd-00038o-6c for manet@optimus.ietf.org; Wed, 24 Sep 2003 07:52:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08681 for ; Wed, 24 Sep 2003 07:51:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A28Bc-0002RU-00 for manet@ietf.org; Wed, 24 Sep 2003 07:52:00 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1A28Bb-0002RR-00 for manet@ietf.org; Wed, 24 Sep 2003 07:51:59 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id h8OBpvp16093; Wed, 24 Sep 2003 13:51:58 +0200 (MEST) Received: from mars.cert.siemens.de (ust.mchp.siemens.de [139.23.201.17]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h8OBprZ21818; Wed, 24 Sep 2003 13:51:53 +0200 (MEST) Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56]) by mars.cert.siemens.de (8.12.10/8.12.10/$SiemensCERT: mail/cert.mc,v 1.46 2003/05/28 09:28:32 ust Exp $) with ESMTP id h8OBpmSZ094866; Wed, 24 Sep 2003 13:51:48 +0200 (CEST) Received: from alpha (alpha [139.23.202.151]) by mail-y.mchp.siemens.de with SMTP id h8OBplMI005670; Wed, 24 Sep 2003 13:51:47 +0200 (MET DST) Date: Wed, 24 Sep 2003 13:51:47 +0200 (MET DST) From: Florian Schiel X-Sender: fschiel@alpha To: Anders Nilsson cc: jelger@dpt-info.u-strasbg.fr, manet Subject: Re: [manet] Gateway discovery In-Reply-To: <3F71731E.3040408@telecom.lth.se> 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: , Hello *, In my optinion the use of multiple prefixes (from different gateways) for global addresses is absolutely useful. Even if applications can not chosse them directly, a predictive process could estimate the 'best' prefix/gateway for any new connection. This is especially useful for nodes with high mobility, where a gateway is only reachable for a short interval. A problem here are the connections made with an 'older' gateway, that may not be reachable anymore. I do not see any biger problem with proactive routing protocols, but reactive protocols may need some sort of procativeness to get information about other available gateways (at least while an applications stays connected and exchanges packets). For most applications (like web-browsing or email) it does not really matter which (source) address is used. For them, the above estimation could be used without trouble as long as the (TCP-) connections are only used for a short time (and thus with a lower chance of breakage). If I did not get your statement wrong, the question here is the selection of the source address. Here, RFC 3484 lists some rules for source-address selection. In the MANET case, a node would be considered to be just like on of the multi-homed examples in the RFC3484, since it has at least its address based of MANET_PREFIX, and one or more addersses with global prefixes. Another question in this context is: Which source- and destination addresses belong to the manet and should be routed by manet-nodes, and which addresses do not belong there and should be dropped? This could be useful to lower pollution of a manet with non-manet traffic routed by manet-nodes. Is this considered somewhere? So long, Florian On Wed, 24 Sep 2003, Anders Nilsson wrote: > Hello, > > I think it is possible to specify the address using (advanced?) socket > options, at least in IPv6. Another question is how an application should > retrieve information about the different available addresses, and > permissions needed to do so. These are just implementation and design > issues. > > So, I think the answer to your question is yes, it is possible. > > regards, > > Anders > > jelger@dpt-info.u-strasbg.fr wrote: > > >Hi Richard/all, > > > >Just to quickly mention that I will be away the next two weeks and > won't be able to reply frequently. > > > >About multiple prefixes, I think maintaining multiple addresses > (from different gateways) is interesting, but the question remains as > how applications can choose among multiple addresses ... I don't think > any application code can today make such a choice, so if we want to > developp some working code I think maintaining multiple prefixes is > maybe a "luxury" that is not really needed. Of course from a research > point of you, this is different. ;-) > > > >Regards, > >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 > Florian Schiel - Siemens CT IC2 Internet and Mobility Lab --------------------------------------------------------------- Siemens AG, CT IC2 phone: +49 89 636-50686 Otto-Hahn Ring 6 mail: florian.schiel@mchp.siemens.de D-81730 Munich _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Sep 24 15:46:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04282 for ; Wed, 24 Sep 2003 15:46:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2FaM-0004Jn-P3 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 15:46:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OJk2DH016588 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 15:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2FaM-0004JT-BL for manet-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 15:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04254 for ; Wed, 24 Sep 2003 15:45:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2FaK-0001W8-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 15:46:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2FaK-0001W3-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 15:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2FZP-0004Dv-45; Wed, 24 Sep 2003 15:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2FZC-0004DP-Dk for manet@optimus.ietf.org; Wed, 24 Sep 2003 15:44:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04200 for ; Wed, 24 Sep 2003 15:44:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2FZA-0001V6-00 for manet@ietf.org; Wed, 24 Sep 2003 15:44:48 -0400 Received: from tomts16.bellnexxia.net ([209.226.175.4] helo=tomts16-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 1A2FZA-0001V2-00 for manet@ietf.org; Wed, 24 Sep 2003 15:44:48 -0400 Received: from ordi ([64.228.196.120]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.04 201-253-122-130-104-20030726) with SMTP id <20030924194444.HYWP14971.tomts16-srv.bellnexxia.net@ordi> for ; Wed, 24 Sep 2003 15:44:44 -0400 Message-ID: <002f01c38299$9e3b27f0$670cfea9@A8245.findquick.com> From: "Omar LAHLOU" To: Date: Wed, 24 Sep 2003 15:44:39 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C382B2.C3696640" 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] Bandwidth 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: , This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C382B2.C3696640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Has anyone know how to calculate the bandwidth available at a node in Ad = Hoc Network. Thanks for help. Omar. ------=_NextPart_000_002C_01C382B2.C3696640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,

Has anyone know how to = calculate=20 the bandwidth available at a node in Ad Hoc = Network.

Thanks for=20 help.

Omar.
------=_NextPart_000_002C_01C382B2.C3696640-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Wed Sep 24 16:55:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07321 for ; Wed, 24 Sep 2003 16:55:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2GfN-0000jq-Ew for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 16:55:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OKtHA2002832 for manet-archive@odin.ietf.org; Wed, 24 Sep 2003 16:55:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2GfN-0000jb-9u for manet-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 16:55:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07291 for ; Wed, 24 Sep 2003 16:55:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2GfL-0002TW-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 16:55:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2GfK-0002TT-00 for manet-web-archive@ietf.org; Wed, 24 Sep 2003 16:55:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Gf8-0000iP-M8; Wed, 24 Sep 2003 16:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Geu-0000fM-7z for manet@optimus.ietf.org; Wed, 24 Sep 2003 16:54:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07269 for ; Wed, 24 Sep 2003 16:54:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ger-0002T1-00 for manet@ietf.org; Wed, 24 Sep 2003 16:54:45 -0400 Received: from [131.179.136.242] (helo=manthos-m50) by ietf-mx with esmtp (Exim 4.12) id 1A2Ger-0002SW-00 for manet@ietf.org; Wed, 24 Sep 2003 16:54:45 -0400 Received: from [127.0.0.1] by manthos-m50 (ArGoSoft Mail Server Freeware, Version 1.8 (1.8.3.5)); Wed, 24 Sep 2003 13:51:16 -0700 Message-ID: <005001c382dd$98d0cd30$f288b383@manthosm50> From: "Dr Manthos Kazantzidis" To: "Omar LAHLOU" , References: <002f01c38299$9e3b27f0$670cfea9@A8245.findquick.com> Subject: Re: [manet] Bandwidth calculation Date: Wed, 24 Sep 2003 13:51:14 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01C382A2.EBA3A8B0" 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 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_004D_01C382A2.EBA3A8B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Omar, You can take a look at a link assisted measurement in http://users.bluehoc.com/archive/pubpapers/itre_kazantzidis.pdf slides in=20 http://users.bluehoc.com/archive/ppthtml/ITRE-kazantzidis.htm For application level measurements you can look in=20 http://www.cs.ucla.edu/~kazantz=20 end-to-end related papers and ab-probe. That page is moving so if sthg is offline feel free to contact me directly to provide the = pdf. Thanks Manthos ----- Original Message -----=20 From: Omar LAHLOU=20 To: manet@ietf.org=20 Sent: Wednesday, September 24, 2003 5:44 AM Subject: [manet] Bandwidth calculation Hi all, Has anyone know how to calculate the bandwidth available at a node in = Ad Hoc Network. Thanks for help. Omar. ------=_NextPart_000_004D_01C382A2.EBA3A8B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Omar,
 
 You can take a look at a link assisted = measurement=20 in
 
= http://users.bluehoc.com/archive/pubpapers/itre_kazantzidis.pdf
 
slides in
 
ht= tp://users.bluehoc.com/archive/ppthtml/ITRE-kazantzidis.htm
 
For application level measurements you can look in=20
 
http://www.cs.ucla.edu/~kazantz<= /A>=20
 
end-to-end related papers and ab-probe. That page is = moving
so if sthg is offline feel free to contact me = directly to=20 provide the pdf.
 
Thanks
Manthos
 
----- Original Message -----
From:=20 Omar=20 LAHLOU
Sent: Wednesday, September 24, = 2003 5:44=20 AM
Subject: [manet] Bandwidth=20 calculation

Hi all,

Has anyone know how = to calculate=20 the bandwidth available at a node in Ad Hoc = Network.

Thanks=20 for=20 help.

Omar.
------=_NextPart_000_004D_01C382A2.EBA3A8B0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 25 08:21:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21232 for ; Thu, 25 Sep 2003 08:21:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2V7b-0003PW-Qb for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 08:21:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PCLNds013104 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 08:21:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2V7b-0003PH-Mf for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 08:21:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21207 for ; Thu, 25 Sep 2003 08:21:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2V7a-0005A0-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 08:21:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2V7a-00059x-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 08:21:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2V7G-0003NI-DF; Thu, 25 Sep 2003 08:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2V6y-0003MV-0Y for manet@optimus.ietf.org; Thu, 25 Sep 2003 08:20:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21173 for ; Thu, 25 Sep 2003 08:20:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2V6w-00058v-00 for manet@ietf.org; Thu, 25 Sep 2003 08:20:42 -0400 Received: from [203.199.93.15] (helo=WS0005.indiatimes.com) by ietf-mx with esmtp (Exim 4.12) id 1A2V6v-00058E-00 for manet@ietf.org; Thu, 25 Sep 2003 08:20:42 -0400 Received: from 192.168.57.15 (a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id RAA04678; Thu, 25 Sep 2003 17:27:52 +0530 From: "sunil kumar vuppala" Message-Id: <200309251157.RAA04678@WS0005.indiatimes.com> To: CC: Reply-To: "sunil kumar vuppala" Date: Thu, 25 Sep 2003 17:45:27 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_200392541745271714636915" MIME-Version: 1.0 Subject: [manet] AD HOC - Secure routing Q. Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --=_MAILER_ATTACH_BOUNDARY1_200392541745271714636915 Content-Type: text/plain; charset=us-ascii Dear NS users & Gurus, I am working in "secure routing in MANETs". and plan to implement these protocols in NS-2.26. Few questions regarding this Secure Routing: 1. Which Secure Routing Protocols for MANETs were included in NS-2.26 distribution? 2. Is the traffic flow for mobile nodes is supported in NAM of NS-2.26? 3. How to use the TRACE files (*.tr) after Simulation run? Could some one help in this regard... thanking you, Regards, Sunil K.Vuppala *********************** Sunil Kumar Vuppala M.Tech(IT),IIT-Roorkee India - 247667 *********************** Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for Air Tickets on Air Sahara Flights at Prices Lower Than Before. Just log on to http://airsahara.indiatimes.com and Bid Now ! --=_MAILER_ATTACH_BOUNDARY1_200392541745271714636915 Content-Type: text/html; charset=us-ascii

Dear NS users & Gurus,

I am working in "secure routing in MANETs".

and plan to implement these protocols in NS-2.26.

Few questions regarding this Secure Routing:

1. Which Secure Routing Protocols for MANETs were included in NS-2.26 distribution?

2. Is the traffic flow for mobile nodes is supported in NAM of NS-2.26?

3. How to use the TRACE files (*.tr) after Simulation run?

Could some one help in this regard...

thanking you,

Regards,

Sunil K.Vuppala



***********************
Sunil Kumar Vuppala
M.Tech(IT),IIT-Roorkee
India - 247667
***********************
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com
Bid for Air Tickets on Air Sahara Flights at Prices Lower Than Before. Just log on to http://airsahara.indiatimes.com and Bid Now ! --=_MAILER_ATTACH_BOUNDARY1_200392541745271714636915-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 25 12:21:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03363 for ; Thu, 25 Sep 2003 12:21:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2YrG-0003c7-Ci for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 12:20:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PGKkG3013890 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 12:20:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2YrG-0003bx-7v for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 12:20: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 MAA03342 for ; Thu, 25 Sep 2003 12:20:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2YrE-0000nb-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 12:20:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2YrE-0000nY-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 12:20:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2YqZ-0003ZY-5v; Thu, 25 Sep 2003 12:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ypd-0003Ut-Ig for manet@optimus.ietf.org; Thu, 25 Sep 2003 12:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03263 for ; Thu, 25 Sep 2003 12:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ypb-0000mI-00 for manet@ietf.org; Thu, 25 Sep 2003 12:19:03 -0400 Received: from [202.84.232.68] (helo=mail.aitlbd.net) by ietf-mx with esmtp (Exim 4.12) id 1A2YpZ-0000m2-00 for manet@ietf.org; Thu, 25 Sep 2003 12:19:02 -0400 Received: from p249.aitlbd.net (p249.aitlbd.net [202.84.231.249]) by mail.aitlbd.net (8.11.7+Sun/8.11.6) with ESMTP id h8PGAeR11683 for ; Thu, 25 Sep 2003 22:10:40 +0600 (GMT) From: merajul Organization: BUET To: manet@ietf.org Date: Thu, 25 Sep 2003 10:18:26 +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: <200309251018.26962.merajul@aitlbd.net> AFTAB-IT-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Subject: [manet] MANET routing algorithm Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 am doing a research as an undergraduate computer engg. student on MANET routing protocol . Does anyone here doing reserach on this same subject ? Where should I start ? Is there any good simulator ? Thanks Meraj -- 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 Thu Sep 25 15:01:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14213 for ; Thu, 25 Sep 2003 15:01:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2bMq-0006Gv-LY for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 15:01:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PJ1WYK024103 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 15:01:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2bMq-0006Gg-H3 for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 15:01:32 -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 PAA14193 for ; Thu, 25 Sep 2003 15:01:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2bMn-00048K-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 15:01:29 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2bMn-00048H-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 15:01:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2bMM-0006Eb-QK; Thu, 25 Sep 2003 15:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2bLN-0006D3-R6 for manet@optimus.ietf.org; Thu, 25 Sep 2003 15:00:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14117 for ; Thu, 25 Sep 2003 14:59:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2bLK-00047J-00 for manet@ietf.org; Thu, 25 Sep 2003 14:59:58 -0400 Received: from engr04ras.eos.ncsu.edu ([152.1.21.49]) by ietf-mx with esmtp (Exim 4.12) id 1A2bLK-00047G-00 for manet@ietf.org; Thu, 25 Sep 2003 14:59:58 -0400 Received: (from jjun@localhost) by engr04ras.eos.ncsu.edu (8.11.6+Sun/8.10.2) id h8PIxtY13448; Thu, 25 Sep 2003 14:59:55 -0400 (EDT) Date: Thu, 25 Sep 2003 14:59:55 -0400 (EDT) From: Jangeun Jun X-X-Sender: jjun@engr04ras.eos.ncsu.edu To: manet@ietf.org In-Reply-To: <20030925160003.6989.98188.Mailman@www1.ietf.org> Message-ID: References: <20030925160003.6989.98188.Mailman@www1.ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Re: Bandwidth calculation (Jangeun Jun) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, Following papers provide a practical technique you can use to calculate ad hoc bandwidth. http://www4.ncsu.edu/~jjun/index_files/full_wmn_capa.pdf http://www4.ncsu.edu/~jjun/index_files/full_tmt.pdf Hope this helps, -Jangeun Jun > Hi all, > > Has anyone know how to calculate the bandwidth available at a node in Ad = > Hoc Network. > > Thanks for help. > > Omar. > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 25 17:42:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22665 for ; Thu, 25 Sep 2003 17:42:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2dsj-00061x-AE for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 17:42:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PLgbsd023175 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 17:42:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2dsj-00061i-4h for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 17:42:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22651 for ; Thu, 25 Sep 2003 17:42:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2dsg-0006az-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 17:42:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2dsg-0006aw-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 17:42:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ds9-0005uc-U3; Thu, 25 Sep 2003 17:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2drX-0005ty-ML for manet@optimus.ietf.org; Thu, 25 Sep 2003 17:41:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22629 for ; Thu, 25 Sep 2003 17:41:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2drV-0006aB-00 for manet@ietf.org; Thu, 25 Sep 2003 17:41:21 -0400 Received: from [129.15.0.75] (helo=c3p0.ou.edu) by ietf-mx with esmtp (Exim 4.12) id 1A2drU-0006Zv-00 for manet@ietf.org; Thu, 25 Sep 2003 17:41:20 -0400 Received: from e500-4.ou.edu (ip-129-15-0-76.zero.ou.edu [129.15.0.76]) by c3p0.ou.edu (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HLS00HCBHK2TO@c3p0.ou.edu> for manet@ietf.org; Thu, 25 Sep 2003 16:40:51 -0500 (CDT) Received: from unknown(129.15.0.75) by e500-4.ou.edu via csmap id 30699; Thu, 25 Sep 2003 16:42:04 -0500 (CDT) Received: from han (han_priv_VIP [192.168.11.58]) by r2d2.ou.edu (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HLS00EENHK2PO@r2d2.ou.edu> for manet@ietf.org; Thu, 25 Sep 2003 16:40:50 -0500 (CDT) Received: from ou.edu (han [192.168.11.21]) by han.ou.edu (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HLS00GREHK2PY@han.ou.edu> for manet@ietf.org; Thu, 25 Sep 2003 16:40:50 -0500 (CDT) Received: from [192.168.26.42] by han.ou.edu (mshttpd); Thu, 25 Sep 2003 16:40:50 -0500 Date: Thu, 25 Sep 2003 16:40:50 -0500 From: "Prasanna.Padmanabhan-1" To: manet Message-id: <6aa4bc51.bc516aa4@ou.edu> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal Content-Transfer-Encoding: 7BIT Subject: [manet] Software prototype 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: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello *, Im a Master student doing my research works on 'Data replication in MANET databases'. I have simulated my application using Awesim and I understand that there lots of other simulating tools like GLOMOSIM, NS-2, and OPNET. I now want to "prototype" my application and would like to know if there are already existing open source code prototypes for MANET applications. It would be of great help if you can give me some pointers on this. Thanks, Prasanna _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 25 18:07:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24043 for ; Thu, 25 Sep 2003 18:07:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2eGY-0007Ik-Uc for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 18:07:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PM7EWB028060 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 18:07:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2eGY-0007IV-EQ for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 18:07:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23978 for ; Thu, 25 Sep 2003 18:07:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2eGV-0006yH-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 18:07:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2eGV-0006yE-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 18:07:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2eGM-0007Dd-Jp; Thu, 25 Sep 2003 18:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2eGB-0007Ce-Mf for manet@optimus.ietf.org; Thu, 25 Sep 2003 18:06:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23931 for ; Thu, 25 Sep 2003 18:06:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2eG8-0006xv-00 for manet@ietf.org; Thu, 25 Sep 2003 18:06:48 -0400 Received: from mta6.algx.net ([67.92.168.235] helo=chimta05.algx.net) by ietf-mx with esmtp (Exim 4.12) id 1A2eG8-0006xh-00 for manet@ietf.org; Thu, 25 Sep 2003 18:06:48 -0400 Received: from wireless-4 (ip67-89-211-170.z211-89-67.customer.algx.net [67.89.211.170]) by chimmx05.algx.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HLS004BLIQDOV@chimmx05.algx.net> for manet@ietf.org; Thu, 25 Sep 2003 17:06:15 -0500 (CDT) Date: Thu, 25 Sep 2003 15:06:53 -0700 From: Amit Kucheria Subject: Re: [manet] Software prototype for MANET In-reply-to: <6aa4bc51.bc516aa4@ou.edu> To: "Prasanna.Padmanabhan-1" Cc: IETF Manet Message-id: <1064527613.1254.16.camel@amit.metricsystems.com> Organization: Metric Systems Corporation MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.3 Content-type: multipart/signed; boundary="=-O9GMfCNW1pOKFa0SOC/t"; protocol="application/pgp-signature"; micalg=pgp-sha1 References: <6aa4bc51.bc516aa4@ou.edu> Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --=-O9GMfCNW1pOKFa0SOC/t Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Following link should give you a list of all major implementations out there: http://www.wikipedia.org/wiki/Ad_hoc_protocols_implementations HTH. /Amit On Thu, 2003-09-25 at 14:40, Prasanna.Padmanabhan-1 wrote: > Hello *, >=20 > Im a Master student doing my research works on 'Data replication in MANET= databases'. I have simulated my application using Awesim and I understand = that there lots of other simulating tools like GLOMOSIM, NS-2, and OPNET.=20 >=20 > I now want to "prototype" my application and would like to know if there = are already existing open source code prototypes for MANET applications. It= would be of great help if you can give me some pointers on this. >=20 > Thanks, > Prasanna >=20 >=20 >=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 |...... --=-O9GMfCNW1pOKFa0SOC/t 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) iD8DBQA/c2b9tLg6PvU36DYRArdRAJ0Xhk8QIajMiOn+1ptHl4NMZ8vJnwCgic5M n9ebkSHGa+SlhVaWcVo0sKs= =K+pP -----END PGP SIGNATURE----- --=-O9GMfCNW1pOKFa0SOC/t-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 25 19:58:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28341 for ; Thu, 25 Sep 2003 19:58:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2fzx-0005Xg-V2 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 19:58:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PNwDwR021297 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 19:58:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2fzx-0005XQ-PJ for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 19:58: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 TAA28323 for ; Thu, 25 Sep 2003 19:58:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2fzv-0000ON-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 19:58:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2fzv-0000OK-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 19:58:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2fzl-0005WO-FW; Thu, 25 Sep 2003 19:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2fzG-0005W3-MB for manet@optimus.ietf.org; Thu, 25 Sep 2003 19:57:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28311 for ; Thu, 25 Sep 2003 19:57:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2fzE-0000O5-00 for manet@ietf.org; Thu, 25 Sep 2003 19:57:28 -0400 Received: from pedigree.cs.ubc.ca ([142.103.6.50]) by ietf-mx with esmtp (Exim 4.12) id 1A2fzE-0000O2-00 for manet@ietf.org; Thu, 25 Sep 2003 19:57:28 -0400 Received: from granville.cs.ubc.ca (granville.cs.ubc.ca [142.103.7.20]) by pedigree.cs.ubc.ca (8.12.10/8.11.4) with ESMTP id h8PNvSpu007253 for ; Thu, 25 Sep 2003 16:57:28 -0700 (PDT) Date: Thu, 25 Sep 2003 16:57:28 -0700 (PDT) From: Kan Cai To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] problems of DSR simulations using GLOMOSIM and NS2 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , hi, All: I am testing the DSR performance using GLOMOSIM and NS2 according to the papers published in mobicom98 and infocom00. Although AODV shows similar results, the DSR performs horribly. I have checked with NS2 problem list, and applied the modifications as suggested, but no luck. With 20 CBRs, 1500mx300m, 50 nodes, max_speed 20m/s, pause_time 0 second, the packet delivery ratio is only about 33%. In GLOMOSIM, with similar scenario, I can get about 60% performance. Is there anybody there can help me out? Thanks a lot. regards, ken _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 25 21:07:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00922 for ; Thu, 25 Sep 2003 21:07:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2h4q-0001aB-4o for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 21:07:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q17JqH006061 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 21:07:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2h4o-0001Zg-23 for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 21:07: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 VAA00890 for ; Thu, 25 Sep 2003 21:07:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2h4l-00017V-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 21:07:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2h4l-00017S-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 21:07:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2h4Y-0001Tj-Ln; Thu, 25 Sep 2003 21:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2h3m-0001SW-Bw for manet@optimus.ietf.org; Thu, 25 Sep 2003 21:06:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00867 for ; Thu, 25 Sep 2003 21:06:06 -0400 (EDT) From: rbandaru@mtu.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2h3j-00016y-00 for manet@ietf.org; Thu, 25 Sep 2003 21:06:11 -0400 Received: from mailoff.mtu.edu ([141.219.70.111]) by ietf-mx with esmtp (Exim 4.12) id 1A2h3j-00016v-00 for manet@ietf.org; Thu, 25 Sep 2003 21:06:11 -0400 Received: from node2. (node2.mtu.edu [141.219.68.102]) by mailoff.mtu.edu (8.11.6+mtu2003.9/8.11.4) with ESMTP id h8Q16Bn15083 for ; Thu, 25 Sep 2003 21:06:11 -0400 (EDT) Received: from node9 (node9.mtu.edu [141.219.68.109]) by node2. (8.11.6/8.11.6) with ESMTP id h8Q16BF08163 for ; Thu, 25 Sep 2003 21:06:11 -0400 Received: from campus4.mtu.edu ([141.219.70.7]) by node9 (MailMonitor for SMTP v1.2.2 ) ; Thu, 25 Sep 2003 21:06:11 -0400 (EDT) Received: from node6. (node6.mtu.edu [141.219.68.106]) by mail.mtu.edu (8.11.6+Sun/8.11.6) with ESMTP id h8Q16BJ02626 for ; Thu, 25 Sep 2003 21:06:11 -0400 (EDT) Received: from node6 (localhost.localdomain [127.0.0.1]) by node6. (8.11.6/8.11.1/mturelay-2.0b) with ESMTP id h8Q16Aw15147 for ; Thu, 25 Sep 2003 21:06:10 -0400 Message-Id: <200309260106.h8Q16Aw15147@node6.> Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary To: manet@ietf.org Organization: Michigan Technological University X-Originating-Ip: 141.219.20.232 MIME-Version: 1.0 Reply-To: rbandaru@mtu.edu Date: Thu, 25 Sep 2003 21:06:10 EDT X-Mailer: EMUmail 4.0 X-Webmail-User: rbandaru@email.mtu.edu Content-Transfer-Encoding: binary Subject: [manet] Is there a MANET existing in real world? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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: binary Content-Transfer-Encoding: binary Hi, I am a masters student new to mobile ad hoc networks. After going through some research papers related to MANET that describes various attacks on mobile ad hoc networks and countermeasures followed, I have a doubt, whether there is a MANET that is being used in any application presently? If there is one where is it being used? I will be more than happy if some one can help me to find answer for my question. Thanks in advance. Rahul Bandaru _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 25 21:18:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01318 for ; Thu, 25 Sep 2003 21:18:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2hEo-0002kJ-4E for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 21:17:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q1HcxR010549 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 21:17:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2hEn-0002k4-Tt for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 21:17:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01309 for ; Thu, 25 Sep 2003 21:17:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2hEl-0001Hl-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 21:17:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2hEk-0001Hi-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 21:17:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2hEE-0002Zs-0E; Thu, 25 Sep 2003 21:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2hDy-0002ZM-M4 for manet@optimus.ietf.org; Thu, 25 Sep 2003 21:16: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 VAA01278 for ; Thu, 25 Sep 2003 21:16:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2hDv-0001Gt-00 for manet@ietf.org; Thu, 25 Sep 2003 21:16:43 -0400 Received: from juno.webvis.net ([202.157.164.2] helo=scientecpersonnel.com) by ietf-mx with esmtp (Exim 4.12) id 1A2hDs-0001GX-00 for manet@ietf.org; Thu, 25 Sep 2003 21:16:41 -0400 Received: from wendycheong ([61.8.246.77]) by scientecpersonnel.com ; Fri, 26 Sep 2003 09:05:00 +0800 SGT Reply-To: From: "Wendy Cheong" To: Date: Fri, 26 Sep 2003 09:16:29 +0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01C3840E.DE9D5F90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Rcpt-To: Subject: [manet] Positions in Singapore Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_007B_01C3840E.DE9D5F90 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA01279 Content-Transfer-Encoding: quoted-printable Hi folks Our client is currently seeking suitable candidates to fill the following positions. Pls forward your resume in MS Word format to us at search@scientecpersonnel.com ScienTec Personnel (www.scientecpersonnel.com) No. 5 Shenton Way #37-02 UIC Building Singapore 068808 -------------------------------------------------------------------------= --- ---- 1. Senior Technical Manager [Perm] Job: To spearhead and lead a team in development of software defined radio fo= r Airborne, Land and Marine applications. Requirements: =B7 PhD/Master/Degree in Electronics/Electrical Engineering with emphasis on digital wireless communications =B7 At least 10 years relevant experience in the area of architechturing and 5 years in leadership role =B7 Competent in the use of RF circuit design and RF system engine= ering tools; possesses good track record of successful design =B7 Familiarity with wireless standards and software defined radio= s =B7 Experience with relevant RF/EMC type approval standards and processes would be an added advantage 2. Technical Manager (RF Group) [Perm] Job: =B7 Lead a team of engineers in areas of linear RF front-end circu= it design covering power amplifier, frequency synthesizers including high po= wer application etc =B7 Demonstrate leadership in RF simulation, analysis and partitio= ning =B7 Interface to customers in the preparation of RF system and specifications Requirements: =B7 PhD/Master/Degree in Electronics/Electrical Engineering with emphasis on digital wireless communications =B7 At least 4 years relevant experience in RF Front End Design an= d 2 years in leadership role =B7 Competent in the use of RF circuit design and RF system engine= ering tools; possesses good track record of successful design =B7 Familiarity with wireless standards and software defined radio= s =B7 Experience with relevant RF/EMC type approval standards and processes would be an added advantage 3. Senior Engineer (DSP Algorithm) [Perm] Job: =B7 Develop digital signal processing algorithm for state-of-the-a= rt Software Defined Radio Requirements: =B7 Masters/Degree in Science with at least 3 years of experience = in signal processing algorithm used in digital communications systems =B7 Good knowledge in DSP with C, MATLAB and/or Simulink with rounding/truncation issues =B7 Theoretical and practical knowledge of DSP- data paths fixed p= oint implementation; familiar with Texas instruments Code Composer =B7 Experience with Viterbi Decoders, Error Correction Code, Digit= al Filters, NCO, DLL, PLL, digital timing recovery and carrier recovery techniques would be an added advantage =B7 Self-motivated with good communication and interpersonal skill= s ------=_NextPart_000_007B_01C3840E.DE9D5F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi folks

Our client is currently seeking = suitable=20 candidates to fill the following positions. Pls forward your resume in = MS Word=20 format to us at search@scientecpersonnel.com=

ScienTec Personnel (www.scientecpersonnel.com)=
No. 5 Shenton = Way
#37-02 UIC = Building
Singapore 068808
1.      = Senior=20 Technical Manager =20 [Perm]
 
Job:
To=20 spearhead  and lead a team = in=20 development of software defined radio for Airborne, Land and Marine=20 applications.
 
Requirements:
=B7       =20 PhD/Master/Degree = in=20 Electronics/Electrical Engineering with emphasis on digital wireless=20 communications
=B7       =20 At least=20 10 years relevant experience in the area of architechturing and 5 years = in=20 leadership role
=B7       =20 Competent in the = use of RF=20 circuit design and RF system engineering tools; possesses good track = record of=20 successful design
=B7       =20 Familiarity with = wireless=20 standards and software defined = radios
=B7       =20 Experience with = relevant=20 RF/EMC type approval standards and processes would be an added=20 advantage
 
 
2.     =20 Technical Manager (RF Group)=20 [Perm]
 
Job:
=B7       =20 Lead a=20 team of engineers in areas of linear RF front-end circuit design = covering power=20 amplifier, frequency synthesizers including high power application=20 etc
=B7       =20 Demonstrate = leadership in RF=20 simulation, analysis and = partitioning
=B7       =20 Interface to = customers in=20 the preparation of RF system and=20 specifications
 
Requirements:
=B7       =20 PhD/Master/Degree = in=20 Electronics/Electrical Engineering with emphasis on digital wireless=20 communications
=B7       =20 At least=20 4 years relevant experience in RF Front End Design and 2 years in = leadership=20 role
=B7       =20 Competent in the = use of RF=20 circuit design and RF system engineering tools; possesses good track = record of=20 successful design
=B7       =20 Familiarity with = wireless=20 standards and software defined = radios
=B7       =20 Experience with = relevant=20 RF/EMC type approval standards and processes would be an added=20 advantage
 
3.      = Senior=20 Engineer (DSP Algorithm) [Perm]
 
Job:
=B7       =20 Develop=20 digital signal processing algorithm for state-of-the-art Software = Defined=20 Radio
 
Requirements:
=B7       =20 Masters/Degree in = Science=20 with at least 3 years of experience in signal processing algorithm used = in=20 digital communications systems
=B7       =20 Good=20 knowledge in DSP with C, MATLAB and/or Simulink with rounding/truncation = issues
=B7       =20 Theoretical and = practical=20 knowledge of DSP- data paths fixed point implementation; familiar with = Texas=20 instruments Code Composer
=B7       =20 Experience with = Viterbi=20 Decoders, Error Correction Code, Digital Filters, NCO, DLL, PLL, digital = timing=20 recovery and carrier recovery techniques would be an added=20 advantage
=B7       =20 Self-motivated=20 with good communication and interpersonal skills=20
------=_NextPart_000_007B_01C3840E.DE9D5F90-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 25 22:37:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03973 for ; Thu, 25 Sep 2003 22:37:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2iU0-0006ps-2R for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 22:37:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q2bNFT026262 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 22:37:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2iTx-0006mG-89 for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 22:37: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 WAA03956 for ; Thu, 25 Sep 2003 22:37:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2iTt-00028s-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 22:37:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2iTt-00028p-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 22:37:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2iTf-0006dO-Ey; Thu, 25 Sep 2003 22:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2iSv-0006cF-4T for manet@optimus.ietf.org; Thu, 25 Sep 2003 22:36:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03940 for ; Thu, 25 Sep 2003 22:36:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2iSr-00028Q-00 for manet@ietf.org; Thu, 25 Sep 2003 22:36:13 -0400 Received: from web20002.mail.yahoo.com ([216.136.225.47]) by ietf-mx with smtp (Exim 4.12) id 1A2iSr-00028N-00 for manet@ietf.org; Thu, 25 Sep 2003 22:36:13 -0400 Message-ID: <20030926023612.8715.qmail@web20002.mail.yahoo.com> Received: from [203.106.65.201] by web20002.mail.yahoo.com via HTTP; Thu, 25 Sep 2003 19:36:12 PDT Date: Thu, 25 Sep 2003 19:36:12 -0700 (PDT) From: Pan Zheng Subject: Re: [manet] Is there a MANET existing in real world? To: rbandaru@mtu.edu, manet@ietf.org In-Reply-To: <200309260106.h8Q16Aw15147@node6.> 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 maybe in US military, they have already tested some real life application, but it is surely confidential. normal master/phd students like us won't be able touch it on. --- rbandaru@mtu.edu wrote: > > Hi, > > I am a masters student new to mobile ad > hoc networks. After > going through some research papers related to MANET > that describes > various attacks on mobile ad hoc networks and > countermeasures followed, I > have a doubt, whether there is a MANET that is being > used in any > application presently? If there is one where is it > being used? > I will be more than happy if some one > can help me to find > answer for my question. > > Thanks in advance. > Rahul Bandaru > > > > > > > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Thu Sep 25 23:11:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04893 for ; Thu, 25 Sep 2003 23:11:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2j0l-0000CA-8e for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 23:11:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q3BEb4000744 for manet-archive@odin.ietf.org; Thu, 25 Sep 2003 23:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2j0i-0000Bv-Q6 for manet-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 23:11: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 XAA04871 for ; Thu, 25 Sep 2003 23:11:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2j0e-0002VB-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 23:11:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2j0e-0002V8-00 for manet-web-archive@ietf.org; Thu, 25 Sep 2003 23:11:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2j0X-00005E-Ki; Thu, 25 Sep 2003 23:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2izz-0008WQ-Ny for manet@optimus.ietf.org; Thu, 25 Sep 2003 23:10:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04849 for ; Thu, 25 Sep 2003 23:10:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2izv-0002Uh-00 for manet@ietf.org; Thu, 25 Sep 2003 23:10:23 -0400 Received: from ms1.usu.edu ([129.123.104.11]) by ietf-mx with esmtp (Exim 4.12) id 1A2izv-0002Ue-00 for manet@ietf.org; Thu, 25 Sep 2003 23:10:23 -0400 Received: from webster.usu.edu (webster.usu.edu [129.123.1.90]) by ms1.usu.edu (8.12.8/8.12.8) with ESMTP id h8Q34fw1008550 for ; Thu, 25 Sep 2003 21:04:41 -0600 X-WebMail-UserID: prakash Date: Thu, 25 Sep 2003 21:04:41 -0600 From: prakash To: manet@ietf.org X-EXP32-SerialNo: 00002751 Message-ID: <3F766B17@webster.usu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: WebMail (Hydra) SMTP v3.62 X-USU-MailScanner-Information: Please contact the USU HelpDesk for more information (http://helpdesk.usu.edu) X-USU-MailScanner: Found to be clean X-USU-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0, required 5) Content-Transfer-Encoding: 7bit Subject: [manet] Need some info regarding Wireless 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi , I am am graduate student doing some research work on " Wireless Mobile ad hoc n/w security". I will be happy if any one could suggest some good papers to read. Also i need to know whether Wireless Manet supports MPLS.If yes pls do send me some information regarding the above. Regards Shashi Prakash Utah State Univ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Sep 26 10:51:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09243 for ; Fri, 26 Sep 2003 10:51:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2twK-0006aT-7L for manet-archive@odin.ietf.org; Fri, 26 Sep 2003 10:51:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QEpOVZ025318 for manet-archive@odin.ietf.org; Fri, 26 Sep 2003 10:51:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2twK-0006aH-0Y for manet-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 10:51:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09226 for ; Fri, 26 Sep 2003 10:51:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2twH-0001ko-00 for manet-web-archive@ietf.org; Fri, 26 Sep 2003 10:51:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2twH-0001kl-00 for manet-web-archive@ietf.org; Fri, 26 Sep 2003 10:51:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2tv0-0006Ul-R9; Fri, 26 Sep 2003 10:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2tuR-0006Tw-9h for manet@optimus.ietf.org; Fri, 26 Sep 2003 10:49:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09179 for ; Fri, 26 Sep 2003 10:49:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2tuO-0001jv-00 for manet@ietf.org; Fri, 26 Sep 2003 10:49:24 -0400 Received: from clavin.cs.tamu.edu ([128.194.130.106] helo=cs.tamu.edu ident=0) by ietf-mx with esmtp (Exim 4.12) id 1A2tuN-0001js-00 for manet@ietf.org; Fri, 26 Sep 2003 10:49:23 -0400 Received: from unix.cs.tamu.edu (unix [128.194.138.13]) by cs.tamu.edu (8.11.0/8.11.0) with ESMTP id h8QEnK726746; Fri, 26 Sep 2003 09:49:20 -0500 (CDT) Received: from localhost (b0l4549@localhost) by unix.cs.tamu.edu (8.10.2+Sun/8.10.2) with ESMTP id h8QEnIo13484; Fri, 26 Sep 2003 09:49:18 -0500 (CDT) X-Authentication-Warning: unix.cs.tamu.edu: b0l4549 owned process doing -bs Date: Fri, 26 Sep 2003 09:49:18 -0500 (CDT) From: Bin Lu To: Pan Zheng cc: rbandaru@mtu.edu, Subject: Re: [manet] Is there a MANET existing in real world? In-Reply-To: <20030926023612.8715.qmail@web20002.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: , You mean there is no way for us students to get real data? Actually I had the same question as Rahul. Thanks, Bin On Thu, 25 Sep 2003, Pan Zheng wrote: > hi > maybe in US military, they have already tested some > real life application, but it is surely confidential. > normal master/phd students like us won't be able touch > it on. > > --- rbandaru@mtu.edu wrote: > > > > Hi, > > > > I am a masters student new to mobile ad > > hoc networks. After > > going through some research papers related to MANET > > that describes > > various attacks on mobile ad hoc networks and > > countermeasures followed, I > > have a doubt, whether there is a MANET that is being > > used in any > > application presently? If there is one where is it > > being used? > > I will be more than happy if some one > > can help me to find > > answer for my question. > > > > Thanks in advance. > > Rahul Bandaru > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.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 Fri Sep 26 11:09:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10042 for ; Fri, 26 Sep 2003 11:09:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uDB-00082f-7Y for manet-archive@odin.ietf.org; Fri, 26 Sep 2003 11:08:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QF8nVb030907 for manet-archive@odin.ietf.org; Fri, 26 Sep 2003 11:08:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uDB-00082Q-3F for manet-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 11:08:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10007 for ; Fri, 26 Sep 2003 11:08:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2uD8-000209-00 for manet-web-archive@ietf.org; Fri, 26 Sep 2003 11:08:46 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2uD8-000206-00 for manet-web-archive@ietf.org; Fri, 26 Sep 2003 11:08:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uCQ-0007pQ-6P; Fri, 26 Sep 2003 11:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2uC3-0007iq-4w for manet@optimus.ietf.org; Fri, 26 Sep 2003 11:07:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09969 for ; Fri, 26 Sep 2003 11:07:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2uC0-0001zD-00 for manet@ietf.org; Fri, 26 Sep 2003 11:07:36 -0400 Received: from mailgw1a.lmco.com ([192.31.106.7]) by ietf-mx with esmtp (Exim 4.12) id 1A2uBz-0001zA-00 for manet@ietf.org; Fri, 26 Sep 2003 11:07:35 -0400 Received: from emss02g01.ems.lmco.com (relay2.ems.lmco.com [166.29.2.54]) by mailgw1a.lmco.com (8.11.6p2/8.11.6) with ESMTP id h8QF7Ed25391; Fri, 26 Sep 2003 09:07:14 -0600 (MDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HLT00001TXROD@lmco.com>; Fri, 26 Sep 2003 09:05:51 -0600 (MDT) Received: from EMSS09I00.us.lmco.com ([158.183.26.31]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HLT00B89TXPSY@lmco.com>; Fri, 26 Sep 2003 09:05:51 -0600 (MDT) Date: Fri, 26 Sep 2003 11:05:42 -0400 From: "Huneycutt, Doug" Subject: RE: [manet] Is there a MANET existing in real world? To: Bin Lu , Pan Zheng Cc: rbandaru@mtu.edu, manet@ietf.org Message-id: <0C73AA5F720CD311AC2A0008C7DBA9B40A78824A@emss09m13.ems.lmco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-Topic: [manet] Is there a MANET existing in real world? Thread-Index: AcOEPcmrElYEwo/URECuXvPP/t1tPwAAR2JA content-class: urn:content-classes:message 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 Real data from operational environments is hard ... If you look at the URL recently shown on this list that itemizes current mobility protocols, there are 8 pages worth, none final. There is a very significant amount of effort going into "productizing" this stuff, particularly for the military. There is openly-available information posted at quite a few US government sites (google for JTRS, WIN-T, MP-CDL, etc). There's also doc on-line at DARPA and MITRE. But if you're looking for lessons-learned from some agency that more than an experimental history with mobile apps, you're probably ahead of your time. On the other hand, a lot of what IS being done is coming out of the heads of "normal master/phd students" like you, so don't feel like you're on the outside looking in ... Not the case. Doug _______________________________ Douglas S Huneycutt, Sr Senior Enterprise Architect Lockheed Martin Secure Enterprise Solutions 9500 Godwin Drive Manassas, VA 20110 703.367.4670 703.367.3312 FAX -----Original Message----- From: Bin Lu [mailto:b0l4549@cs.tamu.edu] Sent: Friday, September 26, 2003 10:49 AM To: Pan Zheng Cc: rbandaru@mtu.edu; manet@ietf.org Subject: Re: [manet] Is there a MANET existing in real world? You mean there is no way for us students to get real data? Actually I had the same question as Rahul. Thanks, Bin On Thu, 25 Sep 2003, Pan Zheng wrote: > hi > maybe in US military, they have already tested some > real life application, but it is surely confidential. > normal master/phd students like us won't be able touch > it on. > > --- rbandaru@mtu.edu wrote: > > > > Hi, > > > > I am a masters student new to mobile ad > > hoc networks. After > > going through some research papers related to MANET > > that describes > > various attacks on mobile ad hoc networks and countermeasures > > followed, I have a doubt, whether there is a MANET that is being > > used in any > > application presently? If there is one where is it > > being used? > > I will be more than happy if some one > > can help me to find > > answer for my question. > > > > Thanks in advance. > > Rahul Bandaru > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.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 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Sep 26 12:54:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13615 for ; Fri, 26 Sep 2003 12:54:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vr0-0006Yj-1h for manet-archive@odin.ietf.org; Fri, 26 Sep 2003 12:54:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QGs2Rt025213 for manet-archive@odin.ietf.org; Fri, 26 Sep 2003 12:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vqz-0006Ya-Ob for manet-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 12:54:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13575 for ; Fri, 26 Sep 2003 12:53:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2vqx-0003CI-00 for manet-web-archive@ietf.org; Fri, 26 Sep 2003 12:53:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2vqx-0003CD-00 for manet-web-archive@ietf.org; Fri, 26 Sep 2003 12:53:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vq2-0006Mk-2S; Fri, 26 Sep 2003 12:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2vpx-0006MX-Mg for manet@optimus.ietf.org; Fri, 26 Sep 2003 12:52:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13545 for ; Fri, 26 Sep 2003 12:52:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2vpv-0003BG-00 for manet@ietf.org; Fri, 26 Sep 2003 12:52:55 -0400 Received: from reserv2.univ-lille1.fr ([193.49.225.90] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1A2vpv-0003BC-00 for manet@ietf.org; Fri, 26 Sep 2003 12:52:55 -0400 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by reserv2.univ-lille1.fr (8.12.9/jtpda-5.3.1) with ESMTP id h8QGqoSH017632 for ; Fri, 26 Sep 2003 18:52:50 +0200 Received: from KRIEK (kriek.lifl.fr [134.206.11.16]) by malonne.lifl.fr with ESMTP id h8QGqoA00827 for ; Fri, 26 Sep 2003 18:52:50 +0200 (MEST) From: "David Simplot" To: Date: Fri, 26 Sep 2003 18:55:13 +0200 Organization: IRCICA/LIFL, Univ. Lille 1 Message-ID: <002e01c3844e$f4389410$100bce86@lifl.fr> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Subject: [manet] 2nd CFP IEEE Network Magazine special issue on 'Ad hoc Networking: Data Communications & Topology Control' Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Please accept our apologies in case you receive this information from multiple sources. ================================================================== 2nd Call for Papers IEEE Network Magazine Special Issue on 'AD HOC NETWORKING: DATA COMMUNICATIONS & TOPOLOGY CONTROL' http://www.lifl.fr/RD2P/download/net-adhoc-cfp-final.pdf IEEE Network seeks articles for a special issue on Ad Hoc Networking: Data Communications and Topology Control, to appear in July 2004. The guest editors for this special issue are David Simplot-Ryl, University of Lille, France, and Ivan Stojmenovic, University of Ottawa, Canada. Purpose Wireless networks and mobile computing research has until recently concentrated on single-hop networks (network nodes communicating directly to a fixed infrastructure), such as cellular and satellite systems. Ad hoc networking covers multi-hop scenarios (network nodes communicating via other network nodes) such as conference, hospital, battlefield, rescue, and monitoring scenarios. Particular ad hoc network systems include packet radio networks, sensor networks, personal communication systems, rooftop networks, and wireless local area networks. Even multi-hop cellular networks may be a viable option when a huge number of cellular phones are concentrated on a small area such as stadium. This special issue will cover comprehensively the network layer in ad hoc networks, which deals with data communication and topology control problems. Data communication problems include routing, broadcasting, multicasting, geocasting, clustering, area monitoring, data and service access. Topology control problems include neighbor discovery, topology construction and maintenance, activity scheduling, position discovery, partition detection, location updates, and network management. The new approaches to ad hoc networks design emphasize cross-layering approach, and therefore the relevant issues arising from network layer problems will also be covered, such as power management, security, quality of service, performance evaluation, data link and transport layers. The goal of the special issue is to publish original research and review articles which should be comprehensive to all readers, regardless of their specialty. Manuscript submission Send papers as PDF file to both co-guest editors simplot@lifl.fr and ivan@site.uottawa.ca. It is recommended that submissions be limited to 4500 words, with the number of references limited to 10. Guidelines for authors can be found on the IEEE Network magazine Website at http://www.comsoc.org/pubs/net/ntwrk/authors.html . Important dates Manuscript Submission: November 30, 2003 Acceptance Notification: February 29, 2004 Final Manuscript Due: May 1, 2004 Publication: July/August 2004 Guest co-editors Dr. David Simplot-Ryl IRCICA/LIFL, Univ. Lille 1, France David.Simplot@lifl.fr Dr. Ivan Stojmenovic SITE, University of Ottawa, Canada ivan@site.uottawa.ca _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Fri Sep 26 14:33:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17240 for ; Fri, 26 Sep 2003 14:33:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xP7-0002Wp-QC for manet-archive@odin.ietf.org; Fri, 26 Sep 2003 14:33:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QIXLon009720 for manet-archive@odin.ietf.org; Fri, 26 Sep 2003 14:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xP7-0002Wh-M5 for manet-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 14:33: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 OAA17188 for ; Fri, 26 Sep 2003 14:33:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2xP4-00049B-00 for manet-web-archive@ietf.org; Fri, 26 Sep 2003 14:33:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2xP4-000498-00 for manet-web-archive@ietf.org; Fri, 26 Sep 2003 14:33:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xNq-0002Ka-2p; Fri, 26 Sep 2003 14:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xNa-0002Ji-Uz for manet@optimus.ietf.org; Fri, 26 Sep 2003 14:31: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 OAA17135 for ; Fri, 26 Sep 2003 14:31:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2xNY-000482-00 for manet@ietf.org; Fri, 26 Sep 2003 14:31:44 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx with esmtp (Exim 4.12) id 1A2xNX-00047x-00 for manet@ietf.org; Fri, 26 Sep 2003 14:31:43 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.9+Sun/8.12.8) with SMTP id h8QIV8gZ015232 for ; Fri, 26 Sep 2003 14:31:08 -0400 (EDT) Received: from [132.250.92.132] ([132.250.92.132]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.2.35) with SMTP id M2003092614310809845 for ; Fri, 26 Sep 2003 14:31:08 -0400 Mime-Version: 1.0 X-Sender: wieselth@pop.itd.nrl.navy.mil Message-Id: Date: Fri, 26 Sep 2003 14:31:07 -0400 To: manet@ietf.org From: Jeff Wieselthier Content-Type: multipart/alternative; boundary="============_-1147521428==_ma============" Subject: [manet] CFP: Deadline is rapidly approaching: JSAC Special Issue on Wireless 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: , --============_-1147521428==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" CALL FOR PAPERS IEEE Journal on Selected Areas in Communications WIRELESS AD HOC NETWORKS http://www.argreenhouse.com/society/J-SAC/Calls/wireless_adhoc.html Novel approaches are needed to address ad hoc networks, which are characterized by the lack of an infrastructure. For example, point-to-point and point-to-multipoint modes of communication must be supported in a multihop network that typically consists of small (often disadvantaged) users that are characterized by severely limited energy supply, signal-processing capability, antenna directivity, bandwidth, etc. Crucial applications for mobile ad hoc networks include military communications and disaster relief, although commercial applications are certainly possible as well. In applications with a large number of nodes, scalability is a major concern. The study of ad hoc networks is an interdisciplinary one, which can potentially incorporate communication and information theory, distributed networking algorithms, data structures and compression, coding, signal processing, detection, antenna characteristics, optimization methods, simulation, testbed implementations etc. Papers submitted for this special issue must directly address ad hoc networking issues. We outline here only a few of the many aspects of ad hoc network design and control that will be addressed in this special issue. First, distributed network organization algorithms (such as those for clustering) may be used to create the equivalent of an ad hoc infrastructure. Distributed algorithms are also needed for routing, channel access, and other control functions. Networking techniques for ad hoc networks must address the challenges imposed by the all-wireless environment. For example, by contrast with wired networks, the conventional layered protocol stack is not well suited to the ad hoc wireless networking environment because it does not exploit the potential improvements in performance that can be obtained by jointly designing protocols that span multiple layers. Specifically, it is expected that improved performance can be obtained by considering the properties of the physical and data link layers when designing and operating the media-access control (MAC) protocol. Similarly, there are potential benefits to be obtained by developing protocols that address jointly the routing and MAC functions. Additional benefits can be obtained by jointly addressing higher-layer functions along with routing and MAC. Energy-aware protocols (from the perspective of either energy-efficient or energy-constrained operation) are of critical importance in many ad hoc scenarios. Such energy-aware operation can span multiple layers, e.g., by addressing trade-offs between energy used for RF transmission and for signal processing. It is the goal of this special issue to reflect the latest in the state of the art in ad hoc networks by examining all aspects of ad hoc network design and control, including the dependencies between various network functions and the potential benefits that can be gained by cross-layer design. We are interested in papers on fundamental performance limits, but more importantly on algorithm design and performance, system implementations, etc. We are seeking papers that describe original and unpublished contributions addressing various aspects of ad hoc networking. Possible topics of interest include, but are not limited to: * Physical layer issues in ad hoc networks * Media Access Control (MAC) techniques * Self-organizing architectures and protocols * Routing protocols * Cross-layer protocol design * Mobility management * Protocols for mobile applications * Transport-layer issues * Signal-processing issues in ad hoc networks * Integration with wired networks * Applications * Energy-aware protocols * Security in ad hoc networks * Capacity and scheduling * Node implementation * Effects on existing protocols * Quality of service * Broadcasting and multicasting * Multimedia and traffic integration * Experiments and testbeds * Error-control schemes * Synchronization and scheduling * Scalability * Performance analysis and simulation * Properties of antennas * Optimization methods * Fundamental limits in ad hoc networks All papers on any of the above topics must include a definite and strong connection to ad hoc networks. Please contact Jeffrey Wieselthier at wieselthier@itd.nrl.navy.mil if there are any questions about the suitability of the paper for this special issue. Prospective authors should prepare their manuscripts in accordance with the IEEE J-SAC format described in the Information for Authors at the J-SAC website. All papers should be submitted in pdf format via email to Jeffrey Wieselthier at wieselthier@itd.nrl.navy.mil according to the following timetable: Manuscript Submission: October 15, 2003 Acceptance Notification: April 1, 2004 Final Manuscript Due: June 1, 2004 Publication: 4th Quarter 2004 Guest Editors Dr. Jeffrey E. Wieselthier, Naval Research Laboratory, Washington, DC, wieselthier@itd.nrl.navy.mil Prof. Eitan Altman, INRIA, Sophia-Antipolis, Cedex, FRANCE, Eitan.Altman@sophia.inria.fr Prof. Anthony Ephremides, University of Maryland, College Park, MD, tony@eng.umd.edu Mr. Joseph Macker, Naval Research Laboratory, Washington, DC, macker@itd.nrl.navy.mil Prof. Harlan B. Russell, Clemson University, Clemson, SC, hrussel@hubcap.clemson.edu Dr. Martha Steenstrup, Stow Research L.L.C., Flanders, NJ, steenie@rcn.com Prof. Stephen Wicker, Cornell University, Ithaca, NY, wicker@ee.cornell.edu --============_-1147521428==_ma============ Content-Type: text/html; charset="us-ascii" CFP: Deadline is rapidly approaching: JSAC Special Iss
                          CALL FOR PAPERS
            IEEE Journal on Selected Areas in Communications
                       WIRELESS AD HOC NETWORKS

http://www.argreenhouse.com/society/J-SAC/Calls/wireless_adhoc.html

Novel approaches are needed to address ad hoc networks, which are characterized by the lack of an infrastructure.  For example, point-to-point and point-to-multipoint modes of communication must be supported in a multihop network that typically consists of small (often disadvantaged) users that are characterized by severely limited energy supply, signal-processing capability, antenna directivity, bandwidth, etc.  Crucial applications for mobile ad hoc networks include military communications and disaster relief, although commercial applications are certainly possible as well.  In applications with a large number of nodes, scalability is a major concern.

The study of ad hoc networks is an interdisciplinary one, which can potentially incorporate communication and information theory, distributed networking algorithms, data structures and compression, coding, signal processing, detection, antenna characteristics, optimization methods, simulation, testbed implementations etc.  Papers submitted for this special issue must directly address ad hoc networking issues. 

We outline here only a few of the many aspects of ad hoc network design and control that will be addressed in this special issue.  First, distributed network organization algorithms (such as those for clustering) may be used to create the equivalent of an ad hoc infrastructure.  Distributed algorithms are also needed for routing, channel access, and other control functions.  Networking techniques for ad hoc networks must address the challenges imposed by the all-wireless environment.  For example, by contrast with wired networks, the conventional layered protocol stack is not well suited to the ad hoc wireless networking environment because it does not exploit the potential improvements in performance that can be obtained by jointly designing protocols that span multiple layers.  Specifically, it is expected that improved performance can be obtained by considering the properties of the physical and data link layers when designing and operating the media-access control (MAC) protocol.  Similarly, there are potential benefits to be obtained by developing protocols that address jointly the routing and MAC functions.  Additional benefits can be obtained by jointly addressing higher-layer functions along with routing and MAC.  Energy-aware protocols (from the perspective of either energy-efficient or energy-constrained operation) are of critical importance in many ad hoc scenarios.  Such energy-aware operation can span multiple layers, e.g., by addressing trade-offs between energy used for RF transmission and for signal processing.

It is the goal of this special issue to reflect the latest in the state of the art in ad hoc networks by examining all aspects of ad hoc network design and control, including the dependencies between various network functions and the potential benefits that can be gained by cross-layer design.  We are interested in papers on fundamental performance limits, but more importantly on algorithm design and performance, system implementations, etc.

We are seeking papers that describe original and unpublished contributions addressing various aspects of ad hoc networking.  Possible topics of interest include, but are not limited to:

     * Physical layer issues in ad hoc networks
     * Media Access Control (MAC) techniques
     * Self-organizing architectures and protocols
     * Routing protocols
     * Cross-layer protocol design
     * Mobility management
     * Protocols for mobile applications
     * Transport-layer issues
     * Signal-processing issues in ad hoc networks
     * Integration with wired networks
     * Applications
     * Energy-aware protocols
     * Security in ad hoc networks
     * Capacity and scheduling
     * Node implementation
     * Effects on existing protocols
     * Quality of service
     * Broadcasting and multicasting
     * Multimedia and traffic integration
     * Experiments and testbeds
     * Error-control schemes
     * Synchronization and scheduling
     * Scalability
     * Performance analysis and simulation
     * Properties of antennas
     * Optimization methods
     * Fundamental limits in ad hoc networks

All papers on any of the above topics must include a definite and strong connection to ad hoc networks.  Please contact Jeffrey Wieselthier at wieselthier@itd.nrl.navy.mil if there are any questions about the suitability of the paper for this special issue. 

Prospective authors should prepare their manuscripts in accordance with the IEEE J-SAC format described in the Information for Authors at the J-SAC website.  All papers should be submitted in pdf format via email to Jeffrey Wieselthier at wieselthier@itd.nrl.navy.mil according to the following timetable:

     Manuscript Submission:     October 15, 2003
     Acceptance Notification:   April 1, 2004
     Final Manuscript Due:      June 1, 2004
     Publication:               4th Quarter 2004


                       Guest Editors

Dr. Jeffrey E. Wieselthier, Naval Research Laboratory, Washington, DC, wieselthier@itd.nrl.navy.mil

Prof. Eitan Altman, INRIA, Sophia-Antipolis, Cedex, FRANCE, Eitan.Altman@sophia.inria.fr

Prof. Anthony Ephremides, University of Maryland, College Park, MD, tony@eng.umd.edu

Mr. Joseph Macker, Naval Research Laboratory, Washington, DC, macker@itd.nrl.navy.mil

Prof. Harlan B. Russell, Clemson University, Clemson, SC, hrussel@hubcap.clemson.edu

Dr. Martha Steenstrup, Stow Research L.L.C., Flanders, NJ, steenie@rcn.com

Prof. Stephen Wicker, Cornell University, Ithaca, NY, wicker@ee.cornell.edu
--============_-1147521428==_ma============-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 27 06:12:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25751 for ; Sat, 27 Sep 2003 06:12:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3C3j-0007ST-WB for manet-archive@odin.ietf.org; Sat, 27 Sep 2003 06:12:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8RACFKv028663 for manet-archive@odin.ietf.org; Sat, 27 Sep 2003 06:12:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3C3j-0007SE-RQ for manet-web-archive@optimus.ietf.org; Sat, 27 Sep 2003 06:12: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 GAA25724 for ; Sat, 27 Sep 2003 06:12:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3C3f-0004P5-00 for manet-web-archive@ietf.org; Sat, 27 Sep 2003 06:12:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3C3f-0004P1-00 for manet-web-archive@ietf.org; Sat, 27 Sep 2003 06:12:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3C3V-0007Qe-2b; Sat, 27 Sep 2003 06:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3C2i-0007M7-OB for manet@optimus.ietf.org; Sat, 27 Sep 2003 06:11: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 GAA25650 for ; Sat, 27 Sep 2003 06:11:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3C2e-0004Na-00 for manet@ietf.org; Sat, 27 Sep 2003 06:11:08 -0400 Received: from web8107.mail.in.yahoo.com ([203.199.70.121]) by ietf-mx with smtp (Exim 4.12) id 1A3C2d-0004NB-00 for manet@ietf.org; Sat, 27 Sep 2003 06:11:08 -0400 Message-ID: <20030927101037.82821.qmail@web8107.mail.in.yahoo.com> Received: from [202.65.156.23] by web8107.mail.in.yahoo.com via HTTP; Sat, 27 Sep 2003 11:10:37 BST Date: Sat, 27 Sep 2003 11:10:37 +0100 (BST) From: =?iso-8859-1?q?koppolu=20prasad?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-391831787-1064657437=:82222" Content-Transfer-Encoding: 8bit Subject: [manet] (no subject) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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-391831787-1064657437=:82222 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear sir Iam keenly interested about MANET i would like to know the current problems which limits the MANET and the recent inventions needed for MANET Thanking you yours sincerely k.b.prasad > > Yahoo! India Matrimony: Find your partner online.Post your profile. --0-391831787-1064657437=:82222 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Dear sir

Iam keenly interested about MANET

i would like to know the  current problems which limits the MANET and the recent inventions needed  for MANET

Thanking you

yours sincerely

k.b.prasad
> >

Yahoo! India Matrimony: Find your partner online. Post your profile. --0-391831787-1064657437=:82222-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 27 14:23:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07893 for ; Sat, 27 Sep 2003 14:23:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Jiw-0006Ky-G6 for manet-archive@odin.ietf.org; Sat, 27 Sep 2003 14:23:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8RINIZ6024357 for manet-archive@odin.ietf.org; Sat, 27 Sep 2003 14:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Jiw-0006Km-9V for manet-web-archive@optimus.ietf.org; Sat, 27 Sep 2003 14: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 OAA07883 for ; Sat, 27 Sep 2003 14:23:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3Jit-0000Il-00 for manet-web-archive@ietf.org; Sat, 27 Sep 2003 14:23:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3Jit-0000Ii-00 for manet-web-archive@ietf.org; Sat, 27 Sep 2003 14:23:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Jif-0006Jg-FL; Sat, 27 Sep 2003 14:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3JiS-0006JK-4O for manet@optimus.ietf.org; Sat, 27 Sep 2003 14:22:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07869 for ; Sat, 27 Sep 2003 14:22:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3JiP-0000IU-00 for manet@ietf.org; Sat, 27 Sep 2003 14:22:45 -0400 Received: from mailoff.mtu.edu ([141.219.70.111]) by ietf-mx with esmtp (Exim 4.12) id 1A3JiO-0000IO-00 for manet@ietf.org; Sat, 27 Sep 2003 14:22:44 -0400 Received: from node2. (node2.mtu.edu [141.219.68.102]) by mailoff.mtu.edu (8.11.6+mtu2003.9/8.11.4) with ESMTP id h8RIMin06752 for ; Sat, 27 Sep 2003 14:22:44 -0400 (EDT) Received: from node25 (node25.mtu.edu [141.219.68.125]) by node2. (8.11.6/8.11.6) with ESMTP id h8RIMiF14846 for ; Sat, 27 Sep 2003 14:22:44 -0400 Received: from campus4.mtu.edu ([141.219.70.7]) by node25 (MailMonitor for SMTP v1.2.2 ) ; Sat, 27 Sep 2003 14:22:44 -0400 (EDT) Received: from node2. (node2.mtu.edu [141.219.68.102]) by mail.mtu.edu (8.11.6+mtu2003.9/8.11.6) with ESMTP id h8RIMho12616 for ; Sat, 27 Sep 2003 14:22:43 -0400 (EDT) Received: from fourierpc5 (fourier-pc5.win.ee.mtu.edu [141.219.20.106]) by node2. (8.12.10/8.12.3/auth_ssl.mc v1.0) with SMTP id h8RIMhK2014841 for ; Sat, 27 Sep 2003 14:22:43 -0400 Message-ID: <007c01c38524$581369d0$6a14db8d@win.ee.mtu.edu> From: "Leiyuan Li" To: Date: Sat, 27 Sep 2003 14:22:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01C38502.D0FAC4F0" 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] [MANET]How to detect attacks Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0079_01C38502.D0FAC4F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm a graduate student doing research on MANET security. After = reviewing some papers, I have a question: what is the basic criteria for = people to pick up certain behavior in MANET runtime as potential = attacking behavior? Some attack behaviors described in different papers = seems pretty much the same in their basic behavior pattern, so I think = they should be categorized as one type of attacks, ie. using certain = pattern of activity to achieve certain illegal benefits. I wonder if = there is any existing categorization of the definitions of different = kinds of attack? =20 Thanks. Leiyuan Li ------=_NextPart_000_0079_01C38502.D0FAC4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,
I'm a graduate student doing research = on MANET=20 security.  After reviewing some papers, I have a question: = what is the=20 basic criteria for people to pick up certain behavior in MANET runtime = as=20 potential attacking behavior?  Some attack behaviors described in = different=20 papers seems pretty much the same in their basic behavior pattern, so I = think=20 they should be categorized as one type of attacks, ie. using certain = pattern of=20 activity to achieve certain illegal benefits.  I wonder if = there is any existing categorization of the = definitions of=20 different kinds of attack? 
Thanks.
Leiyuan Li
------=_NextPart_000_0079_01C38502.D0FAC4F0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sat Sep 27 21:50:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20452 for ; Sat, 27 Sep 2003 21:50:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3QhV-0005JH-9E for manet-archive@odin.ietf.org; Sat, 27 Sep 2003 21:50:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8S1oHw9020405 for manet-archive@odin.ietf.org; Sat, 27 Sep 2003 21:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3QhV-0005J2-3z for manet-web-archive@optimus.ietf.org; Sat, 27 Sep 2003 21:50:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20443 for ; Sat, 27 Sep 2003 21:50:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3QhS-0003rn-00 for manet-web-archive@ietf.org; Sat, 27 Sep 2003 21:50:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3QhR-0003rk-00 for manet-web-archive@ietf.org; Sat, 27 Sep 2003 21:50:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3QhH-0005Hv-Ht; Sat, 27 Sep 2003 21:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3Qgs-0005HI-L1 for manet@optimus.ietf.org; Sat, 27 Sep 2003 21:49:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20420 for ; Sat, 27 Sep 2003 21:49:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3Qgp-0003rT-00 for manet@ietf.org; Sat, 27 Sep 2003 21:49:35 -0400 Received: from acbde252.ipt.aol.com ([172.189.226.82] helo=SERWERUS) by ietf-mx with smtp (Exim 4.12) id 1A3Qgo-0003rP-00 for manet@ietf.org; Sat, 27 Sep 2003 21:49:35 -0400 Received: From kundell (unverified [192.168.0.2]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v5.0.4) with SMTP id <0000000007@SERWERUS>; Sun, 28 Sep 2003 02:47:04 +0100 Message-ID: <000701c38562$d946a240$0200a8c0@kundell> From: "Grzegorz Jablonski" To: "manet" References: <007c01c38524$581369d0$6a14db8d@win.ee.mtu.edu> Date: Sun, 28 Sep 2003 02:19:21 +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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [manet] Ordering of messages 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I'm doing research in formal verification of MANETs. I'm building a communication model, which I want to be consistent with 802.11 adhoc mode. Say we have several 802.11 adhoc nodes with TCP/IP stack. No routing is enabled. All nodes concurrently keep sending out broadcast datagram packets to the network, at the same time listening for broadcast packets and receiving all possible. Obviously, some messages get lost, so after the experiment ends, different nodes will have received different sequences of packets. So the question is, for any two nodes, are all 'common' messages - received by both nodes - received in the same order by each node? I made an experiment which would suggest the answer is yes, and it's what I assume. But if only routing was involved, the answer should be no. After reading 802.11 spec, I'm still not sure if my assumption is right. Greg _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Sun Sep 28 00:52:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25240 for ; Sun, 28 Sep 2003 00:52:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3TXi-0003FG-SJ for manet-archive@odin.ietf.org; Sun, 28 Sep 2003 00:52:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8S4qMlI012475 for manet-archive@odin.ietf.org; Sun, 28 Sep 2003 00:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3TXi-0003F8-Kg for manet-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 00:52:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25224 for ; Sun, 28 Sep 2003 00:52:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3TXf-0005T5-00 for manet-web-archive@ietf.org; Sun, 28 Sep 2003 00:52:19 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3TXf-0005T2-00 for manet-web-archive@ietf.org; Sun, 28 Sep 2003 00: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 1A3TXO-0003Aq-3h; Sun, 28 Sep 2003 00:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3TXI-0003AQ-UB for manet@optimus.ietf.org; Sun, 28 Sep 2003 00:51:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25200 for ; Sun, 28 Sep 2003 00:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3TXG-0005SO-00 for manet@ietf.org; Sun, 28 Sep 2003 00:51:54 -0400 Received: from ziz.its.uow.edu.au ([130.130.68.16]) by ietf-mx with esmtp (Exim 4.12) id 1A3TXF-0005SL-00 for manet@ietf.org; Sun, 28 Sep 2003 00:51:53 -0400 Received: from ziz (localhost [127.0.0.1]) by ziz.its.uow.edu.au (8.12.9/8.12.9) with ESMTP id h8S4pddh025336; Sun, 28 Sep 2003 14:51:39 +1000 (EST) Received: from inti.its.uow.edu.au ([130.130.37.4]) by ziz.its.uow.edu.au (MailMonitor for SMTP v1.2.2 ) ; Sun, 28 Sep 2003 14:51:39 +1000 (EST) Received: (from sendmail@localhost) by inti.its.uow.edu.au (8.12.9/8.12.9) id h8S4pcvt020530; Sun, 28 Sep 2003 14:51:38 +1000 (EST) Received: from hades.snrc.uow.edu.au (hades.snrc.uow.edu.au[130.130.10.100]) by inti.its.uow.edu.au (UWSMTPD 1.5.0) with ESMTP id 7760087.20518; Sunday, 28 September 2003 14:51:35 +1000 Received: from hades (IDENT:0@hades.snrc.uow.edu.au [130.130.10.100]) by hades.snrc.uow.edu.au (8.12.10/8.12.4) with ESMTP id h8S4pX5S013000; Sun, 28 Sep 2003 14:51:33 +1000 Received: from neo.snrc.uow.edu.au ([130.130.10.106]) by hades.snrc.uow.edu.au (MailMonitor for SMTP v1.2.2 ) ; Sun, 28 Sep 2003 14:51:33 +1000 (EST) From: Justin Lipman Reply-To: justin@titr.uow.edu.au Organization: TITR To: "manet" Subject: Re: [manet] Ordering of messages in 802.11 Date: Sun, 28 Sep 2003 14:51:32 +1000 User-Agent: KMail/1.5.3 References: <007c01c38524$581369d0$6a14db8d@win.ee.mtu.edu> <000701c38562$d946a240$0200a8c0@kundell> In-Reply-To: <000701c38562$d946a240$0200a8c0@kundell> Cc: "Grzegorz Jablonski" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309281451.32233.justin@titr.uow.edu.au> X-MessageID: 7760087.20518 X-EnvelopeFrom: 7760087.20518 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, > So the question is, for any two nodes, are all 'common' messages - received > by both nodes - received in the same order by each node? > I made an experiment which would suggest the answer is yes, and it's what I > assume. But if only routing was involved, the answer should be no. After > reading 802.11 spec, I'm still not sure if my assumption is right. If I understand your question correctly then my answer regarding a multihop scenario would be possibly "no". > Say we have several 802.11 adhoc nodes with TCP/IP stack. No routing is > enabled. All nodes concurrently keep sending out broadcast datagram packets > to the network, at the same time listening for broadcast packets and > receiving all possible. Obviously, some messages get lost, so after the > experiment ends, different nodes will have received different sequences of > packets. If IEEE 802.11 is used and all nodes within the ad hoc network are "flooding" packets. I assume you are referring to "flooding" (broadcast datagrams). Then I think the arrival sequence of flooded packets would be subject to various non-deterministic delays due to the use of CSMA (random backoff) when broadcasting during flooding. No RTS/CTS/NAV is used. Hence different packets would experience different delays which may be dependent on node density (topology) and effects of random backoff. One other point is that inorder to implement flooding effectively, one needs to introduce some amount of jitter prior to rebroadcasting. So this may also have a delaying effect. I think if an optimised flooding algorithm is used then packets may travel different paths and thus introduce different delays too. Kind regards, Justin -- PhD Candidate Telecommunications & Information Technology Research Institute School of Computer, Electrical & Telecommunications Engineering University of Wollongong, Australia 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 Sun Sep 28 18:36:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03892 for ; Sun, 28 Sep 2003 18:36:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3k9M-0006fl-23 for manet-archive@odin.ietf.org; Sun, 28 Sep 2003 18:36:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8SMaK8o025650 for manet-archive@odin.ietf.org; Sun, 28 Sep 2003 18:36:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3k9L-0006fd-TY for manet-web-archive@optimus.ietf.org; Sun, 28 Sep 2003 18:36:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03866 for ; Sun, 28 Sep 2003 18:36:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3k9I-0005Qj-00 for manet-web-archive@ietf.org; Sun, 28 Sep 2003 18:36:16 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3k9I-0005Qf-00 for manet-web-archive@ietf.org; Sun, 28 Sep 2003 18:36:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3k94-0006eI-Hn; Sun, 28 Sep 2003 18:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3k8m-0006dY-U4 for manet@optimus.ietf.org; Sun, 28 Sep 2003 18:35:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03857 for ; Sun, 28 Sep 2003 18:35:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3k8j-0005QI-00 for manet@ietf.org; Sun, 28 Sep 2003 18:35:41 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx with esmtp (Exim 4.12) id 1A3k8j-0005QF-00 for manet@ietf.org; Sun, 28 Sep 2003 18:35:41 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA26767; Sun, 28 Sep 2003 17:35:36 -0500 (CDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id PAA03211; Sun, 28 Sep 2003 15:35:36 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h8SMXQV04382; Sun, 28 Sep 2003 15:33:26 -0700 (PDT) Received: from XCH-NE-02.ne.nos.boeing.com ([128.225.80.202]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Sun, 28 Sep 2003 18:33:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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] Ordering of messages in 802.11 Date: Sun, 28 Sep 2003 18:33:37 -0400 Message-ID: Thread-Topic: [manet] Ordering of messages in 802.11 Thread-Index: AcOFfIuSsZPdAIZxRsmk/2H16TqerwAkaSRQ From: "Manfredi, Albert E" To: , "manet" X-OriginalArrivalTime: 28 Sep 2003 22:33:37.0513 (UTC) FILETIME=[8F1CBD90:01C38610] 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 > -----Original Message----- > From: Justin Lipman [mailto:justin@titr.uow.edu.au] > Sent: Saturday, September 27, 2003 11:52 PM > To: manet > Cc: Grzegorz Jablonski > > So the question is, for any two nodes, are all 'common'=20 > messages - received > > by both nodes - received in the same order by each node? > > I made an experiment which would suggest the answer is yes,=20 > and it's what I > > assume. But if only routing was involved, the answer should=20 > be no. After > > reading 802.11 spec, I'm still not sure if my assumption is right. >=20 >=20 > If I understand your question correctly then my answer=20 > regarding a multihop=20 > scenario would be possibly "no". Hmmm. We're only talking an IEEE 802.11 as hoc network here, so I think = the answer has to be yes. There's no routing involved. The hosts on this = network must all be able to monitor the channel, much like hosts in a = single, half-duplex, wired Ethernet LAN. I think the reception times of frames will differ slightly between = hosts, of course, but I think the reception order should be identical. Now, if you go beyond the range of the single ad-hoc "basic service = set," in order to reach other hosts in the 802.11 network, you will have = to rely on the "distributed service" function, which means you'll have = to install "access points." At this point, I think it's possible fort = frames in different wireless domains will be ordered differently. But = this is not a single ad-hoc 802.11 network, either. That's my take on this. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 29 08:05:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06115 for ; Mon, 29 Sep 2003 08:05:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3wmI-0004jJ-GV for manet-archive@odin.ietf.org; Mon, 29 Sep 2003 08:05:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TC5MGO018175 for manet-archive@odin.ietf.org; Mon, 29 Sep 2003 08:05:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3wmI-0004j4-C2 for manet-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 08:05:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06090 for ; Mon, 29 Sep 2003 08:05:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3wmH-0004GT-00 for manet-web-archive@ietf.org; Mon, 29 Sep 2003 08:05:21 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3wmH-0004GQ-00 for manet-web-archive@ietf.org; Mon, 29 Sep 2003 08:05:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3wly-0004hp-TK; Mon, 29 Sep 2003 08:05:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3wlE-0004gg-Bt for manet@optimus.ietf.org; Mon, 29 Sep 2003 08:04:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06069 for ; Mon, 29 Sep 2003 08:04:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3wlD-0004Fk-00 for manet@ietf.org; Mon, 29 Sep 2003 08:04:15 -0400 Received: from web8006.mail.in.yahoo.com ([203.199.70.93]) by ietf-mx with smtp (Exim 4.12) id 1A3wlC-0004FA-00 for manet@ietf.org; Mon, 29 Sep 2003 08:04:14 -0400 Message-ID: <20030929120343.59619.qmail@web8006.mail.in.yahoo.com> Received: from [203.200.20.226] by web8006.mail.in.yahoo.com via HTTP; Mon, 29 Sep 2003 13:03:43 BST Date: Mon, 29 Sep 2003 13:03:43 +0100 (BST) From: =?iso-8859-1?q?Samit?= 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] CMU extension to ns-2.26 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Does CMU have the new CMU Wireless extension 1.1.2 for ns2.26 ? following the suggestion on CMU web site, I downloaded ns2.1b3 all in one using TCL8.0. It can not be installed smoothly on redhat8.0 on my computer. According to the mail list, ns2.26 absorbed CMU Wireless extension. Does that means ad-hockey or other tools in CMU wireless extension can work perfectly with ns2.26, and I need not compile the /ns-src? Do all the old samples on CMU wireless extension 1.1.2 can work smoothly? CMU wireless extension1.1.2 is too old created in 1997. Why they did not release the new verson? Just because new version is included in ns2.26? Where I can find the detail document just like "The CMU Monarch Project's Wireless and Mobility Extensions to ns"? regards ________________________________________________________________________ Yahoo! India Matrimony: Find your partner online. Go to http://yahoo.shaadi.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Mon Sep 29 17:36:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12922 for ; Mon, 29 Sep 2003 17:36:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A45gx-0004dE-2w for manet-archive@odin.ietf.org; Mon, 29 Sep 2003 17:36:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TLaRnL017800 for manet-archive@odin.ietf.org; Mon, 29 Sep 2003 17:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A45gw-0004d1-Vo for manet-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 17:36:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12893 for ; Mon, 29 Sep 2003 17:36:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A45gu-0005S3-00 for manet-web-archive@ietf.org; Mon, 29 Sep 2003 17:36:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A45gu-0005S0-00 for manet-web-archive@ietf.org; Mon, 29 Sep 2003 17:36:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A45gY-0004Yn-IW; Mon, 29 Sep 2003 17:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A45gW-0004YP-CF for manet@optimus.ietf.org; Mon, 29 Sep 2003 17:36: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 RAA12867 for ; Mon, 29 Sep 2003 17:35:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A45gT-0005RD-00 for manet@ietf.org; Mon, 29 Sep 2003 17:35:57 -0400 Received: from smtpproxy1.mitre.org ([192.160.51.75]) by ietf-mx with esmtp (Exim 4.12) id 1A45gT-0005R7-00 for manet@ietf.org; Mon, 29 Sep 2003 17:35:57 -0400 Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.99]) by smtpproxy1.mitre.org (8.12.10/8.12.8) with ESMTP id h8TLZuYG018914 for ; Mon, 29 Sep 2003 17:35:56 -0400 (EDT) Received: from linus.mitre.org (smtp-bedford [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.12.8) with ESMTP id h8TLaYq12292 for ; Mon, 29 Sep 2003 17:36:34 -0400 Received: from faron.mitre.org (faron.mitre.org [129.83.10.2]) by linus.mitre.org (8.12.10/8.12.8) with ESMTP id h8TLZtDS005390 for ; Mon, 29 Sep 2003 17:35:55 -0400 (EDT) Message-Id: <200309292135.h8TLZtDS005390@linus.mitre.org> To: manet@ietf.org X-Mailer: nmh 1.0.4 From: Vipin Swarup Reply-to: swarup@mitre.org Date: Mon, 29 Sep 2003 17:35:55 -0400 Subject: [manet] SASN'03: Call for Participation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , CALL FOR PARTICIPATION 2003 ACM Workshop on Security of Ad Hoc and Sensor Networks (SASN) In conjunction with the 10th ACM Conference on Computer and Communications Security (CCS) October 31, 2003 George Mason University Fairfax, VA http://www.cs.gmu.edu/sasn Sponsored by ACM SIGSAC Registration is available via the ACM CCS website http://www.acm.org/sigs/sigsac/ccs/CCS2003 ----------------------------------------------------------------- TECHNICAL PROGRAM ----------------------------------------------------------------- 8:30-8:45am: Opening Remarks Vipin Swarup and Sanjeev Setia (Workshop Co-Chairs) 8:45-10:00am: Session 1: Ad Hoc Networks * A Security Design for a General Purpose, Self-Organizing, Multihop Ad Hoc Wireless Network. Tom Messerges (Motorola Labs, USA), Johnas Cukier (Mitsubishi Labs, USA), Tom A.M. Kevenaar (Philips Electronics, Netherlands), Larry Puhl (Motorola Labs, USA), Rene Struik (Certicom, Canada), and Ed Callaway (Motorola Labs, USA) * Modeling Vulnerabilities of Ad Hoc Routing Protocols. Shahan Yang and John S. Baras (University of Maryland, College Park, USA) * SECTOR: Secure Tracking of Node Encounters in Multi-hop Wireless Networks. Srdjan Capkun, Levente Buttyan, and Jean-Pierre Hubaux (EPFL, Switzerland) 10:00-10:20: Break 10:20-11:35am: Session 2: Authentication * Identity Certified Authentication for Ad-hoc Networks. Andre Weimerskirch (Ruhr-University, Germany) and Dirk Westhoff (NEC Labs, Germany) * An Approach to Certificate Path Discovery in Mobile Ad Hoc Networks. He Huang (North Carolina State University, USA) and S. Felix Wu (University of California, Davis, USA) * A certificate revocation scheme for wireless ad hoc networks. Claude Crepeau and Carlton R. Davis (McGill University, Canada) 11:35-11:45: Break 11:45-12:45pm: Invited Keynote Talk: David Wagner (University of California, Berkeley, USA) 12:45-1:45pm: Lunch 1:45-2:00pm: Invited Talk: Cliff Wang (U.S. Army Research Office) 2:00-3:15pm: Session 3: Sensor Networks * Random Key Assignment for Secure Wireless Sensor Networks. Roberto Di Pietro, Luigi V. Mancini, and Alessandro Mei (University of Rome "La Sapienza", Italy) * Location-Based Pairwise Key Establishment for Static Sensor Networks. Donggang Liu and Peng Ning (North Carolina State University, USA) * Security Support for In-Network Processing in Wireless Sensor Networks. Jing Deng, Richard Han, and Shivakant Mishra (University of Colorado, Boulder, USA) 3:15-3:35: Break 3:35-4:50pm: Session 4: Secure Group Management * Secure Multicast Groups on Ad Hoc Networks. T. Kaya, G. Lin, G. Noubir, A. Yilmaz (Northeastern University, USA) * Admission Control in Peer-to-Peer: Design and Performance Evaluation. Nitesh Saxena, Gene Tsudik, and Jeong Hyun Yi (University of California, Irvine, USA) * Secure Long Term Communities In Ad Hoc Networks. Nicolas Prigent (Thomson Research & Supelec, France), Christophe Bidan (Supelec, France), Jean-Pierre Andreaux (Thomson Research, France), and Olivier Heen (Thomson Research, France) 4:50-5:00: Break 5:00-5:50pm: Session 5: Intrusion Detection * A Specification-Based Intrusion Detection System For AODV. Chin-Yang Tseng, Poornima Balasubramanyam, Calvin Ko, Rattapon Limprasittiporn, Jeff Rowe, and Karl Levitt (University of California, Davis and Network Associates Labs, USA) * A Cooperative Intrusion Detection System for Ad Hoc Networks. Yi-an Huang and Wenke Lee (Georgia Tech, USA) --------------------------------------------------------- ORGANIZERS --------------------------------------------------------- Workshop Co-Chairs: Vipin Swarup, The MITRE Corporation Sanjeev Setia, George Mason University Program Committee: Virgil Gligor, University of Maryland at College Park Zygmunt Haas, Cornell University Jean-Pierre Hubaux, Swiss Federal Institute of Technology, Lausanne Brian Levine, University of Massachusetts at Amherst Songwu Lu, University of California at Los Angeles Luigi Mancini, University of Rome "La Sapienza" Peng Ning, North Carolina State University Adrian Perrig, Carnegie Mellon University Radha Poovendran, University of Washington at Seattle Emilia Rosti, University of Milan David Wagner, University of California at Berkeley ============================================================ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 30 10:11:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22639 for ; Tue, 30 Sep 2003 10:11:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LDh-00008d-OE for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 10:11:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UEBHY3000525 for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 10:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LDh-00008O-IT for manet-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 10:11:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22586 for ; Tue, 30 Sep 2003 10:11:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4LDf-00074S-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 10:11:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4LDf-00074P-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 10:11:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LDT-00007E-Ab; Tue, 30 Sep 2003 10:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LCp-00006G-Hh for manet@optimus.ietf.org; Tue, 30 Sep 2003 10:10:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22477 for ; Tue, 30 Sep 2003 10:10:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4LCn-00073p-00 for manet@ietf.org; Tue, 30 Sep 2003 10:10:21 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1A4LCm-00073m-00 for manet@ietf.org; Tue, 30 Sep 2003 10:10:20 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h8UEADO18981; Tue, 30 Sep 2003 16:10:13 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: Cc: Subject: AW: [manet] Clarification on RFC 3561 (current time & updating route lifetime) Date: Tue, 30 Sep 2003 16:12:14 +0200 Message-ID: <000001c3875c$d9837d40$989b6686@scoobydoo> 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.4510 Importance: Normal In-Reply-To: <16202.20903.435994.994255@gargle.gargle.HOWL> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Ian Section 6.2 pf RFC 3561 says following. When an ordinary (i.e. non-AODV) packet is received, if routes exist, then they should be updated (lifetime) to destination next hop to destination Source. If destination is equal to next hop, then the lifetime of the destination updates as long as the data packets go. But, if we use Hello messages to detect the link break to next hop, in the above case, we found that the lifetime of the destination never expires due to incomming packets and we can"t detect the link break using Hello messages. Has this problem been addressed in the RFC or Should we update route lifetime of destination that is equal to the next hop, solely due to Hello messages? Kind regards Koojana University of Bremen FB 1 - IKOM/ComNets Koojana Kuladinithi BSc, MSc Otto-Hahn-Allee NW 1 28359 Bremen - Germany _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 30 10:14:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22928 for ; Tue, 30 Sep 2003 10:14:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LGP-0000Xe-Jg for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 10:14:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UEE5hP002076 for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 10:14:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LGP-0000XP-CL for manet-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 10:14:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22880 for ; Tue, 30 Sep 2003 10:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4LGM-00077i-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 10:14:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4LGM-00077f-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 10:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LGL-0000TV-SX; Tue, 30 Sep 2003 10:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LG1-0000T4-ST for manet@optimus.ietf.org; Tue, 30 Sep 2003 10:13:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22851 for ; Tue, 30 Sep 2003 10:13:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4LFz-00077b-00 for manet@ietf.org; Tue, 30 Sep 2003 10:13:39 -0400 Received: from i4mail.informatik.rwth-aachen.de ([137.226.12.21]) by ietf-mx with esmtp (Exim 4.12) id 1A4LFy-00076p-00 for manet@ietf.org; Tue, 30 Sep 2003 10:13:39 -0400 Received: from i4mail (i4mail.informatik.rwth-aachen.de [137.226.12.21]) by i4mail.informatik.rwth-aachen.de (Postfix) with ESMTP id E44EF1848E for ; Tue, 30 Sep 2003 16:13:07 +0200 (CEST) Received: from canary.info-4.informatik.rwth-aachen.de ([137.226.12.209]) by i4mail.informatik.rwth-aachen.de (MailMonitor for SMTP v1.2.2 ) ; Tue, 30 Sep 2003 16:13:07 +0200 (CEST) Reply-To: From: =?iso-8859-2?Q?Mesut_G=FCnes?= To: Date: Tue, 30 Sep 2003 16:13:07 +0200 Organization: RWTH-Aachen Message-ID: <028901c3875c$f8e7fd00$d10ce289@informatik.rwthaachen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" 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 Content-Transfer-Encoding: quoted-printable Subject: [manet] New Version of MobilityVisualizer Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Hello, we have published a new version of our visualization tool. You can download it from our website. http://www.adhoc-nets.de The jar-package contains also the source code of the tool. Sincerly Mesut G=FCne=BA ----------------------------------------------------------------- __ /\_\ __ =20 __\/_//\ \ =20 /\_\ /::\ \ Dipl.-Inform. =20 /:/ / /:/\:\ \ Mesut G=FCnes /:/ / /:/ /\:\_\ =20 /:/ / /:/ / _\/_/ Department of Computer Science =20 /:/ / /:/ / /\_\ Informatik 4 =20 _\/_/ /:/ / /:/ / RWTH-Aachen =20 /\ \ /:/ / /:/ / =20 \:\ \/:/ / /:/ / Office: 4108A =20 \:\/:/ / /:/ / _ =20 \::/ / \:\ \/\_\ Phone: +49 241 8021416 =20 \/_/ \:\/:/ / Fax: +49 241 8022220 =20 \::/ / =20 /::\ \ email: guenes@informatik.rwth-aachen.de /:/\:\_\ http://www-i4.informatik.rwth-aachen.de \/_/\/_/ ----------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 30 12:34:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00762 for ; Tue, 30 Sep 2003 12:34:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4NS1-000133-4k for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 12:34:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UGYD0I004023 for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 12:34:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4NS1-00012o-1V for manet-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 12:34: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 MAA00714 for ; Tue, 30 Sep 2003 12:34:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4NRz-0001L0-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 12:34:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4NRz-0001Kx-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 12:34:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4NRp-00010U-3Q; Tue, 30 Sep 2003 12:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4NQz-000105-6b for manet@optimus.ietf.org; Tue, 30 Sep 2003 12:33:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00645 for ; Tue, 30 Sep 2003 12:33:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4NQx-0001KM-00 for manet@ietf.org; Tue, 30 Sep 2003 12:33:07 -0400 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by ietf-mx with esmtp (Exim 4.12) id 1A4NQx-0001KA-00 for manet@ietf.org; Tue, 30 Sep 2003 12:33:07 -0400 Received: from localhost ([127.0.0.1] helo=mail.zrz.TU-Berlin.DE) by mail.zrz.tu-berlin.de with esmtp (exim-4.24-1) for id 1A4NQS-0002NY-MX; Tue, 30 Sep 2003 18:32:36 +0200 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Tue, 30 Sep 2003 18:32:36 +0200 (CEST) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail.zrz.tu-berlin.de with esmtp (exim-4.24-1) for id 1A4NQS-0002N9-LX; Tue, 30 Sep 2003 18:32:36 +0200 Received: from almathea (mail@almathea.tkn.TU-Berlin.DE [130.149.49.56]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id h8UGWaC16535 for ; Tue, 30 Sep 2003 18:32:36 +0200 Received: from karl by almathea with local (Exim 3.35 #1 (Debian)) id 1A4NQS-0007T3-00 for ; Tue, 30 Sep 2003 18:32:36 +0200 To: manet@ietf.org Message-Id: From: Holger Karl Date: Tue, 30 Sep 2003 18:32:36 +0200 X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Tue, 30 Sep 2003 18:32:36 +0200 Subject: [manet] Call for Papers: WiOpt'04 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- Note: The submission deadline is 5th of November, 2003. *************************************************** ******** 2nd CALL FOR PAPERS ******** *************************************************** * * * WiOpt '04 * * * * 2nd Workshop on Modeling and Optimization * * in Mobile, Ad Hoc and Wireless Networks * * * * March 24 - 26, 2004, Cambridge, UK * * * * * *************************************************** Workshop Website: http://www.cl.cam.ac.uk/Research/SRG/wiopt04/ This workshop is intended to bring together leading researchers from both academia and industry to present both foundations and practical methods and tools for modeling and optimisation of mobile and ad hoc networks. The workshop will bring together researchers studying optimisation issues of mobile networks from both the network performance and the mobile networking perspectives: * Mobile Network Optimisation: Applications and Algorithms * Performance characterisation and optimisation of mobile/wireless networks and systems * Protocol design (MAC, Routing) for optimal mobile network utilisation * Tools for network optimisation * Energy efficiency in mobile networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad hoc networks. Papers to be presented at WiOpt'04 will be selected based on extended abstracts of up to 8 pages, double-spaced, 12 point font size. The submission should not exceed 3000 words including tables and figures, each of which count as 250 words. Authors of accepted presentations will have the opportunity to publish either the extended abstract or the full paper in a proceedings volume. Full papers will further be considered for publication in a special issue of the MONET journal. Plenary Speakers: Bruce Hajek (University of Illinois at Urbana-Champaign, USA) Ian Akyildiz (Georgia Institute of Technology, USA) IMPORTANT DATES: Submission of extended abstract: Nov. 5, 2003. Notification of acceptance: Jan. 15, 2003. Camera ready copy: Feb. 15, 2003. (Further details on the workshop website, http://www.cl.cam.ac.uk/Research/SRG/wiopt04/) General chairman: Imrich Chlamtac Vice General Chair: Roger Whitaker Program Co-Chairs: Marco Conti and Tamer Basar Program committee of the conference: Eitan Altman, Venkat Anantharam, Konstantin Avrachenkov, Andrew Campbell, X. Cao, A. Chockalingam, Jon Crowcroft, Anthony Ephremides, Silvia Giordano, Stephen V. Hanly, Jean-Pierre Hubaux, Holger Karl, Peter Key, P. R. Kumar, Peter Marbach, Derek Mcauley, Archan Misra, Philippe Nain, Sven Oestring, Yoshikuni Onozato, Ariel Orda, Ramesh Rao, Catherine Rosenberg, Ness Shroff, Violet Syrotiuk, Thierry Turletti, Adam Wolisz, Jeff Wieselthier, Moshe Zukerman Local Arrangements Co-Chair: Sven Oestring, Julian Chesterfield and Rajiv Chakravorty Treasurer: Meng How Lim Publicity Chair: Holger Karl The workshop is co-sponsored by * Univ. of Cambridge * IIT (Istituto di Informatica e Telematica) * IEEE IT Society (technical co-sponsorship) (ACM sponsorship is pending.) Additional financial support is provided by: * Intel * Microsoft Research _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 30 13:29:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03403 for ; Tue, 30 Sep 2003 13:29:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OJB-00056O-71 for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 13:29:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UHT9Gg019606 for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 13:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OJB-000569-2K for manet-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 13:29:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03385 for ; Tue, 30 Sep 2003 13:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4OJ8-00022U-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 13:29:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4OJ8-00022R-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 13:29:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OJ4-00052F-2C; Tue, 30 Sep 2003 13:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OIc-00051j-S9 for manet@optimus.ietf.org; Tue, 30 Sep 2003 13:28:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03355 for ; Tue, 30 Sep 2003 13:28:27 -0400 (EDT) From: jayanthi@egr.msu.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4OIa-00022H-00 for manet@ietf.org; Tue, 30 Sep 2003 13:28:32 -0400 Received: from jeeves.egr.msu.edu ([35.9.37.127] helo=egr.msu.edu) by ietf-mx with esmtp (Exim 4.12) id 1A4OIZ-00021Q-00 for manet@ietf.org; Tue, 30 Sep 2003 13:28:32 -0400 Received: from egr.msu.edu (byers [35.9.37.129]) by egr.msu.edu (8.12.10/8.12.10) with SMTP id h8UHS139011486 for ; Tue, 30 Sep 2003 13:28:01 -0400 (EDT) Message-Id: <200309301728.h8UHS139011486@egr.msu.edu> Date: Tue, 30 Sep 2003 17:28:01 -0000 To: X-Mailer: TWIG 2.7.5 Subject: [manet] Need input for choosing a simulation package Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hello, I am currently looking into simulating directional antenna for MANETs. From the academic literature, I get the impression that Qualnet/Glomosim, OPNET and sometimes NS-2 have been used by various groups for simulating routing protocols using directional communication. I would very much appreciate any advice/comments/opinion on which simulation package might be the best for my purpose. Thanks, Jayanthi Rao _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 30 15:53:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12607 for ; Tue, 30 Sep 2003 15:53:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QYg-0001WS-DA for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 15:53:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UJrIK8005848 for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 15:53:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QYg-0001WF-AC for manet-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 15:53: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 PAA12534 for ; Tue, 30 Sep 2003 15:53:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QYa-0004DT-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 15:53:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4QYa-0004DQ-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 15:53:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QYO-0001Th-QZ; Tue, 30 Sep 2003 15:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QY1-0001Sk-IE for manet@optimus.ietf.org; Tue, 30 Sep 2003 15:52:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12397 for ; Tue, 30 Sep 2003 15:52:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QXz-0004B3-00 for manet@ietf.org; Tue, 30 Sep 2003 15:52:35 -0400 Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx with esmtp (Exim 4.12) id 1A4QXz-0004Ap-00 for manet@ietf.org; Tue, 30 Sep 2003 15:52:35 -0400 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 h8UJqPe26545; Tue, 30 Sep 2003 12:52:25 -0700 (PDT) From: Ian Chakeres MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16249.57044.41620.530043@gargle.gargle.HOWL> Date: Tue, 30 Sep 2003 12:51:48 -0700 To: "Koojana Kuladinithi" Cc: Subject: RE:AW: [manet] Clarification on RFC 3561 (current time & updating route lifetime) In-Reply-To: <000001c3875c$d9837d40$989b6686@scoobydoo> References: <16202.20903.435994.994255@gargle.gargle.HOWL> <000001c3875c$d9837d40$989b6686@scoobydoo> 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 There must be separate hello timer associated with each neighbor. The lifetime field in the routing table cannot be used to indicated loss of connectivity to a neighbor. See manet and aodvimpl mailing list archives, I believe this was discussed. Here is an example, consider the network A-B-C where A is sending packets to C. B, must receive a hello message or other message from C within hello_interval*allowed_hello_loss. If B does not, it will detect a loss of connectivity to C. The link connectivity between C and B is independent the lifetime field. The lifetime is influenced by A sending packets to C through B. I hope this helps. Ian Chakeres >Koojana Kuladinithi wrote: >Hi Ian > >Section 6.2 pf RFC 3561 says following. >When an ordinary (i.e. non-AODV) packet is received, if routes exist, then >they should be updated (lifetime) to destination next hop to destination >Source. > >If destination is equal to next hop, then the lifetime of the >destination updates as long as the data packets go. > >But, if we use Hello messages to detect the link break to next hop, in the >above case, we found that the lifetime of the destination never expires due >to incomming packets and we can"t detect the link break using Hello >messages. > >Has this problem been addressed in the RFC or >Should we update route lifetime of destination that is equal to the next >hop, solely due to Hello messages? > >Kind regards > >Koojana > >University of Bremen >FB 1 - IKOM/ComNets >Koojana Kuladinithi BSc, MSc >Otto-Hahn-Allee NW 1 >28359 Bremen - Germany > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 30 17:31:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16739 for ; Tue, 30 Sep 2003 17:31:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4S5b-0007Po-5a for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 17:31:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ULVN9J028498 for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 17:31:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4S5a-0007PX-AH for manet-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 17:31:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16729 for ; Tue, 30 Sep 2003 17:31:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4S5L-0005bc-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 17:31:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4S5L-0005bZ-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 17:31:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4S5G-0007LN-7n; Tue, 30 Sep 2003 17:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4S4u-0007KJ-5z for manet@optimus.ietf.org; Tue, 30 Sep 2003 17:30:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16710 for ; Tue, 30 Sep 2003 17:30:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4S4r-0005bG-00 for manet@ietf.org; Tue, 30 Sep 2003 17:30:37 -0400 Received: from smtp1.voila.fr ([193.252.22.174] helo=mwinf4001.voila.fr) by ietf-mx with esmtp (Exim 4.12) id 1A4S4r-0005b0-00 for manet@ietf.org; Tue, 30 Sep 2003 17:30:37 -0400 Received: from wwinf4002 (wwinf4002 [172.22.157.29]) by mwinf4001.voila.fr (SMTP Server) with ESMTP id 019621800122 for ; Tue, 30 Sep 2003 23:30:07 +0200 (CEST) Message-ID: <7776453.1064957406997.JavaMail.www@wwinf4002> From: "samir.chihi" Reply-To: samir.chihi@voila.fr To: manet@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Date: Tue, 30 Sep 2003 23:30:07 +0200 (CEST) Content-Transfer-Encoding: 7bit Subject: [manet] 802.11 MAC : Beacon 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I want to know the fields of the beacon frame ? How we could use the beacon frame for data collection ? Best regards ------------------------------------------ Faites un voeu et puis Voila ! www.voila.fr _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 30 20:59:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23287 for ; Tue, 30 Sep 2003 20:59:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4VKj-00012Q-4J for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 20:59:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h910xD4W003984 for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 20:59:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4VKj-00012B-0g for manet-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 20:59: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 UAA23268 for ; Tue, 30 Sep 2003 20:59:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4VKg-0007ZR-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 20:59:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4VKg-0007ZO-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 20:59:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4VKX-00010y-I5; Tue, 30 Sep 2003 20:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4VK3-00010S-V4 for manet@optimus.ietf.org; Tue, 30 Sep 2003 20:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23238 for ; Tue, 30 Sep 2003 20:58:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4VK1-0007Yf-00 for manet@ietf.org; Tue, 30 Sep 2003 20:58:29 -0400 Received: from [129.254.114.50] (helo=pec.etri.re.kr) by ietf-mx with esmtp (Exim 4.12) id 1A4VJw-0007Xo-00 for manet@ietf.org; Tue, 30 Sep 2003 20:58:24 -0400 Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.12.9/8.12.9) with SMTP id h911CFV6014449; Wed, 1 Oct 2003 10:12:16 +0900 (KST) Message-ID: <003d01c387b6$e416c140$c470fe81@etri.re.kr> From: "Jaehoon Paul Jeong" To: "John Paul O Grady" Cc: "MANET WG" , "autonet" References: <005f01c3873e$67356320$af29be9d@eeb253w2k> Date: Wed, 1 Oct 2003 09:56:45 +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 Content-Transfer-Encoding: base64 Subject: [manet] Re: IP Address Autoconfiguration (MANET Draft 03) Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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: base64 Content-Transfer-Encoding: base64 SGVsbG8gSm9obiwNCg0KPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+RnJvbTogSm9o biBQYXVsIE8gR3JhZHkgDQo+VG86IHBhdWxAZXRyaS5yZS5rciA7IGphZnlAZXRyaS5yZS5rciA7 IHBqc0BldHJpLnJlLmtyIDsga2hqQGV0cmkucmUua3IgDQo+U2VudDogVHVlc2RheSwgU2VwdGVt YmVyIDMwLCAyMDAzIDc6MzQgUE0NCj5TdWJqZWN0OiBJUCBBZGRyZXNzIEF1dG9jb25maWd1cmF0 aW9uIChNQU5FVCBEcmFmdCAwMykNCj4NCj5IZWxsbw0KPg0KPkkgaGF2ZSBhIHF1ZXN0aW9uIGlu IHJlZ2FyZCB0byB0aGUgSVAgYWRkcmVzcyBhdXRvY29uZmlndXJhdGlvbiBkcmFmdC4gDQo+SW4g dGhlIGRyYWZ0IGEgbnVtYmVyIG9mIGRlZmF1bHQgcGFyYW1ldGVycyBhcmUgdXNlZCwgb25lIG9m IHRoZXNlIGlzIGFuIEFERFJFU1NfRElTQ09WRVJZIHBhcmFtZXRlciwgDQo+d2hpY2ggaXMgdGlt ZSBhIG5vZGUgd2FpdHMgYmV0d2VlbiBzZW5kaW5nIEFSRVEgbWVzc2FnZXMuIA0KPkRlZmF1bHQg dmFsdWVzIHdlcmUgZ2l2ZW4gZm9yIGEgbnVtYmVyIG9mIHRoZXNlIHBhcmFtZXRlcnMgaW4gdGhl IE5vdiAwMSBEcmFmdC4gDQo+DQoNClRoZSBhYm92ZSBkcmFmdCBpcyBDLiBQZXJraW5zJ3Mgb25l LCBkcmFmdC1pZXRmLW1hbmV0LWF1dG9jb25mLTAxLnR4dC4NCg0KPkkgd2FzIGp1c3Qgd29uZGVy aW5nIHdoYXQgc2l6ZSBuZXR3b3JrIHdhcyBjb25zaWRlcmVkIGZvciB0aGVzZSBkZWZhdWx0IHBh cmFtZXRlcnMuIA0KPkZvciBleGFtcGxlIHRoZSBORVRfRElBTUVURVIgcGFyYW1ldGVyIGhhcyBh IGRlZmF1bHQgdmFsdWUgb2YgMTAsIHdoYXQgc2l6ZSBuZXR3b3JrIHdhcyBjb25zaWRlcmVkIA0K PmZvciB0aGlzIHBhcmFtZXRlcj8NCg0KSSB0aGluayB0aGlzIHBhcmFtZXRlciBpcyBmb3IgYSBt aWRkbGUtc2NhbGUgTUFORVQuDQpJbiBSRkMzNTYxLCBBT0RWLCBORVRfRElBTUVURVIgZm9yIHRo ZSByb3V0ZSBkaXNjb3ZlcnkgaXMgMzUuIA0KSSB0aGluayB0aGlzIGlzIGZvciBsYXJnZS1zY2Fs ZSBNQU5FVC4NCg0KPkkgcHJlc3VtZSB0aGUgQUREUkVTU19ESVNDT1ZFUlkgcGFyYXJldGVyIHdp bGwgaW5jcmVhc2UgaW4gc2l6ZSBhcyB0aGUgbmV0d29yayBkb2VzPw0KT25seSBmb3IgU3Ryb25n LURBRCwgSSBhZ3JlZSB3aXRoIHlvdS4NCkhvd2V2ZXIsIGluIG15IGRyYWZ0LCBkcmFmdC1qZW9u Zy1hZGhvYy1pcC1hZGRyLWF1dG9jb25mLTAwLnR4dCwgDQpldmVuIHRob3VnaCB0aGUgbmV0d29y ayBiZWNvbWVzIGxhcmdlLCB0aGUgdmFsdWUgb2YgQUREUkVTU19ESVNDT1ZFUlkgaXMgZml4ZWQu IA0KQmVjYXVzZSB0aGUgY29uZmxpY3Qgb3ZlciB0aGlzIGNvdmVyYWdlIGNhbiBiZSBoYW5kbGVk IGJ5IFdlYWstREFEIA0KdGhhdCBpcyBiYXNlZCBvbiBBZC1ob2Mgcm91dGluZyBwcm90b2NvbC4g DQpUaGlzIGlzIG9uZSBvZiB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0d28gZHJhZnRzLg0KDQpU aGFua3MuDQoNCi9KYWVob29uDQoNCj4NCj5SZWdhcmRzDQo+DQo+Sm9obiBQYXVsIE8gR3JhZHkN Cj5Db3JrIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5DQo+SXJlbGFuZA0KDQo= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From exim@www1.ietf.org Tue Sep 30 21:22:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24071 for ; Tue, 30 Sep 2003 21:22:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Vh1-0002VC-Fz for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 21:22:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h911MFO2009612 for manet-archive@odin.ietf.org; Tue, 30 Sep 2003 21:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Vh1-0002Ux-CE for manet-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 21:22: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 VAA24053 for ; Tue, 30 Sep 2003 21:22:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Vgy-00003Y-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 21:22:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Vgy-00003V-00 for manet-web-archive@ietf.org; Tue, 30 Sep 2003 21:22:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Vgn-0002Qk-95; Tue, 30 Sep 2003 21:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Vg7-0002Py-Fx for manet@optimus.ietf.org; Tue, 30 Sep 2003 21:21:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24036 for ; Tue, 30 Sep 2003 21:21:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Vg4-00002q-00 for manet@ietf.org; Tue, 30 Sep 2003 21:21:16 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1A4Vg4-00002n-00 for manet@ietf.org; Tue, 30 Sep 2003 21:21:16 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HM200J0112LC7@mailout3.samsung.com> for manet@ietf.org; Wed, 01 Oct 2003 10:20:45 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HM200FSZ12KAS@mailout3.samsung.com> for manet@ietf.org; Wed, 01 Oct 2003 10:20:44 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HM200AG912KCW@mmp1.samsung.com> for manet@ietf.org; Wed, 01 Oct 2003 10:20:44 +0900 (KST) Date: Wed, 01 Oct 2003 10:20:54 +0900 From: Soohong Daniel Park Subject: RE: [manet] 802.11 MAC : Beacon frame In-reply-to: <7776453.1064957406997.JavaMail.www@wwinf4002> To: samir.chihi@voila.fr, manet@ietf.org Cc: "'Soohong Daniel Park'" Message-id: <005b01c387ba$423e6cc0$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: multipart/alternative; boundary="Boundary_(ID_pWqouFQJtj+EEyFHEqfGcg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_pWqouFQJtj+EEyFHEqfGcg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Beacon frame is one of management frame not data frame. Management frame format: 2 (octets) 2 6 6 6 2 0-2312 4 [Frame Control] [Duration] [DA] [SA] [BSSID] [Sequence Control] [Frame body] [FCS] Beacon frame (Type=00 / Subtype=1000) [Timestamp][Beacon Interval][Capability Information][SSID][Supported rates] [FH parameter set][DS parameter set][CF parameter set][IBSS parameter set][TIM] Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of samir.chihi > Sent: Wednesday, October 01, 2003 6:30 AM > To: manet@ietf.org > Subject: [manet] 802.11 MAC : Beacon frame > > > Hi, > I want to know the fields of the beacon frame ? > How we could use the beacon frame for data collection ? > > Best regards > ------------------------------------------ > > Faites un voeu et puis Voila ! www.voila.fr > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > --Boundary_(ID_pWqouFQJtj+EEyFHEqfGcg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT 메시지

Beacon frame is one of management frame not data frame.

Management frame format:
             2 (octets)        2            6       6            6                       2                     0-2312            4
[Frame Control] [Duration] [DA] [SA] [BSSID] [Sequence Control] [Frame body] [FCS]

Beacon frame (Type=00 / Subtype=1000)
 
[Timestamp][Beacon Interval][Capability Information][SSID][Supported rates]
[FH parameter set][DS parameter set][CF parameter set][IBSS parameter set][TIM]





Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics




> -----Original Message-----
> From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On
> Behalf Of samir.chihi
> Sent: Wednesday, October 01, 2003 6:30 AM
> To: manet@ietf.org
> Subject: [manet] 802.11 MAC : Beacon frame
>
>
>  Hi,
>  I want to know the fields of the beacon frame ?
>  How we could use the beacon frame for data collection ?
>
> Best regards
> ------------------------------------------
>
> Faites un voeu et puis Voila ! www.voila.fr
>
>
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>

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