From mailnull@www1.ietf.org Sat Mar 1 02:46:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06856 for ; Sat, 1 Mar 2003 02:46:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h217tJQ07344 for manet-archive@odin.ietf.org; Sat, 1 Mar 2003 02:55:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h217tIp07341 for ; Sat, 1 Mar 2003 02:55:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06845 for ; Sat, 1 Mar 2003 02:45:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h217XTp05812; Sat, 1 Mar 2003 02:33:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h217PPp05370 for ; Sat, 1 Mar 2003 02:25:25 -0500 Received: from gawab.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06259 for ; Sat, 1 Mar 2003 02:16:00 -0500 (EST) Received: (qmail 93728 invoked by uid 1004); 1 Mar 2003 07:20:53 -0000 Received: from unknown (HELO amrfbkf7vt1gwf) (comm@gawab.com@217.53.6.169) by gawab.com with SMTP; 1 Mar 2003 07:20:51 -0000 Message-ID: <000201c2dfc2$b5df8790$a90635d9@sfux.com> Reply-To: "Amr Ezzat" From: "Amr Ezzat" To: Date: Sat, 1 Mar 2003 09:09:52 +0200 Organization: communications MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C2DFD2.517036F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [manet] QOS in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C2DFD2.517036F0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable hi all: I am an undergraduate student making a research on the QOS of the MANET=20 I don't have enough resources=20 I need very quickly some web sites which includes papers or thesis about = the QOS in MANET=20 specially which talk about the QOS simulation examples in NS I will be grateful for who help me thanks alot=20 yours sincerely: Eng./ Amr Ezzat e-mail: comm@gawab.com ------=_NextPart_000_002B_01C2DFD2.517036F0 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
hi all:
 
I am an undergraduate student making = a research=20 on the QOS of the MANET
I don't have enough resources =
I need very quickly some web sites = which=20 includes papers or thesis about the QOS in MANET
specially which talk about the QOS = simulation=20 examples in NS
 
I will be grateful for who help = me
thanks alot
 
yours=20 sincerely:
          = ;            =          Eng./ =20 Amr=20 Ezzat
e-mail:
         = ;            =          =20 comm@gawab.com
 
------=_NextPart_000_002B_01C2DFD2.517036F0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Mar 1 07:42:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03897 for ; Sat, 1 Mar 2003 07:42:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h21Cp1J23062 for manet-archive@odin.ietf.org; Sat, 1 Mar 2003 07:51:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21Cp1p23055 for ; Sat, 1 Mar 2003 07:51:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03894 for ; Sat, 1 Mar 2003 07:41:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21CaBp21789; Sat, 1 Mar 2003 07:36:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21CRkp21589 for ; Sat, 1 Mar 2003 07:27:46 -0500 Received: from mail.tiscali.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03627 for ; Sat, 1 Mar 2003 07:18:15 -0500 (EST) Received: from irenein (62.10.137.18) by mail.tiscali.it (6.5.032) id 3E5CA4E4001B3661 for manet@ietf.org; Sat, 1 Mar 2003 13:20:10 +0100 Message-ID: <00dc01c2dfee$b1a6bbe0$73890a3e@irenein> From: "Irene Innocenti" To: Date: Sat, 1 Mar 2003 13:32:58 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01C2DFF7.12C34B20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [manet] manets and fixed networks Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00D9_01C2DFF7.12C34B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I=92m new of the mailing list. I=92d like to know if there exist any interesting work about routing in = hybrid networks made of manets interconnected to a fixed network. Particularly, I=92m interested in energy conserving routing strategies. Thanks in advance. Irene. ------=_NextPart_000_00D9_01C2DFF7.12C34B20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

I’m new of the mailing list.

I’d like to know if there exist any interesting = work about=20 routing in hybrid networks made of manets interconnected to a fixed=20 network.

Particularly, I’m interested in energy = conserving routing=20 strategies.

Thanks in advance.

Irene.

------=_NextPart_000_00D9_01C2DFF7.12C34B20-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Mar 1 08:26: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 IAA04437 for ; Sat, 1 Mar 2003 08:26:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h21DZFu24999 for manet-archive@odin.ietf.org; Sat, 1 Mar 2003 08:35:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21DZFp24996 for ; Sat, 1 Mar 2003 08:35:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04434 for ; Sat, 1 Mar 2003 08:25:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21DL0p24502; Sat, 1 Mar 2003 08:21:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21DCWp24332 for ; Sat, 1 Mar 2003 08:12:32 -0500 Received: from sm.luth.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04172 for ; Sat, 1 Mar 2003 08:02:59 -0500 (EST) Received: from dugdale.cdt.luth.se (dugdale.cdt.luth.se [130.240.64.172]) by sm.luth.se (8.12.3/8.12.3) with ESMTP id h21D4uaV015119; Sat, 1 Mar 2003 14:04:56 +0100 (MET) Date: Sat, 1 Mar 2003 14:07:28 +0100 (CET) From: Anders Lindgren X-X-Sender: dugdale@dugdale.cdt.luth.se To: Amr Ezzat cc: manet@ietf.org Subject: Re: [manet] QOS in MANET In-Reply-To: <000201c2dfc2$b5df8790$a90635d9@sfux.com> Message-ID: <20030301140032.S48175-100000@dugdale.cdt.luth.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , For ns-2 simulation studies of MAC layer QoS schemes, you can look at our publications at http://www.sm.luth.se/~dugdale/index/publications.shtml If you are interested in solutions that reside at a higher layer, I would recommend looking at the SWAN and INSIGNIA work done by the COMET group at Columbia Uni. http://comet.columbia.edu/publications/ /Anders On Sat, 1 Mar 2003, Amr Ezzat wrote: > hi all: > > I am an undergraduate student making a research on the QOS of the MANET > I don't have enough resources > I need very quickly some web sites which includes papers or thesis about > the QOS in MANET specially which talk about the QOS simulation examples > in NS _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Mar 1 19:26:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21304 for ; Sat, 1 Mar 2003 19:26:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h220a7c11958 for manet-archive@odin.ietf.org; Sat, 1 Mar 2003 19:36:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h220a7p11955 for ; Sat, 1 Mar 2003 19:36:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21296 for ; Sat, 1 Mar 2003 19:26:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h220Kkp11428; Sat, 1 Mar 2003 19:20:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h220Bpp11223 for ; Sat, 1 Mar 2003 19:11:51 -0500 Received: from geranium.noc.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20955 for ; Sat, 1 Mar 2003 19:02:05 -0500 (EST) Received: from einstmob (ts18-69.dialup.bol.ucla.edu [169.232.227.82]) by geranium.noc.ucla.edu (8.12.5/8.12.5) with ESMTP id h2203ogc017912; Sat, 1 Mar 2003 16:03:59 -0800 From: "Mario Gerla" To: Cc: , Date: Sat, 1 Mar 2003 16:03:47 -0800 Organization: UCLA Message-ID: <001e01c2e04f$370d9370$52e3e8a9@einstmob> 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.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [manet] AINS 2003 submission deadline extended to March 7 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 colleague: Please find below the CFPs for the Autonomous Intelligent Networked Systems Symposium, Bologna, June 2003. Note that the abstract submission deadline has been extended to March 7 ------------------------------------------------ The Second Annual Symposium on Autonomous Intelligent Networks and Systems www.ains.cs.ucla.edu, http://path.berkeley.edu/ains At Santa Lucia Complex, Bologna, Italy June 30 to July 1, 2003. The goal of this annual symposium has been to explore and encourage research that would support the development of intelligent networks consisting of many autonmous agents, including UAV's, UGV's, or AUV's, interacting with the physical world in a distributed but coordinated fashion, and also to explore applications of such systems for defense, security, industrial control, environmental monitoring, and planetary exploration. As in the first symposium held last year at UCLA, this symposium will explore technological advances in a number of disciplines that would support such a vision; these include communications systems, collaborative robotic systems, battlefield networks, and neuro-biological systems. A major goal is to foster collaboration, on an international scale, through the identification of common models, tools and methodologies and of opportunities for collaboration among engineers and scientists working on related problems with different perspectives. This symposium will serve as a forum for intelligent agent technologists and visionaries from academia, industry and research labs. Papers may describe research or technology advances as well as ongoing prototyping efforts, experience reports, case studies, and descriptions of interesting systems. Submissions that describe future visions as well as practical technologies of significance and relevance to this area are encouraged. Papers, written in English, should not exceed 3000 words. Papers must be unpublished and must not be submitted for publication elsewhere. A selection of the papers will be published as a Reference Book. Authors should submit an extended abstract (max 3 pages), a complete list of authors and their affiliations, a contact person for correspondence, and e-mail addresses. Papers may be accepted either for oral or poster presentation. Both Abstract and Papers must be submitted in electronic form (PDF) to ainspapers@path.berkeley.edu. Topics include but are not limited to * Self-configuring agent-based wireless networks * Collaborative robotic systems, including large robotic "swarms" * Large-scale emergent behavior * Hierarchical system organizations and dynamic system re-organization * Systems informed by advances in neuro-biological networks * Distributed sensing and control networks * Cooperative behavior in natural and artificial systems * Software architecture for large-scale systems * Simulation of large scale distributed systems * Experimental platforms for the study of autonomous agents * Security in distributed systems * Fault tolerant distributed agent networks * Resource management in autonomous systems Important Dates * Electronic Abstract Submission March 7, 2003 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Mar 1 23:54:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24772 for ; Sat, 1 Mar 2003 23:54:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h22547E27837 for manet-archive@odin.ietf.org; Sun, 2 Mar 2003 00:04:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22547p27834 for ; Sun, 2 Mar 2003 00:04:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24763 for ; Sat, 1 Mar 2003 23:54:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224otp27128; Sat, 1 Mar 2003 23:50:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h224fep26891 for ; Sat, 1 Mar 2003 23:41:40 -0500 Received: from fep01-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24357 for ; Sat, 1 Mar 2003 23:31:50 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030302043334.ZXEB4812.fep01-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Sat, 1 Mar 2003 23:33:34 -0500 Message-ID: <3E61897C.9080604@ee.ryerson.ca> Date: Sat, 01 Mar 2003 23:33:00 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Sat, 1 Mar 2003 23:33:34 -0500 Content-Transfer-Encoding: 7bit Subject: [manet] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 10 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Mar 2 11:45:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14273 for ; Sun, 2 Mar 2003 11:45:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h22GsXI15838 for manet-archive@odin.ietf.org; Sun, 2 Mar 2003 11:54:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22GsXp15835 for ; Sun, 2 Mar 2003 11:54:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14265 for ; Sun, 2 Mar 2003 11:44:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22GeCp15277; Sun, 2 Mar 2003 11:40:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22GRdp14178 for ; Sun, 2 Mar 2003 11:27:39 -0500 Received: from mailer.cacs.louisiana.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13810 for ; Sun, 2 Mar 2003 11:17:34 -0500 (EST) Received: from wupc.cacs.louisiana.edu (wupc.cacs.louisiana.edu [130.70.76.5]) by mailer.cacs.louisiana.edu (8.11.3/8.11.3) with ESMTP id h22GJXq02667; Sun, 2 Mar 2003 10:19:33 -0600 (CST) Date: Sun, 2 Mar 2003 10:19:33 -0600 (CST) From: "Dr. Hongyi Wu" To: , In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Final CFP: VTC 2003 Symposium on Integrated Heterogeneous Wireless Networks Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , (We appologize if you received multiple copies of this Call.) CALL FOR PAPERS IEEE VTC 2003 Symposium on Integrated Heterogeneous Wireless Networks October 4-9, 2003 Hyatt Orlando Hotel Orlando, Florida, USA SYMPOSIUM CHAIR: Dr. Hongyi Wu The Center For Advanced Computer Studies University of Louisiana at Lafayette OVERVIEW Various wireless technologies and systems, such as Cellular System, Satellite System, Wireless Local Area Network (WLAN), Mobile Ad hoc Network (MANET), Bluetooth, Home RF Network, and the Sensor Network, have been developed over the years, and all signs are indicating that many more are yet to come. The emergence of these heterogeneous wireless technologies calls for the ubiquitous and integrated wireless infrastructures to make the communication system robust and efficient. While the existing wireless networks have been extensively studied individually, the integrated wireless system brings new challenges in system management, protocol design, performance evaluation, QoS support, etc. We are seeking for papers that are original, unpublished, and not currently under review by other conference, workshop, or journal. Topics of interest include, but are not limited to the following, with particular emphasis on the integration of heterogeneous wireless technologies: -System architecture -Interoperation between wired, terrestrial wireless and satellite networks -Hybrid cellular systems, wireless LANs, ad hoc/sensor networks, Bluetooth -Location, Mobility and Handoff Management -System modeling and performance evaluation -Applications -Protocol design, analysis, and optimization -Routing (including multicasting and broadcasting) -Energy efficient, self-organizing and resilient protocols -Medium access control protocols -TCP/IP over integrated wireless networks -Congestion, admission, and flow control -Quality of service in the hybrid networks -Implementation and testbed experiments SUBMISSION GUIDELINES Authors MUST submit a short abstract submission (approximately 150 words in the EDAS web site form) AND an extended abstract (up to 2 pages) also submitted through the EDAS web site. The extended abstracts are soft copy in MS Word or PDF file formats. The submission must include the name, complete mailing address, telephone and fax numbers, and the email address of the author(s). Extended abstracts should be submitted electronically (MS Word or PDF) by March 10, 2002. IMPORTANT DATES March 10, 2003: Last date for submission of abstracts May 15, 2003: Notification of acceptance July 15, 2003: Camera-ready version of accepted papers ======================================================================== Dr. Hongyi Wu, Assistant Professor The Center for Advanced Computer Studies (CACS) University of Louisiana (UL) at Lafayette P.O. Box 44330, Lafayette, LA 70504-4330, U.S.A. Tel: 337-482-5779, Fax: 337-482-5791 E-mail: wu@cacs.louisiana.edu http://www.cacs.louisiana.edu/~wu ======================================================================== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Mar 2 12:52:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15371 for ; Sun, 2 Mar 2003 12:52:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h22I2JJ20074 for manet-archive@odin.ietf.org; Sun, 2 Mar 2003 13:02:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22I2Jp20071 for ; Sun, 2 Mar 2003 13:02:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15366 for ; Sun, 2 Mar 2003 12:52:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22HnCp19367; Sun, 2 Mar 2003 12:49:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22HdBp19099 for ; Sun, 2 Mar 2003 12:39:11 -0500 Received: from mailgate5.cinetic.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14905 for ; Sun, 2 Mar 2003 12:29:05 -0500 (EST) Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id h22HV5E17465 for manet@ietf.org; Sun, 2 Mar 2003 18:31:05 +0100 Date: Sun, 2 Mar 2003 18:31:05 +0100 Message-Id: <200303021731.h22HV5E17465@mailgate5.cinetic.de> MIME-Version: 1.0 Organization: http://freemail.web.de/ From: Markus Schurius To: manet@ietf.org Precedence: fm-user Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] unsubscribe me Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ______________________________________________________________________________ Die SMS direkt auf's Handy. - Die Blitz-SMS bei WEB.DE FreeMail http://freemail.web.de/features/?mc=021165 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 3 05:02:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15148 for ; Mon, 3 Mar 2003 05:02:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23ACbI32672 for manet-archive@odin.ietf.org; Mon, 3 Mar 2003 05:12:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23ACbp32669 for ; Mon, 3 Mar 2003 05:12:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15099 for ; Mon, 3 Mar 2003 05:02:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h239xWp29598; Mon, 3 Mar 2003 04:59:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h239rSp28870 for ; Mon, 3 Mar 2003 04:53:28 -0500 Received: from mx.laposte.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13386 for ; Mon, 3 Mar 2003 04:43:01 -0500 (EST) Received: from laposte.net (127.0.0.1) by mx.laposte.net (6.0.053) id 3E493B3600311B30 for manet@ietf.org; Mon, 3 Mar 2003 10:45:02 +0100 Date: Mon, 3 Mar 2003 10:45:02 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?ghannay.sana@laposte.net?=" To: "=?iso-8859-1?Q?manet?=" X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 193.95.33.18 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h239rSp28871 Subject: [manet] =?iso-8859-1?Q?ad_hoc?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit hi all: I am student in Master making a research on routing protocole in adhoc networks : OLSR. and I don't have enough resources I need very quickly some web sites which includes papers or thesis about adhoc networks I will be grateful for who help me thanks alot yours sincerely: ghannay sana e-mail: ghannay.sana@laposte.net Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)" _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 3 06:24:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17119 for ; Mon, 3 Mar 2003 06:24:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23BYH106249 for manet-archive@odin.ietf.org; Mon, 3 Mar 2003 06:34:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23BYHp06246 for ; Mon, 3 Mar 2003 06:34:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17116 for ; Mon, 3 Mar 2003 06:23:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23BJRp05387; Mon, 3 Mar 2003 06:19:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23BDop05207 for ; Mon, 3 Mar 2003 06:13:50 -0500 Received: from jive.SoftHome.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16685 for ; Mon, 3 Mar 2003 06:03:23 -0500 (EST) Received: (qmail 21738 invoked by uid 417); 3 Mar 2003 11:05:23 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 3 Mar 2003 11:05:23 -0000 Received: from MAP11 ([203.145.171.34]) (AUTH: LOGIN ankurjain@softhome.net) by softhome.net with esmtp; Mon, 03 Mar 2003 04:05:17 -0700 Message-ID: <034801c2e1e5$cead00c0$2a01a8c0@MAP11> Reply-To: "Ankur Jain" From: "Ankur Jain" To: ghannay.sana@laposte.net Cc: manet@ietf.org Subject: Fw: [manet] ad hoc Date: Mon, 3 Mar 2003 16:34:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Checkout the following url: http://www.geocities.com/ankurjain009/links.htm Regards Ankur ----- Original Message ----- From: To: "manet" Sent: Monday, March 03, 2003 1:45 AM Subject: [manet] ad hoc > hi all: > > I am student in Master making a research on routing protocole > in adhoc networks : OLSR. and I don't have enough resources > I need very quickly some web sites which includes papers or > thesis about adhoc networks > > I will be grateful for who help me > thanks alot > > yours sincerely: > ghannay sana > e-mail: > ghannay.sana@laposte.net > > > Accédez au courrier électronique de La Poste : www.laposte.net ; > 3615 LAPOSTENET (0,34?/mn) ; tél : 08 92 68 13 50 (0,34?/mn)" > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 3 11:21:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01533 for ; Mon, 3 Mar 2003 11:21:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23GVDu31718 for manet-archive@odin.ietf.org; Mon, 3 Mar 2003 11:31:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23GVCp31715 for ; Mon, 3 Mar 2003 11:31:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01512 for ; Mon, 3 Mar 2003 11:20:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23G7kp30144; Mon, 3 Mar 2003 11:07:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23G2Up29104 for ; Mon, 3 Mar 2003 11:02:30 -0500 Received: from jay.mail.ku.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00444 for ; Mon, 3 Mar 2003 10:51:55 -0500 (EST) Received: by jay.mail.ku.edu with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Mar 2003 09:53:55 -0600 Message-ID: From: "Shantha, Raghavendra Vasanth" To: "'manet@ietf.org'" Date: Mon, 3 Mar 2003 09:53:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] documentation of the AODV code Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi I am looking for documentation of the AODV code by UPPSALA UNIV. Please let me know if anybody has a link to it. Thanks Raghu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 3 11:25: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 LAA01709 for ; Mon, 3 Mar 2003 11:25:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23GZpE32021 for manet-archive@odin.ietf.org; Mon, 3 Mar 2003 11:35:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23GZpp32018 for ; Mon, 3 Mar 2003 11:35:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01678 for ; Mon, 3 Mar 2003 11:25:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23GMRp31250; Mon, 3 Mar 2003 11:22:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23GJ1p31070 for ; Mon, 3 Mar 2003 11:19:01 -0500 Received: from meryl.it.uu.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01188 for ; Mon, 3 Mar 2003 11:08:26 -0500 (EST) Received: from nebulosa.it.uu.se (nebulosa.it.uu.se [130.238.8.24]) by meryl.it.uu.se (8.8.5/8.8.5) with ESMTP id RAA03234; Mon, 3 Mar 2003 17:10:18 +0100 (MET) Subject: Re: [manet] documentation of the AODV code From: Erik =?ISO-8859-1?Q?Nordstr=F6m?= To: "Shantha, Raghavendra "Vasanth Cc: "'manet@ietf.org'" In-Reply-To: References: Content-Type: text/plain Message-Id: <1046707817.25367.9.camel@nebulosa.it.uu.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Mar 2003 17:10:18 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit You can find a few sections about AODV-UU in the following thesis: http://www.csd.uu.se/courses/course-material/xjobb/docs-reports/Bjorn_Wiberg-2002.pdf Erik On Mon, 2003-03-03 at 16:53, Shantha, Raghavendra Vasanth wrote: > Hi > I am looking for documentation of the AODV code by UPPSALA UNIV. > Please let me know if anybody has a link to it. > > > Thanks > Raghu > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 3 13:57:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07639 for ; Mon, 3 Mar 2003 13:57:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23J7ex16488 for manet-archive@odin.ietf.org; Mon, 3 Mar 2003 14:07:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23J7ep16485 for ; Mon, 3 Mar 2003 14:07:40 -0500 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 NAA07612 for ; Mon, 3 Mar 2003 13:57:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23IpAp14336; Mon, 3 Mar 2003 13:51:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23IfPp13616 for ; Mon, 3 Mar 2003 13:41:25 -0500 Received: from po4.glue.umd.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06583 for ; Mon, 3 Mar 2003 13:30:44 -0500 (EST) Received: from y.glue.umd.edu (IDENT:root@y.glue.umd.edu [128.8.10.68]) by po4.glue.umd.edu (8.11.6/8.11.6) with ESMTP id h23IWgk04355; Mon, 3 Mar 2003 13:32:42 -0500 (EST) Received: from y.glue.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by y.glue.umd.edu (8.9.3/8.9.3) with SMTP id NAA02188; Mon, 3 Mar 2003 13:32:41 -0500 (EST) Received: from localhost (dineshd@localhost) by y.glue.umd.edu (8.9.3/8.9.3) with ESMTP id NAA02184; Mon, 3 Mar 2003 13:32:40 -0500 (EST) X-Authentication-Warning: y.glue.umd.edu: dineshd owned process doing -bs Date: Mon, 3 Mar 2003 13:32:40 -0500 (EST) From: Dinesh Dharmaraju To: Amr Ezzat cc: manet@ietf.org Subject: Re: [manet] QOS in MANET In-Reply-To: <000201c2dfc2$b5df8790$a90635d9@sfux.com> Message-ID: References: <000201c2dfc2$b5df8790$a90635d9@sfux.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi Amr, You might be interested in looking at INORA, a QoS scheme that uses INSIGNIA and TORA routing protocol. URL: http://bellatrix.isr.umd.edu/TechReports/CSHCN/2002/CSHCN_TR_2002-18/CSHCN_TR_2002-18.pdf Thanks, Dinesh On Sat, 1 Mar 2003, Amr Ezzat wrote: > hi all: > > I am an undergraduate student making a research on the QOS of the MANET > I don't have enough resources > I need very quickly some web sites which includes papers or thesis about the QOS in MANET > specially which talk about the QOS simulation examples in NS > > I will be grateful for who help me > thanks alot > > yours sincerely: > Eng./ Amr Ezzat > e-mail: > comm@gawab.com > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 3 17:27:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15166 for ; Mon, 3 Mar 2003 17:27:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23Mbu400811 for manet-archive@odin.ietf.org; Mon, 3 Mar 2003 17:37:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23Mbup00808 for ; Mon, 3 Mar 2003 17:37:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15156 for ; Mon, 3 Mar 2003 17:26:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23MLGp31686; Mon, 3 Mar 2003 17:21:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23MD2p31420 for ; Mon, 3 Mar 2003 17:13:02 -0500 Received: from c4.si.polymtl.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14576 for ; Mon, 3 Mar 2003 17:02:20 -0500 (EST) Received: (from nobody@localhost) by c4.si.polymtl.ca (8.11.6/8.11.6) id h23M4MC27145 for manet@ietf.org; Mon, 3 Mar 2003 17:04:22 -0500 Received: from 132.207.67.49 ( [132.207.67.49]) as user bemac@pop3.polymtl.ca by www.imp.polymtl.ca with HTTP; Mon, 3 Mar 2003 17:04:22 -0500 Message-ID: <1046729062.3e63d1669ab08@www.imp.polymtl.ca> Date: Mon, 3 Mar 2003 17:04:22 -0500 From: Benjamin Macabeo To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 132.207.67.49 Content-Transfer-Encoding: 8bit Subject: [manet] NODE_TRAVERSAL_TIME in AODV Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hello, I have read in AODV draft 13 that the value of NODE_TRAVERSAL_TIME parameter was 40 milliseconds. I run a simulation of AODV with this parameter set to this value. The problem is that when a node tries to find a route to another node which is unreachable, the initiator node waits for a RREP message during more than 0.6s (which is very long to my mind) before sending RREQs. Is it normal to wait such a long time before? best regards Benjamin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 3 21:00:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20929 for ; Mon, 3 Mar 2003 21:00:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h242AdM14340 for manet-archive@odin.ietf.org; Mon, 3 Mar 2003 21:10:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h242Adp14337 for ; Mon, 3 Mar 2003 21:10:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20906 for ; Mon, 3 Mar 2003 20:59:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h241vPp12842; Mon, 3 Mar 2003 20:57:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h241pYp12679 for ; Mon, 3 Mar 2003 20:51:34 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20493 for ; Mon, 3 Mar 2003 20:40:42 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.2+Sun/8.12.2) with ESMTP id h241hNX4010639 for ; Tue, 4 Mar 2003 09:43:23 +0800 (SGT) Received: from bkdom-MTA by mailer.icr.a-star.edu.sg with Novell_GroupWise; Tue, 04 Mar 2003 09:36:02 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Tue, 04 Mar 2003 09:35:52 +0800 From: "Tan Kean Soon" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h241pYp12680 Subject: [manet] Seeking Ananas Ad-hoc System know-hows & Zero configuration 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: 8bit Content-Transfer-Encoding: 8bit Hi, Has anyone use the Ananas ad-hoc system by INRIA before? Would appreciate those who have used and tested the system can provide some information on how to configure and test it out? Also, any feedback on it's feature (positive or otherwise :-) ) would be very much appreciated. Also, I am looking into the area of automated/intelligent routing protocol discovery/selection/installation, which should be a part of the zero-configuration subgroup. Any suggestion as to it practicality, viability and if there is any draft or implementation/simulation pertaining to it would be very much appreciated. Thanks. Regards, Kean Soon _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 4 04:31:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10215 for ; Tue, 4 Mar 2003 04:31:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h249flt20057 for manet-archive@odin.ietf.org; Tue, 4 Mar 2003 04:41:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249flp20054 for ; Tue, 4 Mar 2003 04:41:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10197 for ; Tue, 4 Mar 2003 04:30:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249HPp17960; Tue, 4 Mar 2003 04:17:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h249Cbp17777 for ; Tue, 4 Mar 2003 04:12:37 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09574 for ; Tue, 4 Mar 2003 04:01:37 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.2+Sun/8.12.2) with ESMTP id h2494EX4016639 for ; Tue, 4 Mar 2003 17:04:14 +0800 (SGT) Received: from bkdom-MTA by mailer.icr.a-star.edu.sg with Novell_GroupWise; Tue, 04 Mar 2003 16:56:53 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Tue, 04 Mar 2003 16:56:33 +0800 From: "Tan Kean Soon" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h249Ccp17778 Subject: [manet] Adhoc with Mobile IPV4 connectivity Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Is there any implementation of Adhoc network which support Mobile IP v4 or v6 ? Came across MEWLANA and MART, but, I think these are not open source. Has anyone implemented the MIPMANET method with any of the Mobile IPv4 implementation such as HUT Dynamic Mobile IPv4 or MIPL (IPv6). Would appreciate any feedback on this matter. Thanks in advance... Regards, KS _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 4 11:52:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00844 for ; Tue, 4 Mar 2003 11:52:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24H3Dr20707 for manet-archive@odin.ietf.org; Tue, 4 Mar 2003 12:03:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24H3Dp20704 for ; Tue, 4 Mar 2003 12:03:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00795 for ; Tue, 4 Mar 2003 11:52:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24Gmlp19161; Tue, 4 Mar 2003 11:48:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GgCp18926 for ; Tue, 4 Mar 2003 11:42:12 -0500 Received: from send.nc.u-tokyo.ac.jp (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29422 for ; Tue, 4 Mar 2003 11:31:07 -0500 (EST) Received: from arten12.nc.u-tokyo.ac.jp (arten12.nc.u-tokyo.ac.jp [133.11.119.42]) by send.nc.u-tokyo.ac.jp (8.12.8/3.7W) with SMTP id BAA20946 for ; Wed, 5 Mar 2003 01:33:48 +0900 (JST) Received: from chamomile.mlab.t.u-tokyo.ac.jp ([133.11.236.1]) by arten12.nc.u-tokyo.ac.jp (NAVGW 2.5.1.18) with SMTP id M2003030501330815906 for ; Wed, 05 Mar 2003 01:33:08 +0900 Received: (qmail 4847 invoked from network); 4 Mar 2003 16:33:08 -0000 Received: from unknown (HELO sunflower.mlab.t.u-tokyo.ac.jp) (192.168.1.1) by 133.11.236.1 with SMTP; 4 Mar 2003 16:33:08 -0000 Received: (qmail 15498 invoked by alias); 4 Mar 2003 16:33:07 -0000 Received: (qmail 15491 invoked from network); 4 Mar 2003 16:33:07 -0000 Received: from unknown (HELO MORI-T30.mlab.t.u-tokyo.ac.jp) (192.168.1.104) by sunflower.mlab.t.u-tokyo.ac.jp with SMTP; 4 Mar 2003 16:33:07 -0000 Message-Id: <5.0.2.7.2.20030305013239.06f36ac0@pop.mlab.t.u-tokyo.ac.jp> X-Sender: mori@pop.mlab.t.u-tokyo.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 Date: Wed, 05 Mar 2003 01:32:40 +0900 To: manet@ietf.org From: Hiroyuki Morikawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] Reminder -- MobiCom 2003 paper registration deadline March 5 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 just a reminder that the deadline for registering papers for submission to MobiCom 2003, Ninth Annual International Conference on Mobile Computing and Networking, is this Wednesday, March 5, 2003. All papers must be registered by 11:59 PM PST (US Pacific timezone) on March 5. Registering a paper involves entering the paper's - title, - abstract, - author information, and - topic areas into the MobiCom 2003 EDAS web-based paper submission system. For more information on paper registration and submission for MobiCom 2003, please see the Call for Papers at http://www.sigmobile.org/mobicom/2003/cfp.html and the detailed submission instructions at http://www.sigmobile.org/mobicom/2003/submit.html Once you have registered your paper in this way by the March 5 deadline above, the deadline for then actually submitting the paper is Wednesday, March 12, at 11:59 PM PST (US Pacific timezone). Hiro _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 5 16:29:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29965 for ; Wed, 5 Mar 2003 16:29:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25LedZ23677 for manet-archive@odin.ietf.org; Wed, 5 Mar 2003 16:40:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LedO23670 for ; Wed, 5 Mar 2003 16:40:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29927 for ; Wed, 5 Mar 2003 16:29:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LKPO21070; Wed, 5 Mar 2003 16:20:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25LCpO20653 for ; Wed, 5 Mar 2003 16:12:51 -0500 Received: from xmxpita.excite.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28326 for ; Wed, 5 Mar 2003 16:01:39 -0500 (EST) Received: by xmxpita.excite.com (Postfix, from userid 110) id 5C2BD133C4; Wed, 5 Mar 2003 16:03:40 -0500 (EST) To: manet@ietf.org Received: from [204.198.72.206] by xprdmailfe5.nwk.excite.com via HTTP; Wed, 05 Mar 2003 16:03:40 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = 89659a7ff4ddd332408b0a759a1a101b Reply-To: jw2000@excite.com From: "Jack Wang" MIME-Version: 1.0 X-Sender: jw2000@excite.com X-Mailer: PHP Content-Type: multipart/alternative; boundary="EXCITEBOUNDARY_000__291d8d4e51276652d6baf27670d09e14"; Content-Transfer-Encoding: 7bit Message-Id: <20030305210340.5C2BD133C4@xmxpita.excite.com> Date: Wed, 5 Mar 2003 16:03:40 -0500 (EST) Subject: [manet] Questions about simulation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --EXCITEBOUNDARY_000__291d8d4e51276652d6baf27670d09e14 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All: I am doing some research on security of Ad Hoc networks. And I want to do some simulation, e.g., on key management, secure routing. But I never do simulation before. Could someone give me some suggestion? How should I start? Which simulation software sould I use, NS2 or GloMoSim?Many thanks in advance. Sincerely, Jack _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! --EXCITEBOUNDARY_000__291d8d4e51276652d6baf27670d09e14 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hi All:

I am doing some research on security of Ad Hoc networks. And I want to do some simulation, e.g., on key management, secure routing. But I never do simulation before. Could someone give me some suggestion? How should I start? Which simulation software sould I use, NS2 or GloMoSim?
Many thanks in advance.

Sincerely,

Jack




Join Excite! - http://www.excite.com
The most personalized portal on the Web! --EXCITEBOUNDARY_000__291d8d4e51276652d6baf27670d09e14-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 03:48:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28571 for ; Thu, 6 Mar 2003 03:48:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h268xVa14334 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 03:59:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h268xUO14331 for ; Thu, 6 Mar 2003 03:59:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28567 for ; Thu, 6 Mar 2003 03:48:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h268ffO13500; Thu, 6 Mar 2003 03:41:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h268Z2O12536 for ; Thu, 6 Mar 2003 03:35:02 -0500 Received: from x86unx3.comp.nus.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28057 for ; Thu, 6 Mar 2003 03:23:34 -0500 (EST) Received: from e500a.comp.nus.edu.sg (e500a.comp.nus.edu.sg [137.132.90.23]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id QAA13077 for ; Thu, 6 Mar 2003 16:25:34 +0800 (GMT-8) From: Er Inn Inn Received: from se11.comp.nus.edu.sg(137.132.80.19) by e500a.comp.nus.edu.sg via csmap id 9066; Thu, 06 Mar 2003 16:24:30 +0800 (SGT) Received: (from http@localhost) by se11.comp.nus.edu.sg (8.12.2+Sun/8.12.5) id h268PYDq003744; Thu, 6 Mar 2003 16:25:34 +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 137.132.31.162) (SquirrelMail authenticated user erinninn) by mysoc.nus.edu.sg with HTTP; Thu, 6 Mar 2003 16:25:34 +0800 (SGT) Message-ID: <4712.137.132.80.35.1046939134.squirrel@mysoc.nus.edu.sg> Date: Thu, 6 Mar 2003 16:25:34 +0800 (SGT) To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [manet] Some Questions on MANET multicast routing protocols Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I am wondering whether we can classified the existing multicast routing protocol into 2 groups: Proactive and Reactive, as in unicast routing protocol. I have read some paper that classified the multicast protocols into whether on-demand or proactive. How to differentiate which protocol is on-demand and which one is proactive. As far as I understand, as long as the multicast tree or multicast mesh is built when it is needed (there is data to be sent) or it is initiated by the source, we may classify it as reactive protocol. Is this theory holds? What are the examples of proactive multicast routing protocol? Is AMRoute one of the examples of proactive multicast routing protocol? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 03:53: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 DAA28676 for ; Thu, 6 Mar 2003 03:53:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2694AV14850 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 04:04:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26949O14847 for ; Thu, 6 Mar 2003 04:04:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28670 for ; Thu, 6 Mar 2003 03:52:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h268lTO13672; Thu, 6 Mar 2003 03:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h268cwO13409 for ; Thu, 6 Mar 2003 03:38:58 -0500 Received: from x86unx3.comp.nus.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28134 for ; Thu, 6 Mar 2003 03:27:20 -0500 (EST) Received: from e500a.comp.nus.edu.sg (e500a.comp.nus.edu.sg [137.132.90.23]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id QAA13221 for ; Thu, 6 Mar 2003 16:29:08 +0800 (GMT-8) From: Er Inn Inn Received: from se11.comp.nus.edu.sg(137.132.80.19) by e500a.comp.nus.edu.sg via csmap id 9419; Thu, 06 Mar 2003 16:28:05 +0800 (SGT) Received: (from http@localhost) by se11.comp.nus.edu.sg (8.12.2+Sun/8.12.5) id h268T8dv003960; Thu, 6 Mar 2003 16:29:08 +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 137.132.31.162) (SquirrelMail authenticated user erinninn) by mysoc.nus.edu.sg with HTTP; Thu, 6 Mar 2003 16:29:08 +0800 (SGT) Message-ID: <1179.137.132.80.35.1046939348.squirrel@mysoc.nus.edu.sg> Date: Thu, 6 Mar 2003 16:29:08 +0800 (SGT) To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [manet] Some questions on multicast routing protocols Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I am wondering whether we can classified the existing multicast routing protocol into 2 groups: Proactive and Reactive, as in unicast routing protocol. I have read some paper that classified the multicast protocols into whether on-demand or proactive. How to differentiate which protocol is on-demand and which one is proactive. As far as I understand, as long as the multicast tree or multicast mesh is built when it is needed (there is data to be sent) or it is initiated by the source, we may classify it as reactive protocol. Is this theory holds? What are the examples of proactive multicast routing protocol? Is AMRoute one of the examples of proactive multicast routing protocol? Thanks in advance! regards, inn inn _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 07:54:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10262 for ; Thu, 6 Mar 2003 07:54:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26D5Xj00978 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 08:05:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26D5XO00975 for ; Thu, 6 Mar 2003 08:05:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10245 for ; Thu, 6 Mar 2003 07:54:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26CnNO32502; Thu, 6 Mar 2003 07:49:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26ChYO32271 for ; Thu, 6 Mar 2003 07:43:34 -0500 Received: from mailout3.samsung.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08958 for ; Thu, 6 Mar 2003 07:32:01 -0500 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HBB00B01UUOK3@mailout3.samsung.com> for manet@ietf.org; Thu, 06 Mar 2003 21:32:48 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HBB006PJUUO4A@mailout3.samsung.com> for manet@ietf.org; Thu, 06 Mar 2003 21:32:48 +0900 (KST) Received: from Shubhranshu ([75.2.41.168]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HBB001HEVJE8J@mmp2.samsung.com> for manet@ietf.org; Thu, 06 Mar 2003 21:47:38 +0900 (KST) Date: Thu, 06 Mar 2003 21:29:52 -0800 From: Shubhranshu Subject: Re: [manet] Some Questions on MANET multicast routing protocols To: Er Inn Inn , manet@ietf.org Reply-to: Shubhranshu Message-id: <01fe01c2e46a$948118f0$a829024b@Shubhranshu> Organization: Samsung MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4712.137.132.80.35.1046939134.squirrel@mysoc.nus.edu.sg> 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 ----- Original Message ----- From: "Er Inn Inn" > I am wondering whether we can classified the existing multicast > routing protocol into 2 groups: Proactive and Reactive, as in unicast > routing protocol. I have read some paper that classified the multicast > protocols into whether on-demand or proactive. How to differentiate > which protocol is on-demand and which one is proactive. As far as I > understand, as long as the multicast tree or multicast mesh is built > when it is needed (there is data to be sent) or it is initiated by the > source, we may classify it as reactive protocol. Is this theory holds? > What are the examples of proactive multicast routing protocol? Is > AMRoute one of the examples of proactive multicast routing protocol? > REACTIVE : makes on-demand searches for a path e.g AODV, DSR, ZRP PROACTIVE: constantly updates the routing table at each node to maintain a nearly global view on the network topology e.g DSDV Warm Regards Shubhranshu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 08:51:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14533 for ; Thu, 6 Mar 2003 08:51:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26E2AX05648 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 09:02:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26E2AO05645 for ; Thu, 6 Mar 2003 09:02:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14488 for ; Thu, 6 Mar 2003 08:50:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26DlNO04626; Thu, 6 Mar 2003 08:47:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Dg3O04435 for ; Thu, 6 Mar 2003 08:42:03 -0500 Received: from x86unx3.comp.nus.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13031 for ; Thu, 6 Mar 2003 08:30:28 -0500 (EST) 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 VAA28593 for ; Thu, 6 Mar 2003 21:32:30 +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 22369; Thu, 06 Mar 2003 21:26:32 +0800 (SGT) Received: (from http@localhost) by se11.comp.nus.edu.sg (8.12.2+Sun/8.12.5) id h26DWUdI015224; Thu, 6 Mar 2003 21:32:30 +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 137.132.31.162) (SquirrelMail authenticated user erinninn) by mysoc.nus.edu.sg with HTTP; Thu, 6 Mar 2003 21:32:30 +0800 (SGT) Message-ID: <1138.137.132.80.35.1046957550.squirrel@mysoc.nus.edu.sg> Date: Thu, 6 Mar 2003 21:32:30 +0800 (SGT) Subject: [manet] Some questions on multicast routing protocols] To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Thanks for the explaination. However, they are all unicast routing protocols. How about multicast routing protocol? Almost all proposed multicast protocols (for MANET) built the multicast tree or mesh when there are senders that wish to initiate multicast session... So could I classify them as on-demand? I know that most of them need an underlying unicast protocol. Those protocol maybe on-demand or proactive. Therefore, I am wondering whether the classification to proactive or reactive classes is not suitable for classifying multicast routing protocols? regards, inn inn > ----- Original Message ----- > From: "Er Inn Inn" > >> I am wondering whether we can classified the existing multicast >> routing protocol into 2 groups: Proactive and Reactive, as in unicast >> routing protocol. I have read some paper that classified the >> multicast protocols into whether on-demand or proactive. How to >> differentiate which protocol is on-demand and which one is proactive. >> As far as I understand, as long as the multicast tree or multicast >> mesh is built when it is needed (there is data to be sent) or it is >> initiated by the source, we may classify it as reactive protocol. Is >> this theory holds? What are the examples of proactive multicast >> routing protocol? Is AMRoute one of the examples of proactive >> multicast routing protocol? > > > REACTIVE : makes on-demand searches for a > path e.g AODV, DSR , ZRP > > PROACTIVE : constantly updates the routing > table at each node to maintain a nearly global > view on the network topology e.g DSDV > > Warm Regards > Shubhranshu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 09:54:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17699 for ; Thu, 6 Mar 2003 09:54:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26F5is10718 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 10:05:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26F5iO10715 for ; Thu, 6 Mar 2003 10:05:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17665 for ; Thu, 6 Mar 2003 09:54:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26EhTO09314; Thu, 6 Mar 2003 09:43:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26EccO09115 for ; Thu, 6 Mar 2003 09:38:38 -0500 Received: from concorde.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16514 for ; Thu, 6 Mar 2003 09:27:04 -0500 (EST) Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h26ESXT21780; Thu, 6 Mar 2003 15:28:33 +0100 (MET) Message-ID: <006701c2e3f0$c94cb960$1f175d80@inria.fr> From: "Philippe Jacquet" To: "Er Inn Inn" , References: <1138.137.132.80.35.1046957550.squirrel@mysoc.nus.edu.sg> Subject: Re: [manet] Some questions on multicast routing protocols] Date: Thu, 6 Mar 2003 15:58:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There exists MOLSR http://hipercom.inria.fr/olsr/draft-ietf-manet-olsr-molsr.txt, a multicast protocol based on the proactive protocol OLSR. There is also the protocol XMAN http://scholar.lib.vt.edu/theses/available/etd-08142002-131727/. I don't know about a multicast version of DSDV On the reactive side, there is MAODV and a multicast version of DSR Philippe ----- Original Message ----- From: Er Inn Inn To: Sent: Thursday, March 06, 2003 2:32 PM Subject: [manet] Some questions on multicast routing protocols] > > Hi, > > Thanks for the explaination. However, they are all unicast routing > protocols. How about multicast routing protocol? Almost all proposed > multicast protocols (for MANET) built the multicast tree or mesh when > there are senders that wish to initiate multicast session... So could I > classify them as on-demand? I know that most of them need an > underlying unicast protocol. Those protocol maybe on-demand or > proactive. Therefore, I am wondering whether the classification to > proactive or reactive classes is not suitable for classifying > multicast routing protocols? > > > > regards, > inn inn > > > > ----- Original Message ----- > > From: "Er Inn Inn" > > > >> I am wondering whether we can classified the existing multicast > >> routing protocol into 2 groups: Proactive and Reactive, as in unicast > >> routing protocol. I have read some paper that classified the > >> multicast protocols into whether on-demand or proactive. How to > >> differentiate which protocol is on-demand and which one is proactive. > >> As far as I understand, as long as the multicast tree or multicast > >> mesh is built when it is needed (there is data to be sent) or it is > >> initiated by the source, we may classify it as reactive protocol. Is > >> this theory holds? What are the examples of proactive multicast > >> routing protocol? Is AMRoute one of the examples of proactive > >> multicast routing protocol? > > > > > > REACTIVE : makes on-demand searches for a > > path e.g AODV, DSR , ZRP > > > > PROACTIVE : constantly updates the routing > > table at each node to maintain a nearly global > > view on the network topology e.g DSDV > > > > Warm Regards > > Shubhranshu > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 11:11:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23710 for ; Thu, 6 Mar 2003 11:11:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26GMll18958 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 11:22:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GMlO18955 for ; Thu, 6 Mar 2003 11:22:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23678 for ; Thu, 6 Mar 2003 11:11:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26G59O16333; Thu, 6 Mar 2003 11:05:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26FulO15878 for ; Thu, 6 Mar 2003 10:56:47 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21478; Thu, 6 Mar 2003 10:45:12 -0500 (EST) Message-Id: <200303061545.KAA21478@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: manet@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Mar 2003 10:45:12 -0500 Subject: [manet] I-D ACTION:draft-ietf-manet-olsr-08.txt Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Optimized Link State Routing Protocol Author(s) : C. Adjih, T. Clausen, P. Jacquet et. al. Filename : draft-ietf-manet-olsr-08.txt Pages : 72 Date : 2003-3-5 This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs) [1], [2]. MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used by for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsr-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-olsr-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-olsr-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-5185502.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-olsr-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-olsr-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5185502.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 11:52:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27774 for ; Thu, 6 Mar 2003 11:52:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26H3JT22493 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 12:03:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26H3JO22490 for ; Thu, 6 Mar 2003 12:03:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27730 for ; Thu, 6 Mar 2003 11:51:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Gm6O21376; Thu, 6 Mar 2003 11:48:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GeAO20936 for ; Thu, 6 Mar 2003 11:40:10 -0500 Received: from mailserver2.opnet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25090 for ; Thu, 6 Mar 2003 11:28:29 -0500 (EST) Received: from wtn11019 (wtn11019.opnet.com [172.16.11.19]) by mailserver2.opnet.com (8.12.8/8.12.6) with ESMTP id h26GU8rB003754; Thu, 6 Mar 2003 11:30:08 -0500 (EST) Message-Id: <4.2.0.58.20030306112920.00acfb50@mailserver.opnet.com> X-Sender: krao@mailserver.opnet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 06 Mar 2003 11:30:08 -0500 To: "Philippe Jacquet" , "Er Inn Inn" , From: Kartik Rao Subject: Re: [manet] Some questions on multicast routing protocols] In-Reply-To: <006701c2e3f0$c94cb960$1f175d80@inria.fr> References: <1138.137.132.80.35.1046957550.squirrel@mysoc.nus.edu.sg> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MailScanner: Found to be clean Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Philippe, Do you know where I can find the draft for multicast version of DSR? Thanks, Kartik At 03:58 PM 3/6/03 +0100, Philippe Jacquet wrote: >There exists MOLSR >http://hipercom.inria.fr/olsr/draft-ietf-manet-olsr-molsr.txt, a multicast >protocol based on the proactive protocol OLSR. There is also the protocol >XMAN http://scholar.lib.vt.edu/theses/available/etd-08142002-131727/. > >I don't know about a multicast version of DSDV > >On the reactive side, there is MAODV and a multicast version of DSR > >Philippe >----- Original Message ----- >From: Er Inn Inn >To: >Sent: Thursday, March 06, 2003 2:32 PM >Subject: [manet] Some questions on multicast routing protocols] > > > > > > Hi, > > > > Thanks for the explaination. However, they are all unicast routing > > protocols. How about multicast routing protocol? Almost all proposed > > multicast protocols (for MANET) built the multicast tree or mesh when > > there are senders that wish to initiate multicast session... So could I > > classify them as on-demand? I know that most of them need an > > underlying unicast protocol. Those protocol maybe on-demand or > > proactive. Therefore, I am wondering whether the classification to > > proactive or reactive classes is not suitable for classifying > > multicast routing protocols? > > > > > > > > regards, > > inn inn > > > > > > > ----- Original Message ----- > > > From: "Er Inn Inn" > > > > > >> I am wondering whether we can classified the existing multicast > > >> routing protocol into 2 groups: Proactive and Reactive, as in unicast > > >> routing protocol. I have read some paper that classified the > > >> multicast protocols into whether on-demand or proactive. How to > > >> differentiate which protocol is on-demand and which one is proactive. > > >> As far as I understand, as long as the multicast tree or multicast > > >> mesh is built when it is needed (there is data to be sent) or it is > > >> initiated by the source, we may classify it as reactive protocol. Is > > >> this theory holds? What are the examples of proactive multicast > > >> routing protocol? Is AMRoute one of the examples of proactive > > >> multicast routing protocol? > > > > > > > > > REACTIVE : makes on-demand searches for a > > > path e.g AODV, DSR , ZRP > > > > > > PROACTIVE : constantly updates the routing > > > table at each node to maintain a nearly global > > > view on the network topology e.g DSDV > > > > > > Warm Regards > > > Shubhranshu > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 12:01:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28598 for ; Thu, 6 Mar 2003 12:01:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HCco24035 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 12:12:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HCcO24032 for ; Thu, 6 Mar 2003 12:12:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28541 for ; Thu, 6 Mar 2003 12:01:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GuKO22083; Thu, 6 Mar 2003 11:56:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GjXO21200 for ; Thu, 6 Mar 2003 11:45:33 -0500 Received: from gs46.sp.cs.cmu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25269 for ; Thu, 6 Mar 2003 11:33:56 -0500 (EST) Received: from gs46.sp.cs.cmu.edu ([127.0.0.1]) by gs46.sp.cs.cmu.edu id aa13154; 6 Mar 2003 11:35 EST Date: Thu, 6 Mar 2003 11:35:42 -0500 (EST) From: Jorjeta Gueorguieva Jetcheva X-Sender: jorjeta+@gs46.sp.cs.cmu.edu To: manet@ietf.org cc: jorjeta@cs.cmu.edu Subject: Re: [manet] Some questions on multicast routing protocols] 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: , There have been many protocol proposals for multicast. Most of them include both proactive and reactive mechanisms. Proactive mechanisms are ones that rely on periodic control packet transmissions such as neighbor detection and periodic flooding. Routing functionality can roughly be divided into two parts: route discovery and route maintenance. Most multicast routing protocols perform the route discovery part on-demand and most perform the route maintenance part proactively, e.g., they use periodic neighbor detection packets, or refresh the multicast state periodically. As far as I am aware, the only general-purpose multicast protocol that performs both route discovery and maintenance on-demand is ADMR. By general-purpose, I mean a protocol that is not meant to only operate with multicast groups of a limited size, or in small networks (e.g., DDM, which encodes all receivers for the multicast group in the packet header). A description and evaluation of ADMR along with a brief classification of multicast protocols according to whether they use reactive or on-demand mechanisms is described in the following paper: --- Jorjeta G. Jetcheva and David B. Johnson. Adaptive Demand-Driven Multicast Routing in Multi-Hop Wireless Ad Hoc Networks. Proceedings of the 2001 ACM International Symposium on Mobile Ad Hoc Networking & Computing (MobiHoc 2001), pp. 33-44, ACM, Long Beach, CA, October, 2001. --- You can download this paper from http://www.monarch.cs.rice.edu/papers.html. > I know that most of them need an underlying unicast protocol. Those > protocol maybe on-demand or proactive. Actually, many multicast protocols do not require a unicast protocol. If a protocol relies on an underlying unicast protocol and cannot be made to work with an on-demand unicast protocol, I'd classify it as proactive. Jorjeta ------------------------------------------------------------------------ There exists MOLSR http://hipercom.inria.fr/olsr/draft-ietf-manet-olsr-molsr.txt, a multicast protocol based on the proactive protocol OLSR. There is also the protocol XMAN http://scholar.lib.vt.edu/theses/available/etd-08142002-131727/. I don't know about a multicast version of DSDV On the reactive side, there is MAODV and a multicast version of DSR Philippe ----- Original Message ----- From: Er Inn Inn To: Sent: Thursday, March 06, 2003 2:32 PM Subject: [manet] Some questions on multicast routing protocols] > > Hi, > > Thanks for the explaination. However, they are all unicast routing > protocols. How about multicast routing protocol? Almost all proposed > multicast protocols (for MANET) built the multicast tree or mesh when > there are senders that wish to initiate multicast session... So could I > classify them as on-demand? I know that most of them need an > underlying unicast protocol. Those protocol maybe on-demand or > proactive. Therefore, I am wondering whether the classification to > proactive or reactive classes is not suitable for classifying > multicast routing protocols? > > > > regards, > inn inn > > > > ----- Original Message ----- > > From: "Er Inn Inn" > > > >> I am wondering whether we can classified the existing multicast > >> routing protocol into 2 groups: Proactive and Reactive, as in unicast > >> routing protocol. I have read some paper that classified the > >> multicast protocols into whether on-demand or proactive. How to > >> differentiate which protocol is on-demand and which one is proactive. > >> As far as I understand, as long as the multicast tree or multicast > >> mesh is built when it is needed (there is data to be sent) or it is > >> initiated by the source, we may classify it as reactive protocol. Is > >> this theory holds? What are the examples of proactive multicast > >> routing protocol? Is AMRoute one of the examples of proactive > >> multicast routing protocol? > > > > > > REACTIVE : makes on-demand searches for a > > path e.g AODV, DSR , ZRP > > PROACTIVE : constantly updates the routing > > table at each node to maintain a nearly global > > view on the network topology e.g DSDV > > > > Warm Regards > > Shubhranshu > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= o j r e a o = o j t = o o = = o Jorjeta G. Jetcheva o = Ph.D. student, Computer Science = o Carnegie Mellon University o = = o http://www.cs.cmu.edu/~jorjeta o =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 12:07:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28962 for ; Thu, 6 Mar 2003 12:07:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26HIGO24506 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 12:18:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26HIGO24503 for ; Thu, 6 Mar 2003 12:18:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28942 for ; Thu, 6 Mar 2003 12:06:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26H3FO22482; Thu, 6 Mar 2003 12:03:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26GjxO21215 for ; Thu, 6 Mar 2003 11:45:59 -0500 Received: from dire.bris.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25324 for ; Thu, 6 Mar 2003 11:34:22 -0500 (EST) Received: from sis.bris.ac.uk by dire.bris.ac.uk with SMTP-PRIV with ESMTP; Thu, 6 Mar 2003 16:36:23 +0000 Received: from EEN9097.een.bris.ac.uk (een9097.een.bris.ac.uk [137.222.189.97]) by sis.bris.ac.uk (8.11.6/8.11.6) with ESMTP id h26GYWT00499 for ; Thu, 6 Mar 2003 16:34:32 GMT Date: Thu, 06 Mar 2003 16:34:32 -0000 From: "D Kothris, Electrical & Electronic Engineering" To: manet@ietf.org Message-ID: <1224929395.1046968472@EEN9097.een.bris.ac.uk> Originator-Info: login-token=Mulberry:01a1qMq8/FxeJrkNIKpczKuR6o0cAGndmI7h2fzsACm5nP9w==; token_authority=postmaster@bristol.ac.uk X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [manet] PhD Thesis Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi , I would like to build an archive of PhD or Master's thesis which deal primarily with issues related to ad hoc / sensor networks. In the near future I hope to host my own website, where this archive will also reside, for the benefit of all. Would anyone like to contribute or point out some? Regards Dimos ---------------------- D Kothris, Electrical & Electronic Engineering D.Kothris@bristol.ac.uk _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 13:49:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06012 for ; Thu, 6 Mar 2003 13:49:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26J0sG03157 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 14:00:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26J0sO03154 for ; Thu, 6 Mar 2003 14:00:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05987 for ; Thu, 6 Mar 2003 13:49:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26IhwO01849; Thu, 6 Mar 2003 13:43:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26Ia7O00721 for ; Thu, 6 Mar 2003 13:36:07 -0500 Received: from SMTP1.ECE.NEU.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04757 for ; Thu, 6 Mar 2003 13:24:28 -0500 (EST) Received: from calvin.ece.neu.edu (calvin.ece.neu.edu [129.10.62.61]) by SMTP1.ECE.NEU.EDU (8.12.5/8.12.5) with SMTP id h26IQQRF014398; Thu, 6 Mar 2003 13:26:30 -0500 (EST) Received: from bibbiena.ece.neu.edu ([129.10.60.216]) by calvin.ece.neu.edu (SAVSMTP 3.0.0.44) with SMTP id M2003030613263003488 ; Thu, 06 Mar 2003 13:26:30 -0500 Received: from localhost (basagni@localhost) by bibbiena.ece.neu.edu (8.11.6+Sun/8.9.3) with ESMTP id h26IQUM20585; Thu, 6 Mar 2003 13:26:30 -0500 (EST) X-Authentication-Warning: bibbiena.ece.neu.edu: basagni owned process doing -bs Date: Thu, 6 Mar 2003 13:26:30 -0500 (EST) From: Stefano Basagni X-X-Sender: basagni@bibbiena To: "D Kothris, Electrical & Electronic Engineering" cc: manet@ietf.org Subject: Re: [manet] PhD Thesis In-Reply-To: <1224929395.1046968472@EEN9097.een.bris.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi, this type of archive (actually extended to mobile nets and computing) is already maintained by the ACM sigmobile. It actually contains only Ph.D. thesis. (www.sigmobile.org/phd/index.html) Cheers, St. -- Stefano Basagni, Ph.D. Assistant Professor of Computer Engineering Dept. of Electrical and Computer Engineering 312 Dana Research Center Northeastern University 360 Huntington Ave. Boston, MA 02115 Tel. 617 373 3061, Fax 617 373 8970 E-mail: basagni@ece.neu.edu *** http://www.ece.neu.edu/faculty/basagni/ *** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 20:22:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22988 for ; Thu, 6 Mar 2003 20:22:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h271Xf603486 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 20:33:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271XfO03483 for ; Thu, 6 Mar 2003 20:33:41 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22947 for ; Thu, 6 Mar 2003 20:21:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h271H0O02454; Thu, 6 Mar 2003 20:17:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2718tO02295 for ; Thu, 6 Mar 2003 20:08:55 -0500 Received: from x86unx3.comp.nus.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22217 for ; Thu, 6 Mar 2003 19:57:06 -0500 (EST) Received: from e500a.comp.nus.edu.sg (e500a.comp.nus.edu.sg [137.132.90.23]) by x86unx3.comp.nus.edu.sg (8.9.1/8.9.1) with SMTP id IAA01816; Fri, 7 Mar 2003 08:59:09 +0800 (GMT-8) From: Er Inn Inn Received: from se11.comp.nus.edu.sg(137.132.80.19) by e500a.comp.nus.edu.sg via csmap id 16311; Fri, 07 Mar 2003 08:58:07 +0800 (SGT) Received: (from http@localhost) by se11.comp.nus.edu.sg (8.12.2+Sun/8.12.5) id h270x8Br027740; Fri, 7 Mar 2003 08:59:08 +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 137.132.31.162) (SquirrelMail authenticated user erinninn) by mysoc.nus.edu.sg with HTTP; Fri, 7 Mar 2003 08:59:08 +0800 (SGT) Message-ID: <47679.137.132.80.35.1046998748.squirrel@mysoc.nus.edu.sg> Date: Fri, 7 Mar 2003 08:59:08 +0800 (SGT) Subject: Re: [manet] Some questions on multicast routing protocols] To: In-Reply-To: References: X-Priority: 3 Importance: Normal Cc: , X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I have read your paper on ADMR. AMRIS is classified as proactive multicast protocol in your paper. However, the author of AMRIS mentioned that their protocol is on-demand as well. Therefore, I am wondering why? Thanks. As far as I know a special node (normally source) in multicast group will initiate the route discovery (building of DAG in this case). Therefore, based on what you explained, this is one of the on-demand characteristics. regards, inn inn > There have been many protocol proposals for multicast. Most of them > include both proactive and reactive mechanisms. Proactive mechanisms > are ones that rely on periodic control packet transmissions such as > neighbor detection and periodic flooding. Routing functionality can > roughly be divided into two parts: route discovery and route > maintenance. Most multicast routing protocols perform the route > discovery part on-demand and most perform the route maintenance part > proactively, e.g., they use periodic neighbor detection packets, or > refresh the multicast state periodically. > > As far as I am aware, the only general-purpose multicast protocol that > performs both route discovery and maintenance on-demand is ADMR. By > general-purpose, I mean a protocol that is not meant to only operate > with multicast groups of a limited size, or in small networks (e.g., > DDM, which encodes all receivers for the multicast group in the > packet header). > > A description and evaluation of ADMR along with a brief classification > of multicast protocols according to whether they use reactive or > on-demand mechanisms is described in the following paper: > > --- > Jorjeta G. Jetcheva and David B. Johnson. > Adaptive Demand-Driven Multicast Routing in Multi-Hop Wireless Ad Hoc > Networks. Proceedings of the 2001 ACM International Symposium on Mobile > Ad Hoc Networking & Computing (MobiHoc 2001), pp. 33-44, ACM, Long > Beach, CA, October, 2001. > --- > > You can download this paper from > http://www.monarch.cs.rice.edu/papers.html. > >> I know that most of them need an underlying unicast protocol. Those >> protocol maybe on-demand or proactive. > > Actually, many multicast protocols do not require a unicast protocol. > If a protocol relies on an underlying unicast protocol and cannot be > made to work with an on-demand unicast protocol, I'd classify it as > proactive. > > Jorjeta > > ------------------------------------------------------------------------- > > There exists MOLSR > http://hipercom.inria.fr/olsr/draft-ietf-manet-olsr-molsr.txt, a > multicast protocol based on the proactive protocol OLSR. There is also > the protocol XMAN > http://scholar.lib.vt.edu/theses/available/etd-08142002-131727/. > > I don't know about a multicast version of DSDV > > On the reactive side, there is MAODV and a multicast version of DSR > > Philippe > > ----- Original Message ----- > From: Er Inn Inn > To: > Sent: Thursday, March 06, 2003 2:32 PM > Subject: [manet] Some questions on multicast routing protocols] > > >> >> Hi, >> >> Thanks for the explaination. However, they are all unicast routing >> protocols. How about multicast routing protocol? Almost all proposed >> multicast protocols (for MANET) built the multicast tree or mesh when >> there are senders that wish to initiate multicast session... So could >> I classify them as on-demand? I know that most of them need an >> underlying unicast protocol. Those protocol maybe on-demand or >> proactive. Therefore, I am wondering whether the classification to >> proactive or reactive classes is not suitable for classifying >> multicast routing protocols? >> >> >> >> regards, >> inn inn >> >> >> > ----- Original Message ----- >> > From: "Er Inn Inn" >> > >> >> I am wondering whether we can classified the existing multicast >> >> routing protocol into 2 groups: Proactive and Reactive, as in >> unicast routing protocol. I have read some paper that classified >> the >> >> multicast protocols into whether on-demand or proactive. How to >> differentiate which protocol is on-demand and which one is >> proactive. As far as I understand, as long as the multicast tree or >> multicast mesh is built when it is needed (there is data to be >> sent) or it is initiated by the source, we may classify it as >> reactive protocol. Is this theory holds? What are the examples of >> proactive multicast routing protocol? Is AMRoute one of the >> examples of proactive multicast routing protocol? >> > >> > >> > REACTIVE : makes on-demand searches for a >> > path e.g AODV, DSR , ZRP >> > >> > PROACTIVE : constantly updates the routing >> > table at each node to maintain a nearly global >> > view on the network topology e.g DSDV >> > >> > Warm Regards >> > Shubhranshu >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > > =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= > o j r e a o > = o j t = > o o > = = > o Jorjeta G. Jetcheva o > = Ph.D. student, Computer Science = > o Carnegie Mellon University o > = = > o http://www.cs.cmu.edu/~jorjeta o > =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 21:53:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25079 for ; Thu, 6 Mar 2003 21:53:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2734Up10051 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 22:04:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2734UO10048 for ; Thu, 6 Mar 2003 22:04:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25069 for ; Thu, 6 Mar 2003 21:52:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h272lDO09310; Thu, 6 Mar 2003 21:47:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h272fxO09141 for ; Thu, 6 Mar 2003 21:41:59 -0500 Received: from gs46.sp.cs.cmu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24718 for ; Thu, 6 Mar 2003 21:30:09 -0500 (EST) Received: from gs46.sp.cs.cmu.edu ([127.0.0.1]) by gs46.sp.cs.cmu.edu id aa13376; 6 Mar 2003 21:31 EST Date: Thu, 6 Mar 2003 21:31:55 -0500 (EST) From: Jorjeta Gueorguieva Jetcheva X-Sender: jorjeta+@gs46.sp.cs.cmu.edu To: manet@ietf.org Subject: Re: [manet] Some questions on multicast routing protocols] 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 Inn Inn, In the Mobihoc paper, we say that AMRIS relies on proactive mechanisms for its operation. The particular mechanism that we had in mind is the periodic broadcasting of "multicast beacons" by all nodes in the network that AMRIS uses for disseminating multicast state information and for link break detection (Section 7 in the AMRIS Internet-Draft). Jorjeta ----------------------------------------------------------------------- Hi, I have read your paper on ADMR. AMRIS is classified as proactive multicast protocol in your paper. However, the author of AMRIS mentioned that their protocol is on-demand as well. Therefore, I am wondering why? Thanks. As far as I know a special node (normally source) in multicast group will initiate the route discovery (building of DAG in this case). Therefore, based on what you explained, this is one of the on-demand characteristics. regards, inn inn > There have been many protocol proposals for multicast. Most of them > include both proactive and reactive mechanisms. Proactive mechanisms > are ones that rely on periodic control packet transmissions such as > neighbor detection and periodic flooding. Routing functionality can > roughly be divided into two parts: route discovery and route > maintenance. Most multicast routing protocols perform the route > discovery part on-demand and most perform the route maintenance part > proactively, e.g., they use periodic neighbor detection packets, or > refresh the multicast state periodically. > > As far as I am aware, the only general-purpose multicast protocol that > performs both route discovery and maintenance on-demand is ADMR. By > general-purpose, I mean a protocol that is not meant to only operate > with multicast groups of a limited size, or in small networks (e.g., > DDM, which encodes all receivers for the multicast group in the > packet header). > > A description and evaluation of ADMR along with a brief classification > of multicast protocols according to whether they use reactive or > on-demand mechanisms is described in the following paper: > > --- > Jorjeta G. Jetcheva and David B. Johnson. > Adaptive Demand-Driven Multicast Routing in Multi-Hop Wireless Ad Hoc > Networks. Proceedings of the 2001 ACM International Symposium on Mobile > Ad Hoc Networking & Computing (MobiHoc 2001), pp. 33-44, ACM, Long > Beach, CA, October, 2001. > --- > > You can download this paper from > http://www.monarch.cs.rice.edu/papers.html. > >> I know that most of them need an underlying unicast protocol. Those >> protocol maybe on-demand or proactive. > > Actually, many multicast protocols do not require a unicast protocol. > If a protocol relies on an underlying unicast protocol and cannot be > made to work with an on-demand unicast protocol, I'd classify it as > proactive. > > Jorjeta > > ------------------------------------------------------------------------- > > There exists MOLSR > http://hipercom.inria.fr/olsr/draft-ietf-manet-olsr-molsr.txt, a > multicast protocol based on the proactive protocol OLSR. There is also > the protocol XMAN > http://scholar.lib.vt.edu/theses/available/etd-08142002-131727/. > > I don't know about a multicast version of DSDV > > On the reactive side, there is MAODV and a multicast version of DSR > > Philippe > > ----- Original Message ----- > From: Er Inn Inn > To: > Sent: Thursday, March 06, 2003 2:32 PM > Subject: [manet] Some questions on multicast routing protocols] > > >> >> Hi, >> >> Thanks for the explaination. However, they are all unicast routing >> protocols. How about multicast routing protocol? Almost all proposed >> multicast protocols (for MANET) built the multicast tree or mesh when >> there are senders that wish to initiate multicast session... So could >> I classify them as on-demand? I know that most of them need an >> underlying unicast protocol. Those protocol maybe on-demand or >> proactive. Therefore, I am wondering whether the classification to >> proactive or reactive classes is not suitable for classifying >> multicast routing protocols? >> >> >> >> regards, >> inn inn >> >> >> > ----- Original Message ----- >> > From: "Er Inn Inn" >> > >> >> I am wondering whether we can classified the existing multicast >> >> routing protocol into 2 groups: Proactive and Reactive, as in >> unicast routing protocol. I have read some paper that classified >> the >> >> multicast protocols into whether on-demand or proactive. How to >> differentiate which protocol is on-demand and which one is >> proactive. As far as I understand, as long as the multicast tree or >> multicast mesh is built when it is needed (there is data to be >> sent) or it is initiated by the source, we may classify it as >> reactive protocol. Is this theory holds? What are the examples of >> proactive multicast routing protocol? Is AMRoute one of the >> examples of proactive multicast routing protocol? >> > >> > >> > REACTIVE : makes on-demand searches for a >> > path e.g AODV, DSR , ZRP >> > >> > PROACTIVE : constantly updates the routing >> > table at each node to maintain a nearly global >> > view on the network topology e.g DSDV >> > >> > Warm Regards >> > Shubhranshu >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > > =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= > o j r e a o > = o j t = > o o > = = > o Jorjeta G. Jetcheva o > = Ph.D. student, Computer Science = > o Carnegie Mellon University o > = = > o http://www.cs.cmu.edu/~jorjeta o > =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= o j r e a o = o j t = o o = = o Jorjeta G. Jetcheva o = Ph.D. student, Computer Science = o Carnegie Mellon University o = = o http://www.cs.cmu.edu/~jorjeta o =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 6 22:27:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25860 for ; Thu, 6 Mar 2003 22:27:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h273cjI16712 for manet-archive@odin.ietf.org; Thu, 6 Mar 2003 22:38:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h273cjO16709 for ; Thu, 6 Mar 2003 22:38:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25850 for ; Thu, 6 Mar 2003 22:26:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25HGx516042; Wed, 5 Mar 2003 12:16:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25H10513331 for ; Wed, 5 Mar 2003 12:01:00 -0500 Received: from mail.cit.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11895 for ; Wed, 5 Mar 2003 11:49:25 -0500 (EST) Received: from eeb253w2k (unverified [157.190.41.56]) by cit.ie (Rockliffe SMTPRA 5.2.5) with SMTP id for ; Wed, 5 Mar 2003 16:38:25 +0000 Message-ID: <001401c2e337$a67e0ba0$3829be9d@eeb253w2k> From: "John Paul O Grady" To: "Manet Mailing List" Date: Wed, 5 Mar 2003 16:52:46 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C2E337.A5C19970" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [manet] NAT in an ad hoc environment Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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_0011_01C2E337.A5C19970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Has anybody done any work on NAT (Network Address Translation) in ad hoc = networks. I cant seem to find information on the subject. Regards John Paul O Grady CIT Ireland = -------------------Legal Disclaimer-------------------------------------= -- The above electronic mail transmission is confidential and intended only = for the person to whom it is addressed. Its contents may be protected by = legal and/or professional privilege. Should it be received by you in erro= r please contact the sender at the above quoted email address. Any unauth= orised form of reproduction of this message is strictly prohibited. The I= nstitute does not guarantee the security of any information electronicall= y transmitted and is not liable if the information contained in this comm= unication is not a proper and complete record of the message as transmitt= ed by the sender nor for any delay in its receipt. -------------------------------------------------------------------------= ---------------= ------=_NextPart_000_0011_01C2E337.A5C19970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Has anybody done any work on NAT = (Network Address=20 Translation) in ad hoc networks. I cant seem to find information on the=20 subject.
 
Regards
 
John Paul O Grady
CIT
Ireland
= -------------------Legal Disclaimer-------------------------------------= -- The above electronic mail transmission is confidential and intended only = for the person to whom it is addressed. Its contents may be protected by = legal and/or professional privilege. Should it be received by you in erro= r please contact the sender at the above quoted email address. Any unauth= orised form of reproduction of this message is strictly prohibited. The I= nstitute does not guarantee the security of any information electronicall= y transmitted and is not liable if the information contained in this comm= unication is not a proper and complete record of the message as transmitt= ed by the sender nor for any delay in its receipt. -------------------------------------------------------------------------= ---------------= ------=_NextPart_000_0011_01C2E337.A5C19970-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 7 07:37:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26670 for ; Fri, 7 Mar 2003 07:37:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27CmbG20956 for manet-archive@odin.ietf.org; Fri, 7 Mar 2003 07:48:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CmbO20953 for ; Fri, 7 Mar 2003 07:48:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26644 for ; Fri, 7 Mar 2003 07:36:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27CTvO18357; Fri, 7 Mar 2003 07:29:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C7FO16364 for ; Fri, 7 Mar 2003 07:07:15 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21820; Fri, 7 Mar 2003 06:55:15 -0500 (EST) Message-Id: <200303071155.GAA21820@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: manet@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 06:55:15 -0500 Subject: [manet] I-D ACTION:draft-ietf-manet-dsr-08.txt Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR) Author(s) : D. Johnson et al. Filename : draft-ietf-manet-dsr-08.txt Pages : 111 Date : 2003-3-6 The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two mechanisms of 'Route Discovery' and 'Route Maintenance', which work together to allow nodes to discover and maintain source routes to arbitrary destinations in the ad hoc network. The use of source routing allows packet routing to be trivially loop-free, avoids the need for up-to-date routing information in the intermediate nodes through which packets are forwarded, and allows nodes forwarding or overhearing packets to cache the routing information in them for their own future use. All aspects of the protocol operate entirely on-demand, allowing the routing packet overhead of DSR to scale automatically to only that needed to react to changes in the routes currently in use. This document specifies the operation of the DSR protocol for routing unicast IP packets in multi-hop wireless ad hoc networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-dsr-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-dsr-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6143623.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-dsr-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-dsr-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6143623.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 7 09:14:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03602 for ; Fri, 7 Mar 2003 09:14:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27EPuM29204 for manet-archive@odin.ietf.org; Fri, 7 Mar 2003 09:25:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27EPuO29199 for ; Fri, 7 Mar 2003 09:25:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03536 for ; Fri, 7 Mar 2003 09:13:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27E6CO27003; Fri, 7 Mar 2003 09:06:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27E0wO26720 for ; Fri, 7 Mar 2003 09:00:58 -0500 Received: from c000.snv.cp.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01718 for ; Fri, 7 Mar 2003 08:48:55 -0500 (EST) Received: (cpmta 886 invoked from network); 7 Mar 2003 05:50:59 -0800 Received: from 12.221.64.123 (HELO cs.uiuc.edu) by smtp.carter.net (209.228.32.64) with SMTP; 7 Mar 2003 05:50:59 -0800 X-Sent: 7 Mar 2003 13:50:59 GMT Message-ID: <3E68A2F2.40709@cs.uiuc.edu> Date: Fri, 07 Mar 2003 07:47:30 -0600 From: Casey Carter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] I-D ACTION:draft-ietf-manet-dsr-08.txt References: <200303071155.GAA21820@ietf.org> 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 Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > Title : The Dynamic Source Routing Protocol for Mobile Ad Hoc > Networks (DSR) > Author(s) : D. Johnson et al. > Filename : draft-ietf-manet-dsr-08.txt > Pages : 111 > Date : 2003-3-6 > > > > The discussion of Link-Maxlife caching in Appendix A claims that 2 = StabilityDecrFactor < 1, an obvious contradiction. I'm guessing that StabilityDecrFactor should actually be 1/2? -- Casey Carter Casey@Carter.net ccarter@uiuc.edu AIM: cartec69 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 7 16:09:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03738 for ; Fri, 7 Mar 2003 16:09:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27LLc710606 for manet-archive@odin.ietf.org; Fri, 7 Mar 2003 16:21:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LLcO10603 for ; Fri, 7 Mar 2003 16:21:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03670 for ; Fri, 7 Mar 2003 16:09:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27L5lO07643; Fri, 7 Mar 2003 16:05:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KlsO05851 for ; Fri, 7 Mar 2003 15:47:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29442; Fri, 7 Mar 2003 15:35:42 -0500 (EST) Message-Id: <200303072035.PAA29442@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: manet@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 15:35:42 -0500 Subject: [manet] I-D ACTION:draft-ietf-manet-tbrpf-07.txt Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Topology Broadcast based on Reverse-Path Forwarding (TBRPF) Author(s) : R. Ogier, M. Lewis, F. Templin Filename : draft-ietf-manet-tbrpf-07.txt Pages : 48 Date : 2003-3-7 TBRPF is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree (providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification of Dijkstra's algorithm. To minimize overhead, each node reports only *part* of its source tree to neighbors. This is in contrast to other protocols in which each node reports its *entire* source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reportable part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using 'differential' HELLO messages which report only *changes* in the status of neighbors. This results in HELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-tbrpf-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-tbrpf-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-tbrpf-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7150823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-tbrpf-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-tbrpf-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7150823.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 7 16:24:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05299 for ; Fri, 7 Mar 2003 16:24:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27LaSP12226 for manet-archive@odin.ietf.org; Fri, 7 Mar 2003 16:36:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LaSO12223 for ; Fri, 7 Mar 2003 16:36:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05203 for ; Fri, 7 Mar 2003 16:24:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LI6O10081; Fri, 7 Mar 2003 16:18:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LDAO09625 for ; Fri, 7 Mar 2003 16:13:10 -0500 Received: from fep04-mail.bloor.is.net.cable.rogers.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02763 for ; Fri, 7 Mar 2003 16:00:56 -0500 (EST) Received: from ee.ryerson.ca ([24.112.78.44]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030307210300.FRFQ265409.fep04-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 7 Mar 2003 16:03:00 -0500 Message-ID: <3E6908FA.3030005@ee.ryerson.ca> Date: Fri, 07 Mar 2003 16:02:50 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: manet@ietf.org References: <3E61897C.9080604@ee.ryerson.ca> Content-Type: multipart/alternative; boundary="------------010709080909040102030107" X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Fri, 7 Mar 2003 16:03:00 -0500 Subject: [manet] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Approaching March 10 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --------------010709080909040102030107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) --------------010709080909040102030107 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Call for Papers - IP Mobility 2003
IEEE VTC Symposium on IP Mobility
October 4-9, 2003 Orlando, FL, USA

in Conjunction with IEEE VTC Fall 2003
Submission Deadline Extended: March 10, 2003

Scope
=====
Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: 
* Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance
* New approaches to wide-area and local mobility
* Quality of Service models, resource management, and provisioning
* Traffic Engineering in mobile wireless IP access networks
* Transport protocol design for mobile wireless networks
* Security including security threat models, threat analysis and their impact on routing
* Application level protocol design and performance
* Mobile and wireless applications, their service requirements and performance
* Content delivery support in IP network for mobile users
* Multicasting for mobile wireless services
* Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network)
* Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular)
* Inter-vehicular network architecture
* Mobile wireless IP access network deployment and management

Posters are also solicited on the projects related to **Support for Network Mobility**.

Submission Instructions
=======================
Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/.

Important Dates
Extended Abstract Due:  March 10, 2003
Acceptance Notification:  May 15, 2003
Camera Ready Copy of Full Paper Due:  July 15, 2003
Symposium Date:  October 4, 2003

Organization
============

Program Co-Chairs:

Muhammad Jaseemuddin (jaseem@ee.ryerson.ca)
Department of Electrical and Computer Engineering
Ryerson University
Toronto, Canada

Hongyi Li (hyli@nortelnetworks.com)
Wireless Technology Lab
Nortel Networks
Ottawa, Canada

Publicity Co-Chair:

Junaid Zubairi (junaid.zubairi@fredonia.edu)
Department of Mathematics and Computer Science
SUNY at Fredonia
Fredonia, NY, USA

Technical Program Committee
===========================
* Ahmed Helmy (U of Southern California, USA)
* Abdelsalam Helal (U of Florida, Gainesville, USA)
* Alan O'Neill (Flarion Technologies, USA)
* Behcet Sarikaya (Alcatel, USA)
* Christophe Janneteau (Motorola, France)
* Govindan Ravindran (Soma Networks, Canada)
* Haseeb Akhtar (inCode Telecom group, USA)
* Hany Elgebaly (Intel Corporation, USA)
* Hesham Soliman (Ericsson, Sweden)
* Lars Wolf (TU Braunschweig, Germany)
* Michael Wolf (Daimler-Chrysler, Germany)
* Raouf Boutaba (U of Waterloo, Canada)
* Sajal Das (The U of Texas at Arlington, USA)
* Samir R. Das (SUNY at Stony Brook, USA)
* Thiery Ernst (Wide, Keio U, Japan)
* Thomas Noel (U of Strasbourg, France)
* Yasser Rasheed (Intel Corporation, USA)
--------------010709080909040102030107-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Mar 8 05:13: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 FAA04487 for ; Sat, 8 Mar 2003 05:13:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h28APgL22828 for manet-archive@odin.ietf.org; Sat, 8 Mar 2003 05:25:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28APgO22825 for ; Sat, 8 Mar 2003 05:25:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04445 for ; Sat, 8 Mar 2003 05:13:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28AAlO22215; Sat, 8 Mar 2003 05:10:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h289tKO21097 for ; Sat, 8 Mar 2003 04:55:20 -0500 Received: from web41606.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29075 for ; Sat, 8 Mar 2003 04:42:52 -0500 (EST) Message-ID: <20030308094458.48303.qmail@web41606.mail.yahoo.com> Received: from [193.95.33.25] by web41606.mail.yahoo.com via HTTP; Sat, 08 Mar 2003 10:44:58 CET Date: Sat, 8 Mar 2003 10:44:58 +0100 (CET) From: =?iso-8859-1?q?stream=20stream?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-607387857-1047116698=:47514" Content-Transfer-Encoding: 8bit Subject: [manet] some general questions Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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-607387857-1047116698=:47514 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi everybody, i would be very pleased if someone gives me any informations about theses problems in ad hoc networks: 1- why and when do we use clustering? what are the services that the clusterhead is supposed to give? 2- can we consider the clusterheads as partial central authorities? if yes how can clusterheads authenticate each others? 3- can we simulate clustering using a network simulator like ns? can we apply clustering in a realistic environment? any help will be appreciated. regards --------------------------------- Yahoo! Móviles Personaliza tu móvil con tu logo y melodía favorito --0-607387857-1047116698=:47514 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

hi everybody,

i would be very pleased if someone gives me any informations about theses problems in ad hoc networks:

1- why and when do we use clustering? what are the services that the clusterhead is supposed to give?

2- can we consider the clusterheads as partial central authorities? if yes how can clusterheads authenticate each others?

3- can we simulate clustering using a network simulator like ns? can we apply clustering in a realistic environment?

any help will be appreciated.

regards

 

Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito --0-607387857-1047116698=:47514-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Mar 8 22:08:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16624 for ; Sat, 8 Mar 2003 22:08:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h293KgR27311 for manet-archive@odin.ietf.org; Sat, 8 Mar 2003 22:20:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h293KgO27308 for ; Sat, 8 Mar 2003 22:20:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16493 for ; Sat, 8 Mar 2003 22:07:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2933AO25682; Sat, 8 Mar 2003 22:03:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h292mGO25340 for ; Sat, 8 Mar 2003 21:48:16 -0500 Received: from ims21.stu.nus.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10405 for ; Sat, 8 Mar 2003 21:35:27 -0500 (EST) Received: from mbxsrv22.stu.nus.edu.sg ([137.132.14.232]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Sun, 9 Mar 2003 10:37:31 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" x-mimeole: Produced By Microsoft Exchange V6.0.6249.0 Date: Sun, 9 Mar 2003 10:37:31 +0800 Message-ID: Thread-Topic: Question about Position-based routing protocol in MANETs Thread-Index: AcLl5NV84dRCBg4MTwWkLVGbKpJvGw== From: "Wu Mintao" To: X-OriginalArrivalTime: 09 Mar 2003 02:37:32.0093 (UTC) FILETIME=[D5BB6ED0:01C2E5E4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h292mGO25341 Subject: [manet] Question about Position-based routing protocol in MANETs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, everybody, i am currently doing research on position-based routing protocol of MANETs. after i have read through some papers, it seems to me that there are quite a lot work has been done in this area. but what are the current critical problems seems not clear. can anyone give me a possible lists of that? besides this, i have 2 more questions: 1). anyone knows any good website on position-based routing protocol of MAMETs? 2). is there any realistic implementation on position-based routing of MANETs? thanks in advance. your answer will be greatly appreciated. yours sincerely, Mintao _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 10 11:33: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 LAA02016 for ; Mon, 10 Mar 2003 11:33:05 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AGk8325481 for manet-archive@odin.ietf.org; Mon, 10 Mar 2003 11:46:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGk8O25478 for ; Mon, 10 Mar 2003 11:46:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01981 for ; Mon, 10 Mar 2003 11:32:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGVYO23500; Mon, 10 Mar 2003 11:31:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGNZO23122 for ; Mon, 10 Mar 2003 11:23:35 -0500 Received: from eccles.ee.ryerson.ca (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00843 for ; Mon, 10 Mar 2003 11:10:02 -0500 (EST) Received: from ee.ryerson.ca ([172.16.30.72]) by eccles.ee.ryerson.ca (8.12.8/8.12.8) with ESMTP id h2AGC89o079254 for ; Mon, 10 Mar 2003 11:12:09 -0500 (EST) (envelope-from jaseem@ee.ryerson.ca) Message-ID: <3E6CB958.6050705@ee.ryerson.ca> Date: Mon, 10 Mar 2003 11:12:08 -0500 From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: manet@ietf.org References: <3E61897C.9080604@ee.ryerson.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 24 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 24, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 24, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 10 12:16: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 MAA04020 for ; Mon, 10 Mar 2003 12:16:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AHToH30056 for manet-archive@odin.ietf.org; Mon, 10 Mar 2003 12:29:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHToO30053 for ; Mon, 10 Mar 2003 12:29:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04004 for ; Mon, 10 Mar 2003 12:16:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AHEPO28524; Mon, 10 Mar 2003 12:14:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AH9GO28238 for ; Mon, 10 Mar 2003 12:09:16 -0500 Received: from itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02814 for ; Mon, 10 Mar 2003 11:55:42 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by itd.nrl.navy.mil (8.8.8+Sun/8.8.8) with ESMTP id LAA27153 for ; Mon, 10 Mar 2003 11:57:49 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2AGvnlL015270 for ; Mon, 10 Mar 2003 11:57:49 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.0.1.45) with SMTP id M2003031011574910234 for ; Mon, 10 Mar 2003 11:57:49 -0500 Message-Id: <5.1.1.5.2.20030310115707.01dd5438@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 10 Mar 2003 11:59:36 -0500 To: manet@ietf.org From: Joe Macker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] Draft Agenda Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Here the planned draft agenda for the San Francisco manet meeting. -------------------------------------------------------------- Mobile Ad Hoc Networks (manet) Agenda Thursday, Mar , 1500-1700 1. Agenda Bashing (5 min) 2. Review of Charter/Milestone Update (10 min) Working Document Progress Updates 3. AODV Update (20 min) 4. DSR Update (20 min) 5. OLSR Update (20 min 6. TBRPF Update (20 min) 7. Further Progression of Documents (5 min) 8. Next Steps: Problem Statement Consensus and Standards Track Approach (20 min) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 10 15:22: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 PAA12212 for ; Mon, 10 Mar 2003 15:22:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AKZur13140 for manet-archive@odin.ietf.org; Mon, 10 Mar 2003 15:35:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKZuO13137 for ; Mon, 10 Mar 2003 15:35:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12192 for ; Mon, 10 Mar 2003 15:22:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKHsO11198; Mon, 10 Mar 2003 15:17:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AKBWO10921 for ; Mon, 10 Mar 2003 15:11:32 -0500 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10585 for ; Mon, 10 Mar 2003 14:57:54 -0500 (EST) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2AJxwhs009397; Mon, 10 Mar 2003 11:59:58 -0800 (PST) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-253-238.cisco.com [10.32.253.238]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with SMTP id AEV41293; Mon, 10 Mar 2003 11:54:44 -0800 (PST) Message-Id: <5.2.0.9.2.20030310104950.0e5e6aa0@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 10 Mar 2003 11:35:54 -0800 To: Chandramouli Balasubramanian From: Fred Baker Subject: Re: [manet] Performance Comparison of QoS Routing for Adhoc Networks Cc: manet@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , At 11:44 PM 12/17/2002 -0800, Chandramouli Balasubramanian wrote: >has anyone ever looked at the Performance Evaluation aspects of the Qos >Routing Protocols? you might take a look at draft-perkins-manet-aodvqos-01.txt, and at OSPF's use for installation of label switched paths in MPLS. The latter could be used in a manet network, and a couple of weeks ago at a talk I gave in Singapore someone literally proposed that MPLS should be the manet solution of choice. Not entirely sure I agreed with them (ahem), but the technology would technically be able to be made to work. As to performance evaluation, I'm not altogether sure what performance you are considering. That particular draft is essentially a traffic engineering proposal; since AODV searches for every possible route and finds one, this proposal basically truncates a search in the event that some constraint is not met, leaving room for another path being searched to succeed. If you're thinking about the packet/octet/delay/jitter/whatever performance of the path chosen, it should be the performance of a path searched and having met that constraint. We can discuss whether the constraint is correctly specified or a sufficient set of constraints are specified to meet a particular purpose, but if the path meets the specified constraints it should operate like one that does. If you're thinking about the performance of the algorithm finding such a path, especially the amount of time it takes to install one, I'm sure that will vary from network to network. If the only routers being searched are in orbits around various planets and the target is en route to alpha centauri, it might not converge very quickly. I could think of several other things that I could describe as a performance evaluation. What performance do you want to evaluate? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 10 17:23:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17284 for ; Mon, 10 Mar 2003 17:23:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AMaAd25740 for manet-archive@odin.ietf.org; Mon, 10 Mar 2003 17:36:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMaAO25737 for ; Mon, 10 Mar 2003 17:36:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17278 for ; Mon, 10 Mar 2003 17:22:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMNrO24743; Mon, 10 Mar 2003 17:23:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMGUO24406 for ; Mon, 10 Mar 2003 17:16:30 -0500 Received: from itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16448 for ; Mon, 10 Mar 2003 17:02:50 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by itd.nrl.navy.mil (8.8.8+Sun/8.8.8) with ESMTP id RAA13948 for ; Mon, 10 Mar 2003 17:04:57 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2AM4vlL022239 for ; Mon, 10 Mar 2003 17:04:57 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.0.1.45) with SMTP id M2003031017045602087 for ; Mon, 10 Mar 2003 17:04:56 -0500 Message-Id: <5.1.1.5.2.20030310170117.01d69fd0@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 10 Mar 2003 17:06:43 -0500 To: manet@ietf.org From: Joe Macker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] Slight manet draft agenda update Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , I added a short IRTF related status report to the agenda. Elizabeth Royer will provide us an update. Also as a reminder the meeting is Thurs, March 20, 1300-1500. As always check the www.ietf.org site for agenda specifics and other information. ------------------------------------------------------------ Mobile Ad Hoc Networks (manet) Agenda Thursday, Mar , 1500-1700 1. Agenda Bashing (5 min) 2. Review of Charter/Milestone and IRTF Update (10 min) Working Document Progress Updates 3. AODV Update (20 min) 4. DSR Update (20 min) 5. OLSR Update (20 min 6. TBRPF Update (20 min) 7. Further Progression of Documents (5 min) 8. Next Steps: Problem Statement Consensus and Standards Track Approach (20 min) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 10 18:05:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18994 for ; Mon, 10 Mar 2003 18:05:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ANIbS29366 for manet-archive@odin.ietf.org; Mon, 10 Mar 2003 18:18:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ANIbO29363 for ; Mon, 10 Mar 2003 18:18:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18930 for ; Mon, 10 Mar 2003 18:04:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AN5YO28000; Mon, 10 Mar 2003 18:05:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AN09O27799 for ; Mon, 10 Mar 2003 18:00:09 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18078 for ; Mon, 10 Mar 2003 17:46:28 -0500 (EST) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with SMTP id h2AMmY106889; Mon, 10 Mar 2003 14:48:34 -0800 (PST) Message-Id: <200303102248.h2AMmY106889@letters.cs.ucsb.edu> Date: Mon, 10 Mar 2003 14:48:34 -0800 (PST) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" Subject: Re: [manet] Slight manet draft agenda update To: manet@ietf.org, macker@itd.nrl.navy.mil MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0Fn6X/pCkabpG3NRdQD98g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Related to this, there will also be a Bar BOF Thursday evening to discuss future direction and focus of the IRTF working group. If you have an opinion, you are welcome to participate. This is an open working group. I'll give more details at the MANET meeting. Elizabeth ~> ~> I added a short IRTF related status report to the agenda. Elizabeth Royer will provide us an update. ~> ~> Also as a reminder the meeting is Thurs, March 20, 1300-1500. As always check the www.ietf.org site for agenda specifics and other information. ~> ~> ------------------------------------------------------------ ~> ~> Mobile Ad Hoc Networks (manet) Agenda ~> Thursday, Mar , 1500-1700 ~> ~> 1. Agenda Bashing (5 min) ~> 2. Review of Charter/Milestone and IRTF Update (10 min) ~> ~> Working Document Progress Updates ~> ~> 3. AODV Update (20 min) ~> 4. DSR Update (20 min) ~> 5. OLSR Update (20 min ~> 6. TBRPF Update (20 min) ~> ~> 7. Further Progression of Documents (5 min) ~> 8. Next Steps: Problem Statement Consensus and Standards Track Approach (20 min) ~> ~> _______________________________________________ ~> manet mailing list ~> manet@ietf.org ~> https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 11 05:09:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14627 for ; Tue, 11 Mar 2003 05:09:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BAN5317423 for manet-archive@odin.ietf.org; Tue, 11 Mar 2003 05:23:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BAN4O17420 for ; Tue, 11 Mar 2003 05:23:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14621 for ; Tue, 11 Mar 2003 05:09:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BA4IO15853; Tue, 11 Mar 2003 05:04:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2B9v2O15590 for ; Tue, 11 Mar 2003 04:57:02 -0500 Received: from gwsmtp.thomson-csf.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14320 for ; Tue, 11 Mar 2003 04:43:07 -0500 (EST) Received: from thalescan.corp.thales (200.3.2.3) by gwsmtp.thomson-csf.com (NPlex 6.5.026) id 3E64E7BF000D3AA4 for manet@ietf.org; Tue, 11 Mar 2003 10:47:29 +0100 Received: from msw001.uk.trt.thales ([192.168.224.28]) by thalescan with InterScan Messaging Security Suite; Tue, 11 Mar 2003 10:44:53 +0100 Received: from NTS013.uk.trt.thales (unverified) by msw001.uk.trt.thales (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 11 Mar 2003 09:44:42 +0000 Received: by NTS013.uk.trt.thales with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Mar 2003 09:41:58 -0000 Message-ID: <51BF576D5A02CC4CB2591F50994FD7660B409B@NTS013.uk.trt.thales> From: "Yong, Chee Yeew " To: "'manet@ietf.org'" Date: Tue, 11 Mar 2003 09:41:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] Anyone experimenting with SWAN? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 experimenting with the NS-2 simulation code for SWAN ( http://www.comet.columbia.edu/swan/simulation.html ) released by COMET recently. Is anyone doing the same? Please contact me if so. Thank you, Chee _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 11 17:58: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 RAA16312 for ; Tue, 11 Mar 2003 17:58:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BNBhD09787 for manet-archive@odin.ietf.org; Tue, 11 Mar 2003 18:11:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNBhO09784 for ; Tue, 11 Mar 2003 18:11:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16304 for ; Tue, 11 Mar 2003 17:57:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMx8O08230; Tue, 11 Mar 2003 17:59:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BMkaO07880 for ; Tue, 11 Mar 2003 17:46:36 -0500 Received: from hellmouth4.gatech.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15639 for ; Tue, 11 Mar 2003 17:32:26 -0500 (EST) Received: from hellmouth4.gatech.edu (localhost [127.0.0.1]) by hellmouth4.gatech.edu (Postfix) with SMTP id 98D8DA54D for ; Tue, 11 Mar 2003 17:34:34 -0500 (EST) (envelope-from gte393q@mail.gatech.edu) Received: from acmey.gatech.edu (acmey.prism.gatech.edu [130.207.171.27]) by hellmouth4.gatech.edu (Postfix) with ESMTP id 5ADCEA50A for ; Tue, 11 Mar 2003 17:34:34 -0500 (EST) (envelope-from gte393q@mail.gatech.edu) Received: by acmey.gatech.edu (Postfix, from userid 21503) id 3A02D31F17; Tue, 11 Mar 2003 17:34:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by acmey.gatech.edu (Postfix) with ESMTP id 3240C330E9 for ; Tue, 11 Mar 2003 17:34:34 -0500 (EST) (envelope-from gte393q@mail.gatech.edu) Date: Tue, 11 Mar 2003 17:34:34 -0500 (EST) From: Young-Jun Lee X-X-Sender: To: Subject: [manet] Difference between OLSR and CEDAR 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: , While reading the OLSD ID, I got impression that OLSR is very similar to CEDAR. Especially, MPR(Multipoint Relay) of OLSR and Core of CEDAR look like almost same thing to me. Is there anyone who knows the BASIC difference between these two prtocols or two functionalities (MPR and Core)? Thanks in advance. Young _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 11 18:57:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19485 for ; Tue, 11 Mar 2003 18:57:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C0BZP13979 for manet-archive@odin.ietf.org; Tue, 11 Mar 2003 19:11:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0BZO13976 for ; Tue, 11 Mar 2003 19:11:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19476 for ; Tue, 11 Mar 2003 18:57:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNtiO12386; Tue, 11 Mar 2003 18:55:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BNmFO11983 for ; Tue, 11 Mar 2003 18:48:15 -0500 Received: from meshpdc.meshnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18532 for ; Tue, 11 Mar 2003 18:34:01 -0500 (EST) Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19) id <15ZD4WJR>; Tue, 11 Mar 2003 18:36:09 -0500 Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048DD225B@meshpdc.meshnetworks.com> From: Sebnem Ozer To: manet@ietf.org Date: Tue, 11 Mar 2003 18:36:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E826.F9FAA6F0" Subject: [manet] FW: CFP:IEEE VTC'03 Wireless Ad hoc, Sensor, and Wearable Network s Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2E826.F9FAA6F0 Content-Type: text/plain; charset="iso-8859-1" We apologize if you received multiple copies of this Call. CALL FOR PAPERS IEEE VTC'03 Wireless Ad hoc, Sensor, and Wearable Networks http://www.cs.queensu.ca/home/safwat/VTC_2003_Symposium/index.html This is the first in a series of high-quality annual symposia dedicated to Wireless Ad hoc, Sensor, and Wearable Networks. Each year there will be one or more themes invigorated by the state of the art. This year's theme is "Energy-Efficient and Context-Aware Designs". However, we welcome all submissions of relevance to wireless ad hoc, sensor, and wearable networks. October 4-9, 2003 Hyatt Orlando Hotel Orlando, Florida, USA Symposium Chair: Ahmed Safwat Queen's University, Canada safwat@cs.queensu.ca Scope: ===== In multi-hop wireless ad hoc, sensor, and wearable networks wireless mobile stations and electronic devices form a network without the intervention of a dedicated infrastructure. Such networks eradicate infrastructure deployment, setup, and administration costs. Nevertheless, although energy efficiency and context awareness in wireless ad hoc, sensor, and wearable networks are of great significance, they both remain the main impediments towards their deployment. The outcomes of this year's Symposium will stimulate and exhilarate the deployment of sustainable and context-rich wireless ad hoc, sensor, and wearable networks. Original papers are solicited in all areas of wireless ad hoc, sensor, and wearable networks. Topics of interest include, but are not limited to, the following: -- Routing protocols -- Medium access control -- Modeling and simulation -- Security algorithms -- Energy-efficient physical designs -- Disruptive applications (telemedical, biological, etc) -- Multi-hop cellular architectures (multi-hop WLANs, 4G, 4G+) -- Body area networks -- M-commerce -- Multi-channel ad hoc/sensor networks: designs and algorithms -- Directive antennas -- Self-configurable wearable networks -- Personal area networks -- Cross-layer designs -- TCP-related issues -- Wireless multi-hop testbeds -- Location-inspired designs -- Incorporation of context into wearable networking -- Non-monolithic/shared conceptual models for context-awareness -- Algorithms for context discovery and delivery Submission Guidelines: ================= Authors are required to submit a short abstract (approximately 150 words) AND an extended abstract (up to 2 pages) as well. All submissions will be handled electronically through the EDAS conference management system at http://edas.info , and must be in MS-Word or PDF format. Your submission should include the names, complete mailing addresses, telephone and fax numbers, and the email addresses of the authors. Important Dates: ============ NEW Deadline for extended abstract submission: March 24, 2003 Notification of Acceptance: May 15, 2003 Camera-Ready Papers: July 15, 2003 **************************************************************************** This e-mail is intended only for the addressee named above and may contain confidential, proprietary or privileged information. If you are not the named addressee or the person responsible for delivering the message to the named addressee, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. The contents should not be disclosed to anyone and no copies should be made. We take reasonable precautions to ensure that our emails are virus free. However we accept no responsibility for any virus transmitted by us and recommend that you subject any incoming e-mail to your own virus checking procedures. ------_=_NextPart_001_01C2E826.F9FAA6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We apologize if you received multiple copies of this = Call.

 

 

CALL = FOR PAPERS

 

 

IEEE = VTC'03 Wireless Ad hoc, Sensor, and Wearable = Networks

 

http://www.cs.queensu.ca/home/safwat/VTC_2003_Symposium/index.html

 

 

 

This is the first in a series of high-quality annual symposia dedicated to Wireless Ad hoc, Sensor, and Wearable Networks. = Each year there will be one or more themes invigorated by the state of the art. = This year's theme is "Energy-Efficient and Context-Aware Designs". However, we welcome all submissions of relevance to wireless ad hoc, = sensor, and wearable networks.

 

October 4-9, = 2003

Hyatt Orlando Hotel

Orlando, = Florida, = USA

 

Symposium Chair:

Ahmed Safwat

Queen's University, = Canada

safwat@cs.queensu.ca=

 

 

Scope:

=3D=3D=3D=3D=3D

 

In multi-hop wireless ad hoc, sensor, and wearable = networks wireless mobile stations and electronic devices form a network without = the intervention of a dedicated infrastructure. Such networks eradicate infrastructure deployment, setup, and administration costs. = Nevertheless, although energy efficiency and context awareness in wireless ad hoc, = sensor, and wearable networks are of great significance, they both remain the = main impediments towards their deployment.

 

The outcomes of this year's Symposium will stimulate and exhilarate the deployment of sustainable and context-rich wireless = ad hoc, sensor, and wearable networks.

 

Original papers are solicited in all areas of = wireless ad hoc, sensor, and wearable networks. Topics of interest include, but are = not limited to, the following:

-- Routing protocols

-- Medium access = control

-- Modeling and = simulation

-- Security algorithms

-- Energy-efficient physical = designs

-- Disruptive applications (telemedical, biological, = etc)

-- Multi-hop cellular architectures (multi-hop = WLANs, 4G, 4G+)

-- Body area networks

-- M-commerce

-- Multi-channel ad hoc/sensor networks: designs and algorithms

-- Directive antennas

-- Self-configurable wearable = networks

-- Personal area = networks

-- Cross-layer designs

-- TCP-related issues

-- Wireless multi-hop = testbeds

-- Location-inspired = designs

-- Incorporation of context into wearable = networking

-- Non-monolithic/shared conceptual models for context-awareness

-- Algorithms for context discovery and = delivery

=A0

Submission Guidelines:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Authors are required to submit a short abstract (approximately 150 words) AND an extended abstract (up to 2 pages) as = well. All submissions will be handled electronically through the EDAS conference management system at http://edas.info, and must be in MS-Word or PDF format. Your submission should include the names, = complete mailing addresses, telephone and fax numbers, and the email addresses = of the authors.

 

 

Important Dates:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

NEW Deadline for extended = abstract submission: March 24, 2003

Notification of Acceptance: May 15, 2003

Camera-Ready Papers: July 15, 2003

 

 

 

*********************************************************= *******************This e-mail is intended only for the addressee named = above and may contain confidential, proprietary or privileged = information. If you are not the named addressee or the person = responsible for delivering the message to the named addressee, please = inform us promptly by reply e-mail, then delete the e-mail and destroy = any printed copy. The contents should not be disclosed to anyone and no = copies should be made. We take reasonable precautions to ensure that = our emails are virus free. However we accept no responsibility for any = virus transmitted by us and recommend that you subject any incoming = e-mail to your own virus checking procedures.

------_=_NextPart_001_01C2E826.F9FAA6F0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 11 19:12:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19946 for ; Tue, 11 Mar 2003 19:12:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C0PkV14779 for manet-archive@odin.ietf.org; Tue, 11 Mar 2003 19:25:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0PjO14776 for ; Tue, 11 Mar 2003 19:25:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19942 for ; Tue, 11 Mar 2003 19:11:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0GPO14149; Tue, 11 Mar 2003 19:16:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C0BIO13968 for ; Tue, 11 Mar 2003 19:11:18 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19470 for ; Tue, 11 Mar 2003 18:57:06 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id PAA29187; Tue, 11 Mar 2003 15:59:12 -0800 (PST) Message-Id: <200303112359.PAA29187@pit.erg.sri.com> To: Young-Jun Lee cc: manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Difference between OLSR and CEDAR In-reply-to: Your message of "Tue, 11 Mar 2003 17:34:34 EST." Date: Tue, 11 Mar 2003 15:59:12 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > While reading the OLSD ID, I got impression that OLSR is very similar to CEDAR. > Especially, MPR(Multipoint Relay) of OLSR and Core of CEDAR look like almost > same thing to me. > Is there anyone who knows the BASIC difference between these two prtocols > or two functionalities (MPR and Core)? > Thanks in advance. > > Young Young, There are some similarities between the core nodes of CEDAR and the MPRs of OLSR, but there are also some big differences: - The core of CEDAR is ideally a minimum dominating set (MDS), which is "source independent" in that (unlike the MPRs of OLSR) the decision of a core node to retransmit (forward) a flooded packet is independent of which neighbor it came from. - In OLSR, an MPR is always an MPR with respect to one or more neighbors, called "MPR selectors". Thus, MPRs are "source dependent". - In OLSR, there always exists (after convergence) a min-hop path that uses only MPRs as intermediate nodes, whereas CEDAR does not provide min-hop paths. - Since CEDAR does not require min-hop paths, it can *potentially* achieve more efficient flooding than source-dependent MPRs, since the number of nodes in the core *may* be smaller than the number of MPRs that retransmit a given flooded packet. This is certainly true if the MDS is optimal (has the minimum number of nodes). Regards, Richard P.S. Anyone who will be in the San Francisco area this Saturday evening (March 15) is invited to attend a chamber music concert in which I will play clarinet: http://www.paphil.org/ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 12 10:13:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06654 for ; Wed, 12 Mar 2003 10:13:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CFRNP18987 for manet-archive@odin.ietf.org; Wed, 12 Mar 2003 10:27:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFRNO18984 for ; Wed, 12 Mar 2003 10:27:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06592 for ; Wed, 12 Mar 2003 10:12:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CFEEO18195; Wed, 12 Mar 2003 10:14:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CF99O18018 for ; Wed, 12 Mar 2003 10:09:09 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05018 for ; Wed, 12 Mar 2003 09:54:37 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id GAA02023; Wed, 12 Mar 2003 06:56:45 -0800 (PST) Message-Id: <200303121456.GAA02023@pit.erg.sri.com> To: Young-Jun Lee cc: manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Difference between OLSR and CEDAR Date: Wed, 12 Mar 2003 06:56:45 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Another difference between the core nodes of CEDAR and the MPRs of OLSR that I forgot to mention is that the CEDAR core is not connected, i.e., it is not a *connected* dominating set, whereas the set of MPR links forms a connected subgraph. Thus, core broadcast in CEDAR uses unicast along tunnels to send packets between core nodes. Also, what I said regarding the MPRs of OLSR also holds for the MPRs computed by TBRPF. (As explained in the internet-draft, TBRPF also computes MPRs, but in a different way.) Regards, Richard > > > While reading the OLSD ID, I got impression that OLSR is very similar to CEDAR. > > Especially, MPR(Multipoint Relay) of OLSR and Core of CEDAR look like almost > > same thing to me. > > Is there anyone who knows the BASIC difference between these two prtocols > > or two functionalities (MPR and Core)? > > Thanks in advance. > > > > Young > > Young, > > There are some similarities between the core nodes of CEDAR and the MPRs of > OLSR, but there are also some big differences: > > - The core of CEDAR is ideally a minimum dominating set (MDS), which is > "source independent" in that (unlike the MPRs of OLSR) the decision of > a core node to retransmit (forward) a flooded packet is independent of > which neighbor it came from. > > - In OLSR, an MPR is always an MPR with respect to one or more neighbors, > called "MPR selectors". Thus, MPRs are "source dependent". > > - In OLSR, there always exists (after convergence) a min-hop path that uses > only MPRs as intermediate nodes, whereas CEDAR does not provide min-hop paths. > > - Since CEDAR does not require min-hop paths, it can *potentially* achieve > more efficient flooding than source-dependent MPRs, since the number of > nodes in the core *may* be smaller than the number of MPRs that retransmit > a given flooded packet. This is certainly true if the MDS is optimal > (has the minimum number of nodes). > > Regards, > Richard > > P.S. Anyone who will be in the San Francisco area this Saturday evening (March 15) > is invited to attend a chamber music concert in which I will play clarinet: > > http://www.paphil.org/ > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 12 13:59:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16247 for ; Wed, 12 Mar 2003 13:59:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CJDt205353 for manet-archive@odin.ietf.org; Wed, 12 Mar 2003 14:13:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJDtO05350 for ; Wed, 12 Mar 2003 14:13:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16241 for ; Wed, 12 Mar 2003 13:59:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJ0HO03902; Wed, 12 Mar 2003 14:00:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CItfO03642 for ; Wed, 12 Mar 2003 13:55:41 -0500 Received: from mgw1.ul.ie (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15694 for ; Wed, 12 Mar 2003 13:41:06 -0500 (EST) Received: from gabriel.ul.ie ([136.201.1.101]) by ul.ie (PMDF V5.2-32 #41948) with ESMTP id <0HBN00GKKG1FGU@ul.ie> for manet@ietf.org; Wed, 12 Mar 2003 18:44:03 +0000 (GMT) Received: by gabriel.ul.ie with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 18:52:39 +0000 Content-return: allowed Date: Wed, 12 Mar 2003 18:52:38 +0000 From: Michael Halpin <9923527@student.ul.ie> To: "'manet@ietf.org'" Message-id: <3106F19CD154D34A818258EBC4147D19318290@gabriel.ul.ie> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Subject: [manet] kernel-aodv(v2.0.1) gateway problems Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 was wondering if someone could help with this problem. I have three laptops configured as a<-->b<-->c with a and c out of range of each other. c is my gateway node, with one interface (eth0) connected to a wired lan(one subnet), and eth1 on the the on the other subnet. within the manet aodv works fine. But when using c as a gateway to the wired lan I can only connect to the exterior network using nodes b and c. When I try to connect using node a, it doesn't seem to generate rreq's to c, as I expected but intead arp messages for c (I figure this is because nodes a and b are configured with the their default gateways as node c's wireless interface. And because a and c do not share a link-layer connection, the arp request can't be satisfied). I've tried turning off the arp's on node a i.e. "ifconfig eth0 -arp", but to no avail, and while I can connect (temporarily- 3 or 4 icmp replies before node c's wireless interface starts generating arps for node a) when I configure node a's gateway to be node b, this seems to defeat the purpose of having an ad-hoc network. Am I over-looking something simple, or is the internet-connectivity limited (because of the gateway's need for a layer 2 connection) to one-hop (on the ad-hoc side) from the gateway? (if its any help I'm running suse 8.0, kernel 2.4.18 on all machines) All help gratefully appreciated, Thanks In Advance, Michael _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 12 15:01:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18642 for ; Wed, 12 Mar 2003 15:01:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CKFgu09842 for manet-archive@odin.ietf.org; Wed, 12 Mar 2003 15:15:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKFgO09839 for ; Wed, 12 Mar 2003 15:15:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18635 for ; Wed, 12 Mar 2003 15:01:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CK0oO08335; Wed, 12 Mar 2003 15:00:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CJuVO08122 for ; Wed, 12 Mar 2003 14:56:31 -0500 Received: from postmark.nist.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17937 for ; Wed, 12 Mar 2003 14:41:54 -0500 (EST) Received: from gwialo (camelot.antd.nist.gov [129.6.50.51]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h2CJhrCZ005503; Wed, 12 Mar 2003 14:43:53 -0500 (EST) From: "Luke Klein-Berndt" To: "'Michael Halpin'" <9923527@student.ul.ie>, Subject: RE: [manet] kernel-aodv(v2.0.1) gateway problems Date: Wed, 12 Mar 2003 14:43:53 -0500 Message-ID: <000101c2e8cf$b65281d0$33320681@campus.nist.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3106F19CD154D34A818258EBC4147D19318290@gabriel.ul.ie> Importance: Normal 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, I am sorry about that... A couple of other people have reported this problem, I think I have found a solution but I haven't had time to try it out. If anyone else is trying to get this to work, email me off the list and we can work together to fix it. -Luke Klein-Berndt > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Michael Halpin > Sent: Wednesday, March 12, 2003 1:53 PM > To: 'manet@ietf.org' > Subject: [manet] kernel-aodv(v2.0.1) gateway problems > > > Hi all, > I was wondering if someone could help with this problem. I > have three laptops configured as > > a<-->b<-->c > > with a and c out of range of each other. c is my gateway > node, with one interface (eth0) connected to a wired lan(one > subnet), and eth1 on the the on the other subnet. within the > manet aodv works fine. But when using c as a gateway to the > wired lan I can only connect to the exterior network using > nodes b and c. When I try to connect using node a, it doesn't > seem to generate rreq's to c, as I expected but intead arp > messages for c (I figure this is because nodes a and b are > configured with the their default gateways as node c's > wireless interface. And because a and c do not share a > link-layer connection, the arp request can't be satisfied). > > > I've tried turning off the arp's on node a i.e. "ifconfig > eth0 -arp", but to no avail, and while I can connect > (temporarily- 3 or 4 icmp replies before node c's wireless > interface starts generating arps for node a) when I > configure node a's gateway to be node b, this seems to defeat > the purpose of having an ad-hoc network. > > Am I over-looking something simple, or is the > internet-connectivity limited (because of the gateway's need > for a layer 2 connection) to one-hop (on the ad-hoc side) > from the gateway? (if its any help I'm running suse 8.0, > kernel 2.4.18 on all machines) > > All help gratefully appreciated, > Thanks In Advance, > Michael > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 12 16:14:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23167 for ; Wed, 12 Mar 2003 16:14:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CLSMC15924 for manet-archive@odin.ietf.org; Wed, 12 Mar 2003 16:28:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CLSMO15921 for ; Wed, 12 Mar 2003 16:28:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23156 for ; Wed, 12 Mar 2003 16:13:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CL60O13382; Wed, 12 Mar 2003 16:06:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CKxkO13063 for ; Wed, 12 Mar 2003 15:59:46 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21495; Wed, 12 Mar 2003 15:45:07 -0500 (EST) Message-Id: <200303122045.PAA21495@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , manet@ietf.org From: The IESG Date: Wed, 12 Mar 2003 15:45:06 -0500 Subject: [manet] Document Action: Ad Hoc On Demand Distance Vector (AODV) Routing to Experimental Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , The IESG has approved the Internet-Draft 'Ad Hoc On Demand Distance Vector (AODV) Routing' as an Experimental RFC. This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Bill Fenner and Alex Zinin. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 12 22:54:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06472 for ; Wed, 12 Mar 2003 22:54:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D492811266 for manet-archive@odin.ietf.org; Wed, 12 Mar 2003 23:09:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D492O11263 for ; Wed, 12 Mar 2003 23:09:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06464 for ; Wed, 12 Mar 2003 22:54:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D3teO09941; Wed, 12 Mar 2003 22:55:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D3kUO09743 for ; Wed, 12 Mar 2003 22:46:30 -0500 Received: from sm203.163.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05870 for ; Wed, 12 Mar 2003 22:31:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by sm203.163.com (Postfix) with SMTP id 30DC11CFAFD0C for ; Thu, 13 Mar 2003 11:33:42 +0800 (CST) Received: from hellsun (unknown [202.112.101.162]) by 192.168.1.203 (Coremail:www.163.com) with SMTP id qAEAAAn8bz4ycGWi.1 for ; Thu, 13 Mar 2003 11:33:42 +0800 (CST) From: "=?GB2312?Q?=CB=EF=C1=C1?=" To: manet X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Date: Thu, 13 Mar 2003 11:35:25 +0800 Message-Id: <20030313033342.30DC11CFAFD0C@sm203.163.com> Content-Transfer-Encoding: 7bit Subject: [manet] 400 nodes in NS Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, Has anyone ever made the ad hoc simulation with 400 nodes in NS? In the duration of 80 seconds simulation time, no CBR packet can be transported successfully,all nodes are trying to set up route but not be completed till the end. If anyone has made this kind of simulation, please tell me how. Best Regards, SUN Liang 2003-03-13 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 13 00:07:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08546 for ; Thu, 13 Mar 2003 00:07:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2D5Lxe15600 for manet-archive@odin.ietf.org; Thu, 13 Mar 2003 00:21:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D5LxO15597 for ; Thu, 13 Mar 2003 00:21:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08504 for ; Thu, 13 Mar 2003 00:07:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D53HO13926; Thu, 13 Mar 2003 00:03:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D4tRO13686 for ; Wed, 12 Mar 2003 23:55:27 -0500 Received: from barrichello.cs.ucr.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07679 for ; Wed, 12 Mar 2003 23:40:41 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id AB3A9AB570B3; Wed, 12 Mar 2003 20:38:42 -0800 (PST) Mailbox-Line: From zye@cs.ucr.edu Wed Mar 12 20:38:39 2003 Received: from hill (hill.cs.ucr.edu [138.23.169.9]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id D5895AB570FF; Wed, 12 Mar 2003 20:38:38 -0800 (PST) Date: Wed, 12 Mar 2003 20:44:44 -0800 (PST) From: "Zhenqiang(Frank) Ye" To: =?GB2312?Q?=CB=EF=C1=C1?= Cc: manet Subject: Re: [manet] 400 nodes in NS In-Reply-To: <20030313033342.30DC11CFAFD0C@sm203.163.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-Spam-Status: No, hits=-2.9 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.31 X-Virus-Scanned: by AMaViS perl-11 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by www1.ietf.org id h2D4tRO13687 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit I had some simulations with 400 nodes. It works OK but consumes a lot of time. Could you provide some information about how many connections in your simulations? Frank On Thu, 13 Mar 2003, [GB2312] ËïÁÁ wrote: > Hi, > > Has anyone ever made the ad hoc simulation with 400 nodes in NS? > In the duration of 80 seconds simulation time, no CBR packet can be transported successfully,all nodes are trying to set up route but not be completed till the end. > If anyone has made this kind of simulation, please tell me how. > > > Best Regards, > > SUN Liang > 2003-03-13 > > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu Mar 13 08:08: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 IAA29078 for ; Thu, 13 Mar 2003 08:08:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DDMT125378 for manet-archive@odin.ietf.org; Thu, 13 Mar 2003 08:22:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DDMTO25375 for ; Thu, 13 Mar 2003 08:22:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29073 for ; Thu, 13 Mar 2003 08:07:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DD3oO23506; Thu, 13 Mar 2003 08:03:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DCvwO23287 for ; Thu, 13 Mar 2003 07:57:58 -0500 Received: from smtp2.libero.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28445 for ; Thu, 13 Mar 2003 07:43:02 -0500 (EST) Received: from f1u2i7 (62.98.88.17) by smtp2.libero.it (6.7.015) id 3E48BA3400B9D2AD for manet@ietf.org; Thu, 13 Mar 2003 13:45:11 +0100 Message-ID: <006f01c2e95f$69baa600$1158623e@f1u2i7> From: "Luca S." To: Date: Thu, 13 Mar 2003 13:44:23 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01C2E966.A7C47000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [manet] Rx sensitivity in 802.11a Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Messaggio in formato MIME composto da piy parti. ------=_NextPart_000_0059_01C2E966.A7C47000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, I need a great help... Can some one help me? I am looking = for rx sensitivity in 802.11a to get an optimal link adaptation... Where can I find this info? Besides, I have another question? Is there a standard to realize link = adaptation? It seem standard not explane this implementation. Thanks, Luca... ------=_NextPart_000_0059_01C2E966.A7C47000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone, I need a great help... Can = some one=20 help me? I am looking for rx sensitivity in 802.11a to get an optimal = link=20 adaptation...
Where can I find this = info?
 
Besides, I have another question? Is = there a=20 standard to realize link adaptation? It seem standard not explane this=20 implementation.
 
Thanks,
Luca...
------=_NextPart_000_0059_01C2E966.A7C47000-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 13 10:16:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04864 for ; Thu, 13 Mar 2003 10:16:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DFUUQ03536 for manet-archive@odin.ietf.org; Thu, 13 Mar 2003 10:30:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFUUO03533 for ; Thu, 13 Mar 2003 10:30:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04796 for ; Thu, 13 Mar 2003 10:15:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFHPO02675; Thu, 13 Mar 2003 10:17:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DFB6O02417 for ; Thu, 13 Mar 2003 10:11:06 -0500 Received: from lenst.det.unifi.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03017 for ; Thu, 13 Mar 2003 09:56:04 -0500 (EST) Received: from CPQ23935158018 (dhcp-40.lenst-int [192.168.11.40]) by lenst.det.unifi.it (8.11.6/8.11.6) with SMTP id h2DEwE930163 for ; Thu, 13 Mar 2003 15:58:14 +0100 Message-ID: <000801c2e970$f106aa30$280ba8c0@CPQ23935158018> From: "Irene Innocenti" To: Date: Thu, 13 Mar 2003 15:57:59 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C2E979.522DC0C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [manet] document Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C2E979.522DC0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everybody, Does anyone know where I can find on the Internet this document: G.G.Finn. - "Routing and addressing problems in large metropolitan-scale = internetworks" - Mar.1987 Thanks in advance. Regards Irene ------=_NextPart_000_0005_01C2E979.522DC0C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everybody,
 
Does anyone know where I can find on = the Internet=20 this document:
 
G.G.Finn. - "Routing and addressing = problems in=20 large metropolitan-scale internetworks" - Mar.1987
 
Thanks in advance.
Regards
 
Irene
------=_NextPart_000_0005_01C2E979.522DC0C0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 13 14:29: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 OAA13975 for ; Thu, 13 Mar 2003 14:29:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJhmF24295 for manet-archive@odin.ietf.org; Thu, 13 Mar 2003 14:43:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJhmO24292 for ; Thu, 13 Mar 2003 14:43:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13949 for ; Thu, 13 Mar 2003 14:28:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJXoO22919; Thu, 13 Mar 2003 14:33:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJRUO22730 for ; Thu, 13 Mar 2003 14:27:30 -0500 Received: from itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13365 for ; Thu, 13 Mar 2003 14:12:25 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by itd.nrl.navy.mil (8.8.8+Sun/8.8.8) with ESMTP id OAA16302 for ; Thu, 13 Mar 2003 14:14:33 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2DJETlP013571 for ; Thu, 13 Mar 2003 14:14:34 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.0.1.45) with SMTP id M2003031314143327925 for ; Thu, 13 Mar 2003 14:14:33 -0500 Message-Id: <5.1.1.5.2.20030313133000.01565e78@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 13 Mar 2003 14:16:07 -0500 To: manet From: Joe Macker Subject: Re: [manet] 400 nodes in NS In-Reply-To: <20030313033342.30DC11CFAFD0C@sm203.163.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , At 11:35 AM 3/13/2003 +0800, =?GB2312?Q?=CB=EF=C1=C1?= wrote: >Hi, > > Has anyone ever made the ad hoc simulation with 400 nodes in NS? > In the duration of 80 seconds simulation time, no CBR packet can be transported successfully,all nodes are trying to set up route but not be completed till the end. > If anyone has made this kind of simulation, please tell me how. I reemphasize this is not an ns2 forum however. I remember doing some short, sparse (non interesting) 500 node demos (large diameters)....in which I exceeded the net diameter settings (at least for the AODV implementation around 32 hops)... In that case the route discovery was limited to a particular diameter by the NET_DIAMETER which I exceeded. I just ran a 500 node grid-based demo and the DSR implementation appears to have even a smaller route request hop limit. You can, of course, change this setting in the implementationif you want. This may be your problem. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 13 14:39:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14594 for ; Thu, 13 Mar 2003 14:39:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DJsRc25243 for manet-archive@odin.ietf.org; Thu, 13 Mar 2003 14:54:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJsRO25240 for ; Thu, 13 Mar 2003 14:54:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14585 for ; Thu, 13 Mar 2003 14:39:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJf0O24156; Thu, 13 Mar 2003 14:41:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DJasO23169 for ; Thu, 13 Mar 2003 14:36:54 -0500 Received: from itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13761 for ; Thu, 13 Mar 2003 14:21:49 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by itd.nrl.navy.mil (8.8.8+Sun/8.8.8) with ESMTP id OAA16757 for ; Thu, 13 Mar 2003 14:23:58 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2DJNxlL013753 for ; Thu, 13 Mar 2003 14:23:59 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.0.1.45) with SMTP id M2003031314235804848 for ; Thu, 13 Mar 2003 14:23:58 -0500 Message-Id: <5.1.1.5.2.20030313141920.02e58a70@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 13 Mar 2003 14:25:32 -0500 To: manet From: Joe Macker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] Homework for next meeting Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , All: Based upon our agreed to new milestones, we need to get to a WG Last Call stage on the three remaining IDs targeted for EXPERIMENTAL submission. If you are an interested WG participant please prepare by reviewing the latest ID revisions that have been posted. The meeting time to discuss these documents will be brief so preparation is critical for any productive discussions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 14 03:47:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19348 for ; Fri, 14 Mar 2003 03:47:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E92Nu25544 for manet-archive@odin.ietf.org; Fri, 14 Mar 2003 04:02:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E92NO25541 for ; Fri, 14 Mar 2003 04:02:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19341 for ; Fri, 14 Mar 2003 03:47:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E8iXO24292; Fri, 14 Mar 2003 03:44:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E8YlO23175 for ; Fri, 14 Mar 2003 03:34:47 -0500 Received: from mx.laposte.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18790 for ; Fri, 14 Mar 2003 03:19:26 -0500 (EST) Received: from laposte.net (127.0.0.1) by mx.laposte.net (6.0.053) id 3E66A2410017915B for manet@ietf.org; Fri, 14 Mar 2003 09:21:36 +0100 Date: Fri, 14 Mar 2003 09:21:36 +0100 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q?ghannay.sana@laposte.net?=" To: "=?iso-8859-1?Q?manet?=" X-XaM3-API-Version: 3.2 R29 (B54 pl1) X-type: 0 X-SenderIP: 193.95.33.25 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2E8YlO23176 Subject: [manet] =?iso-8859-1?Q?ad_hoc?= Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit je suis étudiante en master j'aimarai savoir ou se trouve les réferences suivantes : [4] A. Michail,W. Chen and A. Ephremides. Distributed routing and resource allocation for connection-oriented traffic in ad- hoc wireless networks. In Proc. of the Conference on Information Sciences and Systems (CISS-98), 1998. [5] A. Michail andA. Ephremides.Adistributed routing algorithm for supporting connection-oriented service in wireless networks with time-varying connectivity. In Proceedings of the 3rd IEEE International Symposium on Communications and Control, 1998. et si quel qu'un sait est qui'il peut me l'envoyer en pièce jointe merci Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)" _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 14 15:33:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13412 for ; Fri, 14 Mar 2003 15:33:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2EKmUY08480 for manet-archive@odin.ietf.org; Fri, 14 Mar 2003 15:48:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKmUO08477 for ; Fri, 14 Mar 2003 15:48:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13400 for ; Fri, 14 Mar 2003 15:32:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKRUO06587; Fri, 14 Mar 2003 15:27:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2EKLdO06391 for ; Fri, 14 Mar 2003 15:21:39 -0500 Received: from web20806.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11495 for ; Fri, 14 Mar 2003 15:06:03 -0500 (EST) Message-ID: <20030314200814.52151.qmail@web20806.mail.yahoo.com> Received: from [165.91.5.136] by web20806.mail.yahoo.com via HTTP; Fri, 14 Mar 2003 12:08:14 PST Date: Fri, 14 Mar 2003 12:08:14 -0800 (PST) From: Jianfeng Cai To: manet In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] How to get energy_model in a routing agent? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 posted this question in ns maillist but did not get the response. I want to do something about energy-awared routing. I don't know how to get the energy status in a routing agent. I found if a routing agent can get the pointer to the current node, then it is easy to obtain the energy_model(). But how can a routing agent get the pointer to the node it is attached? Any advice is appreciated. thanks, Jianfeng __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sat Mar 15 08:24:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15757 for ; Sat, 15 Mar 2003 08:24:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2FDeHT08454 for manet-archive@odin.ietf.org; Sat, 15 Mar 2003 08:40:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FDeHO08451 for ; Sat, 15 Mar 2003 08:40:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15720 for ; Sat, 15 Mar 2003 08:24:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FDQVO07175; Sat, 15 Mar 2003 08:26:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2FDFUO06946 for ; Sat, 15 Mar 2003 08:15:30 -0500 Received: from noya.bupt.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15350 for ; Sat, 15 Mar 2003 07:59:34 -0500 (EST) Received: from zoushh ([202.112.101.142]) by noya.bupt.edu.cn (8.12.8/8.12.8) with ESMTP id h2FD1gPo004085 for ; Sat, 15 Mar 2003 21:01:44 +0800 (CST) Message-Id: <200303151301.h2FD1gPo004085@noya.bupt.edu.cn> From: "=?GB2312?Q?=D7=DE=CA=CB=BA=E9?=" Reply-To: hoyli@bupt.edu.cn To: "manet@ietf.org" Organization: =?GB2312?Q?=B1=B1=BE=A9=D3=CA=B5=E7=B4=F3=D1=A7=B9=FA=BC=D2=D6=D8=B5=E3=CA=B5=D1=E9=CA=D2=BF=ED=B4=F8=CD=F8=D6=D0=D0=C4?= X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Date: Sat, 15 Mar 2003 21:5:28 +0800 Content-Transfer-Encoding: 7bit Subject: [manet] does every station can get exactly the same success transmissions and collisions in WLAN? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, when i design some mechanism with IEEE 802.11 in WLAN enviroment, where every station is in the receiving range of each other, can i assume that every station can get exactlty the same number of successful transmissions and that of collisions in a period? i think it should be the same for all stations. but when i do simulation with NS2, i found that some stations get different number of succeess and collisions through listening in a period(i have calculated transmission made by itself). has NS2 implemented some random error for wireless signal propagation? can somebody tell me why? thanks in advance! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Mar 16 09:17:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25375 for ; Sun, 16 Mar 2003 09:17:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GEXnH01632 for manet-archive@odin.ietf.org; Sun, 16 Mar 2003 09:33:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GEXnO01629 for ; Sun, 16 Mar 2003 09:33:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25370 for ; Sun, 16 Mar 2003 09:17:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GEHTO01153; Sun, 16 Mar 2003 09:17:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GE8dO01024 for ; Sun, 16 Mar 2003 09:08:39 -0500 Received: from mail.informatik.uni-ulm.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25139 for ; Sun, 16 Mar 2003 08:52:13 -0500 (EST) Received: from taipan.informatik.uni-ulm.de ([134.60.72.42] helo=informatik.uni-ulm.de) by mail.informatik.uni-ulm.de with esmtp (Exim 3.36 #1) id 18uYam-0008Pj-00 for manet@ietf.org; Sun, 16 Mar 2003 14:54:24 +0100 Message-ID: <3E747A0B.7000307@informatik.uni-ulm.de> Date: Sun, 16 Mar 2003 14:20:11 +0100 From: Liu Changling User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en, zh-CN MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] mulaticast routing protocol implementation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, anyone can provide information about ns or Glomosim implementation for ad hoc multicast routing protocols. Thanks in advance. Changling,Liu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Mar 16 12:01:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29659 for ; Sun, 16 Mar 2003 12:01:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2GHHLn10830 for manet-archive@odin.ietf.org; Sun, 16 Mar 2003 12:17:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GHHLO10827 for ; Sun, 16 Mar 2003 12:17:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29644 for ; Sun, 16 Mar 2003 12:00:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GH3QO09201; Sun, 16 Mar 2003 12:03:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2GGuiO08939 for ; Sun, 16 Mar 2003 11:56:44 -0500 Received: from ux3.sp.cs.cmu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28955 for ; Sun, 16 Mar 2003 11:40:15 -0500 (EST) Received: from ux3.sp.cs.cmu.edu ([127.0.0.1]) by ux3.sp.cs.cmu.edu id aa29036; 16 Mar 2003 11:42 EST Date: Sun, 16 Mar 2003 11:42:10 -0500 (EST) From: Jorjeta Gueorguieva Jetcheva X-X-Sender: To: changling.liu@informatik.uni-ulm.de MMDF-Warning: Parse error in original version of preceding line at ux3.sp.cs.cmu.edu cc: manet@ietf.org, jorjeta@cs.cmu.edu MMDF-Warning: Parse error in original version of preceding line at ux3.sp.cs.cmu.edu Subject: re: [manet] mulaticast routing protocol implementation 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: , My ns-2 implementations of ADMR and ODMRP are available on the Monarch Project website: http://www.monarch.cs.rice.edu/multicast_extensions.html Jorjeta ----------------------------------------------------------------------- Hello, anyone can provide information about ns or Glomosim implementation for ad hoc multicast routing protocols. Thanks in advance. Changling,Liu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= o j r e a o = o j t = o o = = o Jorjeta G. Jetcheva o = Ph.D. student, Computer Science = o Carnegie Mellon University o = = o http://www.cs.cmu.edu/~jorjeta o =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Mar 16 21:29:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16391 for ; Sun, 16 Mar 2003 21:29:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H2kAB12236 for manet-archive@odin.ietf.org; Sun, 16 Mar 2003 21:46:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H2kAO12233 for ; Sun, 16 Mar 2003 21:46:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16376 for ; Sun, 16 Mar 2003 21:29:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H2WsO10843; Sun, 16 Mar 2003 21:32:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H2OSO10609 for ; Sun, 16 Mar 2003 21:24:28 -0500 Received: from sm203.163.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15928 for ; Sun, 16 Mar 2003 21:07:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by sm203.163.com (Postfix) with SMTP id F04111CFA8C90 for ; Mon, 17 Mar 2003 10:09:53 +0800 (CST) Received: from hellsun (unknown [202.112.101.162]) by 192.168.1.203 (Coremail:www.163.com) with SMTP id OwQAAGIudT4QMWWi.1 for ; Mon, 17 Mar 2003 10:09:53 +0800 (CST) From: "=?GB2312?Q?=CB=EF=C1=C1?=" To: manet X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Date: Mon, 17 Mar 2003 10:11:34 +0800 Message-Id: <20030317020953.F04111CFA8C90@sm203.163.com> Content-Transfer-Encoding: 7bit Subject: [manet] An option in the DSR! Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, In the DSR, there is an option that the node can use the route information other packets carrying to another node , not this node. Can anyone knowing about it detail? Thanks! Best Regards, SUN Liang 2003-03-17 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Mar 16 23:48:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19684 for ; Sun, 16 Mar 2003 23:48:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H54j820545 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 00:04:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H54jO20542 for ; Mon, 17 Mar 2003 00:04:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19677 for ; Sun, 16 Mar 2003 23:48:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4q2O19980; Sun, 16 Mar 2003 23:52:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H4kCO19811 for ; Sun, 16 Mar 2003 23:46:12 -0500 Received: from exstudent9.city.unisa.edu.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19079 for ; Sun, 16 Mar 2003 23:29:28 -0500 (EST) Received: by exstudent9.city.unisa.edu.au with Internet Mail Service (5.5.2656.59) id ; Mon, 17 Mar 2003 14:59:28 +1030 Message-ID: From: "Liaw, Yong Shyang - LIAYS001" To: "'??'" , manet Subject: RE: [manet] An option in the DSR! Date: Mon, 17 Mar 2003 15:02:51 +1030 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="gb2312" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Is this really an option of DSR? In Section 3.3 of draft RFC, it says "A node forwarding or otherwise overhearing any packet SHOULD add all usable routing information from that packet to its own Route Cache.". > -----Original Message----- > From: sun7927@163.com [mailto:sun7927@163.com] > Sent: Monday, 17 March 2003 12:42 > To: manet > Subject: [manet] An option in the DSR! > > > Hi, > > In the DSR, there is an option that the node can use > the route information other packets carrying to another node > , not this node. Can anyone knowing about it detail? > Thanks! > > > Best Regards, > > SUN Liang > 2003-03-17 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 17 04:00: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 EAA07425 for ; Mon, 17 Mar 2003 04:00:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H9H8215989 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 04:17:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H9H8O15986 for ; Mon, 17 Mar 2003 04:17:08 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07419 for ; Mon, 17 Mar 2003 04:00:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H94SO14342; Mon, 17 Mar 2003 04:04:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H8wtO13853 for ; Mon, 17 Mar 2003 03:58:55 -0500 Received: from waldorf.cs.uni-dortmund.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06973 for ; Mon, 17 Mar 2003 03:42:04 -0500 (EST) Received: from postamt.cs.uni-dortmund.de (postamt [129.217.4.40]) by waldorf.cs.uni-dortmund.de with ESMTP id h2H8iHK23620 for ; Mon, 17 Mar 2003 09:44:17 +0100 (MET) Received: from bush.cs.uni-dortmund.de (bush [129.217.16.89]) (authenticated bits=0) by postamt.cs.uni-dortmund.de (8.12.8/8.12.7) with ESMTP id h2H8i9V4011068 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 17 Mar 2003 09:44:09 +0100 (MET) From: Alexander Klemm Reply-To: klemm@ls4.cs.uni-dortmund.de Organization: University of Dortmund To: manet@ietf.org Subject: Re: [manet] mulaticast routing protocol implementation Date: Mon, 17 Mar 2003 09:44:09 +0100 User-Agent: KMail/1.5 References: <3E747A0B.7000307@informatik.uni-ulm.de> In-Reply-To: <3E747A0B.7000307@informatik.uni-ulm.de> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200303170942.56823.klemm@ls4.cs.uni-dortmund.de> X-UID: 175 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) / [schalter1] 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, you can find our ns-2 implementations for MAODV and the Multicast / Broadcast Extensions for DSR on our website: http://www4.cs.uni-dortmund.de/~Lindemann/projects/MobileP2P/ Alexander On Sunday 16 March 2003 14:20, Liu Changling wrote: > Hello, > > anyone can provide information about ns or Glomosim implementation for > ad hoc multicast routing protocols. > > Thanks in advance. > > Changling,Liu > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- -------------------------------------------------------------------------------- Alexander Klemm, M.S., University of Dortmund Department of Computer Science Phone: (+49231) 755-2690 -Computersystems and Performance Evaluation- Fax: (+49231) 755-2417 August-Schmidt-Str. 12 E-mail:ak@ls4.cs.uni-dortmund.de 44227 Dortmund WWW: http://www4.cs.uni-dortmund.de/~Klemm/ -------------------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 17 04:35: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 EAA08349 for ; Mon, 17 Mar 2003 04:35:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2H9pmP18753 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 04:51:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H9pmO18750 for ; Mon, 17 Mar 2003 04:51:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08335 for ; Mon, 17 Mar 2003 04:34:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H9dEO17891; Mon, 17 Mar 2003 04:39:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2H9Z0O16850 for ; Mon, 17 Mar 2003 04:35:00 -0500 Received: from web12102.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07871 for ; Mon, 17 Mar 2003 04:18:11 -0500 (EST) Message-ID: <20030317092023.16405.qmail@web12102.mail.yahoo.com> Received: from [130.192.1.135] by web12102.mail.yahoo.com via HTTP; Mon, 17 Mar 2003 01:20:23 PST Date: Mon, 17 Mar 2003 01:20:23 -0800 (PST) From: John Home Cortes To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] Simulator Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi everyone. I'm working on secure routing protocol for Ad Hoc Networks and I have to simulate protocols such as ARAN,SRP, ARIADNE and SAR. I currently donwloaded the software Ns-2 but I think it is necesary an extension of this software.. Anyone knows where to get this extensions o exist another alternative for simulate them (software)? I would appreciate for your help Thanks in advance.. John Home __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 17 06:32:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10708 for ; Mon, 17 Mar 2003 06:32:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HBmhb26109 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 06:48:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HBmhO26106 for ; Mon, 17 Mar 2003 06:48:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10704 for ; Mon, 17 Mar 2003 06:31:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HBNxO24491; Mon, 17 Mar 2003 06:23:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HBIvO24300 for ; Mon, 17 Mar 2003 06:18:57 -0500 Received: from drago.eurecom.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10259 for ; Mon, 17 Mar 2003 06:02:05 -0500 (EST) Received: from monza.eurecom.fr (localhost [127.0.0.1]) by drago.eurecom.fr (8.12.1/8.12.1) with ESMTP id h2HB4BlN017020; Mon, 17 Mar 2003 12:04:12 +0100 (MET) Received: from eurecom.fr (givry.eurecom.fr [172.17.20.35]) by monza.eurecom.fr (Postfix) with ESMTP id C6E673C2D9; Mon, 17 Mar 2003 12:04:11 +0100 (MET) Message-ID: <3E75ABAA.FE2B8B83@eurecom.fr> Date: Mon, 17 Mar 2003 12:04:10 +0100 From: Shiyi Wu Organization: http://www.eurecom.fr X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jorjeta Gueorguieva Jetcheva Cc: manet@ietf.org Subject: Re: [manet] mulaticast routing protocol implementation References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jorjeta Gueorguieva Jetcheva wrote: > > My ns-2 implementations of ADMR and ODMRP are available on the Monarch > Project website: > > http://www.monarch.cs.rice.edu/multicast_extensions.html > > Jorjeta > I can't download the files from this web link. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 17 11:56:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20240 for ; Mon, 17 Mar 2003 11:56:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HHCig15760 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 12:12:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHCiO15757 for ; Mon, 17 Mar 2003 12:12:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20209 for ; Mon, 17 Mar 2003 11:55:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGn9O13408; Mon, 17 Mar 2003 11:49:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HGhYO13178 for ; Mon, 17 Mar 2003 11:43:34 -0500 Received: from athena.bournemouth.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18895 for ; Mon, 17 Mar 2003 11:26:36 -0500 (EST) Received: from bournemouth.ac.uk (poole140.bournemouth.ac.uk [194.80.71.140]) by athena.bournemouth.ac.uk (Switch-2.1.0/Switch-2.1.0) with ESMTP id h2HHPnf03706 for ; Mon, 17 Mar 2003 17:25:49 GMT Message-ID: <3E75F6A3.C628D118@bournemouth.ac.uk> Date: Mon, 17 Mar 2003 16:24:03 +0000 From: pchatzimisios X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: manet@ietf.org References: <20030316170002.9096.14441.Mailman@www1.ietf.org> Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Subject: [manet] 802.11 protocol Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi everyone. Is anyone familiar with the packet delay in 802.11 protocol? For the moment I am using Opnet 9.0 but I have got some problems with that. Any help is appreciated. Peris. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 17 12:29:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21521 for ; Mon, 17 Mar 2003 12:29:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HHk3618628 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 12:46:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHk3O18625 for ; Mon, 17 Mar 2003 12:46:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21494 for ; Mon, 17 Mar 2003 12:29:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHL7O16232; Mon, 17 Mar 2003 12:21:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HHFfO16005 for ; Mon, 17 Mar 2003 12:15:41 -0500 Received: from smtpproxy2.mitre.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20335 for ; Mon, 17 Mar 2003 11:58:40 -0500 (EST) Received: from avsrv2.mitre.org (avsrv2.mitre.org [128.29.154.4]) by smtpproxy2.mitre.org (8.12.8/8.12.8) with ESMTP id h2HH0iOC016566; Mon, 17 Mar 2003 12:00:45 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv2.mitre.org (8.12.8/8.12.8) with ESMTP id h2HH0Rk2018569; Mon, 17 Mar 2003 12:00:28 -0500 (EST) Received: from dnichols.mitre.org (129.83.64.30) by mailhub1.mitre.org with SMTP id 1540322; Mon, 17 Mar 2003 12:00:21 -0500 Message-ID: <3E75FEEF.9020506@mitre.org> Date: Mon, 17 Mar 2003 11:59:27 -0500 From: Kenneth Brayer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Liaw, Yong Shyang - LIAYS001" CC: "'??'" , manet Subject: Re: [manet] An option in the DSR! References: Content-Type: multipart/alternative; boundary="------------060504090908050001030506" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , --------------060504090908050001030506 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit The idea was originally published 20 years ago in Packet Switching for Mobile Earth Stations via Low-Orbit Satellite Network , K. Brayer, Proceedings of the IEEE, November 1984 Reading of the article will give you a description of how it works in updating routing tables. Ken Liaw, Yong Shyang - LIAYS001 wrote: >Is this really an option of DSR? In Section 3.3 of draft RFC, it says "A node >forwarding or otherwise overhearing any packet SHOULD add all > usable routing information from that packet to its own Route Cache.". > > > > > > > >>-----Original Message----- >>From: sun7927@163.com [mailto:sun7927@163.com] >>Sent: Monday, 17 March 2003 12:42 >>To: manet >>Subject: [manet] An option in the DSR! >> >> >>Hi, >> >> In the DSR, there is an option that the node can use >>the route information other packets carrying to another node >>, not this node. Can anyone knowing about it detail? >> Thanks! >> >> >>Best Regards, >> >> SUN Liang >> 2003-03-17 >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet >> >> >> >> >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > -- Kenneth Brayer M/S B312 The MITRE Corporation 202 Burlington Road Bedford, MA 01730 e-mail: kb@mitre.org tele: 781-271-5254 fax: 781-271-2841 --------------060504090908050001030506 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 7bit The idea was originally published 20 years ago in

Packet Switching for Mobile Earth Stations via Low-Orbit Satellite Network, K. Brayer, Proceedings of the IEEE, November 1984

Reading of the article will give you a description of how it works in updating routing tables.

Ken

Liaw, Yong Shyang - LIAYS001 wrote:
Is this really an option of DSR? In Section 3.3 of draft RFC, it says "A node
forwarding or otherwise overhearing any packet SHOULD add all
   usable routing information from that packet to its own Route Cache.".



    

  
-----Original Message-----
From: sun7927@163.com [mailto:sun7927@163.com]
Sent: Monday, 17 March 2003 12:42
To: manet
Subject: [manet] An option in the DSR!


Hi,

	In the DSR, there is an option that the node can use 
the route information other packets carrying to another node 
, not this node. Can anyone knowing about it detail? 
	Thanks!


Best Regards,

				  SUN Liang
             	  2003-03-17


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


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

-- 
Kenneth Brayer
M/S B312
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730

e-mail: kb@mitre.org
tele: 781-271-5254
fax: 781-271-2841

--------------060504090908050001030506-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 17 14:24:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26131 for ; Mon, 17 Mar 2003 14:24:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2HJfOJ28194 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 14:41:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJfOO28191 for ; Mon, 17 Mar 2003 14:41:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26062 for ; Mon, 17 Mar 2003 14:24:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJMEO26209; Mon, 17 Mar 2003 14:22:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HJIaO26016 for ; Mon, 17 Mar 2003 14:18:36 -0500 Received: from ux6.sp.cs.cmu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25090 for ; Mon, 17 Mar 2003 14:01:33 -0500 (EST) Date: Mon, 17 Mar 2003 14:03:09 -0500 (EST) From: Yih-Chun Hu X-Sender: yihchun@ux6.sp.cs.cmu.edu To: John Home Cortes cc: manet@ietf.org Subject: Re: [manet] Simulator In-Reply-To: <20030317092023.16405.qmail@web12102.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi John, I've built simulations for Ariadne and SEAD on an old version of ns (ns-2.1b3). Details are at http://monarch.cs.rice.edu/software.html Hope this helps, Yih-Chun On Mon, 17 Mar 2003, John Home Cortes wrote: >Hi everyone. > >I'm working on secure routing protocol for Ad Hoc >Networks and I have to simulate protocols such as >ARAN,SRP, ARIADNE and SAR. I currently donwloaded the >software Ns-2 but I think it is necesary an extension >of this software.. >Anyone knows where to get this extensions o exist >another alternative for simulate them (software)? > >I would appreciate for your help > >Thanks in advance.. > >John Home > > > >__________________________________________________ >Do you Yahoo!? >Yahoo! Web Hosting - establish your business online >http://webhosting.yahoo.com >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 17 18:48:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08511 for ; Mon, 17 Mar 2003 18:48:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I05DS15782 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 19:05:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I05DO15779 for ; Mon, 17 Mar 2003 19:05:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08499 for ; Mon, 17 Mar 2003 18:48:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNqZO14961; Mon, 17 Mar 2003 18:52:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2HNmrO14867 for ; Mon, 17 Mar 2003 18:48:53 -0500 Received: from localhost.localdomain (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07866 for ; Mon, 17 Mar 2003 18:31:46 -0500 (EST) From: junk@sachitano.net Received: from sachitano.net (taniquetil.sachitano.net [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with SMTP id h2HNXx408656 for ; Mon, 17 Mar 2003 15:33:59 -0800 Received: from 131.204.31.81 (SquirrelMail authenticated user junk) by squirrelmail.sachitano.net with HTTP; Mon, 17 Mar 2003 15:33:59 -0800 (PST) Message-ID: <4713.131.204.31.81.1047944039.squirrel@squirrelmail.sachitano.net> Date: Mon, 17 Mar 2003 15:33:59 -0800 (PST) To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [manet] opnet NIST/AFIT dsr model Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit i don't want to get the list into the business of opnet support, but is anyone willing to help me verify the broken-ness (or not) of the AFIT-DSR models in opnet 8.0.C? please reply to list or email. thanks in advance, adam sachitano junk@sachitano.net _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 17 19:46:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10437 for ; Mon, 17 Mar 2003 19:46:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I13Gl20259 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 20:03:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I13GO20256 for ; Mon, 17 Mar 2003 20:03:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10422 for ; Mon, 17 Mar 2003 19:46:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I0fiO19242; Mon, 17 Mar 2003 19:41:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I0cdO19081 for ; Mon, 17 Mar 2003 19:38:39 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09772 for ; Mon, 17 Mar 2003 19:21:31 -0500 (EST) Received: from olympic (olympic [128.111.40.86]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2I0Nd113790; Mon, 17 Mar 2003 16:23:40 -0800 (PST) Date: Mon, 17 Mar 2003 16:23:39 -0800 (PST) From: "Kimaya M. Sanzgiri" X-Sender: kimaya@olympic To: Yih-Chun Hu cc: John Home Cortes , manet@ietf.org Subject: Re: [manet] Simulator In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , I only have Glomosim code for ARAN - no NS2 code. Let me know if you'd like to use the Glomosim code and I could make it available to you. Kimaya On Mon, 17 Mar 2003, Yih-Chun Hu wrote: > > Hi John, > > I've built simulations for Ariadne and SEAD on an old version of ns > (ns-2.1b3). Details are at http://monarch.cs.rice.edu/software.html > > Hope this helps, > Yih-Chun > > On Mon, 17 Mar 2003, John Home Cortes wrote: > > >Hi everyone. > > > >I'm working on secure routing protocol for Ad Hoc > >Networks and I have to simulate protocols such as > >ARAN,SRP, ARIADNE and SAR. I currently donwloaded the > >software Ns-2 but I think it is necesary an extension > >of this software.. > >Anyone knows where to get this extensions o exist > >another alternative for simulate them (software)? > > > >I would appreciate for your help > > > >Thanks in advance.. > > > >John Home > > > > > > > >__________________________________________________ > >Do you Yahoo!? > >Yahoo! Web Hosting - establish your business online > >http://webhosting.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 mailnull@www1.ietf.org Mon Mar 17 20:57:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12848 for ; Mon, 17 Mar 2003 20:57:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2I2Dxx25820 for manet-archive@odin.ietf.org; Mon, 17 Mar 2003 21:13:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I2DwO25817 for ; Mon, 17 Mar 2003 21:13:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12841 for ; Mon, 17 Mar 2003 20:56:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I1tQO24319; Mon, 17 Mar 2003 20:55:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2I1pRO24190 for ; Mon, 17 Mar 2003 20:51:27 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12379 for ; Mon, 17 Mar 2003 20:34:16 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Mar 2003 17:36:30 -0800 Received: from 137.132.3.10 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 18 Mar 2003 01:36:29 GMT X-Originating-IP: [137.132.3.10] From: "lu guoxiang" To: manet@ietf.org Date: Tue, 18 Mar 2003 01:36:29 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Mar 2003 01:36:30.0233 (UTC) FILETIME=[CCCFB090:01C2ECEE] Subject: [manet] discussion on the routing protocol at Link Layer Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 implementing a bridging method by which the data forwarding function is realised at the data link layer. i would like to hear your comment on the pros and cons of this protocol. first of all, the nodes will form clusters and the bridges which are used to communicate neighboring clusters are selected. and, it is a reactive routing protocol. b4 sending data to dst, the src will multicast a "Request_MAC" message that asking the mac address of the dst. only the bridges elected are resposible to forwarding the "Request_Mac" message. when dst recv the "Request_Mac", it will unitcast a reply back with its MAC address. this process is like AODV except for the addtional MAC address of the dst. same as the AODV, during the request and reply process, all the intermediate nodes that either receive request or reply know the way to the src or dst or both. after the src get dst's MAC address, it will unicast the data pkt to the dst. when a intermediate node recv a data pkt, it will check whether it has the route or not. if it has, just forward the pkt to the dst. otherwise, it will multicast the pkt to bridges. the intermediate nodes, which relay the data pkt, actually do the routing at the datalink layer. it won't pass the pkt to the network layer, cause it knows the dst's mac addr as well as next hop's mac addr. by doing this, we can reduce some processing time. and by the cluster formation, we the "Request_MAC" message are not blindly flooded. thus, we can reduce the routing load. ok, it is just a brief description on my routing protocol. your valuable comments on it are greatly appreciated. cheers, guoxiang _________________________________________________________________ Take a break! Find destinations on MSN Travel. http://www.msn.com.sg/travel/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 18 13:46: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 NAA23317 for ; Tue, 18 Mar 2003 13:46:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IJ32407126 for manet-archive@odin.ietf.org; Tue, 18 Mar 2003 14:03:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IJ32O07123 for ; Tue, 18 Mar 2003 14:03:02 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23288 for ; Tue, 18 Mar 2003 13:45:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIqpO06255; Tue, 18 Mar 2003 13:52:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIljO05985 for ; Tue, 18 Mar 2003 13:47:45 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22663 for ; Tue, 18 Mar 2003 13:30:14 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id KAA27878; Tue, 18 Mar 2003 10:32:27 -0800 (PST) Message-Id: <200303181832.KAA27878@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] I-D ACTION:draft-ietf-manet-olsr-08.txt Date: Tue, 18 Mar 2003 10:32:27 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , All, Section 5.4 (TC Message Generation) of the OLSR draft says: "The list of addresses can be partial in each TC message (e.g. due to message size limitations, imposed by the network), but parsing of all TC messages describing the advertised link set of a node MUST be complete within a certain refreshing period (TC_INTERVAL)." "Parsing" is usually done when a message is received, not sent. Should this be changed to "generating"? Since messages are not sent reliably, a node might not even *receive* all of the partial TC messages describing the advertised link set of a node, so it cannot be required to parse all of them. This can cause a problem when processing partial TC messages, since step 3 of Section 5.6 (TC Message Processing) says that upon receiving a TC message with higher sequence number, all tuples in the topology set with lower sequence numbers MUST be removed. Suppose, for example, that the advertised link set of some node U is broken into 5 partial TC messages, with 1 second between consecutive messages. Also suppose that topology changes are frequent enough so that some change to the advertised link set occurs at least once during each TC_INTERVAL = 5 sec (so that the sequence number is incremented). As soon as the first partial TC message with a higher sequence number is received by some node I, node I must remove all tuples originating from U that are not included in that first partial TC message. Node I will then not have all of the tuples for U until 4 seconds later, shortly before the sequence number is incremented again. Also, it is possible that not all of the 5 partial TC messages are received by node I. Thus, node I unnecessarily deletes useful topology information, which can result in the loss of routes to some destinations. OSPF for IPv6 avoids this problem for Router LSAs by using Link-State IDs, and for Network LSAs by not allowing them to be partial. Similarly, OLSR could be fixed by assigning different Link-State IDs to different subsets of the advertised link set (to allow partial TC messages), or by requiring each TC message to include the entire advertised link set (i.e., don't allow partial TC messages). In order to truly allow differential topology updates, e.g., to report a single link failure immediately without having to send a full update, it must be possible for a node to process such a differential update without deleting all previously received updates originating from the same node. TBRPF does this by using a combination of differential updates (including delete updates) and periodic full updates. Regards, Richard ----------------------- Richard Ogier Sr. Research Engineer SRI International 333 Ravenswood Ave. Menlo Park, CA 94025 Tel: 650-859-4216 Fax: 650-859-4812 Email: ogier@erg.sri.com ------------------------ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 12:20:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26544 for ; Wed, 19 Mar 2003 12:20:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JHcPE14097 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 12:38:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JHcPO14094 for ; Wed, 19 Mar 2003 12:38:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26527 for ; Wed, 19 Mar 2003 12:20:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JHJuO12126; Wed, 19 Mar 2003 12:19:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JHBxO11627 for ; Wed, 19 Mar 2003 12:11:59 -0500 Received: from relay1.clb.oleane.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25688 for ; Wed, 19 Mar 2003 11:54:00 -0500 (EST) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by relay1.clb.oleane.net with SMTP id h2JGuFcu010489 for ; Wed, 19 Mar 2003 17:56:15 +0100 Message-ID: <00ae01c2ee38$86dffa40$0601a8c0@oleane.com> From: "Peter Lewis" To: Date: Wed, 19 Mar 2003 17:56:46 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01C2EE40.E8599DA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [manet] Ultra Wide Band summit - call for proposals Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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_00AB_01C2EE40.E8599DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does the UWB (Ultra Wideband) spectral transmission technology = constitute the broadband future for mobile and Wireless LAN = communications? The Ultra Wide Band summit, to be held next 2-5 December = in Paris, will bring detailed answers to this question. A call for = proposals is online at: http://www.upperside.fr/newmobtech/uwb03cfp.htm ------=_NextPart_000_00AB_01C2EE40.E8599DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Does the UWB (Ultra Wideband) spectral transmission technology = constitute the=20 broadband future for mobile and Wireless LAN communications? The Ultra = Wide Band=20 summit, to be held next 2-5 December in Paris, will bring detailed = answers to=20 this question. A call for proposals is online at:

http://www.upper= side.fr/newmobtech/uwb03cfp.htm

 
------=_NextPart_000_00AB_01C2EE40.E8599DA0-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 12:59: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 MAA28138 for ; Wed, 19 Mar 2003 12:59:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JIGUO17467 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 13:16:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JIGTO17464 for ; Wed, 19 Mar 2003 13:16:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28086 for ; Wed, 19 Mar 2003 12:58:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JI2CO15467; Wed, 19 Mar 2003 13:02:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JHwAO15146 for ; Wed, 19 Mar 2003 12:58:10 -0500 Received: from post.webmailer.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27149 for ; Wed, 19 Mar 2003 12:40:10 -0500 (EST) Received: from barytde (wl-131-241.wireless.ietf56.ietf.org [130.129.131.241]) by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h2JHgIje021656 for ; Wed, 19 Mar 2003 18:42:24 +0100 (MET) Reply-To: From: "Thorsten Claus" To: "manet" Subject: RE: [manet] Ultra Wide Band summit - call for proposals Date: Wed, 19 Mar 2003 09:42:01 -0800 Organization: baryt.de Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <00ae01c2ee38$86dffa40$0601a8c0@oleane.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2JHwAO15147 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 There are drawbacks in UWB in broadcasts, a technical discussion can be found at http://www.eecs.umich.edu/~stark/2002C.pdf A better overview (also with discussion about protocols) is http://inrg.csie.ntu.edu.tw/2002/The%20Broadcasting%20Problem%20in%20wireles s%20Ad-Hoc%20Network.ppt (sorry, PowerPoint :() Interesting might be http://rider.wharton.upenn.edu/~faulhabe/732/Wireless%20Technologies.html Thorsten Claus -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Peter Lewis Sent: Wednesday, March 19, 2003 8:57 AM To: manet@ietf.org Subject: [manet] Ultra Wide Band summit - call for proposals Does the UWB (Ultra Wideband) spectral transmission technology constitute the broadband future for mobile and Wireless LAN communications? The Ultra Wide Band summit, to be held next 2-5 December in Paris, will bring detailed answers to this question. A call for proposals is online at: http://www.upperside.fr/newmobtech/uwb03cfp.htm   _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 14:25:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02044 for ; Wed, 19 Mar 2003 14:25:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JJgoY26108 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 14:42:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJgnO26105 for ; Wed, 19 Mar 2003 14:42:49 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02029 for ; Wed, 19 Mar 2003 14:24:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJWgO24680; Wed, 19 Mar 2003 14:32:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJReO24423 for ; Wed, 19 Mar 2003 14:27:40 -0500 Received: from concorde.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01457 for ; Wed, 19 Mar 2003 14:09:39 -0500 (EST) Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h2JJBCf02566; Wed, 19 Mar 2003 20:11:12 +0100 (MET) Message-ID: <003b01c2ee4f$7bcc2a40$74828182@inria.fr> From: "Philippe Jacquet" To: , References: <200303181832.KAA27878@pit.erg.sri.com> Subject: Re: [manet] I-D ACTION:draft-ietf-manet-olsr-08.txt Date: Wed, 19 Mar 2003 20:40:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Well, it looks like a non-issue. A TC which contains only the originator MPR selector set should fit the MTU limitation. If the avertized set contains more than the MPR selector set and does not fit the MTU limitation, then a node should first send a TC with the new MPR selector set (such that routes through the originator of the TC are immediately available), then send the remans of the advertized link set in other TC's with small interval jitters. On the other hand, I don't think it is safe to mixte differential updates with full updates, this may lead to unconsistency problems. Philippe ----- Original Message ----- From: To: Cc: Sent: Tuesday, March 18, 2003 7:32 PM Subject: Re: [manet] I-D ACTION:draft-ietf-manet-olsr-08.txt > > All, > > Section 5.4 (TC Message Generation) of the OLSR draft says: > > "The list of addresses can be partial in each TC message (e.g. due to > message size limitations, imposed by the network), but parsing of all > TC messages describing the advertised link set of a node MUST be > complete within a certain refreshing period (TC_INTERVAL)." > > "Parsing" is usually done when a message is received, not sent. > Should this be changed to "generating"? Since messages are not > sent reliably, a node might not even *receive* all of the partial > TC messages describing the advertised link set of a node, so it > cannot be required to parse all of them. > > This can cause a problem when processing partial TC messages, > since step 3 of Section 5.6 (TC Message Processing) says that > upon receiving a TC message with higher sequence number, all > tuples in the topology set with lower sequence numbers MUST be > removed. Suppose, for example, that the advertised link set of > some node U is broken into 5 partial TC messages, with 1 second > between consecutive messages. Also suppose that topology changes > are frequent enough so that some change to the advertised link set > occurs at least once during each TC_INTERVAL = 5 sec (so that the > sequence number is incremented). As soon as the first partial TC > message with a higher sequence number is received by some node I, > node I must remove all tuples originating from U that are not > included in that first partial TC message. Node I will then not > have all of the tuples for U until 4 seconds later, shortly before > the sequence number is incremented again. Also, it is possible > that not all of the 5 partial TC messages are received by node I. > Thus, node I unnecessarily deletes useful topology information, > which can result in the loss of routes to some destinations. > > OSPF for IPv6 avoids this problem for Router LSAs by using > Link-State IDs, and for Network LSAs by not allowing them to be partial. > Similarly, OLSR could be fixed by assigning different Link-State IDs to > different subsets of the advertised link set (to allow partial TC messages), > or by requiring each TC message to include the entire advertised link set > (i.e., don't allow partial TC messages). > > In order to truly allow differential topology updates, e.g., to report > a single link failure immediately without having to send a full update, > it must be possible for a node to process such a differential update > without deleting all previously received updates originating from > the same node. TBRPF does this by using a combination of differential > updates (including delete updates) and periodic full updates. > > Regards, > Richard > > ----------------------- > Richard Ogier > Sr. Research Engineer > SRI International > 333 Ravenswood Ave. > Menlo Park, CA 94025 > Tel: 650-859-4216 > Fax: 650-859-4812 > Email: ogier@erg.sri.com > ------------------------ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 14:34:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02609 for ; Wed, 19 Mar 2003 14:34:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JJqMZ27183 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 14:52:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJqMO27180 for ; Wed, 19 Mar 2003 14:52:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02564 for ; Wed, 19 Mar 2003 14:34:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJePO25946; Wed, 19 Mar 2003 14:40:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJaeO24810 for ; Wed, 19 Mar 2003 14:36:40 -0500 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01749 for ; Wed, 19 Mar 2003 14:18:39 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2JJEHF06797 for ; Wed, 19 Mar 2003 19:14:18 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2JJF2t19749 for ; Wed, 19 Mar 2003 19:15:09 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003031911181408683 ; Wed, 19 Mar 2003 11:18:14 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 11:20:34 -0800 Message-ID: From: "Yang, Lily L" To: "'lu guoxiang'" , manet@ietf.org Subject: RE: [manet] discussion on the routing protocol at Link Layer Date: Wed, 19 Mar 2003 11:20:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Guoxiang -- This certainly sounds interesting. Most of the existing routing protocols for MENET are done at one layer up but we also believe there are certain advantages of doing this at the data link layer. Do you have a more complete documentation on this that you can share with us? Lily -----Original Message----- From: lu guoxiang [mailto:luguoxiang@hotmail.com] Sent: Monday, March 17, 2003 5:36 PM To: manet@ietf.org Subject: [manet] discussion on the routing protocol at Link Layer hi all, i am implementing a bridging method by which the data forwarding function is realised at the data link layer. i would like to hear your comment on the pros and cons of this protocol. first of all, the nodes will form clusters and the bridges which are used to communicate neighboring clusters are selected. and, it is a reactive routing protocol. b4 sending data to dst, the src will multicast a "Request_MAC" message that asking the mac address of the dst. only the bridges elected are resposible to forwarding the "Request_Mac" message. when dst recv the "Request_Mac", it will unitcast a reply back with its MAC address. this process is like AODV except for the addtional MAC address of the dst. same as the AODV, during the request and reply process, all the intermediate nodes that either receive request or reply know the way to the src or dst or both. after the src get dst's MAC address, it will unicast the data pkt to the dst. when a intermediate node recv a data pkt, it will check whether it has the route or not. if it has, just forward the pkt to the dst. otherwise, it will multicast the pkt to bridges. the intermediate nodes, which relay the data pkt, actually do the routing at the datalink layer. it won't pass the pkt to the network layer, cause it knows the dst's mac addr as well as next hop's mac addr. by doing this, we can reduce some processing time. and by the cluster formation, we the "Request_MAC" message are not blindly flooded. thus, we can reduce the routing load. ok, it is just a brief description on my routing protocol. your valuable comments on it are greatly appreciated. cheers, guoxiang _________________________________________________________________ Take a break! Find destinations on MSN Travel. http://www.msn.com.sg/travel/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 14:55:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03694 for ; Wed, 19 Mar 2003 14:55:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JKCUb30642 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 15:12:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JKCUO30639 for ; Wed, 19 Mar 2003 15:12:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03674 for ; Wed, 19 Mar 2003 14:54:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JK2VO28761; Wed, 19 Mar 2003 15:02:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JJxSO28544 for ; Wed, 19 Mar 2003 14:59:28 -0500 Received: from kiwi.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02914 for ; Wed, 19 Mar 2003 14:41:26 -0500 (EST) Received: from cs.ucla.edu ([131.179.120.120]) by kiwi.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h2JJhV307067; Wed, 19 Mar 2003 11:43:31 -0800 (PST) Message-ID: <3E78C864.1070602@cs.ucla.edu> Date: Wed, 19 Mar 2003 11:43:32 -0800 From: Mineo Takai 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: "Yang, Lily L" CC: "'lu guoxiang'" , manet@ietf.org Subject: Re: [manet] discussion on the routing protocol at Link Layer 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 Hi, DBS (Dynamic Backbone Subnets) by NRL is one of such routing mechanisms at the data link layer. They presented a tutorial at the IEEE 802 Plenary Meeting this month. http://www.ieee802.org/meeting/meeting_files/DBS%20AP-AP%20Routing.pdf Mineo Yang, Lily L wrote: > Guoxiang -- > This certainly sounds interesting. Most of the existing routing protocols > for MENET are done at one layer up but we also believe there are certain > advantages of doing this at the data link layer. > Do you have a more complete documentation on this that you can share with > us? > > Lily > > -----Original Message----- > From: lu guoxiang [mailto:luguoxiang@hotmail.com] > Sent: Monday, March 17, 2003 5:36 PM > To: manet@ietf.org > Subject: [manet] discussion on the routing protocol at Link Layer > > > > > > > > > > > > hi all, > > i am implementing a bridging method by which the data forwarding function is > > realised at the data link layer. i would like to hear your comment on the > pros and cons of this protocol. > > first of all, the nodes will form clusters and the bridges which are used to > > communicate neighboring clusters are selected. > > and, it is a reactive routing protocol. b4 sending data to dst, the src will > > multicast a "Request_MAC" message that asking the mac address of the dst. > only the bridges elected are resposible to forwarding the "Request_Mac" > message. > when dst recv the "Request_Mac", it will unitcast a reply back with its MAC > address. this process is like AODV except for the addtional MAC address of > the dst. same as the AODV, during the request and reply process, all the > intermediate nodes that either receive request or reply know the way to the > src or dst or both. > > after the src get dst's MAC address, it will unicast the data pkt to the > dst. when a intermediate node recv a data pkt, it will check whether it has > the route or not. if it has, just forward the pkt to the dst. otherwise, it > will multicast the pkt to bridges. > > the intermediate nodes, which relay the data pkt, actually do the routing at > > the datalink layer. it won't pass the pkt to the network layer, cause it > knows the dst's mac addr as well as next hop's mac addr. by doing this, we > can reduce some processing time. > > and by the cluster formation, we the "Request_MAC" message are not blindly > flooded. thus, we can reduce the routing load. > > ok, it is just a brief description on my routing protocol. your valuable > comments on it are greatly appreciated. > > cheers, > guoxiang > > > _________________________________________________________________ > Take a break! Find destinations on MSN Travel. http://www.msn.com.sg/travel/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 15:28: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 PAA06403 for ; Wed, 19 Mar 2003 15:28:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JKkLd01380 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 15:46:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JKkKO01377 for ; Wed, 19 Mar 2003 15:46:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06396 for ; Wed, 19 Mar 2003 15:28:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JKZEO32318; Wed, 19 Mar 2003 15:35:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JKVnO32149 for ; Wed, 19 Mar 2003 15:31:49 -0500 Received: from isrmail.isr.umd.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05658 for ; Wed, 19 Mar 2003 15:13:43 -0500 (EST) Received: from isr.umd.edu (doh.isr.umd.edu [128.8.140.151]) by isrmail.isr.umd.edu (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AJJ81800; Wed, 19 Mar 2003 15:15:47 -0500 (EST) Message-ID: <3E78CFF3.8090609@isr.umd.edu> Date: Wed, 19 Mar 2003 15:15:47 -0500 From: Manish Karir User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yang, Lily L" CC: "'lu guoxiang'" , manet@ietf.org Subject: Re: [manet] discussion on the routing protocol at Link Layer 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 I think LUNAR did something along those lines as well...: http://www.docs.uu.se/docs/research/projects/selnet/lunar/ manish Yang, Lily L wrote: > Guoxiang -- > This certainly sounds interesting. Most of the existing routing protocols > for MENET are done at one layer up but we also believe there are certain > advantages of doing this at the data link layer. > Do you have a more complete documentation on this that you can share with > us? > > Lily > > -----Original Message----- > From: lu guoxiang [mailto:luguoxiang@hotmail.com] > Sent: Monday, March 17, 2003 5:36 PM > To: manet@ietf.org > Subject: [manet] discussion on the routing protocol at Link Layer > > hi all, > > i am implementing a bridging method by which the data forwarding function is > > realised at the data link layer. i would like to hear your comment on the > pros and cons of this protocol. > > first of all, the nodes will form clusters and the bridges which are used to > > communicate neighboring clusters are selected. > > and, it is a reactive routing protocol. b4 sending data to dst, the src will > > multicast a "Request_MAC" message that asking the mac address of the dst. > only the bridges elected are resposible to forwarding the "Request_Mac" > message. > when dst recv the "Request_Mac", it will unitcast a reply back with its MAC > address. this process is like AODV except for the addtional MAC address of > the dst. same as the AODV, during the request and reply process, all the > intermediate nodes that either receive request or reply know the way to the > src or dst or both. > > after the src get dst's MAC address, it will unicast the data pkt to the > dst. when a intermediate node recv a data pkt, it will check whether it has > the route or not. if it has, just forward the pkt to the dst. otherwise, it > will multicast the pkt to bridges. > > the intermediate nodes, which relay the data pkt, actually do the routing at > > the datalink layer. it won't pass the pkt to the network layer, cause it > knows the dst's mac addr as well as next hop's mac addr. by doing this, we > can reduce some processing time. > > and by the cluster formation, we the "Request_MAC" message are not blindly > flooded. thus, we can reduce the routing load. > > ok, it is just a brief description on my routing protocol. your valuable > comments on it are greatly appreciated. > > cheers, > guoxiang _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 16:04:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07996 for ; Wed, 19 Mar 2003 16:04:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLLWi04793 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 16:21:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLLWO04790 for ; Wed, 19 Mar 2003 16:21:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07950 for ; Wed, 19 Mar 2003 16:03:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JL7XO03471; Wed, 19 Mar 2003 16:07:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JL4wO02604 for ; Wed, 19 Mar 2003 16:04:58 -0500 Received: from esl.cs.colorado.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06996 for ; Wed, 19 Mar 2003 15:46:55 -0500 (EST) Received: from cs.colorado.edu (home-dhcp4-53.Colorado.EDU [198.11.31.53]) (authenticated bits=0) by esl.cs.colorado.edu (8.12.6/8.12.6) with ESMTP id h2JKn74N028401 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Mar 2003 13:49:08 -0700 Message-ID: <3E78D71D.9020308@cs.colorado.edu> Date: Wed, 19 Mar 2003 13:46:21 -0700 From: Michael Neufeld User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manish Karir CC: "Yang, Lily L" , "'lu guoxiang'" , manet@ietf.org Subject: Re: [manet] discussion on the routing protocol at Link Layer References: <3E78CFF3.8090609@isr.umd.edu> In-Reply-To: <3E78CFF3.8090609@isr.umd.edu> 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 While they aren't explicitly "ad hoc" routing protocols, SmartBridge (http://citeseer.nj.nec.com/rodeheffer00smartbridge.html) and STAR Bridge (can't find the website right now) both do layer 2 bridging with an eye towards scalability. -Mike Manish Karir wrote: > > > I think LUNAR did something along those lines as well...: > > http://www.docs.uu.se/docs/research/projects/selnet/lunar/ > > manish > > > Yang, Lily L wrote: > >> Guoxiang -- >> This certainly sounds interesting. Most of the existing routing protocols >> for MENET are done at one layer up but we also believe there are certain >> advantages of doing this at the data link layer. Do you have a more >> complete documentation on this that you can share with >> us? >> Lily >> >> -----Original Message----- >> From: lu guoxiang [mailto:luguoxiang@hotmail.com] >> Sent: Monday, March 17, 2003 5:36 PM >> To: manet@ietf.org >> Subject: [manet] discussion on the routing protocol at Link Layer >> >> hi all, >> >> i am implementing a bridging method by which the data forwarding >> function is >> >> realised at the data link layer. i would like to hear your comment on >> the pros and cons of this protocol. >> >> first of all, the nodes will form clusters and the bridges which are >> used to >> >> communicate neighboring clusters are selected. >> >> and, it is a reactive routing protocol. b4 sending data to dst, the >> src will >> >> multicast a "Request_MAC" message that asking the mac address of the >> dst. only the bridges elected are resposible to forwarding the >> "Request_Mac" message. >> when dst recv the "Request_Mac", it will unitcast a reply back with >> its MAC address. this process is like AODV except for the addtional >> MAC address of the dst. same as the AODV, during the request and reply >> process, all the intermediate nodes that either receive request or >> reply know the way to the src or dst or both. >> >> after the src get dst's MAC address, it will unicast the data pkt to >> the dst. when a intermediate node recv a data pkt, it will check >> whether it has the route or not. if it has, just forward the pkt to >> the dst. otherwise, it will multicast the pkt to bridges. >> >> the intermediate nodes, which relay the data pkt, actually do the >> routing at >> >> the datalink layer. it won't pass the pkt to the network layer, cause >> it knows the dst's mac addr as well as next hop's mac addr. by doing >> this, we can reduce some processing time. >> >> and by the cluster formation, we the "Request_MAC" message are not >> blindly flooded. thus, we can reduce the routing load. >> >> ok, it is just a brief description on my routing protocol. your >> valuable comments on it are greatly appreciated. >> >> cheers, >> guoxiang > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 16:23:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08912 for ; Wed, 19 Mar 2003 16:23:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLfAR07050 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 16:41:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLfAO07043 for ; Wed, 19 Mar 2003 16:41:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08878 for ; Wed, 19 Mar 2003 16:23:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLVSO05478; Wed, 19 Mar 2003 16:31:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLRCO05195 for ; Wed, 19 Mar 2003 16:27:12 -0500 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08302 for ; Wed, 19 Mar 2003 16:09:09 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h2JLAceZ026560; Wed, 19 Mar 2003 16:10:38 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2JLAWWe008959; Wed, 19 Mar 2003 16:10:33 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003031916103203037 ; Wed, 19 Mar 2003 16:10:32 -0500 Message-Id: <5.1.1.5.2.20030319160537.014d12b8@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 19 Mar 2003 16:10:08 -0500 To: Mineo Takai , "Yang, Lily L" From: Joe Macker Subject: Re: [manet] discussion on the routing protocol at Link Layer Cc: "'lu guoxiang'" , manet@ietf.org In-Reply-To: <3E78C864.1070602@cs.ucla.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , HIPERLAN 1, also was a such a technique at a lower layer and OLSR is loosely based upon that work. There are also many other historical subnet approaches. MANET is chartered to work IP layer solutions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 16:35:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10120 for ; Wed, 19 Mar 2003 16:35:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLr0q08836 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 16:53:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLr0O08830 for ; Wed, 19 Mar 2003 16:53:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10053 for ; Wed, 19 Mar 2003 16:34:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLcUO06798; Wed, 19 Mar 2003 16:38:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLUVO05423 for ; Wed, 19 Mar 2003 16:30:31 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08450 for ; Wed, 19 Mar 2003 16:12:27 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id NAA03289; Wed, 19 Mar 2003 13:14:38 -0800 (PST) Message-Id: <200303192114.NAA03289@pit.erg.sri.com> To: "Philippe Jacquet" cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] I-D ACTION:draft-ietf-manet-olsr-08.txt In-reply-to: Your message of "Wed, 19 Mar 2003 20:40:58 +0100." <003b01c2ee4f$7bcc2a40$74828182@inria.fr> Date: Wed, 19 Mar 2003 13:14:38 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > Well, it looks like a non-issue. A TC which contains only the > originator MPR selector set should fit the MTU limitation. If the > avertized set contains more than the MPR selector set and does not > fit the MTU limitation, then a node should first send a TC with the > new MPR selector set (such that routes through the originator of the TC > are immediately available), then send the remans of the advertized > link set in other TC's with small interval jitters. A node with a large value for Willingness might have an MPR selector set that includes all of its neighbors, which might not fit the MTU limitation. So, OLSR must either limit the number of neighbors that can be reported as MPR selectors, or must sometimes send TC messages that do not include the entire MPR selector set (resulting in the temporary deletion of useful information), or must sometimes require IP fragmentation (no big deal if only two packets). In any case, some change to the OLSR draft is needed, such as: "A TC Message with a new sequence number SHOULD include the entire MPR selector set whenever possible." > On the other hand, I don't think it is safe to mixte differential updates > with full updates, this may lead to unconsistency problems. It can be done safely if you are careful (e.g., as in TBRPF and DSDV). Since the full updates are periodic, all nodes will eventually have the correct information even if some packets are not received, or are received out of order. Regards, Richard > > Philippe > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, March 18, 2003 7:32 PM > Subject: Re: [manet] I-D ACTION:draft-ietf-manet-olsr-08.txt > > > > > > All, > > > > Section 5.4 (TC Message Generation) of the OLSR draft says: > > > > "The list of addresses can be partial in each TC message (e.g. due to > > message size limitations, imposed by the network), but parsing of all > > TC messages describing the advertised link set of a node MUST be > > complete within a certain refreshing period (TC_INTERVAL)." > > > > "Parsing" is usually done when a message is received, not sent. > > Should this be changed to "generating"? Since messages are not > > sent reliably, a node might not even *receive* all of the partial > > TC messages describing the advertised link set of a node, so it > > cannot be required to parse all of them. > > > > This can cause a problem when processing partial TC messages, > > since step 3 of Section 5.6 (TC Message Processing) says that > > upon receiving a TC message with higher sequence number, all > > tuples in the topology set with lower sequence numbers MUST be > > removed. Suppose, for example, that the advertised link set of > > some node U is broken into 5 partial TC messages, with 1 second > > between consecutive messages. Also suppose that topology changes > > are frequent enough so that some change to the advertised link set > > occurs at least once during each TC_INTERVAL = 5 sec (so that the > > sequence number is incremented). As soon as the first partial TC > > message with a higher sequence number is received by some node I, > > node I must remove all tuples originating from U that are not > > included in that first partial TC message. Node I will then not > > have all of the tuples for U until 4 seconds later, shortly before > > the sequence number is incremented again. Also, it is possible > > that not all of the 5 partial TC messages are received by node I. > > Thus, node I unnecessarily deletes useful topology information, > > which can result in the loss of routes to some destinations. > > > > OSPF for IPv6 avoids this problem for Router LSAs by using > > Link-State IDs, and for Network LSAs by not allowing them to be partial. > > Similarly, OLSR could be fixed by assigning different Link-State IDs to > > different subsets of the advertised link set (to allow partial TC > messages), > > or by requiring each TC message to include the entire advertised link set > > (i.e., don't allow partial TC messages). > > > > In order to truly allow differential topology updates, e.g., to report > > a single link failure immediately without having to send a full update, > > it must be possible for a node to process such a differential update > > without deleting all previously received updates originating from > > the same node. TBRPF does this by using a combination of differential > > updates (including delete updates) and periodic full updates. > > > > Regards, > > Richard > > > > ----------------------- > > Richard Ogier > > Sr. Research Engineer > > SRI International > > 333 Ravenswood Ave. > > Menlo Park, CA 94025 > > Tel: 650-859-4216 > > Fax: 650-859-4812 > > Email: ogier@erg.sri.com > > ------------------------ > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 22:38:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22546 for ; Wed, 19 Mar 2003 22:38:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K3uS303861 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 22:56:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K3uRO03858 for ; Wed, 19 Mar 2003 22:56:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22522 for ; Wed, 19 Mar 2003 22:38:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K3iEO03247; Wed, 19 Mar 2003 22:44:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K3XtO02219 for ; Wed, 19 Mar 2003 22:33:55 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22021 for ; Wed, 19 Mar 2003 22:15:44 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 19 Mar 2003 19:17:59 -0800 Received: from 137.132.3.10 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 20 Mar 2003 03:17:55 GMT X-Originating-IP: [137.132.3.10] X-Originating-Email: [luguoxiang@hotmail.com] From: "lu guoxiang" To: neufeldm@cs.colorado.edu, karir@isr.umd.edu Cc: lily.l.yang@intel.com, manet@ietf.org Subject: Re: [manet] discussion on the routing protocol at Link Layer Date: Thu, 20 Mar 2003 03:17:55 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 20 Mar 2003 03:17:59.0301 (UTC) FILETIME=[4F013B50:01C2EE8F] Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, thanks for your guys' replies. i am just thinking out of the algo & mechanism right now. however, i will write document on it. once i am done, i will put it on the web to share with you. :) regards, guoxiang >From: Michael Neufeld >To: Manish Karir >CC: "Yang, Lily L" , "'lu guoxiang'" >, manet@ietf.org >Subject: Re: [manet] discussion on the routing protocol at Link Layer >Date: Wed, 19 Mar 2003 13:46:21 -0700 > >While they aren't explicitly "ad hoc" routing protocols, SmartBridge >(http://citeseer.nj.nec.com/rodeheffer00smartbridge.html) and STAR Bridge >(can't find the website right now) both do layer 2 bridging with an eye >towards scalability. > >-Mike > >Manish Karir wrote: >> >> >>I think LUNAR did something along those lines as well...: >> >>http://www.docs.uu.se/docs/research/projects/selnet/lunar/ >> >>manish >> >> >>Yang, Lily L wrote: >> >>>Guoxiang -- >>>This certainly sounds interesting. Most of the existing routing protocols >>>for MENET are done at one layer up but we also believe there are certain >>>advantages of doing this at the data link layer. Do you have a more >>>complete documentation on this that you can share with >>>us? >>>Lily >>> >>>-----Original Message----- >>>From: lu guoxiang [mailto:luguoxiang@hotmail.com] >>>Sent: Monday, March 17, 2003 5:36 PM >>>To: manet@ietf.org >>>Subject: [manet] discussion on the routing protocol at Link Layer >>> >>>hi all, >>> >>>i am implementing a bridging method by which the data forwarding function >>>is >>> >>>realised at the data link layer. i would like to hear your comment on the >>>pros and cons of this protocol. >>> >>>first of all, the nodes will form clusters and the bridges which are used >>>to >>> >>>communicate neighboring clusters are selected. >>> >>>and, it is a reactive routing protocol. b4 sending data to dst, the src >>>will >>> >>>multicast a "Request_MAC" message that asking the mac address of the dst. >>>only the bridges elected are resposible to forwarding the "Request_Mac" >>>message. >>>when dst recv the "Request_Mac", it will unitcast a reply back with its >>>MAC address. this process is like AODV except for the addtional MAC >>>address of the dst. same as the AODV, during the request and reply >>>process, all the intermediate nodes that either receive request or reply >>>know the way to the src or dst or both. >>> >>>after the src get dst's MAC address, it will unicast the data pkt to the >>>dst. when a intermediate node recv a data pkt, it will check whether it >>>has the route or not. if it has, just forward the pkt to the dst. >>>otherwise, it will multicast the pkt to bridges. >>> >>>the intermediate nodes, which relay the data pkt, actually do the routing >>>at >>> >>>the datalink layer. it won't pass the pkt to the network layer, cause it >>>knows the dst's mac addr as well as next hop's mac addr. by doing this, >>>we can reduce some processing time. >>> >>>and by the cluster formation, we the "Request_MAC" message are not >>>blindly flooded. thus, we can reduce the routing load. >>> >>>ok, it is just a brief description on my routing protocol. your valuable >>>comments on it are greatly appreciated. >>> >>>cheers, >>>guoxiang >> >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www1.ietf.org/mailman/listinfo/manet _________________________________________________________________ Find gifts, buy online with MSN Shopping. http://shopping.msn.com.sg/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 19 23:05:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23221 for ; Wed, 19 Mar 2003 23:05:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2K4NKm05927 for manet-archive@odin.ietf.org; Wed, 19 Mar 2003 23:23:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4NKO05924 for ; Wed, 19 Mar 2003 23:23:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23188 for ; Wed, 19 Mar 2003 23:05:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4DOO05309; Wed, 19 Mar 2003 23:13:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2K4AeO05209 for ; Wed, 19 Mar 2003 23:10:40 -0500 Received: from caduceus.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22867 for ; Wed, 19 Mar 2003 22:52:29 -0500 (EST) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2K3m8025965 for ; Thu, 20 Mar 2003 03:48:09 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2JLcu811984 for ; Wed, 19 Mar 2003 21:38:56 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003031913403031354 ; Wed, 19 Mar 2003 13:40:30 -0800 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Mar 2003 13:37:30 -0800 Message-ID: From: "Yang, Lily L" To: "'Joe Macker'" , Mineo Takai , "Yang, Lily L" Cc: "'lu guoxiang'" , manet@ietf.org Subject: RE: [manet] discussion on the routing protocol at Link Layer Date: Wed, 19 Mar 2003 13:37:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Anybody aware of any technical comprehensive analysis or comparison of doing this for mesh networks at layer 2 versus layer 3 ? -----Original Message----- From: Joe Macker [mailto:macker@itd.nrl.navy.mil] Sent: Wednesday, March 19, 2003 1:10 PM To: Mineo Takai; Yang, Lily L Cc: 'lu guoxiang'; manet@ietf.org Subject: Re: [manet] discussion on the routing protocol at Link Layer HIPERLAN 1, also was a such a technique at a lower layer and OLSR is loosely based upon that work. There are also many other historical subnet approaches. MANET is chartered to work IP layer solutions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 20 08:07: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 IAA16188 for ; Thu, 20 Mar 2003 08:07:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KDPPo18774 for manet-archive@odin.ietf.org; Thu, 20 Mar 2003 08:25:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KDPKO18766 for ; Thu, 20 Mar 2003 08:25:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16143 for ; Thu, 20 Mar 2003 08:05:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KDDxO18284; Thu, 20 Mar 2003 08:13:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KD7OO18088 for ; Thu, 20 Mar 2003 08:07:24 -0500 Received: from mail.rz.uni-ulm.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15832 for ; Thu, 20 Mar 2003 07:48:33 -0500 (EST) Received: from informatik.uni-ulm.de (delphin.informatik.uni-ulm.de [134.60.70.42]) by mail.rz.uni-ulm.de (8.12.8/8.12.8) with ESMTP id h2KCocIM007967 for ; Thu, 20 Mar 2003 13:50:38 +0100 (MET) Message-ID: <3E79B94E.9050107@informatik.uni-ulm.de> Date: Thu, 20 Mar 2003 13:51:26 +0100 From: Frank Kargl Organization: University of Ulm User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: manet@ietf.org X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Error in ns-2 simulation of AODV? Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all ... I have a quite basic AODV simulation script (see below) that yields strange results. When I use a scenario file on an area of 500x500m I get a delivery ratio of 99%, when I enlarge the area to 1500x300m, the delivery ratio drops to something like 70%. I can not reproduce results published by others that get 99% delivery ratio on areas of 1500mx300m. This happens on ns-2.1b9a and ns-2.26 for the original AODV as well as AODV-UU. The scenarios are generated with 50 nodes, random waypoint, 1m/s, 0 pause time like in a lot of other simulations published. Any idea what goes wrong? Regards ... Frank Here is the script I use: # =================================================== # Define options # =================================================== set val(rp) AODV ;# routing protocol set val(ll) LL set val(mac) Mac/802_11 set val(ifq) Queue/DropTail/PriQueue set val(ifqlen) 50 ;# max packet in ifq set val(ant) Antenna/OmniAntenna set val(prop) Propagation/TwoRayGround set val(phy) Phy/WirelessPhy set val(chan) Channel/WirelessChannel set val(seed) 1.0 set val(x) 800 ;# X dimension of the topography set val(y) 800 ;# Y dimension of the topography set val(nn) 50 ;# how many nodes are simulated set val(cp) "./scen/fscen2" set val(sc) "./scen/cbr-n50-s1" set val(stop) 240.0 ;# simulation time # =================================================== # Main Program # =================================================== # # Initialize Global Variables # set ns_ [new Simulator] set tracefd [open wir-m1.tr w] $ns_ trace-all $tracefd set tracenamfd [open wir-m1.nam w] $ns_ namtrace-all-wireless $tracenamfd $val(x) $val(y) $ns_ use-newtrace # setup topography object set topo [new Topography] # define topology $topo load_flatgrid $val(x) $val(y) # # Create God # set god_ [create-god $val(nn)] # # define how node should be created # #global node setting puts "Calling ns" set chan_ [new $val(chan)] $ns_ node-config -adhocRouting $val(rp) \ ~ -llType $val(ll) \ ~ -macType $val(mac) \ ~ -ifqType $val(ifq) \ ~ -ifqLen $val(ifqlen) \ ~ -antType $val(ant) \ ~ -propType $val(prop) \ ~ -phyType $val(phy) \ ~ -topoInstance $topo \ ~ -channel $chan_ \ ~ -agentTrace ON \ ~ -routerTrace ON \ ~ -macTrace ON \ ~ -movementTrace OFF # Create the specified number of nodes [$val(nn)] # and "attach" them to the channel. puts "Creating nodes" for {set i 0} {$i < $val(nn) } {incr i} { ~ set node_($i) [$ns_ node] ~ $node_($i) random-motion 0 ;# disable random motion } $node_(1) color red # # Define node movement model # puts "Loading connection pattern..." source $val(cp) # # Define traffic model # puts "Loading scenario file..." source $val(sc) # Define node initial position in nam for {set i 0} {$i < $val(nn)} {incr i} { ~ # 20 defines the node size in nam, ~ # must adjust it according to your scenario ~ # The function must be called after ~ # mobility model is defined ~ $ns_ initial_node_pos $node_($i) 20 } # # Tell nodes when the simulation ends # for {set i 0} {$i < $val(nn) } {incr i} { ~ $ns_ at $val(stop).0 "$node_($i) reset"; } $ns_ at $val(stop).0002 "puts \"NS EXITING...\" ; $ns_ halt" # puts $tracefd "M 0.0 nn $val(nn) x $val(x) y $val(y) rp $val(adhocRouting)" # puts $tracefd "M 0.0 sc $val(sc) cp $val(cp) seed $val(seed)" # puts $tracefd "M 0.0 prop $val(prop) ant $val(ant)" proc stop {} { ~ global ns_ tracefd ~ $ns_ flush-trace ~ close $tracefd } puts "Starting Simulation..." $ns_ run - -- - ----------------------------------------------------------------------- ~ Frank Kargl Multimedia Computing, University of Ulm, Germany ~ Mail:frank.kargl@informatik.uni-ulm.de http://www.uni-ulm.de/~fkargl/ - ----------------------------------------------------------------------- ~ Use the SOURCE, Luke ! I feel a great disturbance in the SOURCE. ~ But beware of the Microsoft side of the SOURCE ! - ----------------------------------------------------------------------- ---> CFP HICSS-37 Wireless PANs Minitrack: <--- ---> http://crystal.uta.edu/~zaruba/hicss37/ <--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+eblNPfhIZ4vQvRQRAl8gAKDg+47Np976+ICJm4HZ+9SbEbrUjACfSTcD E5/2+ZbzJetdg9yEgJAErCk= =rIN3 -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 20 12:48:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26971 for ; Thu, 20 Mar 2003 12:48:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KI6Nq10189 for manet-archive@odin.ietf.org; Thu, 20 Mar 2003 13:06:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KI6NO10186 for ; Thu, 20 Mar 2003 13:06:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26957 for ; Thu, 20 Mar 2003 12:47:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHouO09121; Thu, 20 Mar 2003 12:50:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KHeGO08740 for ; Thu, 20 Mar 2003 12:40:16 -0500 Received: from mailhost.cs.auc.dk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25799 for ; Thu, 20 Mar 2003 12:21:47 -0500 (EST) Received: from armada (voop@pico.cs.auc.dk [130.225.194.80]) by mailhost.cs.auc.dk (8.12.3/8.12.3) with SMTP id h2KHNvEE017731; Thu, 20 Mar 2003 18:23:59 +0100 (MET) Date: Thu, 20 Mar 2003 18:23:55 +0100 From: Thomas Heide Clausen To: ogier@erg.sri.com Cc: philippe.jacquet@inria.fr, manet@ietf.org Subject: Re: [manet] I-D ACTION:draft-ietf-manet-olsr-08.txt Message-Id: <20030320182355.345fdb34.T.Clausen@computer.org> In-Reply-To: <200303192114.NAA03289@pit.erg.sri.com> References: <003b01c2ee4f$7bcc2a40$74828182@inria.fr> <200303192114.NAA03289@pit.erg.sri.com> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.14 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 19 Mar 2003 13:14:38 -0800 ogier@erg.sri.com wrote: > In any case, some change to the OLSR draft is needed, such as: > "A TC Message with a new sequence number SHOULD include the entire > MPR selector set whenever possible." No need. As you said yourself: "since the full updates are periodic, all nodes will eventually have the correct information even if some packets are not received, or are received out of order." --thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 20 13:24:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28149 for ; Thu, 20 Mar 2003 13:24:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KIgGB13601 for manet-archive@odin.ietf.org; Thu, 20 Mar 2003 13:42:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KIgGO13598 for ; Thu, 20 Mar 2003 13:42:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28139 for ; Thu, 20 Mar 2003 13:23:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KILUO11636; Thu, 20 Mar 2003 13:21:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KICBO11278 for ; Thu, 20 Mar 2003 13:12:11 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27065 for ; Thu, 20 Mar 2003 12:53:41 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2KHuac1013276 for ; Fri, 21 Mar 2003 01:56:36 +0800 (SGT) Received: from bkdom-MTA by mailer.icr.a-star.edu.sg with Novell_GroupWise; Fri, 21 Mar 2003 01:48:51 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Fri, 21 Mar 2003 01:54:48 +0800 From: "Paul Tan Hock Lai" To: , , Cc: , Subject: RE: [manet] discussion on the routing protocol at Link Layer Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2KICBO11279 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, my observation from the mailing list is that MANET's routing protocols are mostly implemented or simulated on ieee802.11 radio. i believed that implementing routing at the ip layer enables heterogenous mixture of links/networks. i am not sure abt the benefits from doing it in the L2 layer (link-specific). maybe the community would like to share info/advantages on doing it in L2 with us. cheers, Paul Tan >>> "Yang, Lily L" 03/19/03 01:37PM >>> Anybody aware of any technical comprehensive analysis or comparison of doing this for mesh networks at layer 2 versus layer 3 ? -----Original Message----- From: Joe Macker [mailto:macker@itd.nrl.navy.mil] Sent: Wednesday, March 19, 2003 1:10 PM To: Mineo Takai; Yang, Lily L Cc: 'lu guoxiang'; manet@ietf.org Subject: Re: [manet] discussion on the routing protocol at Link Layer HIPERLAN 1, also was a such a technique at a lower layer and OLSR is loosely based upon that work. There are also many other historical subnet approaches. MANET is chartered to work IP layer solutions. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 20 13:44:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29015 for ; Thu, 20 Mar 2003 13:44:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KJ2sf14737 for manet-archive@odin.ietf.org; Thu, 20 Mar 2003 14:02:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KJ2sO14733 for ; Thu, 20 Mar 2003 14:02:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29004 for ; Thu, 20 Mar 2003 13:44:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KIoKO13862; Thu, 20 Mar 2003 13:50:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KIfuO13575 for ; Thu, 20 Mar 2003 13:41:56 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28131 for ; Thu, 20 Mar 2003 13:23:26 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id KAA07366; Thu, 20 Mar 2003 10:18:34 -0800 (PST) Message-Id: <200303201818.KAA07366@pit.erg.sri.com> To: Thomas Heide Clausen cc: ogier@erg.sri.com, philippe.jacquet@inria.fr, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] I-D ACTION:draft-ietf-manet-olsr-08.txt In-reply-to: Your message of "Thu, 20 Mar 2003 18:23:55 +0100." <20030320182355.345fdb34.T.Clausen@computer.org> Date: Thu, 20 Mar 2003 10:18:34 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > On Wed, 19 Mar 2003 13:14:38 -0800 > ogier@erg.sri.com wrote: > > > > > In any case, some change to the OLSR draft is needed, such as: > > "A TC Message with a new sequence number SHOULD include the entire > > MPR selector set whenever possible." > > No need. As you said yourself: "since the full updates are periodic, > all nodes will eventually have the correct information even if some > packets are not received, or are received out of order." But according to the OLSR draft, TC Messages don't have to be full, they can be partial. Someone might think it is OK to report a single link addition (i.e., a differential update), which would imply that all the other links (MPR selectors) should be deleted. So there needs to be a statement that TC messages should be full when possible. Richard > > --thomas > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 20 17:51:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11219 for ; Thu, 20 Mar 2003 17:51:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2KN9ua05216 for manet-archive@odin.ietf.org; Thu, 20 Mar 2003 18:09:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KN9uO05213 for ; Thu, 20 Mar 2003 18:09:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11203 for ; Thu, 20 Mar 2003 17:51:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KMsiO03260; Thu, 20 Mar 2003 17:54:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2KMINO01142 for ; Thu, 20 Mar 2003 17:18:23 -0500 Received: from aconcagua.alumnos.utfsm.cl (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09725 for ; Thu, 20 Mar 2003 16:59:48 -0500 (EST) From: christian.bravom@alumnos.utfsm.cl Received: from aconcagua.alumnos.utfsm.cl (localhost [127.0.0.1]) by aconcagua.alumnos.utfsm.cl (8.12.8/8.12.8) with ESMTP id h2KM227i029097 for ; Thu, 20 Mar 2003 18:02:02 -0400 (CLT) Received: (from web@localhost) by aconcagua.alumnos.utfsm.cl (8.12.8/8.12.2/Submit) id h2KM22tu029090 for manet@ietf.org; Thu, 20 Mar 2003 18:02:02 -0400 (CLT) X-Authentication-Warning: aconcagua.alumnos.utfsm.cl: web set sender to christian.bravom@alumnos.utfsm.cl using -f Received: from eq-mfuica.intranet.quilpue.cl ( [eq-mfuica.intranet.quilpue.cl]) as user christian.bravom@localhost by webmail.alumnos.utfsm.cl with HTTP; Thu, 20 Mar 2003 18:02:01 -0400 Message-ID: <1048197721.3e7a3a59d1fa7@webmail.alumnos.utfsm.cl> Date: Thu, 20 Mar 2003 18:02:01 -0400 To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 200.72.93.175 Content-Transfer-Encoding: 8bit Subject: [manet] Research work 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: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I'm a student of the Master Program in the Computer Science and Telecommunications Area of the Electronic Department at the Santa Maria University of Valparaiso, Chile Last year I studied the MANET protocols (AODV, DSR, TORA, etc) and they were very interesting to me. Now, I'm writing to the list because I'll have to focus my research work about Mobile Wireless Networks and I haven't decided yet the specific topic which I'm going to work on. I really want to know if somebody have some topic or open problem that I can develop as my thesis work. Thanks in advance Christian M. Bravo Electronic Engineering UTFSM - CHILE _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 20 21:05:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18673 for ; Thu, 20 Mar 2003 21:05:55 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2L2O1Y19155 for manet-archive@odin.ietf.org; Thu, 20 Mar 2003 21:24:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L2O0O19150 for ; Thu, 20 Mar 2003 21:24:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18664 for ; Thu, 20 Mar 2003 21:05:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L2CEO18676; Thu, 20 Mar 2003 21:12:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2L24YO17694 for ; Thu, 20 Mar 2003 21:04:34 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18242 for ; Thu, 20 Mar 2003 20:45:55 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2L1mmc1016842 for ; Fri, 21 Mar 2003 09:48:48 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Fri, 21 Mar 2003 09:40:59 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 31976A517; Fri, 21 Mar 2003 09:48:03 +0800 (SGT) Date: Fri, 21 Mar 2003 09:48:03 +0800 From: Sukanta Kumar Hazra To: Manet WG Message-ID: <20030321014803.GA5127@localhost> Mail-Followup-To: Manet WG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Subject: [manet] should we have size of MANET as a metric Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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! Regarding the comments made by Dave in the MANET meeting today, I tend to agree with him, that we need an idea of the size of the network that the different protocols support. That might be an important consideration. The network model and the traffic model might be somthing that is difficult to agree on, but would be desirable. I have the need to evaluate a number of ad hoc routing protocols for network consisting of up to 10000 nodes, and some idea of which protocol is suitable for such a network would be great. - Sukanta -- -------------------------------------------------------------------- Sukanta Kumar Hazra Institute for Infocomm Research, Singapore Phone: +65 68709338 Fax: +65 67795441 -------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 21 05:52:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10065 for ; Fri, 21 Mar 2003 05:52:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LBBGA28668 for manet-archive@odin.ietf.org; Fri, 21 Mar 2003 06:11:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LBBGO28665 for ; Fri, 21 Mar 2003 06:11:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10052 for ; Fri, 21 Mar 2003 05:52:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LB22O27584; Fri, 21 Mar 2003 06:02:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LAtDO27406 for ; Fri, 21 Mar 2003 05:55:13 -0500 Received: from prue.eim.surrey.ac.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09871 for ; Fri, 21 Mar 2003 05:36:25 -0500 (EST) Received: from romeo.ee.surrey.ac.uk ([131.227.76.30] helo=eim.surrey.ac.uk ident=www) by prue.eim.surrey.ac.uk with smtp (Exim 3.33 #4) id 18wJuz-0005JJ-00 for manet@ietf.org; Fri, 21 Mar 2003 10:38:33 +0000 Received: from m85-mp1.cvx2-c.lng.dial.ntli.net ([62.252.188.85]) (SquirrelMail authenticated user eem1tk) by secure.eps.surrey.ac.uk with HTTP; Fri, 21 Mar 2003 10:38:33 -0000 (GMT) Message-ID: <3143.62.252.188.85.1048243113.squirrel@secure.eps.surrey.ac.uk> Date: Fri, 21 Mar 2003 10:38:33 -0000 (GMT) From: "Teng Kang" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.9) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-106.6 required=5.5 tests=BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *18wJuz-0005JJ-00*YtB/j/hxOHc* (SECM, UniS) Content-Transfer-Encoding: 8bit Subject: [manet] implementation of PCF in Glomosim Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Dear all: I am a fresher of Glomosim and want to be familier with the 802.11. I just wonder there is any method or algorithm to implement PCF in the Glomosim. Looking for forwards your reply, thank a lot. regards _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 21 10:05:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15131 for ; Fri, 21 Mar 2003 10:05:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LFNuo11699 for manet-archive@odin.ietf.org; Fri, 21 Mar 2003 10:23:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFNuO11696 for ; Fri, 21 Mar 2003 10:23:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15078 for ; Fri, 21 Mar 2003 10:05:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFAkO11107; Fri, 21 Mar 2003 10:10:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LF3iO10093 for ; Fri, 21 Mar 2003 10:03:44 -0500 Received: from mx2.isti.cnr.it (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14498 for ; Fri, 21 Mar 2003 09:44:50 -0500 (EST) Received: from CONVERSION.MAIL.IAT.CNR.IT by mx.isti.cnr.it (PMDF V6.2 #30641) id <01KTSIDKOLJK9S3S2V@mx.isti.cnr.it> for manet@ietf.org; Fri, 21 Mar 2003 15:46:40 -0500 (EST) Received: from iitpa6v64oitt1 (labgreg2.cnuce.cnr.it [146.48.82.129]) by mx.isti.cnr.it (PMDF V6.2 #30641) with SMTP id <01KTSIDKKYHQ9TCO74@mx.isti.cnr.it> for manet@ietf.org; Fri, 21 Mar 2003 15:46:40 +0100 (MET) Date: Fri, 21 Mar 2003 15:47:16 +0100 From: Eleonora Borgia To: manet@ietf.org Message-id: <001b01c2efb8$c4a4a2a0$81523092@iitpa6v64oitt1> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: multipart/alternative; boundary="Boundary_(ID_RlSAmZtYIrpffLQrad6J4w)" X-Priority: 3 X-MSMail-priority: Normal Subject: [manet] transmit power of 802.11 wireless card Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_RlSAmZtYIrpffLQrad6J4w) Content-type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all! I've read, in the IEEE 802.11 standard, that the maximum output power = is 100 mW (equal to 20dbm) in Europe, but I haven't found anything about = the transmit power. Does anybody know if the transmit power of a wireless card is a fixed = parameter (for example, the transmit power of all wireless cards is = always 15 dbm (32 mW)) or each vendor can choose a different transmit = power for its card with a value less than 100 mW? =20 Thanks a lot. Eleonora --Boundary_(ID_RlSAmZtYIrpffLQrad6J4w) Content-type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi = all!
 
I've read, in = the IEEE=20 802.11 standard, that  the maximum output power is 100 mW (equal to = 20dbm)=20 in Europe, but I haven't found anything about the transmit=20 power.
 
Does anybody = know if the=20 transmit power of a wireless card is a fixed parameter (for example, the = transmit power of all wireless cards  is always 15 dbm (32 = mW))=20 or each vendor can choose a different transmit power for its = card with=20 a value less than 100 mW?
 
Thanks a = lot.
 
Eleonora
--Boundary_(ID_RlSAmZtYIrpffLQrad6J4w)-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 21 10:28:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16769 for ; Fri, 21 Mar 2003 10:28:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LFl2S13422 for manet-archive@odin.ietf.org; Fri, 21 Mar 2003 10:47:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFl1O13418 for ; Fri, 21 Mar 2003 10:47:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16747 for ; Fri, 21 Mar 2003 10:28:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFbZO12877; Fri, 21 Mar 2003 10:37:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LFWMO12074 for ; Fri, 21 Mar 2003 10:32:22 -0500 Received: from bubba.NMSU.Edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16044 for ; Fri, 21 Mar 2003 10:13:24 -0500 (EST) Received: from dns1.nmsu.edu (dns1.NMSU.Edu [128.123.3.5]) by bubba.NMSU.Edu (8.10.2+Sun/8.9.0) with ESMTP id h2LFFVc20690; Fri, 21 Mar 2003 08:15:32 -0700 (MST) Received: from nestor.NMSU.Edu (nestor.NMSU.Edu [128.123.34.146]) by dns1.nmsu.edu (8.9.3/8.9.0) with ESMTP id IAA20325; Fri, 21 Mar 2003 08:15:33 -0700 (MST) Received: from PCMullen2 (pc-mullen-2.NMSU.Edu [128.123.245.103]) by nestor.NMSU.Edu (AIX4.3/8.9.3/8.9.0) with ESMTP id IAA218910; Fri, 21 Mar 2003 08:15:19 -0700 From: "John Mullen" To: "'Sukanta Kumar Hazra'" , "'Manet WG'" Subject: RE: [manet] should we have size of MANET as a metric Date: Fri, 21 Mar 2003 08:15:34 -0700 Message-ID: <000001c2efbc$b903a870$67f57b80@IEngr.ad.nmsu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20030321014803.GA5127@localhost> 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 Sukanta, I agree that this is important, but the trouble with "size" is the problem of how to describe it. Certainly, the number of nodes is a factor, but it is one thing when most nodes can reach their destinations directly and another when multi-hops are the norm. The trouble is that technology, geography, and usage patterns interact. For example, if the network is over a wide area, but the traffic pattern is such that 90% of messages are to neighbors, there will be a relatively small need for relays. The same situation can arise if the network is compact enough that most nodes can reach one another directly, regardless of the traffic pattern. However, if traffic patterns or geographical dispersion is greater, then the same number of nodes presents a more difficult problem. For another, a network that is working in a large, open, mostly featureless area will not have the same problems as one working in an urban environment. There are other factors that will affect the "size" of the MANET. For example, if nodes are highly mobile, it will be necessary to broadcast Hellos more frequently to retain and distribute knowledge of the topology, than if the MANET contains only a few mobile nodes or is relatively stable. This increases the risk of latency problems and reduces the BW available for transmitting messages. Certainly, the size should be a metric, but I feel that "size" needs to be measured in a way that has some relevance to the MANET problem. Some measures that might work are: 1. Total number of nodes, as you suggest, plus 2. Average fraction of the net within one hop, or maybe better yet, the distribution of the number of hops, 3. The area of the network in terms of the direct-connect radius, 4. The aspect ratio or some other shape parameter of the geographical coverage and so on. Of course, the important thing is the MANET community agree on whatever measures that are chosen so that people don't end up trying to compare apples to televisions. John Mullen -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Sukanta Kumar Hazra Sent: Thursday, March 20, 2003 6:48 PM To: Manet WG Subject: [manet] should we have size of MANET as a metric Hi! Regarding the comments made by Dave in the MANET meeting today, I tend to agree with him, that we need an idea of the size of the network that the different protocols support. That might be an important consideration. The network model and the traffic model might be somthing that is difficult to agree on, but would be desirable. I have the need to evaluate a number of ad hoc routing protocols for network consisting of up to 10000 nodes, and some idea of which protocol is suitable for such a network would be great. - Sukanta -- -------------------------------------------------------------------- Sukanta Kumar Hazra Institute for Infocomm Research, Singapore Phone: +65 68709338 Fax: +65 67795441 -------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 21 12:58:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20539 for ; Fri, 21 Mar 2003 12:58:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LIH3c24463 for manet-archive@odin.ietf.org; Fri, 21 Mar 2003 13:17:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LIH3O24460 for ; Fri, 21 Mar 2003 13:17:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20518 for ; Fri, 21 Mar 2003 12:58:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LI7IO23554; Fri, 21 Mar 2003 13:07:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LI1uO22897 for ; Fri, 21 Mar 2003 13:01:56 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20154 for ; Fri, 21 Mar 2003 12:42:58 -0500 (EST) From: idc@engineering.ucsb.edu Received: from KENAI.cs.ucsb.edu (badlands.cs.ucsb.edu [128.111.40.116]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with ESMTP id h2LHj4107997; Fri, 21 Mar 2003 09:45:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15995.20379.442000.287444@gargle.gargle.HOWL> Date: Fri, 21 Mar 2003 09:44:59 -0800 To: Eleonora Borgia Cc: manet@ietf.org Subject: RE:[manet] transmit power of 802.11 wireless card In-Reply-To: <001b01c2efb8$c4a4a2a0$81523092@iitpa6v64oitt1> References: <001b01c2efb8$c4a4a2a0$81523092@iitpa6v64oitt1> X-Mailer: VM 7.07 under Emacs 21.1.1 Reply-To: idc@engineering.ucsb.edu Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Each vendor and card may have different transmit power (which maybe configurable). For example many Cisco Aironet cards have adjustable transmit power. I believe most vendors use the max transmit power. Ian Chakeres >Eleonora Borgia wrote: >Hi all! > >I've read, in the IEEE 802.11 standard, that the maximum output power is 100 mW (equal to 20dbm) in Europe, but I haven't found anything about the transmit power. > >Does anybody know if the transmit power of a wireless card is a fixed parameter (for example, the transmit power of all wireless cards is always 15 dbm (32 mW)) or each vendor can choose a different transmit power for its card with a value less than 100 mW? > >Thanks a lot. > >Eleonora _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 21 15:54:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27388 for ; Fri, 21 Mar 2003 15:54:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LLDFY06236 for manet-archive@odin.ietf.org; Fri, 21 Mar 2003 16:13:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LLDEO06233 for ; Fri, 21 Mar 2003 16:13:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27366 for ; Fri, 21 Mar 2003 15:54:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LL03O04729; Fri, 21 Mar 2003 16:00:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LKrVO04393 for ; Fri, 21 Mar 2003 15:53:31 -0500 Received: from smtp2.yaonline.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26701 for ; Fri, 21 Mar 2003 15:34:31 -0500 (EST) Received: from [217.125.50.240] (helo=ieee.org) by smtp2.yaonline.es with esmtp id 18wTFi-0004ds-00; Fri, 21 Mar 2003 21:36:34 +0100 Message-ID: <3E7B84C5.2080807@ieee.org> Date: Fri, 21 Mar 2003 21:31:49 +0000 From: Miguel Sanchez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: idc@engineering.ucsb.edu CC: Eleonora Borgia , manet@ietf.org Subject: Re: [manet] transmit power of 802.11 wireless card References: <001b01c2efb8$c4a4a2a0$81523092@iitpa6v64oitt1> <15995.20379.442000.287444@gargle.gargle.HOWL> In-Reply-To: <15995.20379.442000.287444@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, You may want to look at http://www.seattlewireless.net/index.cgi/HardwareComparison there are several adapters info. Regards, Miguel Sánchez Polytechnic University of Valencia, Spain idc@engineering.ucsb.edu wrote: >Each vendor and card may have different transmit power (which maybe >configurable). For example many Cisco Aironet cards have adjustable >transmit power. I believe most vendors use the max transmit power. > >Ian Chakeres > > > > >>Eleonora Borgia wrote: >>Hi all! >> >>I've read, in the IEEE 802.11 standard, that the maximum output power is 100 mW (equal to 20dbm) in Europe, but I haven't found anything about the transmit power. >> >>Does anybody know if the transmit power of a wireless card is a fixed parameter (for example, the transmit power of all wireless cards is always 15 dbm (32 mW)) or each vendor can choose a different transmit power for its card with a value less than 100 mW? >> >>Thanks a lot. >> >>Eleonora >> >> > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 21 17:55:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00200 for ; Fri, 21 Mar 2003 17:55:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LNDgf15983 for manet-archive@odin.ietf.org; Fri, 21 Mar 2003 18:13:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNDgO15979 for ; Fri, 21 Mar 2003 18:13:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00181 for ; Fri, 21 Mar 2003 17:54:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMtoO14058; Fri, 21 Mar 2003 17:55:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMoZO13767 for ; Fri, 21 Mar 2003 17:50:35 -0500 Received: from letters.cs.ucsb.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29458 for ; Fri, 21 Mar 2003 17:31:32 -0500 (EST) Received: from saguaro (saguaro [128.111.40.82]) by letters.cs.ucsb.edu (8.11.6+Sun/8.11.6) with SMTP id h2LMXm105231 for ; Fri, 21 Mar 2003 14:33:48 -0800 (PST) Message-Id: <200303212233.h2LMXm105231@letters.cs.ucsb.edu> Date: Fri, 21 Mar 2003 14:33:47 -0800 (PST) From: "Elizabeth M. Belding-Royer" Reply-To: "Elizabeth M. Belding-Royer" To: manet@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vOrXtkyq4+zUMgBddotqEg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Subject: [manet] IRTF ANSRG Slides Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi, The slides from my presentation on the IRTF Ad hoc Network Scalability Research Group can be found here: http://www.cs.ucsb.edu/~ebelding/ans_update.pdf The slides contain information for subscribing to the mailing list and locating the research group website. Elizabeth _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 21 17:58:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00280 for ; Fri, 21 Mar 2003 17:58:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2LNHWk16157 for manet-archive@odin.ietf.org; Fri, 21 Mar 2003 18:17:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LNHWO16154 for ; Fri, 21 Mar 2003 18:17:32 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00271 for ; Fri, 21 Mar 2003 17:58:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMwJO14173; Fri, 21 Mar 2003 17:58:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2LMpWO13814 for ; Fri, 21 Mar 2003 17:51:32 -0500 Received: from grumpy.usu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29497 for ; Fri, 21 Mar 2003 17:32:29 -0500 (EST) Received: from webmail.usu.edu ("port 4171"@webster.usu.edu [129.123.1.90]) by cc.usu.edu (PMDF V5.2-32 #39089) with ESMTP id <01KTSHXRKHZWAYMWW1@cc.usu.edu> for manet@ietf.org; Fri, 21 Mar 2003 15:34:43 MDT Date: Fri, 21 Mar 2003 15:34:42 -0700 From: Sumeeth Nagaraj Subject: Re: [manet] transmit power of 802.11 wireless card To: Eleonora Borgia Cc: manet Message-id: <3E7DD2E3@webmail.usu.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: snagaraj X-EXP32-SerialNo: 00002751 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 Cisco Aironet350 series cards come with a different transmission power, adjustable by the user from a GUI provided. The cards from Symbol technologies(LA-4137), adjust their power with the AP(automatically), i.e they follow the transmission power of AP that it is associated with. Hope this helps. Best Regards, Sumeeth >===== Original Message From idc@engineering.ucsb.edu ===== >Each vendor and card may have different transmit power (which maybe >configurable). For example many Cisco Aironet cards have adjustable >transmit power. I believe most vendors use the max transmit power. > >Ian Chakeres > > >>Eleonora Borgia wrote: >>Hi all! >> >>I've read, in the IEEE 802.11 standard, that the maximum output power is 100 mW (equal to 20dbm) in Europe, but I haven't found anything about the transmit power. >> >>Does anybody know if the transmit power of a wireless card is a fixed parameter (for example, the transmit power of all wireless cards is always 15 dbm (32 mW)) or each vendor can choose a different transmit power for its card with a value less than 100 mW? >> >>Thanks a lot. >> >>Eleonora > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet Best Regards, Sumeeth _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 21 19:31:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03448 for ; Fri, 21 Mar 2003 19:31:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2M0ndl22058 for manet-archive@odin.ietf.org; Fri, 21 Mar 2003 19:49:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M0ncO22055 for ; Fri, 21 Mar 2003 19:49:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03436 for ; Fri, 21 Mar 2003 19:30:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M0eCO21738; Fri, 21 Mar 2003 19:40:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2M0ajO20857 for ; Fri, 21 Mar 2003 19:36:45 -0500 Received: from web41605.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03181 for ; Fri, 21 Mar 2003 19:17:39 -0500 (EST) Message-ID: <20030322001956.74565.qmail@web41605.mail.yahoo.com> Received: from [202.184.17.249] by web41605.mail.yahoo.com via HTTP; Fri, 21 Mar 2003 16:19:56 PST Date: Fri, 21 Mar 2003 16:19:56 -0800 (PST) From: Shaiful To: manet@ietf.org Cc: tanpaul@i2r.a-star.edu.sg MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [manet] RE: discussion on the routing protocol at Link Layer Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi, I think when he said layer 2, he really meant layer 2.5 ;-) Similar to what MPLS does for wired network. In another jargon, it is "under-lay" as opposed to "over-lay" network as in p2p. Regards, Shaiful Paul tan wrote: my observation from the mailing list is that MANET's routing protocols are mostly implemented or simulated on ieee802.11 radio. i believed that implementing routing at the ip layer enables heterogenous mixture of links/networks. i am not sure abt the benefits from doing it in the L2 layer (link-specific). maybe the community would like to share info/advantages on doing it in L2 with us. __________________________________________________ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Mar 23 20:20:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17321 for ; Sun, 23 Mar 2003 20:20:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O1eBu10322 for manet-archive@odin.ietf.org; Sun, 23 Mar 2003 20:40:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O1eBO10319 for ; Sun, 23 Mar 2003 20:40:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17312 for ; Sun, 23 Mar 2003 20:20:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O1POO08998; Sun, 23 Mar 2003 20:25:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O1IZO08824 for ; Sun, 23 Mar 2003 20:18:35 -0500 Received: from ux3.sp.cs.cmu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16950 for ; Sun, 23 Mar 2003 19:58:30 -0500 (EST) Received: from ux3.sp.cs.cmu.edu ([127.0.0.1]) by ux3.sp.cs.cmu.edu id aa02913; 23 Mar 2003 20:00 EST Date: Sun, 23 Mar 2003 20:00:09 -0500 (EST) From: Jorjeta Gueorguieva Jetcheva X-X-Sender: To: manet@ietf.org MMDF-Warning: Parse error in original version of preceding line at ux3.sp.cs.cmu.edu cc: jorjeta@cs.cmu.edu MMDF-Warning: Parse error in original version of preceding line at ux3.sp.cs.cmu.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] ns-2 multicast extensions back up Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , FTP access to the Monarch website was disabled last week due to a network upgrade at Rice University. The multicast extensions are now accessible again. For those of you already using them, there have been several updates to the code since the original version was first released. Information on the extensions and the upgrades is available on the Monarch website: http://www.monarch.cs.rice.edu/multicast_extensions.html. Jorjeta =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= o j r e a o = o j t = o o = = o Jorjeta G. Jetcheva o = Ph.D. student, Computer Science = o Carnegie Mellon University o = = o http://www.cs.cmu.edu/~jorjeta o =o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o=o= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Mar 23 20:58:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17910 for ; Sun, 23 Mar 2003 20:58:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O2Hli12231 for manet-archive@odin.ietf.org; Sun, 23 Mar 2003 21:17:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O2HlO12228 for ; Sun, 23 Mar 2003 21:17:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17895 for ; Sun, 23 Mar 2003 20:57:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O25TO11004; Sun, 23 Mar 2003 21:05:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O20sO10866 for ; Sun, 23 Mar 2003 21:00:54 -0500 Received: from exstudent9.city.unisa.edu.au (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17612 for ; Sun, 23 Mar 2003 20:40:47 -0500 (EST) Received: by exstudent9.city.unisa.edu.au with Internet Mail Service (5.5.2656.59) id ; Mon, 24 Mar 2003 12:10:48 +1030 Message-ID: From: "Liaw, Yong Shyang - LIAYS001" To: manet@ietf.org Date: Mon, 24 Mar 2003 12:14:12 +1030 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [manet] Frequent Link failures in MANET Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi, I have performed some simulation using DSR on a static MANET. I am surprised to find that even on a simple static linear chain where nodes are stationary, the link fails (and hence Route Error) happens very frequently i.e. Route Error every 1-3 seconds. I am using IEEE 802.11 with CTS/RTS as MAC, which shall minimise collosion. I am using Opnet 8.1 for the simulation. For my simulation, I have only 1 TCP connnection & no other traffic. Has anyone also observed this behaviour (i.e. link breaks every 1-3 seconds) in static MANET (especially using the NS2)? I would really appreciate if you can share with me your experience in this matter, so that I can confirm this problem is not caused by Opnet's 802.11 model. Thank you. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Sun Mar 23 21:07:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18088 for ; Sun, 23 Mar 2003 21:07:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2O2Qvp12546 for manet-archive@odin.ietf.org; Sun, 23 Mar 2003 21:26:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O2QvO12543 for ; Sun, 23 Mar 2003 21:26:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18043 for ; Sun, 23 Mar 2003 21:06:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O2G3O12145; Sun, 23 Mar 2003 21:16:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2O2BgO12014 for ; Sun, 23 Mar 2003 21:11:42 -0500 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17806 for ; Sun, 23 Mar 2003 20:51:36 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h2O1rtjZ012087 for ; Sun, 23 Mar 2003 20:53:55 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2O1roWe007002 for ; Sun, 23 Mar 2003 20:53:50 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003032320534915032 for ; Sun, 23 Mar 2003 20:53:49 -0500 Message-Id: <5.1.1.5.2.20030323205014.014d2be8@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Sun, 23 Mar 2003 20:53:07 -0500 To: manet@ietf.org From: Joe Macker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] submission info for presenters Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Reminder to the presenters at Thursday's meeting. Please submit your slides to minutes@ietf.org Further instructions are at http://www.ietf.org/instructions/slides.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 24 05:44:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09901 for ; Mon, 24 Mar 2003 05:44:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OB4d722542 for manet-archive@odin.ietf.org; Mon, 24 Mar 2003 06:04:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OB4cO22539 for ; Mon, 24 Mar 2003 06:04:38 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09870 for ; Mon, 24 Mar 2003 05:44:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OAovO21852; Mon, 24 Mar 2003 05:50:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OAiiO21637 for ; Mon, 24 Mar 2003 05:44:44 -0500 Received: from zaz.kom.auc.dk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09537 for ; Mon, 24 Mar 2003 05:24:27 -0500 (EST) Received: from petarp-w2k.kom.auc.dk ([192.168.110.200] helo=PETARPW2K) by zaz.kom.auc.dk with smtp (Exim 2.05 #3) id 18xPA9-0007Z1-00; Mon, 24 Mar 2003 11:26:41 +0100 Message-ID: <001b01c2f1ef$dc3984b0$c86ea8c0@kom.auc.dk> From: "Petar Popovski" To: "Liaw, Yong Shyang - LIAYS001" , References: Subject: Re: [manet] Frequent Link failures in MANET Date: Mon, 24 Mar 2003 11:26:41 +0100 Organization: Center for PersonKommunikation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 that the problem you encounter comes from the interaction between TCP and 802.11 MAC. It has been investigated in: S. Xu and T. Saadawi. "Does the IEEE 802.11 MAC protocol work well in multihop wireless ad hoc networks?" IEEE Communications Magazine, Vol 39, No. 6, pages 130 -137, June 2001. and this is where you can get the paper: http://academic.csuohio.edu/yuc/mobile03/0415-xu.pdf Regards, Petar ----- Original Message ----- From: "Liaw, Yong Shyang - LIAYS001" To: Sent: Monday, March 24, 2003 2:44 AM Subject: [manet] Frequent Link failures in MANET > Hi, > > I have performed some simulation using DSR on a static MANET. I am surprised to > find that even on a simple static linear chain where nodes are stationary, the > link fails (and hence Route Error) happens very frequently i.e. Route Error > every 1-3 seconds. I am using IEEE 802.11 with CTS/RTS as MAC, which shall > minimise collosion. I am using Opnet 8.1 for the simulation. For my simulation, > I have only 1 TCP connnection & no other traffic. > > Has anyone also observed this behaviour (i.e. link breaks every 1-3 seconds) in > static MANET (especially using the NS2)? I would really appreciate if you can > share with me your experience in this matter, so that I can confirm this > problem is not caused by Opnet's 802.11 model. Thank you. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 24 07:21:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11560 for ; Mon, 24 Mar 2003 07:21:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OCes329155 for manet-archive@odin.ietf.org; Mon, 24 Mar 2003 07:40:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCesO29152 for ; Mon, 24 Mar 2003 07:40:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11552 for ; Mon, 24 Mar 2003 07:20:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCUPO27868; Mon, 24 Mar 2003 07:30:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCOwO27681 for ; Mon, 24 Mar 2003 07:24:58 -0500 Received: from web41607.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11227 for ; Mon, 24 Mar 2003 07:04:40 -0500 (EST) Message-ID: <20030324120658.26296.qmail@web41607.mail.yahoo.com> Received: from [193.95.33.18] by web41607.mail.yahoo.com via HTTP; Mon, 24 Mar 2003 13:06:58 CET Date: Mon, 24 Mar 2003 13:06:58 +0100 (CET) From: =?iso-8859-1?q?stream=20stream?= To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1774410622-1048507618=:25293" Content-Transfer-Encoding: 8bit Subject: [manet] i need your opinion about these security problems Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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-1774410622-1048507618=:25293 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi everybody, i would be very pleased if someone gives me any informations about theses problems in ad hoc networks: 1- why and when do we use clustering? what are the services that the clusterhead is supposed to give? 2- can we consider the clusterheads as partial central authorities? if yes how can clusterheads authenticate each others? 3- can we simulate clustering using a network simulator like ns? can we apply clustering in a realistic environment? any help will be appreciated. regards --------------------------------- Yahoo! Messenger Nueva versión: Super Webcam, voz, caritas animadas, y más #161;Gratis! --0-1774410622-1048507618=:25293 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

hi everybody,

i would be very pleased if someone gives me any informations about theses problems in ad hoc networks:

1- why and when do we use clustering? what are the services that the clusterhead is supposed to give?

2- can we consider the clusterheads as partial central authorities? if yes how can clusterheads authenticate each others?

3- can we simulate clustering using a network simulator like ns? can we apply clustering in a realistic environment?

any help will be appreciated.

regards

 

Yahoo! Messenger
Nueva versión: Super Webcam, voz, caritas animadas, y más ¡Gratis! --0-1774410622-1048507618=:25293-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 24 08:57:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18465 for ; Mon, 24 Mar 2003 08:57:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OEGul03825 for manet-archive@odin.ietf.org; Mon, 24 Mar 2003 09:16:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OEGtO03822 for ; Mon, 24 Mar 2003 09:16:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18455 for ; Mon, 24 Mar 2003 08:56:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OE6VO02474; Mon, 24 Mar 2003 09:06:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OE0xO02219 for ; Mon, 24 Mar 2003 09:00:59 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17430 for ; Mon, 24 Mar 2003 08:40:35 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2ODhVNH001450 for ; Mon, 24 Mar 2003 21:43:31 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Mon, 24 Mar 2003 21:35:29 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 3022A81F1; Mon, 24 Mar 2003 21:42:37 +0800 (SGT) Date: Mon, 24 Mar 2003 21:42:37 +0800 From: "'Sukanta Kumar Hazra'" To: "'Manet WG'" Subject: Re: [manet] should we have size of MANET as a metric Message-ID: <20030324134237.GA4819@localhost> Mail-Followup-To: 'Manet WG' References: <20030321014803.GA5127@localhost> <000001c2efbc$b903a870$67f57b80@IEngr.ad.nmsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c2efbc$b903a870$67f57b80@IEngr.ad.nmsu.edu> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi John, I agree with the issues that you have pointed out. If we could agree on a few scenarios, which take into account most the points that you have raised, that would be good. We could avoid the problems associated with finding "the one" model that is representative of all the factors that we want to take into account. It would then be possible to evaluate the various routing protocols in these scenarios and thus have some feel for their performance and suitabililty. - Sukanta ----- Original Message ----- From: "John Mullen " Date: Fri, 21 Mar, 2003 23:15 SGT Subject: RE: [manet] should we have size of MANET as a metric > Hi Sukanta, > > I agree that this is important, but the trouble with "size" is the > problem of how to describe it. Certainly, the number of nodes is a > factor, but it is one thing when most nodes can reach their destinations > directly and another when multi-hops are the norm. The trouble is that > technology, geography, and usage patterns interact. > > For example, if the network is over a wide area, but the traffic pattern > is such that 90% of messages are to neighbors, there will be a > relatively small need for relays. The same situation can arise if the > network is compact enough that most nodes can reach one another > directly, regardless of the traffic pattern. However, if traffic > patterns or geographical dispersion is greater, then the same number of > nodes presents a more difficult problem. > > For another, a network that is working in a large, open, mostly > featureless area will not have the same problems as one working in an > urban environment. > > There are other factors that will affect the "size" of the MANET. For > example, if nodes are highly mobile, it will be necessary to broadcast > Hellos more frequently to retain and distribute knowledge of the > topology, than if the MANET contains only a few mobile nodes or is > relatively stable. This increases the risk of latency problems and > reduces the BW available for transmitting messages. > > Certainly, the size should be a metric, but I feel that "size" needs to > be measured in a way that has some relevance to the MANET problem. Some > measures that might work are: > > 1. Total number of nodes, as you suggest, plus > 2. Average fraction of the net within one hop, or maybe better yet, the > distribution of the number of hops, > 3. The area of the network in terms of the direct-connect radius, > 4. The aspect ratio or some other shape parameter of the geographical > coverage > > and so on. > > Of course, the important thing is the MANET community agree on whatever > measures that are chosen so that people don't end up trying to compare > apples to televisions. > > John Mullen > > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of > Sukanta Kumar Hazra > Sent: Thursday, March 20, 2003 6:48 PM > To: Manet WG > Subject: [manet] should we have size of MANET as a metric > > > Hi! > > Regarding the comments made by Dave in the MANET meeting today, I tend > to agree with him, that we need an idea of the size of the network that > the different protocols support. That might be an important > consideration. The network model and the traffic model might be somthing > that is difficult to agree on, but would be desirable. I have the need > to evaluate a number of ad hoc routing protocols for network consisting > of up to 10000 nodes, and some idea of which protocol is suitable for > such a network would be great. > > - Sukanta > > -- > -------------------------------------------------------------------- > Sukanta Kumar Hazra > Institute for Infocomm Research, Singapore > Phone: +65 68709338 Fax: +65 67795441 > -------------------------------------------------------------------- > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 24 10:27:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22991 for ; Mon, 24 Mar 2003 10:27:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OFkuQ10518 for manet-archive@odin.ietf.org; Mon, 24 Mar 2003 10:46:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OFkuO10515 for ; Mon, 24 Mar 2003 10:46:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22984 for ; Mon, 24 Mar 2003 10:26:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OFZRO09109; Mon, 24 Mar 2003 10:35:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OFTsO08917 for ; Mon, 24 Mar 2003 10:29:54 -0500 Received: from tounes103.gw.tn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21572 for ; Mon, 24 Mar 2003 10:09:30 -0500 (EST) Received: from tounes-22.ati.tn (tounes-22.ati.tn [193.95.66.22]) by tounes.tngw.tn (8.8.8/8.8.8) with ESMTP id QAA25790 for ; Mon, 24 Mar 2003 16:12:44 -0100 (GMT) Received: from smtp.planet.tn ([193.95.67.167]) by tounes-22.ati.tn (8.12.8/8.12.8) with ESMTP id h2OEBt2E010019 for ; Mon, 24 Mar 2003 16:11:55 +0200 (EET) Received: from planet.tn ([193.95.96.56]) by smtp.planet.tn (8.11.6/8.11.6) with ESMTP id h2OHDO221257 for ; Mon, 24 Mar 2003 16:13:24 -0100 (GMT) Message-ID: <3E7F1F0E.661EAE5B@planet.tn> Date: Mon, 24 Mar 2003 16:06:54 +0100 From: Farouk Kamoun X-Mailer: Mozilla 4.7 [fr] (Win95; U) X-Accept-Language: fr MIME-Version: 1.0 To: manet Content-Type: multipart/mixed; boundary="------------FD2D9EE3C22551156AD6A6C6" Subject: [manet] Med-Hoc-Net-2003 CFP deadline extension Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Il s'agit d'un message multivolet au format MIME. --------------FD2D9EE3C22551156AD6A6C6 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I would like to inform that the deadline to submit papers to The 2nd Mediterranean Workshop on Ad-Hoc Networks Med-Hoc-Net 2003 workshop has been extended till April 15 2003. see below CFP F Kamoun MED-HOC NET 2003 Mahdia, Tunisia, June 25-27, 2003 Call for papers The second Med-Hoc-Net 2003 is a major annual international workshop in the Mediterrnean region. It brings together researchers, technologists and visionaries from academia, research labs, and industry, engineers and students to exchange, discuss and share their experiences, new ideas and research about theoretical and practical aspects of ad-hoc networking. The Med-Hoc-Net 2003 second edition intends to build upon the background of the previous workshop Med-Hoc-Net 2002 held in Sardegna, Italy, by presenting theoretical and practical achievements and advances in the field, current research, experience reports, ongoing prototyping efforts, case studies, and description of innovative ad hoc systems. Keynote Speaker : Leonard Kleinrock (UCLA) “Ubiquitous Computing” Topics will include (but are not limited to): · Innovative applications · Multimedia applications middleware for support in ad hoc networks and real time transports over ad hoc networks · Pilot projects, test beds, implementations · Sensor networks · Embedded systems · Resource discovery, network reconfiguration and self organization · Multimedia location services · QoS oriented multi-hop mobile network architectures, Intserv, Diffserv, MPLS etc. · QoS support in Bluetooth, HomeRF, Hiperlan, IEEE 802.11 etc. · QoS enabling ad hoc network prototypes · Call admission and traffic control policies for ad hoc networks · Congestion control · Transport protocols · Fault tolerance and error recovery · Security in ad hoc networks · Interconnection between ad hoc and wired networks · Unicast and multicast routing in ad hoc multi-hop wireless networks · Scheduling radio resource sharing and MAC protocols for multi-hop networks · Signal processing algorithms (coding, compression) for ad hoc networks · Power management and control algorithms · Performance evaluation of QoS oriented protocols, middleware and applications via measurements, analytical models or simulation · Metrology, Ad-Hoc network measurement Tools Steering Committee: Farouk Kamoun (ENSI, Tunisia) Mario Gerla (UCLA, USA) Guy Pujolle (LIP6, France) Khaldoun Al Agha (LRI, France) Giovanni Pau (UCLA, USA) Program Chair: Abdelfettah Belghith (ENSI, Tunisia) Program Co-chair: Sami Tabbane (SUPCOM, Tunisia) Program Committee: Amine Benkiran (EMI, Morocco) Anne Fladenmuller (LIP6, France) Augusto Casaca (INESC, Portugal) Bernhard Walke (Comnets, Germany) Christophe Diot (Sprint Labs, USA) Farouk Kamoun (ENSI, Tunisia) Fouad Tobagi (Stanford Univ, USA) Gerard LeLann (INRIA, France) Giovanni Pau (UCLA, USA) Guy Omidyar (CWC, Singapore) Guy Pujolle (LIP6, France) Hamid Aghvami (King’s College London, UK) Houssam Afifi (INT, France) Jan Slavik (Testcom, Czech Republic) Jean-Marie Bonnin (ENST-Bretagne, France) Khaldoun Al Agha (LRI, France) Luigi Fratta (Polimi, Italy) Mario Gerla (UCLA, USA) Michel Diaz (LAAS, France) Otto Duarte (UFRJ, Brazil) Parviz Kermani (IBM, USA) Philippe Jacquet (INRIA, France) Pierre Rolin (FTRD, France) Raouf Boutaba (Waterloo, Canada) Ramon Puigjaner (Baleares Univ, Spain) Samir Thomé (ENST, France) Serge Fdida (LIP6, France) Sergio Palazzo (Catania Univ, Italy)) Tomas Robles Valladares (ETSI, Spain) Volker Tschamer (GMD, Gernany) Walid Dabbous (INRIA, France) Authors are invited to submit electronically original contributions in the conference themes and related topics. Papers should not be longer than 12 pages. All submitted papers will be reviewed and evaluated on the basis of relevance, originality, technical quality and clarity. Accepted papers will be included in the conference proceedings. The official workshop oral and written language is English. Paper Submission Deadlines Full Paper Electronic Submission : 15 April 2003 Notification of acceptance/Rejection : 10 May 2003 Camera ready submission of full papers: 20 May 2003 Papers must be submitted by email to: Abdelfattah.belghith@ensi.rnu.tn and frk.kamoun@planet.tn . All information, news and links will be available at the address : http://www.cck.rnu.tn/medhoc2003 Workshop organized by : CRISTAL Laboratory, Ecole Nationale des Sciences de l’Informatique, University of Manouba Tunisia. With the collaboration of : LIP6 Laboratory, University of Paris VI, France. Wireless Adaptive Mobility (WAM) Laboratory, Computer Science Dpt., UCLA, USA. UTIC Laboratory , Ecole Supérieure des Communications, Tunis, Tunisia LRI Laboratory, France. Workshop sponsored by : IFIP-TC6-WG6.8 --------------FD2D9EE3C22551156AD6A6C6 Content-Type: text/x-vcard; charset=us-ascii; name="frk.kamoun.vcf" Content-Description: Carte pour Farouk Kamoun Content-Disposition: attachment; filename="frk.kamoun.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Kamoun;Farouk tel;cell:+216 98 32 80 83 tel;fax:+216 71 600 449 tel;home:+216 71 775 707 tel;work:+216 71 744 065 x-mozilla-html:FALSE adr:;;;;;; version:2.1 email;internet:frk.kamoun@planet.tn fn:Farouk Kamoun end:vcard --------------FD2D9EE3C22551156AD6A6C6-- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 24 17:55:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07081 for ; Mon, 24 Mar 2003 17:55:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2ONFNE09026 for manet-archive@odin.ietf.org; Mon, 24 Mar 2003 18:15:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ONFMO09023 for ; Mon, 24 Mar 2003 18:15:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07057 for ; Mon, 24 Mar 2003 17:54:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2ON5gO07700; Mon, 24 Mar 2003 18:05:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OMwmO07401 for ; Mon, 24 Mar 2003 17:58:48 -0500 Received: from mailer.cacs.louisiana.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06525 for ; Mon, 24 Mar 2003 17:38:16 -0500 (EST) Received: from swamp450.cacs.louisiana.edu (swamp450.cacs.louisiana.edu [130.70.75.99]) by mailer.cacs.louisiana.edu (8.11.3/8.11.3) with ESMTP id h2OMeaq19145 for ; Mon, 24 Mar 2003 16:40:37 -0600 (CST) Date: Mon, 24 Mar 2003 16:40:35 -0600 (CST) From: "Dmitri D. Perkins" To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] IP-802.11 interface Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Some of the manet routing protocols (e.g., AODV abd DSR) have the option of using MAC layer messages to realize link failures. Several simulation based papers have modeled the IEEE 802.11 MAC as providing such connectivity messages to the routing layer. However, is there any work on providing a "real" IP-to-802.11 interface? A broader issue concerns the design tradeoffs and performance gains when using such a vertical-layer or cross-layer design approach. Any studies or thoughts on these issues? Is this problem in the scope of the MANET group? Thanks for you time... Dmitri ================================================== Dr. Dmitri D. Perkins, Assistant Professor The Center for Advanced Computer Studies University of Louisiana at Lafayette P.O. Box 44330, Lafayette, LA 70504-4330 office: (337)482-6732 fax: (337)482-5791 ================================================== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 24 21:27:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14277 for ; Mon, 24 Mar 2003 21:27:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P2lHC23482 for manet-archive@odin.ietf.org; Mon, 24 Mar 2003 21:47:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2lHO23479 for ; Mon, 24 Mar 2003 21:47:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14251 for ; Mon, 24 Mar 2003 21:26:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2YeO22012; Mon, 24 Mar 2003 21:34:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2RVO21630 for ; Mon, 24 Mar 2003 21:27:31 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13822 for ; Mon, 24 Mar 2003 21:06:53 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2P29oNH007948 for ; Tue, 25 Mar 2003 10:09:50 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Tue, 25 Mar 2003 10:01:46 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 191DB16B7A; Tue, 25 Mar 2003 10:08:56 +0800 (SGT) Date: Tue, 25 Mar 2003 10:08:56 +0800 From: Sukanta Kumar Hazra To: "Dmitri D. Perkins" Cc: manet@ietf.org Subject: Re: [manet] IP-802.11 interface Message-ID: <20030325020856.GA9070@localhost> Mail-Followup-To: "Dmitri D. Perkins" , manet@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi Dmitri, I recall that some effort (standard) in this direction was sought in the IP trigger BOF in IETF some time ago. From what I remember they failed to reach a consensus. - Sukanta ----- Original Message ----- From: ""Dmitri D. Perkins" " Date: Tue, 25 Mar, 2003 06:40 SGT Subject: [manet] IP-802.11 interface > > Some of the manet routing protocols (e.g., AODV abd DSR) have the > option of using MAC layer messages to realize link failures. Several > simulation based papers have modeled the IEEE 802.11 MAC as providing > such connectivity messages to the routing layer. However, is there > any work on providing a "real" IP-to-802.11 interface? A broader > issue concerns the design tradeoffs and performance gains when using such > a vertical-layer or cross-layer design approach. Any studies or thoughts > on these issues? > > Is this problem in the scope of the MANET group? > > Thanks for you time... > Dmitri > > ================================================== > Dr. Dmitri D. Perkins, Assistant Professor > The Center for Advanced Computer Studies > University of Louisiana at Lafayette > P.O. Box 44330, Lafayette, LA 70504-4330 > > office: (337)482-6732 fax: (337)482-5791 > ================================================== > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 24 21:33:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14457 for ; Mon, 24 Mar 2003 21:33:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P2rSq23788 for manet-archive@odin.ietf.org; Mon, 24 Mar 2003 21:53:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2rSO23785 for ; Mon, 24 Mar 2003 21:53:28 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14448 for ; Mon, 24 Mar 2003 21:32:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2dsO23042; Mon, 24 Mar 2003 21:39:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P2ViO21938 for ; Mon, 24 Mar 2003 21:31:44 -0500 Received: from memphis.ece.cornell.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13912 for ; Mon, 24 Mar 2003 21:11:09 -0500 (EST) Received: from photon.ece.cornell.edu (photon.ece.cornell.edu [128.84.81.138]) by memphis.ece.cornell.edu (8.11.6/8.11.2) with ESMTP id h2P2DSb32743 for ; Mon, 24 Mar 2003 21:13:28 -0500 Date: Mon, 24 Mar 2003 21:07:19 -0500 (EST) From: Edward Hua X-X-Sender: eyh5@photon.ece.cornell.edu To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] OPNET codes of Split Multipath Routing Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi, I'm wondering if anybody has the OPNET codes of a routing scheme known as Split Multipath Routing (SMR). The researchers who did SMR had NS-2 simulations only. Has anybody done the simulation in OPNET? If so, can I have a copy of the SMR OPNET codes? Thanks in advance. -Ed _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 03:51:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03858 for ; Tue, 25 Mar 2003 03:51:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P9Boq27117 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 04:11:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P9BoO27114 for ; Tue, 25 Mar 2003 04:11:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03850 for ; Tue, 25 Mar 2003 03:51:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P91kO25626; Tue, 25 Mar 2003 04:01:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P8tkO25384 for ; Tue, 25 Mar 2003 03:55:46 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03594 for ; Tue, 25 Mar 2003 03:35:02 -0500 (EST) From: Leping.Huang@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2P8ZrU10138 for ; Tue, 25 Mar 2003 10:35:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Mar 2003 10:37:20 +0200 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Mar 2003 10:37:20 +0200 Received: from toebe001.NOE.Nokia.com ([172.24.109.35]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 25 Mar 2003 10:37:10 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 17:36:57 +0900 Message-ID: Thread-Topic: [manet] IP-802.11 interface Thread-Index: AcLydJt4NVswxpU2Req3VguCg1raIwANDw4w To: , Cc: X-OriginalArrivalTime: 25 Mar 2003 08:37:10.0808 (UTC) FILETIME=[BA420980:01C2F2A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2P8tlO25385 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, Sukata: I am also quite interested in this issue. Do you still remember which WG was tackling this problem inside/outside IETF? Are there any draft/RFC they produced? I was told that there is a draft in MobileIPv6 WG, which may be related to this issue. "Mobile IPv6 Fast Handovers for 802.11 Networks" http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-01.txt Yours Leping Hi Dmitri, I recall that some effort (standard) in this direction was sought in the IP trigger BOF in IETF some time ago. From what I remember they failed to reach a consensus. - Sukanta ----- Original Message ----- From: ""Dmitri D. Perkins" " Date: Tue, 25 Mar, 2003 06:40 SGT Subject: [manet] IP-802.11 interface > > Some of the manet routing protocols (e.g., AODV abd DSR) have the > option of using MAC layer messages to realize link failures. Several > simulation based papers have modeled the IEEE 802.11 MAC as providing > such connectivity messages to the routing layer. However, is there > any work on providing a "real" IP-to-802.11 interface? A broader > issue concerns the design tradeoffs and performance gains when using such > a vertical-layer or cross-layer design approach. Any studies or thoughts > on these issues? > > Is this problem in the scope of the MANET group? > > Thanks for you time... > Dmitri > > ================================================== > Dr. Dmitri D. Perkins, Assistant Professor > The Center for Advanced Computer Studies > University of Louisiana at Lafayette > P.O. Box 44330, Lafayette, LA 70504-4330 > > office: (337)482-6732 fax: (337)482-5791 > ================================================== > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 04:10:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04262 for ; Tue, 25 Mar 2003 04:10:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2P9UX227866 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 04:30:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P9UXO27863 for ; Tue, 25 Mar 2003 04:30:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04237 for ; Tue, 25 Mar 2003 04:09:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P9K7O27423; Tue, 25 Mar 2003 04:20:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2P9FnO27257 for ; Tue, 25 Mar 2003 04:15:49 -0500 Received: from gandalf.icr.a-star.edu.sg ([137.132.31.244]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03931 for ; Tue, 25 Mar 2003 03:54:59 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2P8tQNH012901 for ; Tue, 25 Mar 2003 16:55:26 +0800 (SGT) Received: from sukwin ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Tue, 25 Mar 2003 16:47:32 +0800 Message-ID: <002101c2f2ac$38c05260$80d910ac@sukwin> From: "Sukanta Kumar Hazra" To: , Cc: References: Subject: Re: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 16:55:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 Leping, As I said, I attended the BOF (IP Triggers). Due to lack of consensus it did not go on to become a working group. Yes, the fast handoff draft may provide some clues, but I am not well aware of the activities in the mobileip group. - Sukanta ----- Original Message ----- From: To: ; Cc: Sent: Tuesday, March 25, 2003 4:36 PM Subject: RE: [manet] IP-802.11 interface > Hi, Sukata: > > I am also quite interested in this issue. > Do you still remember which WG was tackling this problem inside/outside IETF? > Are there any draft/RFC they produced? > > I was told that there is a draft in MobileIPv6 WG, which may be related to this issue. > "Mobile IPv6 Fast Handovers for 802.11 Networks" > http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-01.txt > > Yours > Leping > > > > Hi Dmitri, > > I recall that some effort (standard) in this direction was sought in the IP > trigger BOF in IETF some time ago. From what I remember they failed to > reach a consensus. > > - Sukanta > > > ----- Original Message ----- > From: ""Dmitri D. Perkins" " > Date: Tue, 25 Mar, 2003 06:40 SGT > Subject: [manet] IP-802.11 interface > > > > > Some of the manet routing protocols (e.g., AODV abd DSR) have the > > option of using MAC layer messages to realize link failures. Several > > simulation based papers have modeled the IEEE 802.11 MAC as providing > > such connectivity messages to the routing layer. However, is there > > any work on providing a "real" IP-to-802.11 interface? A broader > > issue concerns the design tradeoffs and performance gains when using such > > a vertical-layer or cross-layer design approach. Any studies or thoughts > > on these issues? > > > > Is this problem in the scope of the MANET group? > > > > Thanks for you time... > > Dmitri > > > > ================================================== > > Dr. Dmitri D. Perkins, Assistant Professor > > The Center for Advanced Computer Studies > > University of Louisiana at Lafayette > > P.O. Box 44330, Lafayette, LA 70504-4330 > > > > office: (337)482-6732 fax: (337)482-5791 > > ================================================== > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > -- > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 05:16:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05575 for ; Tue, 25 Mar 2003 05:16:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PAah932277 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 05:36:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PAahO32274 for ; Tue, 25 Mar 2003 05:36:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05569 for ; Tue, 25 Mar 2003 05:15:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PAMaO31476; Tue, 25 Mar 2003 05:22:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PAFFO31178 for ; Tue, 25 Mar 2003 05:15:15 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05063 for ; Tue, 25 Mar 2003 04:54:26 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2P9vKNH013726 for ; Tue, 25 Mar 2003 17:57:20 +0800 (SGT) Received: from bkdom-MTA by mailer.icr.a-star.edu.sg with Novell_GroupWise; Tue, 25 Mar 2003 17:49:30 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.3 Date: Tue, 25 Mar 2003 17:49:21 +0800 From: "Paul Tan Hock Lai" To: , "Sukanta Kumar Hazra" , Cc: Subject: RE: [manet] IP-802.11 interface Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PAFFO31179 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 also interest in this issue too. I have actually tried to query the mailing list on the similar matter, but failed to get a response. Maybe it's out of the scope of MANET. 8-) > Some of the manet routing protocols (e.g., AODV abd DSR) have the > option of using MAC layer messages to realize link failures. MANET protocol (layer) requires triggers (link-up, link-down, etc) from the mobile node (itself), I am not sure it TrigTrans can apply here (triggers sent by other entities). The timing and the reliability of the triggers are important too. Regards, Paul > simulation based papers have modeled the IEEE 802.11 MAC as providing > such connectivity messages to the routing layer. However, is there > any work on providing a "real" IP-to-802.11 interface? A broader > issue concerns the design tradeoffs and performance gains when using such > a vertical-layer or cross-layer design approach. Any studies or thoughts > on these issues? > > Is this problem in the scope of the MANET group? >>> 25-Mar-03 4:36:57 PM >>> Hi, Sukata: I am also quite interested in this issue. Do you still remember which WG was tackling this problem inside/outside IETF? Are there any draft/RFC they produced? I was told that there is a draft in MobileIPv6 WG, which may be related to this issue. "Mobile IPv6 Fast Handovers for 802.11 Networks" http://www.ietf.org/internet-drafts/draft-mccann-mobileip-80211fh-01.txt Yours Leping Hi Dmitri, I recall that some effort (standard) in this direction was sought in the IP trigger BOF in IETF some time ago. From what I remember they failed to reach a consensus. - Sukanta ----- Original Message ----- From: ""Dmitri D. Perkins" " Date: Tue, 25 Mar, 2003 06:40 SGT Subject: [manet] IP-802.11 interface > > Some of the manet routing protocols (e.g., AODV abd DSR) have the > option of using MAC layer messages to realize link failures. Several > simulation based papers have modeled the IEEE 802.11 MAC as providing > such connectivity messages to the routing layer. However, is there > any work on providing a "real" IP-to-802.11 interface? A broader > issue concerns the design tradeoffs and performance gains when using such > a vertical-layer or cross-layer design approach. Any studies or thoughts > on these issues? > > Is this problem in the scope of the MANET group? > > Thanks for you time... > Dmitri > > ================================================== > Dr. Dmitri D. Perkins, Assistant Professor > The Center for Advanced Computer Studies > University of Louisiana at Lafayette > P.O. Box 44330, Lafayette, LA 70504-4330 > > office: (337)482-6732 fax: (337)482-5791 > ================================================== > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 10:53:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19165 for ; Tue, 25 Mar 2003 10:53:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PGE3Y22391 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 11:14:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGE3O22388 for ; Tue, 25 Mar 2003 11:14:03 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19140 for ; Tue, 25 Mar 2003 10:53:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PFtoO20670; Tue, 25 Mar 2003 10:55:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PFnrO20209 for ; Tue, 25 Mar 2003 10:49:53 -0500 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17953 for ; Tue, 25 Mar 2003 10:29:01 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h2PFV7jZ025051; Tue, 25 Mar 2003 10:31:07 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2PFUwWg021333; Tue, 25 Mar 2003 10:31:01 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003032510305821311 ; Tue, 25 Mar 2003 10:30:58 -0500 Message-Id: <5.1.1.5.2.20030325102149.014d7610@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 25 Mar 2003 10:30:58 -0500 To: "Paul Tan Hock Lai" , , "Sukanta Kumar Hazra" , From: Joe Macker Subject: RE: [manet] IP-802.11 interface Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: >Hi, > >I am also interest in this issue too. I have actually tried to query the mailing list on the similar matter, but failed to get a response. Maybe it's out of the scope of MANET. 8-) Its not that its out of scope, but that there has not been a standard interface mechanisms to work with. We have discussed this quite a bit when the WG began. However, that doesn't one can't do something. The MAC ACK monitoring approach has some drawbacks (unicast only and congestion problems) and shouldn't be seen as the best approach, even though that is typically what is simulated. More precise link quality (filtered S/N-based) or simple link up/down would be useful if available.. In most specs the protocols are designed to work in the absence of such mechanisms, but most have wording to say take advantage of such an interface if available. >> Some of the manet routing protocols (e.g., AODV abd DSR) have the >> option of using MAC layer messages to realize link failures. > >MANET protocol (layer) requires triggers (link-up, link-down, etc) from the mobile node (itself), >I am not sure it TrigTrans can apply here (triggers sent by other entities). > >The timing and the reliability of the triggers are important too. Yes, these are important issues. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 11:17:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19970 for ; Tue, 25 Mar 2003 11:17:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PGbxA24253 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 11:37:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGbxO24250 for ; Tue, 25 Mar 2003 11:37:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19940 for ; Tue, 25 Mar 2003 11:17:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGNuO22800; Tue, 25 Mar 2003 11:23:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PGHAO22492 for ; Tue, 25 Mar 2003 11:17:10 -0500 Received: from bluejay.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19228 for ; Tue, 25 Mar 2003 10:56:18 -0500 (EST) Received: from user-11206hj.dsl.mindspring.com ([66.32.26.51] helo=SGOSWAMIPCL) by bluejay.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18xqov-0002yd-00 for manet@ietf.org; Tue, 25 Mar 2003 07:58:37 -0800 From: "Subrata Goswami" To: Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 07:50:56 -0800 Message-ID: <022801c2f2e6$531c03e0$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <5.1.1.5.2.20030325102149.014d7610@pop.itd.nrl.navy.mil> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b9153747d285ea474a148ed524fae2b3b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 Questions. What would the IP-802.11 interface address ? Would it allow manipulation of 802.11 control/mangement frames ? What type of interface would this be - API ? Subrata > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Joe Macker > Sent: Tuesday, March 25, 2003 7:31 AM > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta > Kumar Hazra; Leping.Huang@nokia.com > Cc: manet@ietf.org > Subject: RE: [manet] IP-802.11 interface > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > >Hi, > > > >I am also interest in this issue too. I have actually tried to query > >the mailing list on the similar matter, but failed to get a > response. > >Maybe it's out of the scope of MANET. 8-) > > Its not that its out of scope, but that there has not been a > standard interface mechanisms to work with. We have > discussed this quite a bit when the WG began. However, that > doesn't one can't do something. The MAC ACK monitoring > approach has some drawbacks (unicast only and congestion > problems) and shouldn't be seen as the best approach, even > though that is typically what is simulated. > > More precise link quality (filtered S/N-based) or simple link > up/down would be useful if available.. > > In most specs the protocols are designed to work in the > absence of such mechanisms, but most have wording to say take > advantage of such an interface if available. > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have the > >> option of using MAC layer messages to realize link failures. > > > >MANET protocol (layer) requires triggers (link-up, > link-down, etc) from > >the mobile node (itself), I am not sure it TrigTrans can apply here > >(triggers sent by other entities). > > > >The timing and the reliability of the triggers are important too. > > Yes, these are important issues. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 13:47: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 NAA25033 for ; Tue, 25 Mar 2003 13:47:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJ7Us03250 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 14:07:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJ7UO03239 for ; Tue, 25 Mar 2003 14:07:30 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25025 for ; Tue, 25 Mar 2003 13:46:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PItpO01959; Tue, 25 Mar 2003 13:55:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PIoxO01741 for ; Tue, 25 Mar 2003 13:50:59 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24310 for ; Tue, 25 Mar 2003 13:30:01 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2PIWwNH017997 for ; Wed, 26 Mar 2003 02:32:58 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Wed, 26 Mar 2003 02:25:01 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 2D70D2D50E; Wed, 26 Mar 2003 02:32:10 +0800 (SGT) Date: Wed, 26 Mar 2003 02:32:10 +0800 From: Sukanta Kumar Hazra To: Joe Macker Cc: Paul Tan Hock Lai , perkins@cacs.louisiana.edu, Leping.Huang@nokia.com, manet@ietf.org Subject: Re: [manet] IP-802.11 interface Message-ID: <20030325183210.GA15609@localhost> Mail-Followup-To: Joe Macker , Paul Tan Hock Lai , perkins@cacs.louisiana.edu, Leping.Huang@nokia.com, manet@ietf.org References: <5.1.1.5.2.20030325102149.014d7610@pop.itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.1.5.2.20030325102149.014d7610@pop.itd.nrl.navy.mil> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Would it be fair to interpret that a standard approach for obtaining link quality information is sought by the MANET group? - Sukanta ----- Original Message ----- From: "Joe Macker " Date: Tue, 25 Mar, 2003 23:30 SGT Subject: RE: [manet] IP-802.11 interface > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > >Hi, > > > >I am also interest in this issue too. I have actually tried to query the mailing list on the similar matter, but failed to get a response. Maybe it's out of the scope of MANET. 8-) > > Its not that its out of scope, but that there has not been a standard interface mechanisms to work with. We have discussed this quite a bit when the WG began. However, that doesn't one can't do something. The MAC ACK monitoring approach has some drawbacks (unicast only and congestion problems) and shouldn't be seen as the best approach, even though that is typically what is simulated. > > More precise link quality (filtered S/N-based) or simple link up/down would be useful if available.. > > In most specs the protocols are designed to work in the absence of such mechanisms, but most have wording to say take advantage of such an interface if available. > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have the > >> option of using MAC layer messages to realize link failures. > > > >MANET protocol (layer) requires triggers (link-up, link-down, etc) from the mobile node (itself), > >I am not sure it TrigTrans can apply here (triggers sent by other entities). > > > >The timing and the reliability of the triggers are important too. > > Yes, these are important issues. > > -- -------------------------------------------------------------------- Sukanta Kumar Hazra Institute for Infocomm Research, Singapore Phone: +65 68709338 Fax: +65 67795441 -------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 14:12:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26006 for ; Tue, 25 Mar 2003 14:12:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJWYG04504 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 14:32:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJWYO04501 for ; Tue, 25 Mar 2003 14:32:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25979 for ; Tue, 25 Mar 2003 14:11:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJK4O03784; Tue, 25 Mar 2003 14:20:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJFnO03603 for ; Tue, 25 Mar 2003 14:15:49 -0500 Received: from bluejay.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25393 for ; Tue, 25 Mar 2003 13:54:52 -0500 (EST) Received: from user-11206hj.dsl.mindspring.com ([66.32.26.51] helo=SGOSWAMIPCL) by bluejay.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18xtbk-0004SZ-00 for manet@ietf.org; Tue, 25 Mar 2003 10:57:12 -0800 From: "Subrata Goswami" To: Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 10:49:30 -0800 Message-ID: <024001c2f2ff$4553fe70$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20030325183210.GA15609@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4bf5e7c7795b8e4efec5c326ddd07367d1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 Why limit the API just to link quality ? That seems very myopic to me. If an interface is defined then it needs to be general and be capable of extensions. The general problem is of how to pass information between 802.11 and IP other than IP being payload in 802.11. A standard way to pass information (e.g. Information Elements, ) which are essentially of control type is required. Subrata > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > Behalf Of Sukanta Kumar Hazra > Sent: Tuesday, March 25, 2003 10:32 AM > To: Joe Macker > Cc: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; > Leping.Huang@nokia.com; manet@ietf.org > Subject: Re: [manet] IP-802.11 interface > > > Would it be fair to interpret that a standard approach for > obtaining link quality information is sought by the MANET group? > > - Sukanta > ----- Original Message ----- > From: "Joe Macker " > Date: Tue, 25 Mar, 2003 23:30 SGT > Subject: RE: [manet] IP-802.11 interface > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > > >Hi, > > > > > >I am also interest in this issue too. I have actually > tried to query > > >the mailing list on the similar matter, but failed to get > a response. > > >Maybe it's out of the scope of MANET. 8-) > > > > Its not that its out of scope, but that there has not been > a standard > > interface mechanisms to work with. We have discussed this > quite a bit > > when the WG began. However, that doesn't one can't do > something. The > > MAC ACK monitoring approach has some drawbacks (unicast only and > > congestion problems) and shouldn't be seen as the best > approach, even > > though that is typically what is simulated. > > > > More precise link quality (filtered S/N-based) or simple > link up/down > > would be useful if available.. > > > > In most specs the protocols are designed to work in the absence of > > such mechanisms, but most have wording to say take > advantage of such > > an interface if available. > > > > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) > have the > > >> option of using MAC layer messages to realize link failures. > > > > > >MANET protocol (layer) requires triggers (link-up, link-down, etc) > > >from the mobile node (itself), I am not sure it TrigTrans > can apply > > >here (triggers sent by other entities). > > > > > >The timing and the reliability of the triggers are important too. > > > > Yes, these are important issues. > > > > > > -- > -------------------------------------------------------------------- > Sukanta Kumar Hazra > Institute for Infocomm Research, Singapore > Phone: +65 68709338 Fax: +65 67795441 > -------------------------------------------------------------------- > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 14:28:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26983 for ; Tue, 25 Mar 2003 14:28:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PJnOL06277 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 14:49:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJnOO06274 for ; Tue, 25 Mar 2003 14:49:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26968 for ; Tue, 25 Mar 2003 14:28:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJa9O04666; Tue, 25 Mar 2003 14:36:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJVhO04437 for ; Tue, 25 Mar 2003 14:31:43 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25926 for ; Tue, 25 Mar 2003 14:10:45 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2PJDcNH018355 for ; Wed, 26 Mar 2003 03:13:38 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Wed, 26 Mar 2003 03:05:35 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 0B88E2D50E; Wed, 26 Mar 2003 03:12:46 +0800 (SGT) Date: Wed, 26 Mar 2003 03:12:46 +0800 From: Sukanta Kumar Hazra To: Subrata Goswami Cc: manet@ietf.org Subject: Re: [manet] IP-802.11 interface Message-ID: <20030325191246.GC15696@localhost> Mail-Followup-To: Subrata Goswami , manet@ietf.org References: <5.1.1.5.2.20030325102149.014d7610@pop.itd.nrl.navy.mil> <022801c2f2e6$531c03e0$0200a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <022801c2f2e6$531c03e0$0200a8c0@SGOSWAMIPCL> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Subrata, Maybe it is premature to discuss the requirements for the API at this time, however it could be something as simple as link layer providing triggers (information) to upper layers regarding link status, SNR or anything else that the upper layer may find important. I have seen implementations of such schemes, what lacks is a standard API. - Sukanta ----- Original Message ----- From: "Subrata Goswami " Date: Tue, 25 Mar, 2003 23:50 SGT Subject: RE: [manet] IP-802.11 interface > Questions. What would the IP-802.11 interface address ? > Would it allow manipulation of 802.11 control/mangement frames ? > What type of interface would this be - API ? > > Subrata > > > > -----Original Message----- > > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > > Behalf Of Joe Macker > > Sent: Tuesday, March 25, 2003 7:31 AM > > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta > > Kumar Hazra; Leping.Huang@nokia.com > > Cc: manet@ietf.org > > Subject: RE: [manet] IP-802.11 interface > > > > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > > >Hi, > > > > > >I am also interest in this issue too. I have actually tried to query > > >the mailing list on the similar matter, but failed to get a > > response. > > >Maybe it's out of the scope of MANET. 8-) > > > > Its not that its out of scope, but that there has not been a > > standard interface mechanisms to work with. We have > > discussed this quite a bit when the WG began. However, that > > doesn't one can't do something. The MAC ACK monitoring > > approach has some drawbacks (unicast only and congestion > > problems) and shouldn't be seen as the best approach, even > > though that is typically what is simulated. > > > > More precise link quality (filtered S/N-based) or simple link > > up/down would be useful if available.. > > > > In most specs the protocols are designed to work in the > > absence of such mechanisms, but most have wording to say take > > advantage of such an interface if available. > > > > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have the > > >> option of using MAC layer messages to realize link failures. > > > > > >MANET protocol (layer) requires triggers (link-up, > > link-down, etc) from > > >the mobile node (itself), I am not sure it TrigTrans can apply here > > >(triggers sent by other entities). > > > > > >The timing and the reliability of the triggers are important too. > > > > Yes, these are important issues. > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 14:48:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28035 for ; Tue, 25 Mar 2003 14:48:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PK8i008505 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 15:08:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PK8iO08502 for ; Tue, 25 Mar 2003 15:08:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28005 for ; Tue, 25 Mar 2003 14:47:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJsUO06634; Tue, 25 Mar 2003 14:54:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PJepO05741 for ; Tue, 25 Mar 2003 14:40:51 -0500 Received: from bluejay.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26573 for ; Tue, 25 Mar 2003 14:19:55 -0500 (EST) Received: from user-11206hj.dsl.mindspring.com ([66.32.26.51] helo=SGOSWAMIPCL) by bluejay.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18xtzx-0000G8-00 for manet@ietf.org; Tue, 25 Mar 2003 11:22:13 -0800 From: "Subrata Goswami" To: Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 11:14:31 -0800 Message-ID: <024901c2f302$c40d5f10$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20030325191246.GC15696@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b8e260acc1b8b78b046ee44507337f9d3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I do not think it is premature to discuss what is the problem we are trying to solve. It is difficult to extend protocols/api's beyond what they are designed for. If the effort to design an api(?) is to be spent then, it (api?) should be at least bidirectional (i.e. both to and from 802.11) and extensible. Subrata > -----Original Message----- > From: Sukanta Kumar Hazra [mailto:sukanta@i2r.a-star.edu.sg] > Sent: Tuesday, March 25, 2003 11:13 AM > To: Subrata Goswami > Cc: manet@ietf.org > Subject: Re: [manet] IP-802.11 interface > > > Subrata, > > Maybe it is premature to discuss the requirements for the API > at this time, however it could be something as simple as link > layer providing triggers (information) to upper layers > regarding link status, SNR or anything else that the upper > layer may find important. I have seen implementations of such > schemes, what lacks is a standard API. > > - Sukanta > ----- Original Message ----- > From: "Subrata Goswami " > Date: Tue, 25 Mar, 2003 23:50 SGT > Subject: RE: [manet] IP-802.11 interface > > > Questions. What would the IP-802.11 interface address ? > > Would it allow manipulation of 802.11 control/mangement frames ? > > What type of interface would this be - API ? > > > > Subrata > > > > > > > -----Original Message----- > > > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > > > Behalf Of Joe Macker > > > Sent: Tuesday, March 25, 2003 7:31 AM > > > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta > > > Kumar Hazra; Leping.Huang@nokia.com > > > Cc: manet@ietf.org > > > Subject: RE: [manet] IP-802.11 interface > > > > > > > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > > > >Hi, > > > > > > > >I am also interest in this issue too. I have actually tried to > > > >query > > > >the mailing list on the similar matter, but failed to get a > > > response. > > > >Maybe it's out of the scope of MANET. 8-) > > > > > > Its not that its out of scope, but that there has not been a > > > standard interface mechanisms to work with. We have > > > discussed this quite a bit when the WG began. However, that > > > doesn't one can't do something. The MAC ACK monitoring > > > approach has some drawbacks (unicast only and congestion > > > problems) and shouldn't be seen as the best approach, even > > > though that is typically what is simulated. > > > > > > More precise link quality (filtered S/N-based) or simple link > > > up/down would be useful if available.. > > > > > > In most specs the protocols are designed to work in the > > > absence of such mechanisms, but most have wording to say take > > > advantage of such an interface if available. > > > > > > > > > >> Some of the manet routing protocols (e.g., AODV abd > DSR) have the > > > >> option of using MAC layer messages to realize link failures. > > > > > > > >MANET protocol (layer) requires triggers (link-up, > > > link-down, etc) from > > > >the mobile node (itself), I am not sure it TrigTrans can > apply here > > > >(triggers sent by other entities). > > > > > > > >The timing and the reliability of the triggers are important too. > > > > > > Yes, these are important issues. > > > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > -- > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 15:00:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28738 for ; Tue, 25 Mar 2003 15:00:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKLLV09294 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 15:21:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKLLO09288 for ; Tue, 25 Mar 2003 15:21:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28650 for ; Tue, 25 Mar 2003 15:00:23 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PK8UO08489; Tue, 25 Mar 2003 15:08:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PK3sO07441 for ; Tue, 25 Mar 2003 15:03:54 -0500 Received: from exchange.vivato.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27796 for ; Tue, 25 Mar 2003 14:42:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 11:45:15 -0800 Message-ID: Thread-Topic: [manet] IP-802.11 interface Thread-Index: AcLzBQPrIsi4LtKnSmCRFXKbvSrJnAAAgL6w From: "Jim Thompson" To: "Sukanta Kumar Hazra" , "Subrata Goswami" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PK3sO07442 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Isn't this SNMP? > -----Original Message----- > From: Sukanta Kumar Hazra [mailto:sukanta@i2r.a-star.edu.sg] > Sent: Tuesday, March 25, 2003 11:13 AM > To: Subrata Goswami > Cc: manet@ietf.org > Subject: Re: [manet] IP-802.11 interface > > Subrata, > > Maybe it is premature to discuss the requirements for the API at this > time, however it could be something as simple as link layer providing > triggers (information) to upper layers regarding link status, SNR or > anything else that the upper layer may find important. I have seen > implementations of such schemes, what lacks is a standard API. > > - Sukanta > ----- Original Message ----- > From: "Subrata Goswami " > Date: Tue, 25 Mar, 2003 23:50 SGT > Subject: RE: [manet] IP-802.11 interface > > > Questions. What would the IP-802.11 interface address ? > > Would it allow manipulation of 802.11 control/mangement frames ? > > What type of interface would this be - API ? > > > > Subrata > > > > > > > -----Original Message----- > > > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > > > Behalf Of Joe Macker > > > Sent: Tuesday, March 25, 2003 7:31 AM > > > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta > > > Kumar Hazra; Leping.Huang@nokia.com > > > Cc: manet@ietf.org > > > Subject: RE: [manet] IP-802.11 interface > > > > > > > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > > > >Hi, > > > > > > > >I am also interest in this issue too. I have actually tried to query > > > >the mailing list on the similar matter, but failed to get a > > > response. > > > >Maybe it's out of the scope of MANET. 8-) > > > > > > Its not that its out of scope, but that there has not been a > > > standard interface mechanisms to work with. We have > > > discussed this quite a bit when the WG began. However, that > > > doesn't one can't do something. The MAC ACK monitoring > > > approach has some drawbacks (unicast only and congestion > > > problems) and shouldn't be seen as the best approach, even > > > though that is typically what is simulated. > > > > > > More precise link quality (filtered S/N-based) or simple link > > > up/down would be useful if available.. > > > > > > In most specs the protocols are designed to work in the > > > absence of such mechanisms, but most have wording to say take > > > advantage of such an interface if available. > > > > > > > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have the > > > >> option of using MAC layer messages to realize link failures. > > > > > > > >MANET protocol (layer) requires triggers (link-up, > > > link-down, etc) from > > > >the mobile node (itself), I am not sure it TrigTrans can apply here > > > >(triggers sent by other entities). > > > > > > > >The timing and the reliability of the triggers are important too. > > > > > > Yes, these are important issues. > > > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > -- > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 15:04:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29034 for ; Tue, 25 Mar 2003 15:04:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKP5o09539 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 15:25:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKP5O09536 for ; Tue, 25 Mar 2003 15:25:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28969 for ; Tue, 25 Mar 2003 15:04:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKDuO08833; Tue, 25 Mar 2003 15:13:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PK9KO08635 for ; Tue, 25 Mar 2003 15:09:20 -0500 Received: from bluejay.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28067 for ; Tue, 25 Mar 2003 14:48:23 -0500 (EST) Received: from user-11206hj.dsl.mindspring.com ([66.32.26.51] helo=SGOSWAMIPCL) by bluejay.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18xuRV-000414-00; Tue, 25 Mar 2003 11:50:41 -0800 From: "Subrata Goswami" To: "'Jim Thompson'" , Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 11:42:59 -0800 Message-ID: <024b01c2f306$bdc65400$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b30fcce0f6a7e06d74e66d63b312ab0ab350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 SNMP , how ?? > -----Original Message----- > From: Jim Thompson [mailto:jimt@vivato.net] > Sent: Tuesday, March 25, 2003 11:45 AM > To: Sukanta Kumar Hazra; Subrata Goswami > Cc: manet@ietf.org > Subject: RE: [manet] IP-802.11 interface > > > Isn't this SNMP? > > > -----Original Message----- > > From: Sukanta Kumar Hazra [mailto:sukanta@i2r.a-star.edu.sg] > > Sent: Tuesday, March 25, 2003 11:13 AM > > To: Subrata Goswami > > Cc: manet@ietf.org > > Subject: Re: [manet] IP-802.11 interface > > > > Subrata, > > > > Maybe it is premature to discuss the requirements for the > API at this > > time, however it could be something as simple as link layer > providing > > triggers (information) to upper layers regarding link > status, SNR or > > anything else that the upper layer may find important. I have seen > > implementations of such schemes, what lacks is a standard API. > > > > - Sukanta > > ----- Original Message ----- > > From: "Subrata Goswami " > > Date: Tue, 25 Mar, 2003 23:50 SGT > > Subject: RE: [manet] IP-802.11 interface > > > > > Questions. What would the IP-802.11 interface address ? Would it > > > allow manipulation of 802.11 control/mangement frames ? > What type of > > > interface would this be - API ? > > > > > > Subrata > > > > > > > > > > -----Original Message----- > > > > From: manet-admin@ietf.org > [mailto:manet-admin@ietf.org] On Behalf > > > > Of Joe Macker > > > > Sent: Tuesday, March 25, 2003 7:31 AM > > > > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; > Sukanta Kumar > > > > Hazra; Leping.Huang@nokia.com > > > > Cc: manet@ietf.org > > > > Subject: RE: [manet] IP-802.11 interface > > > > > > > > > > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > > > > >Hi, > > > > > > > > > >I am also interest in this issue too. I have actually tried to > query > > > > >the mailing list on the similar matter, but failed to get a > > > > response. > > > > >Maybe it's out of the scope of MANET. 8-) > > > > > > > > Its not that its out of scope, but that there has not been a > > > > standard interface mechanisms to work with. We have discussed > > > > this quite a bit when the WG began. However, that doesn't one > > > > can't do something. The MAC ACK monitoring approach has some > > > > drawbacks (unicast only and congestion > > > > problems) and shouldn't be seen as the best approach, > even though > > > > that is typically what is simulated. > > > > > > > > More precise link quality (filtered S/N-based) or simple link > > > > up/down would be useful if available.. > > > > > > > > In most specs the protocols are designed to work in the > absence of > > > > such mechanisms, but most have wording to say take advantage of > > > > such an interface if available. > > > > > > > > > > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have > the > > > > >> option of using MAC layer messages to realize link failures. > > > > > > > > > >MANET protocol (layer) requires triggers (link-up, > > > > link-down, etc) from > > > > >the mobile node (itself), I am not sure it TrigTrans can apply > here > > > > >(triggers sent by other entities). > > > > > > > > > >The timing and the reliability of the triggers are > important too. > > > > > > > > Yes, these are important issues. > > > > > > > > > > > > > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 15:11:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00118 for ; Tue, 25 Mar 2003 15:11:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKW4Z10182 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 15:32:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKW4O10177 for ; Tue, 25 Mar 2003 15:32:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00044 for ; Tue, 25 Mar 2003 15:11:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKIMO09081; Tue, 25 Mar 2003 15:18:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PK9nO08674 for ; Tue, 25 Mar 2003 15:09:49 -0500 Received: from kiwi.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28135 for ; Tue, 25 Mar 2003 14:48:52 -0500 (EST) Received: from cs.ucla.edu ([131.179.120.120]) by kiwi.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h2PJp5322365; Tue, 25 Mar 2003 11:51:05 -0800 (PST) Message-ID: <3E80B32C.8040700@cs.ucla.edu> Date: Tue, 25 Mar 2003 11:51:08 -0800 From: Mineo Takai 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: Subrata Goswami CC: manet@ietf.org Subject: Re: [manet] IP-802.11 interface References: <024901c2f302$c40d5f10$0200a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, It is not an IETF effort, but the IEEE 802.11 Working Group created Task Group K (802.11k) to discuss what radio resource measurement data to provide to higher layers. It is not bidirectional (only from 802.11), but may be one of good starting points. Mineo Subrata Goswami wrote: > I do not think it is premature to discuss what is the problem we are > trying to solve. It is difficult to extend protocols/api's beyond what > they are designed for. If the effort to design an api(?) is to be spent > then, it (api?) should be at least bidirectional (i.e. both to and from > 802.11) and extensible. > > Subrata > > > >>-----Original Message----- >>From: Sukanta Kumar Hazra [mailto:sukanta@i2r.a-star.edu.sg] >>Sent: Tuesday, March 25, 2003 11:13 AM >>To: Subrata Goswami >>Cc: manet@ietf.org >>Subject: Re: [manet] IP-802.11 interface >> >> >>Subrata, >> >>Maybe it is premature to discuss the requirements for the API >>at this time, however it could be something as simple as link >>layer providing triggers (information) to upper layers >>regarding link status, SNR or anything else that the upper >>layer may find important. I have seen implementations of such >>schemes, what lacks is a standard API. >> >>- Sukanta >>----- Original Message ----- >>From: "Subrata Goswami " >>Date: Tue, 25 Mar, 2003 23:50 SGT >>Subject: RE: [manet] IP-802.11 interface >> >> >>>Questions. What would the IP-802.11 interface address ? >>>Would it allow manipulation of 802.11 control/mangement frames ? >>>What type of interface would this be - API ? >>> >>>Subrata >>> >>> >>> >>>>-----Original Message----- >>>>From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On >>>>Behalf Of Joe Macker >>>>Sent: Tuesday, March 25, 2003 7:31 AM >>>>To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta >>>>Kumar Hazra; Leping.Huang@nokia.com >>>>Cc: manet@ietf.org >>>>Subject: RE: [manet] IP-802.11 interface >>>> >>>> >>>>At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: >>>> >>>>>Hi, >>>>> >>>>>I am also interest in this issue too. I have actually tried to >>>>>query >>>>>the mailing list on the similar matter, but failed to get a >>>> >>>>response. >>>> >>>>>Maybe it's out of the scope of MANET. 8-) >>>> >>>>Its not that its out of scope, but that there has not been a >>>>standard interface mechanisms to work with. We have >>>>discussed this quite a bit when the WG began. However, that >>>>doesn't one can't do something. The MAC ACK monitoring >>>>approach has some drawbacks (unicast only and congestion >>>>problems) and shouldn't be seen as the best approach, even >>>>though that is typically what is simulated. >>>> >>>>More precise link quality (filtered S/N-based) or simple link >>>>up/down would be useful if available.. >>>> >>>>In most specs the protocols are designed to work in the >>>>absence of such mechanisms, but most have wording to say take >>>>advantage of such an interface if available. >>>> >>>> >>>> >>>>>>Some of the manet routing protocols (e.g., AODV abd >>>>> >>DSR) have the >> >>>>>>option of using MAC layer messages to realize link failures. >>>>> >>>>>MANET protocol (layer) requires triggers (link-up, >>>> >>>>link-down, etc) from >>>> >>>>>the mobile node (itself), I am not sure it TrigTrans can >>>> >>apply here >> >>>>>(triggers sent by other entities). >>>>> >>>>>The timing and the reliability of the triggers are important too. >>>> >>>>Yes, these are important issues. >>>> >>>> >>>> >>>>_______________________________________________ >>>>manet mailing list >>>>manet@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/manet >>>> >>> >>>_______________________________________________ >>>manet mailing list >>>manet@ietf.org >>>https://www1.ietf.org/mailman/listinfo/manet >> >>-- >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 15:17:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00919 for ; Tue, 25 Mar 2003 15:17:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKc5w11638 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 15:38:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKc5O11635 for ; Tue, 25 Mar 2003 15:38:05 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00880 for ; Tue, 25 Mar 2003 15:17:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKMhO09357; Tue, 25 Mar 2003 15:22:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKESO08871 for ; Tue, 25 Mar 2003 15:14:28 -0500 Received: from bluejay.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28310 for ; Tue, 25 Mar 2003 14:53:31 -0500 (EST) Received: from user-11206hj.dsl.mindspring.com ([66.32.26.51] helo=SGOSWAMIPCL) by bluejay.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18xuWT-0004bl-00; Tue, 25 Mar 2003 11:55:50 -0800 From: "Subrata Goswami" To: "'Mineo Takai'" Cc: Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 11:48:07 -0800 Message-ID: <024c01c2f307$75a54040$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3E80B32C.8040700@cs.ucla.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4bfe278d5fc5a6a3bc2b874883b322b292350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 That is good to know, IETF should get involved with anything that provides info to layers below IP, should not it ? A parallel work to 802.11K in IETF is required, is not it ? Subrata > -----Original Message----- > From: Mineo Takai [mailto:mineo@CS.UCLA.EDU] > Sent: Tuesday, March 25, 2003 11:51 AM > To: Subrata Goswami > Cc: manet@ietf.org > Subject: Re: [manet] IP-802.11 interface > > > Hi, > > It is not an IETF effort, but the IEEE 802.11 Working Group > created Task > Group K (802.11k) to discuss what radio resource measurement data to > provide to higher layers. It is not bidirectional (only from 802.11), > but may be one of good starting points. > > Mineo > > Subrata Goswami wrote: > > I do not think it is premature to discuss what is the > problem we are > > trying to solve. It is difficult to extend protocols/api's > beyond what > > they are designed for. If the effort to design an api(?) is to be > > spent then, it (api?) should be at least bidirectional > (i.e. both to > > and from > > 802.11) and extensible. > > > > Subrata > > > > > > > >>-----Original Message----- > >>From: Sukanta Kumar Hazra [mailto:sukanta@i2r.a-star.edu.sg] > >>Sent: Tuesday, March 25, 2003 11:13 AM > >>To: Subrata Goswami > >>Cc: manet@ietf.org > >>Subject: Re: [manet] IP-802.11 interface > >> > >> > >>Subrata, > >> > >>Maybe it is premature to discuss the requirements for the API > >>at this time, however it could be something as simple as link > >>layer providing triggers (information) to upper layers > >>regarding link status, SNR or anything else that the upper > >>layer may find important. I have seen implementations of such > >>schemes, what lacks is a standard API. > >> > >>- Sukanta > >>----- Original Message ----- > >>From: "Subrata Goswami " > >>Date: Tue, 25 Mar, 2003 23:50 SGT > >>Subject: RE: [manet] IP-802.11 interface > >> > >> > >>>Questions. What would the IP-802.11 interface address ? Would it > >>>allow manipulation of 802.11 control/mangement frames ? > What type of > >>>interface would this be - API ? > >>> > >>>Subrata > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] > On Behalf > >>>>Of Joe Macker > >>>>Sent: Tuesday, March 25, 2003 7:31 AM > >>>>To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta > >>>>Kumar Hazra; Leping.Huang@nokia.com > >>>>Cc: manet@ietf.org > >>>>Subject: RE: [manet] IP-802.11 interface > >>>> > >>>> > >>>>At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > >>>> > >>>>>Hi, > >>>>> > >>>>>I am also interest in this issue too. I have actually tried to > >>>>>query > >>>>>the mailing list on the similar matter, but failed to get a > >>>> > >>>>response. > >>>> > >>>>>Maybe it's out of the scope of MANET. 8-) > >>>> > >>>>Its not that its out of scope, but that there has not been a > >>>>standard interface mechanisms to work with. We have > discussed this > >>>>quite a bit when the WG began. However, that doesn't one can't do > >>>>something. The MAC ACK monitoring approach has some drawbacks > >>>>(unicast only and congestion > >>>>problems) and shouldn't be seen as the best approach, even > >>>>though that is typically what is simulated. > >>>> > >>>>More precise link quality (filtered S/N-based) or simple link > >>>>up/down would be useful if available.. > >>>> > >>>>In most specs the protocols are designed to work in the > absence of > >>>>such mechanisms, but most have wording to say take > advantage of such > >>>>an interface if available. > >>>> > >>>> > >>>> > >>>>>>Some of the manet routing protocols (e.g., AODV abd > >>>>> > >>DSR) have the > >> > >>>>>>option of using MAC layer messages to realize link failures. > >>>>> > >>>>>MANET protocol (layer) requires triggers (link-up, > >>>> > >>>>link-down, etc) from > >>>> > >>>>>the mobile node (itself), I am not sure it TrigTrans can > >>>> > >>apply here > >> > >>>>>(triggers sent by other entities). > >>>>> > >>>>>The timing and the reliability of the triggers are important too. > >>>> > >>>>Yes, these are important issues. > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>manet mailing list > >>>>manet@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/manet > >>>> > >>> > >>>_______________________________________________ > >>>manet mailing list > >>>manet@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/manet > >> > >>-- > >> > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 15:17: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 PAA00943 for ; Tue, 25 Mar 2003 15:17:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKcGN11664 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 15:38:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKcGO11661 for ; Tue, 25 Mar 2003 15:38:16 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00893 for ; Tue, 25 Mar 2003 15:17:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKQjO09614; Tue, 25 Mar 2003 15:26:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKF8O08918 for ; Tue, 25 Mar 2003 15:15:08 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28341 for ; Tue, 25 Mar 2003 14:54:10 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2PJv7NH018748 for ; Wed, 26 Mar 2003 03:57:07 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Wed, 26 Mar 2003 03:49:05 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id C628E2D50E; Wed, 26 Mar 2003 03:56:16 +0800 (SGT) Date: Wed, 26 Mar 2003 03:56:16 +0800 From: Sukanta Kumar Hazra To: manet@ietf.org Subject: Re: [manet] IP-802.11 interface Message-ID: <20030325195616.GC15793@localhost> Mail-Followup-To: manet@ietf.org References: <20030325183210.GA15609@localhost> <024001c2f2ff$4553fe70$0200a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024001c2f2ff$4553fe70$0200a8c0@SGOSWAMIPCL> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Agreed. I should have phrased it better (as an example, link quality). And not just 802.11 but lets call it link later. - Sukanta ----- Original Message ----- From: "Subrata Goswami " Date: Wed, 26 Mar, 2003 02:49 SGT Subject: RE: [manet] IP-802.11 interface > Why limit the API just to link quality ? That seems very myopic to me. > If an interface is defined then it needs to be general and be capable of > extensions. > > The general problem is of how to pass information between 802.11 and IP > other than IP being payload in 802.11. A standard way to pass > information (e.g. Information Elements, ) which are essentially of > control type is required. > > Subrata > > > -----Original Message----- > > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On > > Behalf Of Sukanta Kumar Hazra > > Sent: Tuesday, March 25, 2003 10:32 AM > > To: Joe Macker > > Cc: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; > > Leping.Huang@nokia.com; manet@ietf.org > > Subject: Re: [manet] IP-802.11 interface > > > > > > Would it be fair to interpret that a standard approach for > > obtaining link quality information is sought by the MANET group? > > > > - Sukanta > > ----- Original Message ----- > > From: "Joe Macker " > > Date: Tue, 25 Mar, 2003 23:30 SGT > > Subject: RE: [manet] IP-802.11 interface > > > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > > > >Hi, > > > > > > > >I am also interest in this issue too. I have actually > > tried to query > > > >the mailing list on the similar matter, but failed to get > > a response. > > > >Maybe it's out of the scope of MANET. 8-) > > > > > > Its not that its out of scope, but that there has not been > > a standard > > > interface mechanisms to work with. We have discussed this > > quite a bit > > > when the WG began. However, that doesn't one can't do > > something. The > > > MAC ACK monitoring approach has some drawbacks (unicast only and > > > congestion problems) and shouldn't be seen as the best > > approach, even > > > though that is typically what is simulated. > > > > > > More precise link quality (filtered S/N-based) or simple > > link up/down > > > would be useful if available.. > > > > > > In most specs the protocols are designed to work in the absence of > > > such mechanisms, but most have wording to say take > > advantage of such > > > an interface if available. > > > > > > > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) > > have the > > > >> option of using MAC layer messages to realize link failures. > > > > > > > >MANET protocol (layer) requires triggers (link-up, link-down, etc) > > > >from the mobile node (itself), I am not sure it TrigTrans > > can apply > > > >here (triggers sent by other entities). > > > > > > > >The timing and the reliability of the triggers are important too. > > > > > > Yes, these are important issues. > > > > > > > > > > -- > > -------------------------------------------------------------------- > > Sukanta Kumar Hazra > > Institute for Infocomm Research, Singapore > > Phone: +65 68709338 Fax: +65 67795441 > > -------------------------------------------------------------------- > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 15:27:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01519 for ; Tue, 25 Mar 2003 15:27:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKlXp12519 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 15:47:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKlXO12516 for ; Tue, 25 Mar 2003 15:47:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01493 for ; Tue, 25 Mar 2003 15:26:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKbaO11378; Tue, 25 Mar 2003 15:37:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKWeO10284 for ; Tue, 25 Mar 2003 15:32:40 -0500 Received: from hermes.fm.intel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00158 for ; Tue, 25 Mar 2003 15:11:42 -0500 (EST) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.51 2002/09/23 20:43:23 dmccart Exp $) with ESMTP id h2PKAT206155 for ; Tue, 25 Mar 2003 20:10:29 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.28 2003/01/13 19:44:39 dmccart Exp $) with SMTP id h2PIK8P00268 for ; Tue, 25 Mar 2003 18:20:09 GMT Received: from fmsmsx019.fm.intel.com ([132.233.42.130]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003032510232705737 ; Tue, 25 Mar 2003 10:23:27 -0800 Received: by fmsmsx019.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Mar 2003 10:25:30 -0800 Message-ID: From: "Yang, Lily L" To: "'Joe Macker'" , Paul Tan Hock Lai , perkins@cacs.louisiana.edu, Sukanta Kumar Hazra , Leping.Huang@nokia.com Cc: manet@ietf.org Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 10:25:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , In the recent IEEE Plenary meeting, Mesh Network presented a proposal to extend 802.11 to better support mesh networking. One of the recommendations is to extend the existing 802.11 standard MAC to allow information pertinent to ad hoc networking to be passed across the network efficiently. I quote a few paragraphs relevant to the discussion here -- "Feedback from MAC/LLC to Routing implementation: Immediate feedback of the TX and Rx status of packets received is critical in developing a reliable ad-hoc routing network. This status data is typically available in some form from the MAC layer implementations of 802.11 hardware, but is seldom available outside of the scope of the link layer. In Layer 2 routing implementations based in or immediately above the link layer this information can be passed directly. In layer 3 implementations the cost of reporting per-packet information up to the network layer of a protocol stack may be computationally or architecturally prohibitive. In that case a cumulative derivative value can be computed in a small module collocated near the MAC. This value can then be reported to the routing layer on a less frequent per-destination basis. Most current driver/stack combinations do not pass this information up in the stack. Mac layer acknowledgements for transmitted directed packets must be reported to some agent of the routing implementations. This is necessary to determine the status of links in the multi-hop network. Some normalized measure of signal quality or S/N ratio of received packets must be reported on a per packet basis to some agent of the routing implementation. Management packets should be made available to some agent of the routing implementation so they can be used to inform the routing of status of individual neighboring stations." "Feedback from the PHY: A normalized measure of the number of corrected bit errors on a received perpacket should be made available to some agent of the routing implementation. This can be used to predict degrading links in the network and proactively switch routes." The full presentation can be found at: http://www.ieee802.org/meeting/meeting_files/Ad%20Hoc%20And%208022.pdf So maybe IEEE instead of IETF is the right place to do this ... In any event, if 802.11 is going to work well for mesh networking, perhaps it also calls for better coordination/interaction between the two groups. -----Original Message----- From: Joe Macker [mailto:macker@itd.nrl.navy.mil] Sent: Tuesday, March 25, 2003 7:31 AM To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta Kumar Hazra; Leping.Huang@nokia.com Cc: manet@ietf.org Subject: RE: [manet] IP-802.11 interface At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: >Hi, > >I am also interest in this issue too. I have actually tried to query the mailing list on the similar matter, but failed to get a response. Maybe it's out of the scope of MANET. 8-) Its not that its out of scope, but that there has not been a standard interface mechanisms to work with. We have discussed this quite a bit when the WG began. However, that doesn't one can't do something. The MAC ACK monitoring approach has some drawbacks (unicast only and congestion problems) and shouldn't be seen as the best approach, even though that is typically what is simulated. More precise link quality (filtered S/N-based) or simple link up/down would be useful if available.. In most specs the protocols are designed to work in the absence of such mechanisms, but most have wording to say take advantage of such an interface if available. >> Some of the manet routing protocols (e.g., AODV abd DSR) have the >> option of using MAC layer messages to realize link failures. > >MANET protocol (layer) requires triggers (link-up, link-down, etc) from the mobile node (itself), >I am not sure it TrigTrans can apply here (triggers sent by other entities). > >The timing and the reliability of the triggers are important too. Yes, these are important issues. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 15:30:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01831 for ; Tue, 25 Mar 2003 15:30:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PKpFC12923 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 15:51:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKpFO12920 for ; Tue, 25 Mar 2003 15:51:15 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01772 for ; Tue, 25 Mar 2003 15:30:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKfvO11912; Tue, 25 Mar 2003 15:41:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PKZQO10649 for ; Tue, 25 Mar 2003 15:35:26 -0500 Received: from bluejay.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00548 for ; Tue, 25 Mar 2003 15:14:28 -0500 (EST) Received: from user-11206hj.dsl.mindspring.com ([66.32.26.51] helo=SGOSWAMIPCL) by bluejay.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18xuqj-0007Ln-00; Tue, 25 Mar 2003 12:16:46 -0800 From: "Subrata Goswami" To: "'Jim Thompson'" Cc: Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 12:09:03 -0800 Message-ID: <024e01c2f30a$62502fc0$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b14aff221d690822cf49f102b4fc9fbef350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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 So you are saying something like the following ? The IP and 802.11 layers now has to somehow talk through SNMP ? What are these API(?)'s ? Layer 5 [SNMP] /\ / \ Layer 3 [IP ] \ \ \ Layer 2/1 [802.11] Subrata > -----Original Message----- > From: Jim Thompson [mailto:jimt@vivato.net] > Sent: Tuesday, March 25, 2003 12:07 PM > To: Subrata Goswami > Subject: RE: [manet] IP-802.11 interface > > > Link up, link down: traps (triggers work well too) > Snr: mib variables > > > -----Original Message----- > > From: Subrata Goswami [mailto:sgoswami@umich.edu] > > Sent: Tuesday, March 25, 2003 11:43 AM > > To: Jim Thompson; manet@ietf.org > > Subject: RE: [manet] IP-802.11 interface > > > > SNMP , how ?? > > > > > > > -----Original Message----- > > > From: Jim Thompson [mailto:jimt@vivato.net] > > > Sent: Tuesday, March 25, 2003 11:45 AM > > > To: Sukanta Kumar Hazra; Subrata Goswami > > > Cc: manet@ietf.org > > > Subject: RE: [manet] IP-802.11 interface > > > > > > > > > Isn't this SNMP? > > > > > > > -----Original Message----- > > > > From: Sukanta Kumar Hazra [mailto:sukanta@i2r.a-star.edu.sg] > > > > Sent: Tuesday, March 25, 2003 11:13 AM > > > > To: Subrata Goswami > > > > Cc: manet@ietf.org > > > > Subject: Re: [manet] IP-802.11 interface > > > > > > > > Subrata, > > > > > > > > Maybe it is premature to discuss the requirements for the > > > API at this > > > > time, however it could be something as simple as link layer > > > providing > > > > triggers (information) to upper layers regarding link > > > status, SNR or > > > > anything else that the upper layer may find important. > I have seen > > > > implementations of such schemes, what lacks is a standard API. > > > > > > > > - Sukanta > > > > ----- Original Message ----- > > > > From: "Subrata Goswami " > > > > Date: Tue, 25 Mar, 2003 23:50 SGT > > > > Subject: RE: [manet] IP-802.11 interface > > > > > > > > > Questions. What would the IP-802.11 interface address > ? Would it > > > > > allow manipulation of 802.11 control/mangement frames ? > > > What type of > > > > > interface would this be - API ? > > > > > > > > > > Subrata > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: manet-admin@ietf.org > > > [mailto:manet-admin@ietf.org] On Behalf > > > > > > Of Joe Macker > > > > > > Sent: Tuesday, March 25, 2003 7:31 AM > > > > > > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; > > > Sukanta Kumar > > > > > > Hazra; Leping.Huang@nokia.com > > > > > > Cc: manet@ietf.org > > > > > > Subject: RE: [manet] IP-802.11 interface > > > > > > > > > > > > > > > > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > > > > > > >Hi, > > > > > > > > > > > > > >I am also interest in this issue too. I have actually tried > to > > > query > > > > > > >the mailing list on the similar matter, but failed to get a > > > > > > response. > > > > > > >Maybe it's out of the scope of MANET. 8-) > > > > > > > > > > > > Its not that its out of scope, but that there has > not been a > > > > > > standard interface mechanisms to work with. We > have discussed > > > > > > this quite a bit when the WG began. However, that > doesn't one > > > > > > can't do something. The MAC ACK monitoring approach > has some > > > > > > drawbacks (unicast only and congestion > > > > > > problems) and shouldn't be seen as the best approach, > > > even though > > > > > > that is typically what is simulated. > > > > > > > > > > > > More precise link quality (filtered S/N-based) or > simple link > > > > > > up/down would be useful if available.. > > > > > > > > > > > > In most specs the protocols are designed to work in the > > > absence of > > > > > > such mechanisms, but most have wording to say take advantage > of > > > > > > such an interface if available. > > > > > > > > > > > > > > > > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) > have > > > the > > > > > > >> option of using MAC layer messages to realize link > failures. > > > > > > > > > > > > > >MANET protocol (layer) requires triggers (link-up, > > > > > > link-down, etc) from > > > > > > >the mobile node (itself), I am not sure it TrigTrans can > apply > > > here > > > > > > >(triggers sent by other entities). > > > > > > > > > > > > > >The timing and the reliability of the triggers are > > > important too. > > > > > > > > > > > > Yes, these are important issues. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > manet mailing list > > > > > > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > > > > > > > > > _______________________________________________ > > > > > manet mailing list > > > > > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > > > > > > > > -- > > > > _______________________________________________ > > > > manet mailing list > > > > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 17:19:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06880 for ; Tue, 25 Mar 2003 17:19:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PMddX22591 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 17:39:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMddO22588 for ; Tue, 25 Mar 2003 17:39:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06842 for ; Tue, 25 Mar 2003 17:18:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMNnO20992; Tue, 25 Mar 2003 17:23:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMExO20476 for ; Tue, 25 Mar 2003 17:14:59 -0500 Received: from copland.udel.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05621 for ; Tue, 25 Mar 2003 16:53:59 -0500 (EST) Received: from udel.edu (host75-110.student.udel.edu [128.175.75.110]) by copland.udel.edu (8.12.8/8.12.8) with ESMTP id h2PLuHrg023222 for ; Tue, 25 Mar 2003 16:56:18 -0500 (EST) Message-ID: <3E80D07A.2030800@udel.edu> Date: Tue, 25 Mar 2003 16:56:10 -0500 From: Girish Borkar Reply-To: girish@cis.udel.edu Organization: CIS UD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 NOSPAM_INC,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MOZILLA_UA,X_ACCEPT_LANG X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [manet] 802.11a and 802.11b Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi everyone, Can anyone point me to an article which summarizes differences between 802.11a and 802.11b standards. I know the main differences like the difference in data rates and the frequency band used. Any other differences ? Another question is about the lower interference in the 5Ghz band. Is it just due to the fact that there is less stray tranmission in that range ? I read somewhere that there are more channels are available in the 5Ghz band which results in lower interference... ??? Can the nodes dynamically switch channels to counter interference ? Thanks, Girish Borkar University of Delaware _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 18:10:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09896 for ; Tue, 25 Mar 2003 18:10:33 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2PNV4P26428 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 18:31:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNV4O26425 for ; Tue, 25 Mar 2003 18:31:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09848 for ; Tue, 25 Mar 2003 18:10:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNJPO25359; Tue, 25 Mar 2003 18:19:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PMwNO23575 for ; Tue, 25 Mar 2003 17:58:23 -0500 Received: from smtp4.server.rpi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07400 for ; Tue, 25 Mar 2003 17:37:21 -0500 (EST) Received: from NILE (nile.ecse.rpi.edu [128.113.61.117]) by smtp4.server.rpi.edu (8.12.8/8.12.7) with SMTP id h2PMdfuE007108; Tue, 25 Mar 2003 17:39:41 -0500 Message-ID: <002301c2f31f$9235f2a0$753d7180@NILE> From: "Alhussein Abouzeid" To: "Yang, Lily L" Cc: References: Subject: Re: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 17:40:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Scanned-By: MIMEDefang 2.28 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 For some time now, many have advocated that the layering approach doesn't work well for ad-hoc (transport, routing etc.) and have proposed solutions when the layers were allowed to "talk" to each other. It is actually quite refreshing to see some serious talk here about standardization activities for interlayer interactions. My question pertains to a statement you make below that interlayer interactions may incur prohibitively high additional cost. It would be quite helpful if you would provide some details on this assessment from your experiments. You also raise a point about scalability in the introductory part of your report. Gupta and Kumar's work comes to mind, among others. Again, I was wondering if you had some experimental results regarding this. Many thanks. AA ----- Original Message ----- From: "Yang, Lily L" To: "'Joe Macker'" ; "Paul Tan Hock Lai" ; ; "Sukanta Kumar Hazra" ; Cc: Sent: Tuesday, March 25, 2003 1:25 PM Subject: RE: [manet] IP-802.11 interface > > In the recent IEEE Plenary meeting, Mesh Network presented a proposal to > extend 802.11 to better support mesh networking. One of the recommendations > is to extend the existing 802.11 standard MAC to allow information pertinent > to ad hoc networking to be passed across the network efficiently. I quote a > few paragraphs relevant to the discussion here -- > "Feedback from MAC/LLC to Routing implementation: > Immediate feedback of the TX and Rx status of packets received is critical > in > developing a reliable ad-hoc routing network. This status data is typically > available in some form from the MAC layer implementations of 802.11 > hardware, > but is seldom available outside of the scope of the link layer. In Layer 2 > routing > implementations based in or immediately above the link layer this > information > can be passed directly. In layer 3 implementations the cost of reporting > per-packet > information up to the network layer of a protocol stack may be > computationally or > architecturally prohibitive. In that case a cumulative derivative value can > be > computed in a small module collocated near the MAC. This value can then be > reported to the routing layer on a less frequent per-destination basis. Most > current > driver/stack combinations do not pass this information up in the stack. > Mac layer acknowledgements for transmitted directed packets must be reported > to > some agent of the routing implementations. This is necessary to determine > the > status of links in the multi-hop network. > Some normalized measure of signal quality or S/N ratio of received packets > must > be reported on a per packet basis to some agent of the routing > implementation. > Management packets should be made available to some agent of the routing > implementation so they can be used to inform the routing of status of > individual > neighboring stations." > "Feedback from the PHY: > A normalized measure of the number of corrected bit errors on a received > perpacket > should be made available to some agent of the routing implementation. > This can be used to predict degrading links in the network and proactively > switch > routes." > > The full presentation can be found at: > http://www.ieee802.org/meeting/meeting_files/Ad%20Hoc%20And%208022.pdf > > So maybe IEEE instead of IETF is the right place to do this ... > In any event, if 802.11 is going to work well for mesh networking, perhaps > it also calls for better coordination/interaction between the two groups. > > -----Original Message----- > From: Joe Macker [mailto:macker@itd.nrl.navy.mil] > Sent: Tuesday, March 25, 2003 7:31 AM > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta Kumar Hazra; > Leping.Huang@nokia.com > Cc: manet@ietf.org > Subject: RE: [manet] IP-802.11 interface > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > >Hi, > > > >I am also interest in this issue too. I have actually tried to query the > mailing list on the similar matter, but failed to get a response. Maybe it's > out of the scope of MANET. 8-) > > Its not that its out of scope, but that there has not been a standard > interface mechanisms to work with. We have discussed this quite a bit when > the WG began. However, that doesn't one can't do something. The MAC ACK > monitoring approach has some drawbacks (unicast only and congestion > problems) and shouldn't be seen as the best approach, even though that is > typically what is simulated. > > More precise link quality (filtered S/N-based) or simple link up/down would > be useful if available.. > > In most specs the protocols are designed to work in the absence of such > mechanisms, but most have wording to say take advantage of such an interface > if available. > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have the > >> option of using MAC layer messages to realize link failures. > > > >MANET protocol (layer) requires triggers (link-up, link-down, etc) from the > mobile node (itself), > >I am not sure it TrigTrans can apply here (triggers sent by other > entities). > > > >The timing and the reliability of the triggers are important too. > > Yes, these are important issues. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 18:47:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11564 for ; Tue, 25 Mar 2003 18:47:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q08VI29524 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 19:08:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q08VO29521 for ; Tue, 25 Mar 2003 19:08:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11536 for ; Tue, 25 Mar 2003 18:47:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNwKO28281; Tue, 25 Mar 2003 18:58:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNrvO28096 for ; Tue, 25 Mar 2003 18:53:57 -0500 Received: from stl-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11075 for ; Tue, 25 Mar 2003 18:32:55 -0500 (EST) Received: from stl-av-02.boeing.com ([192.76.190.7]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id RAA18882; Tue, 25 Mar 2003 17:35:14 -0600 (CST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id RAA00499; Tue, 25 Mar 2003 17:35:14 -0600 (CST) 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 h2PNZCl09494; Tue, 25 Mar 2003 15:35:12 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 18:35:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [manet] 802.11a and 802.11b Date: Tue, 25 Mar 2003 18:35:11 -0500 Message-ID: Thread-Topic: [manet] 802.11a and 802.11b Thread-Index: AcLzGvon6ly6RV7+R/OcSjt2iPrn7wACks0g From: "Manfredi, Albert E" To: , X-OriginalArrivalTime: 25 Mar 2003 23:35:11.0335 (UTC) FILETIME=[2D8DFF70:01C2F327] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PNrvO28097 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Girish Borkar wrote: > Hi everyone, > > Can anyone point me to an article which summarizes differences between > 802.11a and 802.11b standards. I know the main differences like the > difference in data rates and the frequency band used. > Any other differences ? If you go to the IEEE web site, you can download IEEE 802.11, and the 802.11a and 802.11b supplements. I think you'll find that the differences are all in the lower layers: PHY, PLCP, PMD. Modulation schemes, scrambling, forward error correction, frequency bands, and speed options. Briefly, 802.11b is in the 2.6 GHz band, uses direct sequence spread spectrum, very similar to CDMA cell phones, actually very similar to 3G cellular. Where 802.11a, in the 5 GHz band, uses orthogonal frequency division multiplexing. A multicarrier scheme as used in European digital TV broadcast. > Another question is about the lower interference in the 5Ghz band. > Is it just due to the fact that there is less stray > tranmission in that > range ? > I read somewhere that there are more channels are available > in the 5Ghz band > which > results in lower interference... ??? Again, the documents describe this. There are 14 bands available in IEEE 802.11b, and only 12 in IEEE 802.11a. But, for example, in IEEE 802.11a each band is 40 MHz wide, yet they are spaced 20 MHz apart. Meaning that they can't all be used in the same location. The interference is less at the 5 GHz band only because there's less stuff up there and signals attenuate faster up that high. > Can the nodes dynamically switch channels to counter interference ? Once the LAN has chosen a frequency band, it stays there. Is that what you're asking? Nodes can search for availability of a wireless LAN, yes, but the LAN will not suddenly change frequency if the one chosen is bad for some of the hosts. At least, that's a feature that I would be unaware of (not that being unaware is anything new for me). Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 18:56:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11934 for ; Tue, 25 Mar 2003 18:56:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q0Gmx30079 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 19:16:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0GmO30076 for ; Tue, 25 Mar 2003 19:16:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11918 for ; Tue, 25 Mar 2003 18:55:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q07RO29172; Tue, 25 Mar 2003 19:07:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2PNu0O28192 for ; Tue, 25 Mar 2003 18:56:00 -0500 Received: from slb-smtpout-01.boeing.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11117 for ; Tue, 25 Mar 2003 18:34:58 -0500 (EST) Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA04331; Tue, 25 Mar 2003 15:37:00 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id PAA04057; Tue, 25 Mar 2003 15:37:17 -0800 (PST) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h2PNbFl12664; Tue, 25 Mar 2003 15:37:15 -0800 (PST) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Mar 2003 18:37:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [manet] 802.11a and 802.11b Date: Tue, 25 Mar 2003 18:37:14 -0500 Message-ID: Thread-Topic: [manet] 802.11a and 802.11b Thread-Index: AcLzGvon6ly6RV7+R/OcSjt2iPrn7wACks0gAACBtWA= From: "Manfredi, Albert E" To: , X-OriginalArrivalTime: 25 Mar 2003 23:37:14.0848 (UTC) FILETIME=[772C9600:01C2F327] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2PNu0O28193 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 > Briefly, 802.11b is in the 2.6 GHz band, uses direct sequence > spread spectrum, very similar to CDMA cell phones, actually > very similar to 3G cellular. Ooops. Forgot that frequency hopping spread spectrum is a legal option for IEEE 802.11b. Bert _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 19:06:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12359 for ; Tue, 25 Mar 2003 19:06:19 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q0Qpu30820 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 19:26:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0QpO30817 for ; Tue, 25 Mar 2003 19:26:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12347 for ; Tue, 25 Mar 2003 19:05:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0F8O29991; Tue, 25 Mar 2003 19:15:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q0AJO29765 for ; Tue, 25 Mar 2003 19:10:19 -0500 Received: from smtp.covadmail.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11674 for ; Tue, 25 Mar 2003 18:49:16 -0500 (EST) Received: (covad.net 19461 invoked from network); 25 Mar 2003 23:51:33 -0000 Received: from unknown (HELO amd2100) (64.105.208.137) by sun-qmail14 with SMTP; 25 Mar 2003 23:51:33 -0000 Reply-To: From: "Herbert Rubens" To: Cc: "'Yang, Lily L'" Subject: RE: [manet] IP-802.11 interface Date: Tue, 25 Mar 2003 18:51:34 -0500 Organization: Center for Networking and Distributed Systems Message-ID: <001301c2f329$77a8e000$0300a8c0@amd2100> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I absolutely agree that the availability of MAC and physical layer signal quality information is essential in order to make efficient routing decisions. Aside from link failure detection, this information can be used to increase route stability and throughput. This is briefly mentioned in the presentation you referred to. We have been actively researching how this information can be used to enhance routing. A technical report is available which examines this in detail. http://www.cnds.jhu.edu/research/networks/archipelago/publications/MTM-T echnicalReport2.pdf -----Original Message----- From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of Yang, Lily L Sent: Tuesday, March 25, 2003 1:25 PM To: 'Joe Macker'; Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta Kumar Hazra; Leping.Huang@nokia.com Cc: manet@ietf.org Subject: RE: [manet] IP-802.11 interface In the recent IEEE Plenary meeting, Mesh Network presented a proposal to extend 802.11 to better support mesh networking. One of the recommendations is to extend the existing 802.11 standard MAC to allow information pertinent to ad hoc networking to be passed across the network efficiently. I quote a few paragraphs relevant to the discussion here -- "Feedback from MAC/LLC to Routing implementation: Immediate feedback of the TX and Rx status of packets received is critical in developing a reliable ad-hoc routing network. This status data is typically available in some form from the MAC layer implementations of 802.11 hardware, but is seldom available outside of the scope of the link layer. In Layer 2 routing implementations based in or immediately above the link layer this information can be passed directly. In layer 3 implementations the cost of reporting per-packet information up to the network layer of a protocol stack may be computationally or architecturally prohibitive. In that case a cumulative derivative value can be computed in a small module collocated near the MAC. This value can then be reported to the routing layer on a less frequent per-destination basis. Most current driver/stack combinations do not pass this information up in the stack. Mac layer acknowledgements for transmitted directed packets must be reported to some agent of the routing implementations. This is necessary to determine the status of links in the multi-hop network. Some normalized measure of signal quality or S/N ratio of received packets must be reported on a per packet basis to some agent of the routing implementation. Management packets should be made available to some agent of the routing implementation so they can be used to inform the routing of status of individual neighboring stations." "Feedback from the PHY: A normalized measure of the number of corrected bit errors on a received perpacket should be made available to some agent of the routing implementation. This can be used to predict degrading links in the network and proactively switch routes." The full presentation can be found at: http://www.ieee802.org/meeting/meeting_files/Ad%20Hoc%20And%208022.pdf So maybe IEEE instead of IETF is the right place to do this ... In any event, if 802.11 is going to work well for mesh networking, perhaps it also calls for better coordination/interaction between the two groups. -----Original Message----- From: Joe Macker [mailto:macker@itd.nrl.navy.mil] Sent: Tuesday, March 25, 2003 7:31 AM To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta Kumar Hazra; Leping.Huang@nokia.com Cc: manet@ietf.org Subject: RE: [manet] IP-802.11 interface At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: >Hi, > >I am also interest in this issue too. I have actually tried to query the mailing list on the similar matter, but failed to get a response. Maybe it's out of the scope of MANET. 8-) Its not that its out of scope, but that there has not been a standard interface mechanisms to work with. We have discussed this quite a bit when the WG began. However, that doesn't one can't do something. The MAC ACK monitoring approach has some drawbacks (unicast only and congestion problems) and shouldn't be seen as the best approach, even though that is typically what is simulated. More precise link quality (filtered S/N-based) or simple link up/down would be useful if available.. In most specs the protocols are designed to work in the absence of such mechanisms, but most have wording to say take advantage of such an interface if available. >> Some of the manet routing protocols (e.g., AODV abd DSR) have the >> option of using MAC layer messages to realize link failures. > >MANET protocol (layer) requires triggers (link-up, link-down, etc) from the mobile node (itself), >I am not sure it TrigTrans can apply here (triggers sent by other entities). > >The timing and the reliability of the triggers are important too. Yes, these are important issues. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 20:21:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13889 for ; Tue, 25 Mar 2003 20:21:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q1gVl03503 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 20:42:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q1gVO03500 for ; Tue, 25 Mar 2003 20:42:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13886 for ; Tue, 25 Mar 2003 20:21:26 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q1TDO02181; Tue, 25 Mar 2003 20:29:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q1N6O01975 for ; Tue, 25 Mar 2003 20:23:07 -0500 Received: from mail.cs.utexas.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13406 for ; Tue, 25 Mar 2003 20:02:02 -0500 (EST) Received: from x20.cs.utexas.edu (horatio-209.cs.utexas.edu [128.83.158.209]) (authenticated bits=0) by mail.cs.utexas.edu (8.12.8/8.12.8) with ESMTP id h2Q14LBE007514 for ; Tue, 25 Mar 2003 19:04:23 -0600 (CST) Message-Id: <5.1.0.14.2.20030325171755.00ab73a0@mailbox.cs.utexas.edu> X-Sender: ygz@mailbox.cs.utexas.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 25 Mar 2003 19:07:20 -0600 To: manet@ietf.org From: Yongguang Zhang In-Reply-To: <20030325201900.9128.39639.Mailman@www1.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [manet] OS support for ad-hoc routing Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , I'd like to start a new topic, on OS support for ad-hoc routing. We have seen lots of activity regarding implementation of various routing protocols in general-purpose OS like Linux. Various system issues regarding these implementations do not appear to have been settled yet. Often operating-system kernel modifications are required, or implementations are not as clean and efficient as one would wish. Our investigations into these system issues has led to the development of an API which could facilitate the implementation of ad hoc routing protocols. We also provide a user-space implementation of this API in Linux, called the Ad hoc Support Library (ASL), and fresh implementation of AODV and DSR to attest this API. In the future, an ad-hoc routing API could possible be incorporated in all OS kernels, easing the deployment of any ad-hoc routing protocol. But now, this API probably needs extensions and refinements. We hope the MANET list can provide a good forum for this. For further details please refer to our recent publication: Vikas Kawadia, Yongguang Zhang, and Binita Gupta, "System Services for Implementing Ad-Hoc Routing: Architecture, Implementation and Experiences", MobiSys 2003. This paper and source code is at http://aslib.sourceforge.net . Yongguang Zhang _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Tue Mar 25 21:23:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15270 for ; Tue, 25 Mar 2003 21:23:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q2hYw07255 for manet-archive@odin.ietf.org; Tue, 25 Mar 2003 21:43:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q2hYO07252 for ; Tue, 25 Mar 2003 21:43:34 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15258 for ; Tue, 25 Mar 2003 21:22:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q2WpO06084; Tue, 25 Mar 2003 21:32:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q2QSO05845 for ; Tue, 25 Mar 2003 21:26:28 -0500 Received: from kiwi.cs.ucla.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14961 for ; Tue, 25 Mar 2003 21:05:24 -0500 (EST) Received: from cs.ucla.edu ([131.179.120.120]) by kiwi.cs.ucla.edu (8.11.6+Sun/8.11.6/UCLACS-5.2) with ESMTP id h2Q27e308970; Tue, 25 Mar 2003 18:07:40 -0800 (PST) Message-ID: <3E810B70.8040906@cs.ucla.edu> Date: Tue, 25 Mar 2003 18:07:44 -0800 From: Mineo Takai 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: "Manfredi, Albert E" CC: girish@cis.udel.edu, manet@ietf.org Subject: Re: [manet] 802.11a and 802.11b 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 Bert, IEEE 802.11b (High Rate DSSS) only extends the DSSS part of the (legacy) IEEE 802.11 standard. It considers interoperability with the IEEE 802.11 FHSS, but it never defines an extension to FHSS. Mineo PS We can probably take this discussion offline from now on because I don't see much relevance to this mailing list.. Manfredi, Albert E wrote: >>Briefly, 802.11b is in the 2.6 GHz band, uses direct sequence >>spread spectrum, very similar to CDMA cell phones, actually >>very similar to 3G cellular. > > > Ooops. Forgot that frequency hopping spread spectrum is a legal option for IEEE 802.11b. > > Bert > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 26 01:29:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19603 for ; Wed, 26 Mar 2003 01:29:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q6oMF21591 for manet-archive@odin.ietf.org; Wed, 26 Mar 2003 01:50:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q6oLO21588 for ; Wed, 26 Mar 2003 01:50:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19564 for ; Wed, 26 Mar 2003 01:29:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q6bOO20755; Wed, 26 Mar 2003 01:37:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q6S2O19788 for ; Wed, 26 Mar 2003 01:28:02 -0500 Received: from mgw-x1.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19116 for ; Wed, 26 Mar 2003 01:06:51 -0500 (EST) From: Leping.Huang@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h2Q67gU19835 for ; Wed, 26 Mar 2003 08:07:42 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Mar 2003 08:09:10 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 08:09:10 +0200 Received: from toebe001.NOE.Nokia.com ([172.24.109.35]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 26 Mar 2003 08:09:10 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [manet] IP-802.11 interface Date: Wed, 26 Mar 2003 15:09:03 +0900 Message-ID: Thread-Topic: [manet] IP-802.11 interface Thread-Index: AcLzImWu0IXXAsi4SfSHd7QaAQXi+QAOnajA To: , Cc: X-OriginalArrivalTime: 26 Mar 2003 06:09:10.0457 (UTC) FILETIME=[3791C290:01C2F35E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2Q6S2O19789 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, AA: >Gupta and Kumar's work comes to mind, among others. Again, >I was wondering if you had some experimental results regarding this. It is quite important to have experimental experience before defining such IP-802.11 interface. Can you tell me the name/URL of some document/paper you know about such IP-802.11 interface work? such as "Gupta and Kumar's work":) Yours Leping ----- Original Message ----- From: "Yang, Lily L" To: "'Joe Macker'" ; "Paul Tan Hock Lai" ; ; "Sukanta Kumar Hazra" ; Cc: Sent: Tuesday, March 25, 2003 1:25 PM Subject: RE: [manet] IP-802.11 interface > > In the recent IEEE Plenary meeting, Mesh Network presented a proposal to > extend 802.11 to better support mesh networking. One of the recommendations > is to extend the existing 802.11 standard MAC to allow information pertinent > to ad hoc networking to be passed across the network efficiently. I quote a > few paragraphs relevant to the discussion here -- > "Feedback from MAC/LLC to Routing implementation: > Immediate feedback of the TX and Rx status of packets received is critical > in > developing a reliable ad-hoc routing network. This status data is typically > available in some form from the MAC layer implementations of 802.11 > hardware, > but is seldom available outside of the scope of the link layer. In Layer 2 > routing > implementations based in or immediately above the link layer this > information > can be passed directly. In layer 3 implementations the cost of reporting > per-packet > information up to the network layer of a protocol stack may be > computationally or > architecturally prohibitive. In that case a cumulative derivative value can > be > computed in a small module collocated near the MAC. This value can then be > reported to the routing layer on a less frequent per-destination basis. Most > current > driver/stack combinations do not pass this information up in the stack. > Mac layer acknowledgements for transmitted directed packets must be reported > to > some agent of the routing implementations. This is necessary to determine > the > status of links in the multi-hop network. > Some normalized measure of signal quality or S/N ratio of received packets > must > be reported on a per packet basis to some agent of the routing > implementation. > Management packets should be made available to some agent of the routing > implementation so they can be used to inform the routing of status of > individual > neighboring stations." > "Feedback from the PHY: > A normalized measure of the number of corrected bit errors on a received > perpacket > should be made available to some agent of the routing implementation. > This can be used to predict degrading links in the network and proactively > switch > routes." > > The full presentation can be found at: > http://www.ieee802.org/meeting/meeting_files/Ad%20Hoc%20And%208022.pdf > > So maybe IEEE instead of IETF is the right place to do this ... > In any event, if 802.11 is going to work well for mesh networking, perhaps > it also calls for better coordination/interaction between the two groups. > > -----Original Message----- > From: Joe Macker [mailto:macker@itd.nrl.navy.mil] > Sent: Tuesday, March 25, 2003 7:31 AM > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta Kumar Hazra; > Leping.Huang@nokia.com > Cc: manet@ietf.org > Subject: RE: [manet] IP-802.11 interface > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > >Hi, > > > >I am also interest in this issue too. I have actually tried to query the > mailing list on the similar matter, but failed to get a response. Maybe it's > out of the scope of MANET. 8-) > > Its not that its out of scope, but that there has not been a standard > interface mechanisms to work with. We have discussed this quite a bit when > the WG began. However, that doesn't one can't do something. The MAC ACK > monitoring approach has some drawbacks (unicast only and congestion > problems) and shouldn't be seen as the best approach, even though that is > typically what is simulated. > > More precise link quality (filtered S/N-based) or simple link up/down would > be useful if available.. > > In most specs the protocols are designed to work in the absence of such > mechanisms, but most have wording to say take advantage of such an interface > if available. > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have the > >> option of using MAC layer messages to realize link failures. > > > >MANET protocol (layer) requires triggers (link-up, link-down, etc) from the > mobile node (itself), > >I am not sure it TrigTrans can apply here (triggers sent by other > entities). > > > >The timing and the reliability of the triggers are important too. > > Yes, these are important issues. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 26 02:42:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16956 for ; Wed, 26 Mar 2003 02:42:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q839l04353 for manet-archive@odin.ietf.org; Wed, 26 Mar 2003 03:03:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q839O04350 for ; Wed, 26 Mar 2003 03:03:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16941 for ; Wed, 26 Mar 2003 02:41:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q7ntO03657; Wed, 26 Mar 2003 02:49:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q7gjO03388 for ; Wed, 26 Mar 2003 02:42:45 -0500 Received: from gandalf.icr.a-star.edu.sg (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07391 for ; Wed, 26 Mar 2003 02:21:16 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2Q7O3NH026179 for ; Wed, 26 Mar 2003 15:24:03 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Wed, 26 Mar 2003 15:16:01 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 80D383054C; Wed, 26 Mar 2003 15:23:12 +0800 (SGT) Date: Wed, 26 Mar 2003 15:23:12 +0800 From: Sukanta Kumar Hazra To: manet@ietf.org Subject: Re: [manet] IP-802.11 interface Message-ID: <20030326072312.GA20022@localhost> Mail-Followup-To: manet@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , ----- Original Message ----- From: "Leping.Huang@nokia.com" Date: Wed, 26 Mar, 2003 14:09 SGT Subject: RE: [manet] IP-802.11 interface > Hi, AA: > > >Gupta and Kumar's work comes to mind, among others. Again, > >I was wondering if you had some experimental results regarding this. > It is quite important to have experimental experience before defining such IP-802.11 interface. > Can you tell me the name/URL of some document/paper you know about such IP-802.11 interface work? > such as "Gupta and Kumar's work":) Gupta kumar (Capcity of Wirless Networks) (http://citeseer.nj.nec.com/gupta99capacity.html) the following might be of interest as well - Capacity of ad hoc wireless networks (http://www.pdos.lcs.mit.edu/papers/grid:mobicom01/paper.pdf) - Mobility increases the capacity of ad hoc networks (http://www.ece.utexas.edu/~jandrews/ee381k/EE381KTA/tse_mobility.pdf) They do not deal with IP-802.11 interface, but are followup to gupta and kumar's work. - Sukanta > > Yours > Leping > > > > > ----- Original Message ----- > From: "Yang, Lily L" > To: "'Joe Macker'" ; "Paul Tan Hock Lai" > ; ; "Sukanta Kumar > Hazra" ; > Cc: > Sent: Tuesday, March 25, 2003 1:25 PM > Subject: RE: [manet] IP-802.11 interface > > > > > > In the recent IEEE Plenary meeting, Mesh Network presented a proposal to > > extend 802.11 to better support mesh networking. One of the > recommendations > > is to extend the existing 802.11 standard MAC to allow information > pertinent > > to ad hoc networking to be passed across the network efficiently. I quote > a > > few paragraphs relevant to the discussion here -- > > "Feedback from MAC/LLC to Routing implementation: > > Immediate feedback of the TX and Rx status of packets received is critical > > in > > developing a reliable ad-hoc routing network. This status data is > typically > > available in some form from the MAC layer implementations of 802.11 > > hardware, > > but is seldom available outside of the scope of the link layer. In Layer 2 > > routing > > implementations based in or immediately above the link layer this > > information > > can be passed directly. In layer 3 implementations the cost of reporting > > per-packet > > information up to the network layer of a protocol stack may be > > computationally or > > architecturally prohibitive. In that case a cumulative derivative value > can > > be > > computed in a small module collocated near the MAC. This value can then be > > reported to the routing layer on a less frequent per-destination basis. > Most > > current > > driver/stack combinations do not pass this information up in the stack. > > Mac layer acknowledgements for transmitted directed packets must be > reported > > to > > some agent of the routing implementations. This is necessary to determine > > the > > status of links in the multi-hop network. > > Some normalized measure of signal quality or S/N ratio of received packets > > must > > be reported on a per packet basis to some agent of the routing > > implementation. > > Management packets should be made available to some agent of the routing > > implementation so they can be used to inform the routing of status of > > individual > > neighboring stations." > > "Feedback from the PHY: > > A normalized measure of the number of corrected bit errors on a received > > perpacket > > should be made available to some agent of the routing implementation. > > This can be used to predict degrading links in the network and proactively > > switch > > routes." > > > > The full presentation can be found at: > > http://www.ieee802.org/meeting/meeting_files/Ad%20Hoc%20And%208022.pdf > > > > So maybe IEEE instead of IETF is the right place to do this ... > > In any event, if 802.11 is going to work well for mesh networking, perhaps > > it also calls for better coordination/interaction between the two groups. > > > > -----Original Message----- > > From: Joe Macker [mailto:macker@itd.nrl.navy.mil] > > Sent: Tuesday, March 25, 2003 7:31 AM > > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta Kumar Hazra; > > Leping.Huang@nokia.com > > Cc: manet@ietf.org > > Subject: RE: [manet] IP-802.11 interface > > > > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > > >Hi, > > > > > >I am also interest in this issue too. I have actually tried to query the > > mailing list on the similar matter, but failed to get a response. Maybe > it's > > out of the scope of MANET. 8-) > > > > Its not that its out of scope, but that there has not been a standard > > interface mechanisms to work with. We have discussed this quite a bit > when > > the WG began. However, that doesn't one can't do something. The MAC ACK > > monitoring approach has some drawbacks (unicast only and congestion > > problems) and shouldn't be seen as the best approach, even though that is > > typically what is simulated. > > > > More precise link quality (filtered S/N-based) or simple link up/down > would > > be useful if available.. > > > > In most specs the protocols are designed to work in the absence of such > > mechanisms, but most have wording to say take advantage of such an > interface > > if available. > > > > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have the > > >> option of using MAC layer messages to realize link failures. > > > > > >MANET protocol (layer) requires triggers (link-up, link-down, etc) from > the > > mobile node (itself), > > >I am not sure it TrigTrans can apply here (triggers sent by other > > entities). > > > > > >The timing and the reliability of the triggers are important too. > > > > Yes, these are important issues. > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet -- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 26 04:05: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 EAA18671 for ; Wed, 26 Mar 2003 04:05:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q9QT710858 for manet-archive@odin.ietf.org; Wed, 26 Mar 2003 04:26:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q9QTO10855 for ; Wed, 26 Mar 2003 04:26:29 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18659 for ; Wed, 26 Mar 2003 04:05:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q9CCO09983; Wed, 26 Mar 2003 04:12:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q94GO08977 for ; Wed, 26 Mar 2003 04:04:16 -0500 Received: from gumby.usu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18158 for ; Wed, 26 Mar 2003 03:43:02 -0500 (EST) Received: from webmail.usu.edu ("port 3603"@webster.usu.edu [129.123.1.90]) by cc.usu.edu (PMDF V5.2-32 #39089) with ESMTP id <01KTYOG7H61Y8WW438@cc.usu.edu> for manet@ietf.org; Wed, 26 Mar 2003 01:45:21 MDT Date: Wed, 26 Mar 2003 01:45:21 -0700 From: Sumeeth Nagaraj Subject: Re: [manet] IP-802.11 interface To: "lily.l.yang@intel.com" Cc: "manet@ietf.org" Message-id: <3E8164E8@webmail.usu.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: snagaraj X-EXP32-SerialNo: 00002751 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 Leping, The upper bound derived for ad hoc networks by Gupta and Kumar is for network with static or stationary nodes- More information at http://decision.csl.uiuc.edu/~piyush/pub_list.html and also some simulations are done with the IEEE 802.11 MAC protocols and you can find more information at http://www.pdos.lcs.mit.edu/papers/grid:mobicom01/ Hope this helps Best Regards, Sumeeth ----- Original Message ----- From: To: ; Cc: Sent: Tuesday, March 25, 2003 11:09 PM Subject: RE: [manet] IP-802.11 interface > Hi, AA: > > >Gupta and Kumar's work comes to mind, among others. Again, > >I was wondering if you had some experimental results regarding this. > It is quite important to have experimental experience before defining such IP-802.11 interface. > Can you tell me the name/URL of some document/paper you know about such IP-802.11 interface work? > such as "Gupta and Kumar's work":) > > Yours > Leping > > > > > ----- Original Message ----- > From: "Yang, Lily L" > To: "'Joe Macker'" ; "Paul Tan Hock Lai" > ; ; "Sukanta Kumar > Hazra" ; > Cc: > Sent: Tuesday, March 25, 2003 1:25 PM > Subject: RE: [manet] IP-802.11 interface > > > > > > In the recent IEEE Plenary meeting, Mesh Network presented a proposal to > > extend 802.11 to better support mesh networking. One of the > recommendations > > is to extend the existing 802.11 standard MAC to allow information > pertinent > > to ad hoc networking to be passed across the network efficiently. I quote > a > > few paragraphs relevant to the discussion here -- > > "Feedback from MAC/LLC to Routing implementation: > > Immediate feedback of the TX and Rx status of packets received is critical > > in > > developing a reliable ad-hoc routing network. This status data is > typically > > available in some form from the MAC layer implementations of 802.11 > > hardware, > > but is seldom available outside of the scope of the link layer. In Layer 2 > > routing > > implementations based in or immediately above the link layer this > > information > > can be passed directly. In layer 3 implementations the cost of reporting > > per-packet > > information up to the network layer of a protocol stack may be > > computationally or > > architecturally prohibitive. In that case a cumulative derivative value > can > > be > > computed in a small module collocated near the MAC. This value can then be > > reported to the routing layer on a less frequent per-destination basis. > Most > > current > > driver/stack combinations do not pass this information up in the stack. > > Mac layer acknowledgements for transmitted directed packets must be > reported > > to > > some agent of the routing implementations. This is necessary to determine > > the > > status of links in the multi-hop network. > > Some normalized measure of signal quality or S/N ratio of received packets > > must > > be reported on a per packet basis to some agent of the routing > > implementation. > > Management packets should be made available to some agent of the routing > > implementation so they can be used to inform the routing of status of > > individual > > neighboring stations." > > "Feedback from the PHY: > > A normalized measure of the number of corrected bit errors on a received > > perpacket > > should be made available to some agent of the routing implementation. > > This can be used to predict degrading links in the network and proactively > > switch > > routes." > > > > The full presentation can be found at: > > http://www.ieee802.org/meeting/meeting_files/Ad%20Hoc%20And%208022.pdf > > > > So maybe IEEE instead of IETF is the right place to do this ... > > In any event, if 802.11 is going to work well for mesh networking, perhaps > > it also calls for better coordination/interaction between the two groups. > > > > -----Original Message----- > > From: Joe Macker [mailto:macker@itd.nrl.navy.mil] > > Sent: Tuesday, March 25, 2003 7:31 AM > > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta Kumar Hazra; > > Leping.Huang@nokia.com > > Cc: manet@ietf.org > > Subject: RE: [manet] IP-802.11 interface > > > > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > > >Hi, > > > > > >I am also interest in this issue too. I have actually tried to query the > > mailing list on the similar matter, but failed to get a response. Maybe > it's > > out of the scope of MANET. 8-) > > > > Its not that its out of scope, but that there has not been a standard > > interface mechanisms to work with. We have discussed this quite a bit > when > > the WG began. However, that doesn't one can't do something. The MAC ACK > > monitoring approach has some drawbacks (unicast only and congestion > > problems) and shouldn't be seen as the best approach, even though that is > > typically what is simulated. > > > > More precise link quality (filtered S/N-based) or simple link up/down > would > > be useful if available.. > > > > In most specs the protocols are designed to work in the absence of such > > mechanisms, but most have wording to say take advantage of such an > interface > > if available. > > > > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have the > > >> option of using MAC layer messages to realize link failures. > > > > > >MANET protocol (layer) requires triggers (link-up, link-down, etc) from > the > > mobile node (itself), > > >I am not sure it TrigTrans can apply here (triggers sent by other > > entities). > > > > > >The timing and the reliability of the triggers are important too. > > > > Yes, these are important issues. > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 26 04:14:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18877 for ; Wed, 26 Mar 2003 04:14:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2Q9Ymd11229 for manet-archive@odin.ietf.org; Wed, 26 Mar 2003 04:34:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q9YmO11226 for ; Wed, 26 Mar 2003 04:34:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18843 for ; Wed, 26 Mar 2003 04:13:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q9JMO10301; Wed, 26 Mar 2003 04:19:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2Q982O09874 for ; Wed, 26 Mar 2003 04:08:02 -0500 Received: from juke.msrit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18211 for ; Wed, 26 Mar 2003 03:46:47 -0500 (EST) Received: (qmail 4746 invoked by uid 510); 26 Mar 2003 08:50:46 -0000 Message-ID: <20030326085046.4745.qmail@juke.msrit.edu> From: "Shekhar H M P" To: manet@ietf.org Date: Wed, 26 Mar 2003 08:50:46 GMT Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] QoS in MANETs Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, Currently we are working on QoS for MANETs...I have discussed with many Profs..about the experimentation aspect of QoS routing... and other QoS techniques and they said that the result of working with simulators is not quite okay in terms of accuracy...We have no testbed created in our lab... I want some advice related to experimentation aspects of QoS related issues in MANETs... QoS routing...QOS models.. etc.. if any good references too Regards, Shekhar H M P PhD Student, BITS, Pilani, INDIA Official: Faculty Department of Computer Science & Engineering M S Ramaiah Institute of Technology Bangalore - 560 054 Ph: 080-3600822 Ext. 313,322 Your's: #67, 8th 'D' Cross, Srinidhilayout, Vidyaranyapura, Bangalore - 97 Ph: 080-364 3166 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 26 06:19:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21161 for ; Wed, 26 Mar 2003 06:19:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QBeje20250 for manet-archive@odin.ietf.org; Wed, 26 Mar 2003 06:40:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QBejO20247 for ; Wed, 26 Mar 2003 06:40:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21145 for ; Wed, 26 Mar 2003 06:19:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QBVDO19027; Wed, 26 Mar 2003 06:31:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QBPoO18828 for ; Wed, 26 Mar 2003 06:25:50 -0500 Received: from concorde.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20887 for ; Wed, 26 Mar 2003 06:04:34 -0500 (EST) Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h2QB6Af06237; Wed, 26 Mar 2003 12:06:10 +0100 (MET) Message-ID: <003601c2f38b$eadc3920$1f175d80@inria.fr> From: "Philippe Jacquet" To: "Shekhar H M P" , Cc: References: <20030326085046.4745.qmail@juke.msrit.edu> Subject: Re: [manet] QoS in MANETs Date: Wed, 26 Mar 2003 12:36:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Shekhar, We are currently working on QoS management on MANET. It does not as easy as in the wired world where you can put weights and metrics on links and play Belman-Ford. In the wireless world the links interfer up to one or two hops (depending on the interference model). Therefore the search of the shortest path that doesn't kill the capacities of the neighboring links is no longer a simple Belman-Ford algorithm, but is an NP hard problem. We are trying some heuristics on link state protocols (e.g OSPF, OLSR). Philippe ----- Original Message ----- From: Shekhar H M P To: Sent: Wednesday, March 26, 2003 9:50 AM Subject: [manet] QoS in MANETs > Dear All, > > Currently we are working on QoS for MANETs...I have discussed with many > Profs..about the experimentation aspect of QoS routing... and other QoS > techniques and they said that the result of working with simulators is not > quite okay in terms of accuracy...We have no testbed created in our lab... > I want some advice related to experimentation aspects of QoS related issues > in MANETs... QoS routing...QOS models.. etc.. if any good references too > > Regards, > > Shekhar H M P > PhD Student, BITS, Pilani, INDIA > > Official: > > Faculty > Department of Computer Science & Engineering > M S Ramaiah Institute of Technology > Bangalore - 560 054 > Ph: 080-3600822 Ext. 313,322 > > Your's: > > #67, 8th 'D' Cross, > Srinidhilayout, > Vidyaranyapura, > Bangalore - 97 > Ph: 080-364 3166 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 26 07:40:35 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 HAA23895 for ; Wed, 26 Mar 2003 07:40:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QD1NS25268 for manet-archive@odin.ietf.org; Wed, 26 Mar 2003 08:01:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QD1NO25265 for ; Wed, 26 Mar 2003 08:01:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23890 for ; Wed, 26 Mar 2003 07:40:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCo6O24490; Wed, 26 Mar 2003 07:50:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QCiOO24299 for ; Wed, 26 Mar 2003 07:44:24 -0500 Received: from zaz.kom.auc.dk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22796 for ; Wed, 26 Mar 2003 07:23:04 -0500 (EST) Received: from petarp-w2k.kom.auc.dk ([192.168.110.200] helo=PETARPW2K) by zaz.kom.auc.dk with smtp (Exim 2.05 #3) id 18y9y3-0003dj-00; Wed, 26 Mar 2003 13:25:19 +0100 Message-ID: <010601c2f392$c4067ed0$c86ea8c0@kom.auc.dk> From: "Petar Popovski" To: , Cc: "'Yang, Lily L'" References: <001301c2f329$77a8e000$0300a8c0@amd2100> Subject: Re: [manet] IP-802.11 interface Date: Wed, 26 Mar 2003 13:25:19 +0100 Organization: Center for PersonKommunikation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I would also like to share some thoughts regarding the interlayer interactions. To my understanding, the traditional layering in the communication protocols reflects the way in which the communication system is usually decomposed. For example, there is a procedure for reliable transmission over a link, while the routing concatenates several such link procedures in order to produce a full route, but without intervention into the mechanisms employed by the link procedure itself. This works fine as long as the link procedures within a route are mutually independent. But, when they are not, as it is a case in the wireless ad hoc networks, some "other" system decomposition is needed and this decomposition depends on the goal we want to achieve. The layering decomposition is suitable for the case when the communication is across heterogenous link layers. However, in ad hoc networks the usual target is to optimize the power consumption, while the network is (usually) homogeneous. That is, in ad hoc nets where all devices are connected through a single radio interface, the system can be observed as homogenous up to and including the routing layer. Hence, a node uses a communication block that spans routing, link and physical layer in order to establish multihop connection. Now my question is: Is there any work at present that makes a general discussion how this communication block should be designed (decomposed into subblocks), depending on goal to be achieved (e.g. power-efficient communication)? Best regards, Petar Popovski ----- Original Message ----- From: "Herbert Rubens" To: Cc: "'Yang, Lily L'" Sent: Wednesday, March 26, 2003 12:51 AM Subject: RE: [manet] IP-802.11 interface > I absolutely agree that the availability of MAC and physical layer > signal quality information is essential in order to make efficient > routing decisions. Aside from link failure detection, this information > can be used to increase route stability and throughput. This is briefly > mentioned in the presentation you referred to. We have been actively > researching how this information can be used to enhance routing. A > technical report is available which examines this in detail. > > http://www.cnds.jhu.edu/research/networks/archipelago/publications/MTM-T > echnicalReport2.pdf > > > > > -----Original Message----- > From: manet-admin@ietf.org [mailto:manet-admin@ietf.org] On Behalf Of > Yang, Lily L > Sent: Tuesday, March 25, 2003 1:25 PM > To: 'Joe Macker'; Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta > Kumar Hazra; Leping.Huang@nokia.com > Cc: manet@ietf.org > Subject: RE: [manet] IP-802.11 interface > > > In the recent IEEE Plenary meeting, Mesh Network presented a proposal to > extend 802.11 to better support mesh networking. One of the > recommendations > is to extend the existing 802.11 standard MAC to allow information > pertinent > to ad hoc networking to be passed across the network efficiently. I > quote a > few paragraphs relevant to the discussion here -- > "Feedback from MAC/LLC to Routing implementation: > Immediate feedback of the TX and Rx status of packets received is > critical > in > developing a reliable ad-hoc routing network. This status data is > typically > available in some form from the MAC layer implementations of 802.11 > hardware, > but is seldom available outside of the scope of the link layer. In Layer > 2 > routing > implementations based in or immediately above the link layer this > information > can be passed directly. In layer 3 implementations the cost of reporting > per-packet > information up to the network layer of a protocol stack may be > computationally or > architecturally prohibitive. In that case a cumulative derivative value > can > be > computed in a small module collocated near the MAC. This value can then > be > reported to the routing layer on a less frequent per-destination basis. > Most > current > driver/stack combinations do not pass this information up in the stack. > Mac layer acknowledgements for transmitted directed packets must be > reported > to > some agent of the routing implementations. This is necessary to > determine > the > status of links in the multi-hop network. > Some normalized measure of signal quality or S/N ratio of received > packets > must > be reported on a per packet basis to some agent of the routing > implementation. > Management packets should be made available to some agent of the routing > implementation so they can be used to inform the routing of status of > individual > neighboring stations." > "Feedback from the PHY: > A normalized measure of the number of corrected bit errors on a received > perpacket > should be made available to some agent of the routing implementation. > This can be used to predict degrading links in the network and > proactively > switch > routes." > > The full presentation can be found at: > http://www.ieee802.org/meeting/meeting_files/Ad%20Hoc%20And%208022.pdf > > So maybe IEEE instead of IETF is the right place to do this ... > In any event, if 802.11 is going to work well for mesh networking, > perhaps > it also calls for better coordination/interaction between the two > groups. > > -----Original Message----- > From: Joe Macker [mailto:macker@itd.nrl.navy.mil] > Sent: Tuesday, March 25, 2003 7:31 AM > To: Paul Tan Hock Lai; perkins@cacs.louisiana.edu; Sukanta Kumar Hazra; > Leping.Huang@nokia.com > Cc: manet@ietf.org > Subject: RE: [manet] IP-802.11 interface > > > At 05:49 PM 3/25/2003 +0800, Paul Tan Hock Lai wrote: > >Hi, > > > >I am also interest in this issue too. I have actually tried to query > the > mailing list on the similar matter, but failed to get a response. Maybe > it's > out of the scope of MANET. 8-) > > Its not that its out of scope, but that there has not been a standard > interface mechanisms to work with. We have discussed this quite a bit > when > the WG began. However, that doesn't one can't do something. The MAC ACK > monitoring approach has some drawbacks (unicast only and congestion > problems) and shouldn't be seen as the best approach, even though that > is > typically what is simulated. > > More precise link quality (filtered S/N-based) or simple link up/down > would > be useful if available.. > > In most specs the protocols are designed to work in the absence of such > mechanisms, but most have wording to say take advantage of such an > interface > if available. > > > >> Some of the manet routing protocols (e.g., AODV abd DSR) have the > >> option of using MAC layer messages to realize link failures. > > > >MANET protocol (layer) requires triggers (link-up, link-down, etc) from > the > mobile node (itself), > >I am not sure it TrigTrans can apply here (triggers sent by other > entities). > > > >The timing and the reliability of the triggers are important too. > > Yes, these are important issues. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Wed Mar 26 16:31:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15920 for ; Wed, 26 Mar 2003 16:31:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2QLqIx04794 for manet-archive@odin.ietf.org; Wed, 26 Mar 2003 16:52:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLqIO04791 for ; Wed, 26 Mar 2003 16:52:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15890 for ; Wed, 26 Mar 2003 16:30:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLghO04183; Wed, 26 Mar 2003 16:42:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2QLaiO03156 for ; Wed, 26 Mar 2003 16:36:44 -0500 Received: from mail.informatik.uni-ulm.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15130 for ; Wed, 26 Mar 2003 16:15:16 -0500 (EST) Received: from taipan.informatik.uni-ulm.de ([134.60.72.42] helo=informatik.uni-ulm.de) by mail.informatik.uni-ulm.de with esmtp (Exim 3.36 #1) id 18yIHA-0004ck-00 for manet@ietf.org; Wed, 26 Mar 2003 22:17:36 +0100 Message-ID: <3E8218DA.1040607@informatik.uni-ulm.de> Date: Wed, 26 Mar 2003 22:17:14 +0100 From: Liu Changling User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en, zh-CN MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] about the core extraction algorithm in CEDAR Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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, Friends! I want to know how the core nodes extraction algorithm in CEDAR been implemenated. Any advice is appreciated. thanks, Changling,Liu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 04:59:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21537 for ; Thu, 27 Mar 2003 04:59:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RAKI803249 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 05:20:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RAKIO03246 for ; Thu, 27 Mar 2003 05:20:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21516 for ; Thu, 27 Mar 2003 04:58:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RA6qO01875; Thu, 27 Mar 2003 05:06:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2R9vbO01472 for ; Thu, 27 Mar 2003 04:57:37 -0500 Received: from marfik.upv.es (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21041 for ; Thu, 27 Mar 2003 04:35:51 -0500 (EST) Received: from pop.upv.es (maia.cc.upv.es [158.42.4.11]) by marfik.upv.es (8.11.6/8.11.6) with ESMTP id h2R9c8h27802 for ; Thu, 27 Mar 2003 10:38:08 +0100 Received: from smtp2.upv.es (smtp02.cc.upv.es [158.42.249.52]) by pop.upv.es (8.11.3/8.11.3) with ESMTP id h2R9cAO15174 for ; Thu, 27 Mar 2003 10:38:10 +0100 (MET) Received: from nao.disca.upv.es (nao.disca.upv.es [158.42.53.70]) by smtp2.upv.es (8.11.4/8.11.4) with ESMTP id h2R9c7X23166 for ; Thu, 27 Mar 2003 10:38:07 +0100 Received: by nao.disca.upv.es (Postfix on SuSE eMail Server 2.0, from userid 30) id E181A1FE8B; Thu, 27 Mar 2003 10:37:37 +0100 (CET) To: manet@ietf.org Message-ID: <1048757857.3e82c661dbf9f@nao.disca.upv.es> Date: Thu, 27 Mar 2003 10:37:37 +0100 (CET) From: Carlos Calafate MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 158.42.61.34 Content-Transfer-Encoding: 8bit Subject: [manet] Multipath routing Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Can anyone tell me where I can find implementations of multipath routing protocols for NS-2? Regards, _________________________________________________ Carlos Miguel Tavares de Araújo Cesariny Calafate Universidad Politécnica de Valencia e-mail: calafate@disca.upv.es http://reptar.grc.upv.es/~calafate/ _________________________________________________ \"In an open world without walls and fences who needs Windows and Gates?\" _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 11:33:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06241 for ; Thu, 27 Mar 2003 11:33:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RGsak30877 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 11:54:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGsZO30874 for ; Thu, 27 Mar 2003 11:54:35 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06216 for ; Thu, 27 Mar 2003 11:32:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGdpO29953; Thu, 27 Mar 2003 11:39:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RGNEO28370 for ; Thu, 27 Mar 2003 11:23:14 -0500 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04868 for ; Thu, 27 Mar 2003 11:01:23 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h2RG3KjZ009724; Thu, 27 Mar 2003 11:03:20 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2RG3FWe011589; Thu, 27 Mar 2003 11:03:15 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003032711031529984 ; Thu, 27 Mar 2003 11:03:15 -0500 Message-Id: <5.1.1.5.2.20030327094505.016d4278@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 27 Mar 2003 11:03:06 -0500 To: Carlos Calafate , manet@ietf.org From: Joe Macker Subject: Re: [manet] Multipath routing In-Reply-To: <1048757857.3e82c661dbf9f@nao.disca.upv.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , At 10:37 AM 3/27/2003 +0100, Carlos Calafate wrote: >Hi, > >Can anyone tell me where I can find implementations of multipath routing >protocols for NS-2? We have an NRL version of an OLSR derivative (CVS repository) with lots of experimental options at http://pf.itd.nrl.navy.mil. If compiled for ns2 this code has disjoint path routing/load balancing and other purely EXPERIMENTAL capabilities. While this code also compiles for Linux, the multipath routing option will only work within the simulator code. -joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 12:41:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09485 for ; Thu, 27 Mar 2003 12:41:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RI2kj05402 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 13:02:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RI2kO05399 for ; Thu, 27 Mar 2003 13:02:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09468 for ; Thu, 27 Mar 2003 12:40:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RHnwO04504; Thu, 27 Mar 2003 12:49:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RHiFO04295 for ; Thu, 27 Mar 2003 12:44:15 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08668 for ; Thu, 27 Mar 2003 12:22:22 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id JAA07936; Thu, 27 Mar 2003 09:16:54 -0800 (PST) Message-Id: <200303271716.JAA07936@pit.erg.sri.com> To: Carlos Calafate , manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Multipath routing In-reply-to: Your message of "Thu, 27 Mar 2003 11:03:06 EST." <5.1.1.5.2.20030327094505.016d4278@pop.itd.nrl.navy.mil> Date: Thu, 27 Mar 2003 09:16:54 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , One caution in using multipath routing with OLSR. If you want two node-disjoint paths, for example, then the MPR Redundancy parameter needs to be 2, since using non-redundant MPRs does not ensure that disjoint paths will be found even if they exist. >From the OLSR draft: "Redundancy of the MPR set affects the overhead through affecting the amount of links being advertised, the amount of nodes advertising links to the MPR selector and the efficiency of the MPR flooding mechanism." The result is that increasing the MPR redundancy to 2 will roughly increase the TC overhead by a factor of 4. This is unnecessary - a factor of 2 is quite possible. Some may argue that the factor of 4 buys more robustness, but I have not seen any simulation results showing this, and I doubt that it improves robustness sufficiently to justify the large overhead. Richard > At 10:37 AM 3/27/2003 +0100, Carlos Calafate wrote: > >Hi, > > > >Can anyone tell me where I can find implementations of multipath routing > >protocols for NS-2? > > We have an NRL version of an OLSR derivative (CVS repository) with lots of ex perimental options at http://pf.itd.nrl.navy.mil. If compiled for ns2 this cod e has disjoint path routing/load balancing and other purely EXPERIMENTAL capabi lities. While this code also compiles for Linux, the multipath routing option w ill only work within the simulator code. > > -joe > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 13:41:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11776 for ; Thu, 27 Mar 2003 13:41:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RJ2XC09839 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 14:02:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RJ2XO09836 for ; Thu, 27 Mar 2003 14:02:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11757 for ; Thu, 27 Mar 2003 13:40:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RIlTO08919; Thu, 27 Mar 2003 13:47:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RIeBO08592 for ; Thu, 27 Mar 2003 13:40:11 -0500 Received: from concorde.inria.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10814 for ; Thu, 27 Mar 2003 13:18:17 -0500 (EST) Received: from zephyrin (byzantium.inria.fr [128.93.17.6]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h2RIKb502549 for ; Thu, 27 Mar 2003 19:20:38 +0100 (MET) Message-ID: <048c01c2f491$a65ad0c0$1f175d80@inria.fr> From: "Philippe Jacquet" To: References: <200303271716.JAA07936@pit.erg.sri.com> Subject: Re: [manet] Multipath routing Date: Thu, 27 Mar 2003 19:49:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I think multipath routing is a priori a problem of routing table: one must have two entries in the routing table for the same destination. This is not easy to handle in hop by hop routing. Maybe source routing option in IP stack would help. In order to have load balancing the routes should probably be two hops or three hops away in order to avoid co-interference. Regarding OLSR I don't think MPR coverage is an issue here since MPR coverage addresses only flooding reliability. In OLSR one can advertize more links than the MPR links. In fact nodes can advertize their whole link set and simulations don't show tremendous more overhead (TC still benefit from MPR forwarding). With knowledge of the whole link state in the network, one can compute all possible redundant routes if one wishes so. Philippe ----- Original Message ----- From: To: Carlos Calafate ; Sent: Thursday, March 27, 2003 6:16 PM Subject: Re: [manet] Multipath routing > > One caution in using multipath routing with OLSR. > If you want two node-disjoint paths, for example, > then the MPR Redundancy parameter needs to be 2, > since using non-redundant MPRs does not ensure that > disjoint paths will be found even if they exist. > > >From the OLSR draft: "Redundancy of the MPR set affects the overhead > through affecting the amount of links being advertised, the amount of > nodes advertising links to the MPR selector and the efficiency of the > MPR flooding mechanism." > > The result is that increasing the MPR redundancy to 2 will > roughly increase the TC overhead by a factor of 4. > This is unnecessary - a factor of 2 is quite possible. > > Some may argue that the factor of 4 buys more robustness, > but I have not seen any simulation results showing this, > and I doubt that it improves robustness sufficiently to > justify the large overhead. > > Richard > > > > At 10:37 AM 3/27/2003 +0100, Carlos Calafate wrote: > > >Hi, > > > > > >Can anyone tell me where I can find implementations of multipath routing > > >protocols for NS-2? > > > > We have an NRL version of an OLSR derivative (CVS repository) with lots of ex > perimental options at http://pf.itd.nrl.navy.mil. If compiled for ns2 this cod > e has disjoint path routing/load balancing and other purely EXPERIMENTAL capabi > lities. While this code also compiles for Linux, the multipath routing option w > ill only work within the simulator code. > > > > -joe > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 15:20:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17359 for ; Thu, 27 Mar 2003 15:20:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RKfpF18492 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 15:41:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RKfpO18489 for ; Thu, 27 Mar 2003 15:41:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17266 for ; Thu, 27 Mar 2003 15:19:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RKQnO16668; Thu, 27 Mar 2003 15:26:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RKHiO16192 for ; Thu, 27 Mar 2003 15:17:44 -0500 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15643 for ; Thu, 27 Mar 2003 14:55:47 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h2RJvojZ023424; Thu, 27 Mar 2003 14:57:50 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2RJvjWe014350; Thu, 27 Mar 2003 14:57:45 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003032714574531207 ; Thu, 27 Mar 2003 14:57:45 -0500 Message-Id: <5.1.1.5.2.20030327135933.02eb0788@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 27 Mar 2003 14:57:35 -0500 To: ogier@erg.sri.com, Carlos Calafate , manet@ietf.org From: Joe Macker Subject: Re: [manet] Multipath routing In-Reply-To: <200303271716.JAA07936@pit.erg.sri.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , At 09:16 AM 3/27/2003 -0800, ogier@erg.sri.com wrote: >One caution in using multipath routing with OLSR. >If you want two node-disjoint paths, for example, >then the MPR Redundancy parameter needs to be 2, >since using non-redundant MPRs does not ensure that >disjoint paths will be found even if they exist. I should have added, this was ONLY done with a full link state advertisement option, but with minimal MPR control flooding. Many of these experimental features are also not related to the OLSR specification or the MPR robustness factor (it was just done to support more generic work by Justin Dean and myself). It borrows OLSR packet formats.. So MPR election has nothing to do with routing path selection,etc...in our non-spec case... Also, I should have mentioned the load balancing results using full link state we obtained under congestion tests showed improvements, but not significant (somewhat scenario dependent). We wouldn't recommend necessarily doing this function because the complexity did not seem to be worth it.. The full link state option, however, did improve route repair performance when a link layer detection mechanism was used..yes, there are more TCs generated and results are likely scenario dependent to some degree. Just answering the question if there was an implementation and I wouldn't want that to be misinterpreted as a general recommendation. >>From the OLSR draft: "Redundancy of the MPR set affects the overhead >through affecting the amount of links being advertised, the amount of >nodes advertising links to the MPR selector and the efficiency of the >MPR flooding mechanism." > >The result is that increasing the MPR redundancy to 2 will >roughly increase the TC overhead by a factor of 4. >This is unnecessary - a factor of 2 is quite possible. > >Some may argue that the factor of 4 buys more robustness, >but I have not seen any simulation results showing this, >and I doubt that it improves robustness sufficiently to >justify the large overhead. > >Richard > > >> At 10:37 AM 3/27/2003 +0100, Carlos Calafate wrote: >> >Hi, >> > >> >Can anyone tell me where I can find implementations of multipath routing >> >protocols for NS-2? >> >> We have an NRL version of an OLSR derivative (CVS repository) with lots of ex >perimental options at http://pf.itd.nrl.navy.mil. If compiled for ns2 this cod >e has disjoint path routing/load balancing and other purely EXPERIMENTAL capabi >lities. While this code also compiles for Linux, the multipath routing option w >ill only work within the simulator code. >> >> -joe >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 17:31:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22409 for ; Thu, 27 Mar 2003 17:31:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RMqi629005 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 17:52:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RMqiO29002 for ; Thu, 27 Mar 2003 17:52:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22394 for ; Thu, 27 Mar 2003 17:30:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RMaVO27439; Thu, 27 Mar 2003 17:36:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RMU5O27094 for ; Thu, 27 Mar 2003 17:30:05 -0500 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21655 for ; Thu, 27 Mar 2003 17:08:06 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h2RMARjZ029934 for ; Thu, 27 Mar 2003 17:10:27 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2RMAMWe015759 for ; Thu, 27 Mar 2003 17:10:22 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003032717102231817 for ; Thu, 27 Mar 2003 17:10:22 -0500 Message-Id: <5.1.1.5.2.20030327155838.030add08@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 27 Mar 2003 17:10:11 -0500 To: manet@ietf.org From: Joe Macker Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [manet] ID Progression and WG Input Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , All: The previous milestone schedule for submitting the three remaining IDs for EXPERIMENTAL consideration is well upon us. I am recommending the following be done to quickly progress the efforts of the last few months. DSR submission was slightly delayed by the authors to allow for one more iteration. That document iteration has now been posted for a few weeks allowing WG perusal. I would request that the authors provide a additional short WG period to gather any last minute input/potential changes (nits/security,etc) and prepare for a document submission request by next week (April 3, 2003) to capture any changes needed. Both TBRPF and OLSR have been posted for a few weeks, but as WG chair I feel a little more review time is needed. AODV and DSR both went through previous WG Last Call processes. I know some people have reviewed the recent iterations and some others are in progress on reviewing them. Already, it was reported, that WG review input was received and collected by the OLSR authors (TBRPF may have received input as well?). Also, if the authors post a short summary of any intended mods it may save on redundant commentary. I am suggesting that next week be a WG Last Call period (ending on 1200 EST April 4, next Friday) for WG input prior to submission revision and consideration for both of these documents. It was indicated in San Francisco that authors of these two IDs could commit to a short turnaround and I would like to target April 10 for submission consideration with any revisions. Authors please make sure you go over and check the ID author nits prior to any final revisions.. http://www.ietf.org/ID-nits.html Although EXPERIMENTAL status may be more lenient on technical content nits,etc.. Specific ones to note: (1) Security Considerations Section....(something meaningful said about issues/risks..possible solutions)..AODV got through this so you may want to review any final statements with the authors since there are some risk similarities among most of the protocols. (2) Specific IPR claims and terms must not be in RFC (but should be on IPR web page) I think we are good here for all three documents with all present revisions I looked at. (3) IANA Considerations if needed ... -joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 17:44:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22830 for ; Thu, 27 Mar 2003 17:44:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RN5pS29764 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 18:05:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RN5pO29761 for ; Thu, 27 Mar 2003 18:05:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22824 for ; Thu, 27 Mar 2003 17:43:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RMlwO28744; Thu, 27 Mar 2003 17:47:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RMhuO28580 for ; Thu, 27 Mar 2003 17:43:56 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22172 for ; Thu, 27 Mar 2003 17:21:57 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id OAA09214; Thu, 27 Mar 2003 14:24:15 -0800 (PST) Message-Id: <200303272224.OAA09214@pit.erg.sri.com> To: "Philippe Jacquet" cc: manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Multipath routing In-reply-to: Your message of "Thu, 27 Mar 2003 19:49:51 +0100." <048c01c2f491$a65ad0c0$1f175d80@inria.fr> Date: Thu, 27 Mar 2003 14:24:14 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Yes, advertising more links than the MPR links is more efficient than using redundant MPRs. But instead of advertising the full topology, it would be nice to allow advertising less than the full topology, e.g., a biconnected topology, that would still allow computation of 2 disjoint paths to each destination. This could result in significantly less overhead in very dense networks and in implementations that use smaller packet headers (so that the size of the TC message becomes more significant). I wonder why OLSR does not provide such an option. Also, I wonder if there may be a problem with forwarding a packet to a neighbor that is not an MPR of the following hop, i.e., such that the second link of the path is not an MPR link. The potential problem is that the non-MPR neighbor might not even know that the path exists (yet), since the neighbor would not report the path. And if a link on the path fails, the non-MPR neighbor would not report the failure. Richard > Hello, > > I think multipath routing is a priori a problem of routing table: one must > have two entries in the routing table for the same destination. This is not > easy to handle in hop by hop routing. Maybe source routing option in IP > stack would help. In order to have load balancing the routes should probably > be two hops or three hops away in order to avoid co-interference. > > Regarding OLSR I don't think MPR coverage is an issue here since MPR > coverage addresses only flooding reliability. In OLSR one can advertize more > links than the MPR links. In fact nodes can advertize their whole link set > and simulations don't show tremendous more overhead (TC still benefit from > MPR forwarding). With knowledge of the whole link state in the network, one > can compute all possible redundant routes if one wishes so. > > Philippe > ----- Original Message ----- > From: > To: Carlos Calafate ; > Sent: Thursday, March 27, 2003 6:16 PM > Subject: Re: [manet] Multipath routing > > > > > > One caution in using multipath routing with OLSR. > > If you want two node-disjoint paths, for example, > > then the MPR Redundancy parameter needs to be 2, > > since using non-redundant MPRs does not ensure that > > disjoint paths will be found even if they exist. > > > > >From the OLSR draft: "Redundancy of the MPR set affects the overhead > > through affecting the amount of links being advertised, the amount of > > nodes advertising links to the MPR selector and the efficiency of the > > MPR flooding mechanism." > > > > The result is that increasing the MPR redundancy to 2 will > > roughly increase the TC overhead by a factor of 4. > > This is unnecessary - a factor of 2 is quite possible. > > > > Some may argue that the factor of 4 buys more robustness, > > but I have not seen any simulation results showing this, > > and I doubt that it improves robustness sufficiently to > > justify the large overhead. > > > > Richard > > > > > > > At 10:37 AM 3/27/2003 +0100, Carlos Calafate wrote: > > > >Hi, > > > > > > > >Can anyone tell me where I can find implementations of multipath > routing > > > >protocols for NS-2? > > > > > > We have an NRL version of an OLSR derivative (CVS repository) with lots > of ex > > perimental options at http://pf.itd.nrl.navy.mil. If compiled for ns2 > this cod > > e has disjoint path routing/load balancing and other purely EXPERIMENTAL > capabi > > lities. While this code also compiles for Linux, the multipath routing > option w > > ill only work within the simulator code. > > > > > > -joe > > > > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 18:22:35 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 SAA25290 for ; Thu, 27 Mar 2003 18:22:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2RNi4600746 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 18:44:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RNi4O00743 for ; Thu, 27 Mar 2003 18:44:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25279 for ; Thu, 27 Mar 2003 18:22:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RNOAO31316; Thu, 27 Mar 2003 18:24:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2RNJkO31147 for ; Thu, 27 Mar 2003 18:19:46 -0500 Received: from MM01SNLNTO.sandia.gov (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23142 for ; Thu, 27 Mar 2003 17:57:45 -0500 (EST) Received: from 132.175.109.4 by MM01SNLNTO.sandia.gov with ESMTP ( Tumbleweed MMS SMTP Relay 01 (MMS v5.5.0)); Thu, 27 Mar 2003 16:00:03 -0600 Received: from es08snlnt.sandia.gov (smtp-in.sandia.gov [134.253.130.11] ) by mailgate2.sandia.gov (8.12.8/8.12.8) with ESMTP id h2RN01U1010404 for ; Thu, 27 Mar 2003 16:00:01 -0700 (MST) Received: by es08snlnt.sandia.gov with Internet Mail Service ( 5.5.2653.19) id ; Thu, 27 Mar 2003 16:00:01 -0700 Message-ID: From: "Van Leeuwen, Brian P" To: "'manet@ietf.org'" Date: Thu, 27 Mar 2003 15:59:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 129D5DF9812768-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [manet] Lean DSR or Other Ad Hoc Routing Implementation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I'm involved in setting up an experiment that requires a basic or lean implementation of an ad hoc routing protocol. DSR meets my requirements, however, I could get by with another routing implementation. QUESTION: Have any of you implemented DSR in the user space? If so, are you willing to share your implementation for my experiment? Any suggestions as to where I might find an implementation are welcome. Thanks for your help, Brian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 19:07:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27385 for ; Thu, 27 Mar 2003 19:07:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S0T6p03704 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 19:29:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S0T6O03701 for ; Thu, 27 Mar 2003 19:29:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27379 for ; Thu, 27 Mar 2003 19:07:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S0EfO02871; Thu, 27 Mar 2003 19:14:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S094O02682 for ; Thu, 27 Mar 2003 19:09:04 -0500 Received: from mailhost.cs.auc.dk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26412 for ; Thu, 27 Mar 2003 18:47:03 -0500 (EST) Received: from armada (voop@pico.cs.auc.dk [130.225.194.80]) by mailhost.cs.auc.dk (8.12.3/8.12.3) with SMTP id h2RNnIPO024273; Fri, 28 Mar 2003 00:49:19 +0100 (MET) Date: Fri, 28 Mar 2003 00:49:17 +0100 From: Thomas Heide Clausen To: ogier@erg.sri.com Cc: philippe.jacquet@inria.fr, manet@ietf.org Subject: Re: [manet] Multipath routing Message-Id: <20030328004917.140e3c21.T.Clausen@computer.org> In-Reply-To: <200303272224.OAA09214@pit.erg.sri.com> References: <048c01c2f491$a65ad0c0$1f175d80@inria.fr> <200303272224.OAA09214@pit.erg.sri.com> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.14 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 27 Mar 2003 14:24:14 -0800 ogier@erg.sri.com wrote: > > Yes, advertising more links than the MPR links is more efficient > than using redundant MPRs. But instead of advertising the > full topology, it would be nice to allow advertising less > than the full topology, e.g., a biconnected topology, > that would still allow computation of 2 disjoint paths to > each destination. This could result in significantly less > overhead in very dense networks and in implementations that > use smaller packet headers (so that the size of the TC message > becomes more significant). > I wonder why OLSR does not provide such an option. The OLSR draft specifies, in the very beginning, that: " Indeed, the only requirement for OLSR to provide routes to all destinations is that MPR nodes declare link-state information for links between them self and their MPR selectors. Additional available link-state information may be utilized, e.g. for redundancy." I.e. the specifications gives a minimum requirement for correct operation. Additional information may, under specific conditions, be of advantage and is indeed permitted. Doesn't this address exactly what you mention? --thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 19:27:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28235 for ; Thu, 27 Mar 2003 19:27:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S0mxE05567 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 19:48:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S0mxO05564 for ; Thu, 27 Mar 2003 19:48:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28218 for ; Thu, 27 Mar 2003 19:26:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S0Z0O03988; Thu, 27 Mar 2003 19:35:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S0UqO03768 for ; Thu, 27 Mar 2003 19:30:52 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27436 for ; Thu, 27 Mar 2003 19:08:50 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id QAA09604; Thu, 27 Mar 2003 16:10:59 -0800 (PST) Message-Id: <200303280010.QAA09604@pit.erg.sri.com> To: Thomas Heide Clausen cc: ogier@erg.sri.com, philippe.jacquet@inria.fr, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Multipath routing In-reply-to: Your message of "Fri, 28 Mar 2003 00:49:17 +0100." <20030328004917.140e3c21.T.Clausen@computer.org> Date: Thu, 27 Mar 2003 16:10:59 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > On Thu, 27 Mar 2003 14:24:14 -0800 > ogier@erg.sri.com wrote: > > > > > Yes, advertising more links than the MPR links is more efficient > > than using redundant MPRs. But instead of advertising the > > full topology, it would be nice to allow advertising less > > than the full topology, e.g., a biconnected topology, > > that would still allow computation of 2 disjoint paths to > > each destination. This could result in significantly less > > overhead in very dense networks and in implementations that > > use smaller packet headers (so that the size of the TC message > > becomes more significant). > > I wonder why OLSR does not provide such an option. > > The OLSR draft specifies, in the very beginning, that: > > " Indeed, the only > requirement for OLSR to provide routes to all destinations is that > MPR nodes declare link-state information for links between them > self and their MPR selectors. Additional available link-state > information may be utilized, e.g. for redundancy." > > I.e. the specifications gives a minimum requirement for correct > operation. Additional information may, under specific conditions, be > of advantage and is indeed permitted. Doesn't this address exactly > what you mention? Not really. That informal statement from the Introduction only says that additional link-state information may be "utilized". But Section 11.1 (quoted below) is very specific about what redundant information may be included in TC messages. Maybe you would like to change "the amount of information that is included in the TC messages" to "the minimum information that must be included in the TC messages." Richard 11.1. TC_REDUNDANCY Parameter The parameter TC_REDUNDANCY specifies, for the local node, the amount of information that is included in the TC messages. The parameter is interpreted as follows: - if the TC_REDUNDANCY parameter of the node is 0, then its advertised link set is limited to the MPR selector set (as described in section 4 - if the TC_REDUNDANCY parameter of the node is 1, then its advertised set is the union of its MPR set and its MPR selec- tor set, - if the TC_REDUNDANCY parameter of the node is 2, then its advertised set is neighbor set (full link-state information is diffused). A node with willingness equal to zero SHOULD have TC_REDUNDANCY also equal to zero. > > > --thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 19:58:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29247 for ; Thu, 27 Mar 2003 19:58:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S1KPU08150 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 20:20:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S1KPO08147 for ; Thu, 27 Mar 2003 20:20:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29225 for ; Thu, 27 Mar 2003 19:58:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S11eO06280; Thu, 27 Mar 2003 20:01:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S0uvO06033 for ; Thu, 27 Mar 2003 19:56:57 -0500 Received: from mailhost.cs.auc.dk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28533 for ; Thu, 27 Mar 2003 19:34:55 -0500 (EST) Received: from armada (voop@pico.cs.auc.dk [130.225.194.80]) by mailhost.cs.auc.dk (8.12.3/8.12.3) with SMTP id h2S0bDPO027003; Fri, 28 Mar 2003 01:37:13 +0100 (MET) Date: Fri, 28 Mar 2003 01:37:13 +0100 From: Thomas Heide Clausen To: manet@ietf.org, ogier@erg.sri.com Subject: Re: [manet] Multipath routing Message-Id: <20030328013713.40b28df7.T.Clausen@computer.org> In-Reply-To: <200303280010.QAA09604@pit.erg.sri.com> References: <20030328004917.140e3c21.T.Clausen@computer.org> <200303280010.QAA09604@pit.erg.sri.com> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.14 Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 27 Mar 2003 16:10:59 -0800 ogier@erg.sri.com wrote: > > On Thu, 27 Mar 2003 14:24:14 -0800 > > ogier@erg.sri.com wrote: > > > > > > > > Yes, advertising more links than the MPR links is more > > > efficient than using redundant MPRs. But instead of > > > advertising the full topology, it would be nice to allow > > > advertising less than the full topology, e.g., a biconnected > > > topology, that would still allow computation of 2 disjoint > > > paths to each destination. This could result in significantly > > > less overhead in very dense networks and in implementations > > > that use smaller packet headers (so that the size of the TC > > > message becomes more significant). > > > I wonder why OLSR does not provide such an option. > > > > The OLSR draft specifies, in the very beginning, that: > > > > " Indeed, the only > > requirement for OLSR to provide routes to all destinations is > > that MPR nodes declare link-state information for links between > > them self and their MPR selectors. Additional available > > link-state information may be utilized, e.g. for redundancy." > > > > I.e. the specifications gives a minimum requirement for correct > > operation. Additional information may, under specific conditions, > > be of advantage and is indeed permitted. Doesn't this address > > exactly what you mention? > > Not really. That informal statement from the Introduction only says > that additional link-state information may be "utilized". > But Section 11.1 (quoted below) is very specific about what > redundant information may be included in TC messages. Maybe you > would like to change "the amount of information that is included in > the TC messages" to "the minimum information that must be included > in the TC messages." Not well that section 5 (Topology Discovery) states that: "Routes are constructed through advertised links and links with neighbors. A node must at least disseminate links between itself and the nodes in its MPR-selector set, in order to provide sufficient information to enable routing." This is not an informal statement, rather a firm requirement. Also, later in 5.3: "A TC message is sent by a node in the network to declare a set of links, called advertised link set which MUST include at least the links to all nodes of its MPR Selector set, i.e., the neighbors which have selected the sender node as a MPR. If, for some reason, it is required to distribute redundant TC information, refer to section 11." I.e. section 11 is a proposed way of diffusing additional/redundant TC-information. However any way you can concieve of, which satisfies section 5 (that a node at least disseminates links between itself and the MPR selector set), is permitted. I.e. section 5 specifies the "musts" which are required for interoperability. Notice that one of the options proposed in section 11 is, exactly, what Joe implemented: diffusing full link-state, but profiting from the MPR optimized flooding. Notice also, that you may come up with a different set of links to diffuse, as long as you at least diffuse the MPR selector set of each node. --thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 20:38: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 UAA00405 for ; Thu, 27 Mar 2003 20:38:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S20NC10606 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 21:00:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S20MO10603 for ; Thu, 27 Mar 2003 21:00:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00393 for ; Thu, 27 Mar 2003 20:38:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S1kFO09814; Thu, 27 Mar 2003 20:46:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S1cFO09555 for ; Thu, 27 Mar 2003 20:38:15 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29561 for ; Thu, 27 Mar 2003 20:16:12 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id RAA09824; Thu, 27 Mar 2003 17:18:29 -0800 (PST) Message-Id: <200303280118.RAA09824@pit.erg.sri.com> To: Thomas Heide Clausen cc: manet@ietf.org, ogier@erg.sri.com Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Multipath routing In-reply-to: Your message of "Fri, 28 Mar 2003 01:37:13 +0100." <20030328013713.40b28df7.T.Clausen@computer.org> Date: Thu, 27 Mar 2003 17:18:29 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > On Thu, 27 Mar 2003 16:10:59 -0800 > ogier@erg.sri.com wrote: > > > > On Thu, 27 Mar 2003 14:24:14 -0800 > > > ogier@erg.sri.com wrote: > > > > > > > > > > > Yes, advertising more links than the MPR links is more > > > > efficient than using redundant MPRs. But instead of > > > > advertising the full topology, it would be nice to allow > > > > advertising less than the full topology, e.g., a biconnected > > > > topology, that would still allow computation of 2 disjoint > > > > paths to each destination. This could result in significantly > > > > less overhead in very dense networks and in implementations > > > > that use smaller packet headers (so that the size of the TC > > > > message becomes more significant). > > > > I wonder why OLSR does not provide such an option. > > > > > > The OLSR draft specifies, in the very beginning, that: > > > > > > " Indeed, the only > > > requirement for OLSR to provide routes to all destinations is > > > that MPR nodes declare link-state information for links between > > > them self and their MPR selectors. Additional available > > > link-state information may be utilized, e.g. for redundancy." > > > > > > I.e. the specifications gives a minimum requirement for correct > > > operation. Additional information may, under specific conditions, > > > be of advantage and is indeed permitted. Doesn't this address > > > exactly what you mention? > > > > Not really. That informal statement from the Introduction only says > > that additional link-state information may be "utilized". > > But Section 11.1 (quoted below) is very specific about what > > redundant information may be included in TC messages. Maybe you > > would like to change "the amount of information that is included in > > the TC messages" to "the minimum information that must be included > > in the TC messages." > > Not well that section 5 (Topology Discovery) states that: > > "Routes are constructed through advertised links and links with > neighbors. A node must at least disseminate links between itself and > the nodes in its MPR-selector set, in order to provide sufficient > information to enable routing." > > This is not an informal statement, rather a firm requirement. Also, The statement "A node must at least disseminate.." does not describe or imply how much *additional* information can be disseminated. That is the purpose of Section 11. You would have to say something like "any additional information may be included". But even if you did, Section 11 is very specific about what additional information can be included, and would contradict such a statement. > later in 5.3: > > "A TC message is sent by a node in the network to declare a set of > links, called advertised link set which MUST include at least the > links to all nodes of its MPR Selector set, i.e., the neighbors > which have selected the sender node as a MPR. If, for some reason, > it is required to distribute redundant TC information, refer to > section 11." I interpret this to mean that if you want to send redundant TC information, you must do so as specified in Section 11. And as I said, Section 11 is very specific about what redundant information can be included in TC messages, and allows only three options: - if the TC_REDUNDANCY parameter of the node is 0, then its advertised link set is limited to the MPR selector set (as described in section 4.6.2), - if the TC_REDUNDANCY parameter of the node is 1, then its advertised set is the union of its MPR set and its MPR selec- tor set, - if the TC_REDUNDANCY parameter of the node is 2, then its advertised set is neighbor set (full link-state information is diffused). The first option actually says that the advertised link set is *limited* to the MPR selector set. What value for TC_REDUNDANCY should I use if I want to report more than the MPR selector set, but less than the full topology (e.g., a biconnected subgraph)? According to Section 11, it can't be 0, 1, or 2. Richard > I.e. section 11 is a proposed way of diffusing additional/redundant > TC-information. However any way you can concieve of, which satisfies > section 5 (that a node at least disseminates links between itself and > the MPR selector set), is permitted. I.e. section 5 specifies the > "musts" which are required for interoperability. > > Notice that one of the options proposed in section 11 is, exactly, > what Joe implemented: diffusing full link-state, but profiting from > the MPR optimized flooding. Notice also, that you may come up with a > different set of links to diffuse, as long as you at least diffuse > the MPR selector set of each node. > > --thomas _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Thu Mar 27 21:28:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01620 for ; Thu, 27 Mar 2003 21:28:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S2nxC14484 for manet-archive@odin.ietf.org; Thu, 27 Mar 2003 21:49:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2nxO14481 for ; Thu, 27 Mar 2003 21:49:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01604 for ; Thu, 27 Mar 2003 21:27:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2RQO12820; Thu, 27 Mar 2003 21:27:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S2MfO12635 for ; Thu, 27 Mar 2003 21:22:41 -0500 Received: from mailhost.cs.auc.dk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01175 for ; Thu, 27 Mar 2003 21:00:36 -0500 (EST) Received: from armada (voop@pico.cs.auc.dk [130.225.194.80]) by mailhost.cs.auc.dk (8.12.3/8.12.3) with SMTP id h2S22tPO001265; Fri, 28 Mar 2003 03:02:55 +0100 (MET) Date: Fri, 28 Mar 2003 03:02:54 +0100 From: Thomas Heide Clausen To: ogier@erg.sri.com Cc: manet@ietf.org Subject: Re: [manet] Multipath routing Message-Id: <20030328030254.19b0392f.T.Clausen@computer.org> In-Reply-To: <200303280118.RAA09824@pit.erg.sri.com> References: <20030328013713.40b28df7.T.Clausen@computer.org> <200303280118.RAA09824@pit.erg.sri.com> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.14 Content-Transfer-Encoding: 8bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit On Thu, 27 Mar 2003 17:18:29 -0800 ogier@erg.sri.com wrote: > > On Thu, 27 Mar 2003 16:10:59 -0800 > > ogier@erg.sri.com wrote: > > > > > > On Thu, 27 Mar 2003 14:24:14 -0800 > > > > ogier@erg.sri.com wrote: > > > > > > > > > > > > > > Yes, advertising more links than the MPR links is more > > > > > efficient than using redundant MPRs. But instead of > > > > > advertising the full topology, it would be nice to allow > > > > > advertising less than the full topology, e.g., a > > > > > biconnected topology, that would still allow computation of > > > > > 2 disjoint paths to each destination. This could result in > > > > > significantly less overhead in very dense networks and in > > > > > implementations that use smaller packet headers (so that > > > > > the size of the TC message becomes more significant). > > > > > I wonder why OLSR does not provide such an option. > > > > > > > > The OLSR draft specifies, in the very beginning, that: > > > > > > > > " Indeed, the only > > > > requirement for OLSR to provide routes to all destinations > > > > is that MPR nodes declare link-state information for links > > > > between them self and their MPR selectors. Additional > > > > available link-state information may be utilized, e.g. for > > > > redundancy." > > > > > > > > I.e. the specifications gives a minimum requirement for > > > > correct operation. Additional information may, under specific > > > > conditions, be of advantage and is indeed permitted. Doesn't > > > > this address exactly what you mention? > > > > > > Not really. That informal statement from the Introduction only > > > says that additional link-state information may be "utilized". > > > But Section 11.1 (quoted below) is very specific about what > > > redundant information may be included in TC messages. Maybe > > > you would like to change "the amount of information that is > > > included in the TC messages" to "the minimum information that > > > must be included in the TC messages." > > > > Not well that section 5 (Topology Discovery) states that: > > > > "Routes are constructed through advertised links and links with > > neighbors. A node must at least disseminate links between itself > > and the nodes in its MPR-selector set, in order to provide > > sufficient information to enable routing." > > > > This is not an informal statement, rather a firm requirement. > > Also, > > The statement "A node must at least disseminate.." does not > describe or imply how much *additional* information can be > disseminated. That is the purpose of Section 11. Actually, section 11 describes only the interpretation of the TC_REDUNDANCY parameter. It does *not* modify the basic requirement from section 5, namely that "A node must at least disseminate links between itself and the nodes in its MPR-selector set, in order to provide sufficient information to enable routing." It is very much the intention of the spec. to give the minimal required for interoperability (which is exactly that the MPR selector set by dissiminated) while allowing for flexibility where needed. > > You would have to say something like "any additional information > may be included". But even if you did, Section 11 is very specific > about what additional information can be included, and would > contradict such a statement. No. Section 11 specifies the interpretation of the TC_REDUNDANCY parameter. Including additional information (again, respecting the requirements of section 5) does not yield a contradiction. > > > later in 5.3: > > > > "A TC message is sent by a node in the network to declare a set > > of > > links, called advertised link set which MUST include at least > > the links to all nodes of its MPR Selector set, i.e., the > > neighbors which have selected the sender node as a MPR. If, for > > some reason, it is required to distribute redundant TC > > information, refer to section 11." > > I interpret this to mean that if you want to send redundant TC > information, you must do so as specified in Section 11. And as I > said, Section 11 is very specific about what redundant information > can be included in TC messages, and allows only three options: Section 11 is specific about the interpretation of the TC_REDUNDANCY parameter only, supplementing section 5. It does not place any further restrictions on section 5 which, to repeat myself, states that "A node must at least disseminate links between itself and the nodes in its MPR-selector set, in order to provide sufficient information to enable routing." > > - if the TC_REDUNDANCY parameter of the node is 0, then its > advertised link set is limited to the MPR selector set (as > described in section 4.6.2), > > - if the TC_REDUNDANCY parameter of the node is 1, then its > advertised set is the union of its MPR set and its MPR selec- > tor set, > > - if the TC_REDUNDANCY parameter of the node is 2, then its > advertised set is neighbor set (full link-state information is > diffused). > > The first option actually says that the advertised link set is > *limited* to the MPR selector set. Yes, *IF* the TC_REDUNDANCY parameter is employed. > > What value for TC_REDUNDANCY should I use if I want to report > more than the MPR selector set, but less than the full topology > (e.g., a biconnected subgraph)? > According to Section 11, it can't be 0, 1, or 2. > Well, if you want to advertise additional topological information, then as long as you respect the requirements from section 5, namely that "A node must at least disseminate links between itself and the nodes in its MPR-selector set, in order to provide sufficient information to enable routing", you are not conflicting the spec atall. You will, basically, not need to be concerned with section 11, unless you specifically need/want the features provided herein. This was precisely the idea of seperating those issues (section 8-12): to only engage these sections when the features they provide are explicitly needed/wanted. Anyways, I think that your issue basically is, that you read section 11 as "overriding" section 5, not "supplementing" section 5, correct? Notice that section 11 does not include any "must", rather it uses "can". I'd be happy to change the "can" to a "may", if you think that will be clearer? In either case, the interpretation is the same. --thomas > Richard > > > > I.e. section 11 is a proposed way of diffusing > > additional/redundant TC-information. However any way you can > > concieve of, which satisfies section 5 (that a node at least > > disseminates links between itself and the MPR selector set), is > > permitted. I.e. section 5 specifies the"musts" which are required > > for interoperability. > > > > Notice that one of the options proposed in section 11 is, > > exactly, what Joe implemented: diffusing full link-state, but > > profiting from the MPR optimized flooding. Notice also, that you > > may come up with a different set of links to diffuse, as long as > > you at least diffuse the MPR selector set of each node. > > > > --thomas > -- ------------------------------------------- Thomas Heide Clausen Civilingeniør i Datateknik (cand.polyt) M.Sc in Computer Engineering E-Mail: T.Clausen@computer.org WWW: http://www.cs.auc.dk/~voop ------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 28 00:22:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05168 for ; Fri, 28 Mar 2003 00:22:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S5iOm25647 for manet-archive@odin.ietf.org; Fri, 28 Mar 2003 00:44:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S5iOO25644 for ; Fri, 28 Mar 2003 00:44:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05153 for ; Fri, 28 Mar 2003 00:22:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S5USO24331; Fri, 28 Mar 2003 00:30:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S5LBO24136 for ; Fri, 28 Mar 2003 00:21:11 -0500 Received: from mail2.iitk.ac.in (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04693 for ; Thu, 27 Mar 2003 23:59:02 -0500 (EST) Received: from antivirus.cc.iitk.ac.in (antivirus.cc.iitk.ac.in [172.31.1.102]) by mail2.iitk.ac.in (8.12.8/8.12.5) with SMTP id h2S5Cc2q021321 for ; Fri, 28 Mar 2003 10:42:38 +0530 Received: from mailhost.cse.iitk.ac.in ([172.31.16.2]) by antivirus.cc.iitk.ac.in (NAVGW 2.5.2.12) with SMTP id M2003032810310327677 for ; Fri, 28 Mar 2003 10:31:03 +0530 Received: from cselinux1.cse.iitk.ac.in (cselinux1.cse.iitk.ac.in [172.31.16.12]) by mailhost.cse.iitk.ac.in (8.12.8/8.12.8) with ESMTP id h2S59NJv027277 for ; Fri, 28 Mar 2003 10:39:23 +0530 Date: Fri, 28 Mar 2003 10:22:12 +0530 (IST) From: Ashish Pandey To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] ns2 in clustering computation Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Anybody ever used network simulator ns2 for checking clustering characterstics in manet. If anyone has conducted experiments for clustering properties on Ad Hoc network testbed or on ns2 ..please let me know.. Thanks Ashish -------------------------------------------------------------- Ashish Pandey Department of Computer Science & Engineering Indian Institute of Technology Kanpur - 208016, India email: ashishp@iitk.ac.in ashishp@cse.iitk.ac.in _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 28 02:35:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19673 for ; Fri, 28 Mar 2003 02:35:34 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S7vDE12601 for manet-archive@odin.ietf.org; Fri, 28 Mar 2003 02:57:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7vCO12598 for ; Fri, 28 Mar 2003 02:57:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19614 for ; Fri, 28 Mar 2003 02:35:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7fHO11488; Fri, 28 Mar 2003 02:41:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S7ZBO10491 for ; Fri, 28 Mar 2003 02:35:11 -0500 Received: from pit.erg.sri.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18252 for ; Fri, 28 Mar 2003 02:13:00 -0500 (EST) Received: from pit.erg.sri.com (localhost [127.0.0.1]) by pit.erg.sri.com (8.9.3+Sun/8.9.1) with ESMTP id XAA10899; Thu, 27 Mar 2003 23:15:20 -0800 (PST) Message-Id: <200303280715.XAA10899@pit.erg.sri.com> To: Thomas Heide Clausen cc: ogier@erg.sri.com, manet@ietf.org Reply-To: ogier@erg.sri.com From: ogier@erg.sri.com Subject: Re: [manet] Multipath routing In-reply-to: Your message of "Fri, 28 Mar 2003 03:02:54 +0100." <20030328030254.19b0392f.T.Clausen@computer.org> Date: Thu, 27 Mar 2003 23:15:20 -0800 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > On Thu, 27 Mar 2003 17:18:29 -0800 > ogier@erg.sri.com wrote: > > > > On Thu, 27 Mar 2003 16:10:59 -0800 > > > ogier@erg.sri.com wrote: > > > > > > > > On Thu, 27 Mar 2003 14:24:14 -0800 > > > > > ogier@erg.sri.com wrote: > > > > > > > > > > > > > > > > > Yes, advertising more links than the MPR links is more > > > > > > efficient than using redundant MPRs. But instead of > > > > > > advertising the full topology, it would be nice to allow > > > > > > advertising less than the full topology, e.g., a > > > > > > biconnected topology, that would still allow computation of > > > > > > 2 disjoint paths to each destination. This could result in > > > > > > significantly less overhead in very dense networks and in > > > > > > implementations that use smaller packet headers (so that > > > > > > the size of the TC message becomes more significant). > > > > > > I wonder why OLSR does not provide such an option. > > > > > > > > > > The OLSR draft specifies, in the very beginning, that: > > > > > > > > > > " Indeed, the only > > > > > requirement for OLSR to provide routes to all destinations > > > > > is that MPR nodes declare link-state information for links > > > > > between them self and their MPR selectors. Additional > > > > > available link-state information may be utilized, e.g. for > > > > > redundancy." > > > > > > > > > > I.e. the specifications gives a minimum requirement for > > > > > correct operation. Additional information may, under specific > > > > > conditions, be of advantage and is indeed permitted. Doesn't > > > > > this address exactly what you mention? > > > > > > > > Not really. That informal statement from the Introduction only > > > > says that additional link-state information may be "utilized". > > > > But Section 11.1 (quoted below) is very specific about what > > > > redundant information may be included in TC messages. Maybe > > > > you would like to change "the amount of information that is > > > > included in the TC messages" to "the minimum information that > > > > must be included in the TC messages." > > > > > > Not well that section 5 (Topology Discovery) states that: > > > > > > "Routes are constructed through advertised links and links with > > > neighbors. A node must at least disseminate links between itself > > > and the nodes in its MPR-selector set, in order to provide > > > sufficient information to enable routing." > > > > > > This is not an informal statement, rather a firm requirement. > > > Also, > > > > The statement "A node must at least disseminate.." does not > > describe or imply how much *additional* information can be > > disseminated. That is the purpose of Section 11. > > Actually, section 11 describes only the interpretation of the > TC_REDUNDANCY parameter. It does *not* modify the basic requirement > from section 5, namely that "A node must at least disseminate links > between itself and the nodes in its MPR-selector set, in order to > provide sufficient information to enable routing." > > It is very much the intention of the spec. to give the minimal > required for interoperability (which is exactly that the MPR selector > set by dissiminated) while allowing for flexibility where needed. > > > > > You would have to say something like "any additional information > > may be included". But even if you did, Section 11 is very specific > > about what additional information can be included, and would > > contradict such a statement. > > No. Section 11 specifies the interpretation of the TC_REDUNDANCY > parameter. Including additional information (again, respecting the > requirements of section 5) does not yield a contradiction. > > > > > > later in 5.3: > > > > > > "A TC message is sent by a node in the network to declare a set > > > of > > > links, called advertised link set which MUST include at least > > > the links to all nodes of its MPR Selector set, i.e., the > > > neighbors which have selected the sender node as a MPR. If, for > > > some reason, it is required to distribute redundant TC > > > information, refer to section 11." > > > > I interpret this to mean that if you want to send redundant TC > > information, you must do so as specified in Section 11. And as I > > said, Section 11 is very specific about what redundant information > > can be included in TC messages, and allows only three options: > > Section 11 is specific about the interpretation of the TC_REDUNDANCY > parameter only, supplementing section 5. It does not place any > further restrictions on section 5 which, to repeat myself, states > that "A node must at least disseminate links between itself and the > nodes in its MPR-selector set, in order to provide sufficient > information to enable routing." > > > > > - if the TC_REDUNDANCY parameter of the node is 0, then its > > advertised link set is limited to the MPR selector set (as > > described in section 4.6.2), > > > > - if the TC_REDUNDANCY parameter of the node is 1, then its > > advertised set is the union of its MPR set and its MPR selec- > > tor set, > > > > - if the TC_REDUNDANCY parameter of the node is 2, then its > > advertised set is neighbor set (full link-state information is > > diffused). > > > > The first option actually says that the advertised link set is > > *limited* to the MPR selector set. > > Yes, *IF* the TC_REDUNDANCY parameter is employed. Where does it say that the TC_REDUNDANCY parameter is optional? A parameter is a parameter and must have a value. > > > > > What value for TC_REDUNDANCY should I use if I want to report > > more than the MPR selector set, but less than the full topology > > (e.g., a biconnected subgraph)? > > According to Section 11, it can't be 0, 1, or 2. > > > > Well, if you want to advertise additional topological information, > then as long as you respect the requirements from section 5, namely > that "A node must at least disseminate links between itself and the > nodes in its MPR-selector set, in order to provide sufficient > information to enable routing", you are not conflicting the spec > atall. > > You will, basically, not need to be concerned with section 11, unless > you specifically need/want the features provided herein. This was > precisely the idea of seperating those issues (section 8-12): to only > engage these sections when the features they provide are explicitly > needed/wanted. > > Anyways, I think that your issue basically is, that you read section > 11 as "overriding" section 5, not "supplementing" section 5, correct? > Notice that section 11 does not include any "must", rather it uses > "can". I'd be happy to change the "can" to a "may", if you think > that will be clearer? In either case, the interpretation is the same. No, that won't help. First of all, it is not clear that the TC_REDUNDANCY parameter is optional. Section 5 specifies the minimum information that must be included in TC messages. That leads me to ask "what else can be included?". Section 11 says what else can (or may) be included. I don't want to assume that I can include anything in TC messages unless it says what else MAY be included. For example, MAY I include garbage or non-adjacent links? Also, it is natural to assume that if you want to advertise redundant infomation, then Section 11 applies, since it is entitled "Distributing Redundant Topology Information". That's all I have to say. I'll leave it to you and others to decide whether any changes should be made. Richard > > --thomas > > > > Richard > > > > > > > I.e. section 11 is a proposed way of diffusing > > > additional/redundant TC-information. However any way you can > > > concieve of, which satisfies section 5 (that a node at least > > > disseminates links between itself and the MPR selector set), is > > > permitted. I.e. section 5 specifies the"musts" which are required > > > for interoperability. > > > > > > Notice that one of the options proposed in section 11 is, > > > exactly, what Joe implemented: diffusing full link-state, but > > > profiting from the MPR optimized flooding. Notice also, that you > > > may come up with a different set of links to diffuse, as long as > > > you at least diffuse the MPR selector set of each node. > > > > > > --thomas > > > > > -- > > ------------------------------------------- > Thomas Heide Clausen > Civilingeniør i Datateknik (cand.polyt) > M.Sc in Computer Engineering > > E-Mail: T.Clausen@computer.org > WWW: http://www.cs.auc.dk/~voop > ------------------------------------------- > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 28 04:13:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21819 for ; Fri, 28 Mar 2003 04:13:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2S9ZBF19927 for manet-archive@odin.ietf.org; Fri, 28 Mar 2003 04:35:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S9ZBO19924 for ; Fri, 28 Mar 2003 04:35:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21806 for ; Fri, 28 Mar 2003 04:12:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S9JjO19160; Fri, 28 Mar 2003 04:19:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2S9EVO19025 for ; Fri, 28 Mar 2003 04:14:31 -0500 Received: from janeway.comnets.rwth-aachen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21427 for ; Fri, 28 Mar 2003 03:52:18 -0500 (EST) Received: from agnel (agnel [137.226.4.75]) by janeway.comnets.rwth-aachen.de (8.11.6+Sun/8.11.6) with ESMTP id h2S8sel15790 for ; Fri, 28 Mar 2003 09:54:40 +0100 (MET) Date: Fri, 28 Mar 2003 09:54:40 +0100 (CET) From: "Erik Weiss, ComNets" X-X-Sender: erw@agnel To: manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [manet] Question for: AODV Local Repair Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Hi all, i have a question about AODV Local Repair, Considering the following case: This Route was built: (8) -> (9) -> (3) -> (4) -> (5) Now the node 5 moves and 4 initiates a local repair, it will end up something like the following. Expected 4 sends the RREQ for Dest 5 (8) -> (9) -> (3) -> (4) -> (7) -> (5) Now 7 got the request originated by 4 and with 7, the destination(5) is reachable again. However 7 didn't have the source node (8) in its routing table, because the RREQ has been sent by 4, therefore also no next hop towards the source exists, and the reverse path is not properly build! Each Paket arriving 7 from 8 does not update the times for source (8) and next hop (7) towards (8). Further more the routing table entry for (4) will expire although we are receiving continuously packets from 4. Possible but complex alternative: 4 sends the RREQ on behalf of 8 however, temporary routing tables and special handling for Request Id's will become necessary. Are these consideration right? Can someone give me a hint how (4) is able to repair the route without losing the reverse path and without the upcomig expiration of 4. Regards Erik _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 28 07:03:35 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 HAA25279 for ; Fri, 28 Mar 2003 07:03:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SCPKr31010 for manet-archive@odin.ietf.org; Fri, 28 Mar 2003 07:25:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SCPKO31007 for ; Fri, 28 Mar 2003 07:25:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25269 for ; Fri, 28 Mar 2003 07:03:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SC9BO30259; Fri, 28 Mar 2003 07:09:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SC0BO29188 for ; Fri, 28 Mar 2003 07:00:11 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24784 for ; Fri, 28 Mar 2003 06:37:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 28 Mar 2003 03:40:18 -0800 Received: from 136.142.79.169 by by2fd.bay2.hotmail.msn.com with HTTP; Fri, 28 Mar 2003 11:40:17 GMT X-Originating-IP: [136.142.79.169] X-Originating-Email: [sherief_essam@hotmail.com] From: "Sherif Khattab" To: erw@comnets.rwth-aachen.de Cc: manet@ietf.org Subject: Re: [manet] Question for: AODV Local Repair Date: Fri, 28 Mar 2003 11:40:17 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 28 Mar 2003 11:40:18.0234 (UTC) FILETIME=[CE8371A0:01C2F51E] Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 Erik, For the first problem, the reverse path breakage, the reverse path will be broken anyway when node (5) moves. The local-repair mechanism tries to repair the forward path only but the reverse path will be repaired once node (5) sends a packet to (8), in which case (7) will send a RERR and (5) will issue RREQ for (8) and most probably it will be (4) who sends the RREP back establishing a route entry in (7) for (8). i think this behavior of on-demand repairing of the reverse path conforms with the reactive nature of AODV. For the second issue, packets from (8) to (5) are not going to update the expiration time for the route entry of (8) anyway. Only entries of (5) will get updated. So, i think the local repair mechanism is not causing a route expiration problem. am i right? Sherif >From: "Erik Weiss, ComNets" >To: manet@ietf.org >Subject: [manet] Question for: AODV Local Repair >Date: Fri, 28 Mar 2003 09:54:40 +0100 (CET) > > >Hi all, > >i have a question about AODV Local Repair, > >Considering the following case: > >This Route was built: > >(8) -> (9) -> (3) -> (4) -> (5) > >Now the node 5 moves and 4 initiates a local repair, it will end up >something like the following. > >Expected 4 sends the RREQ for Dest 5 >(8) -> (9) -> (3) -> (4) -> (7) -> (5) > > >Now 7 got the request originated by 4 and with 7, the destination(5) is >reachable again. >However 7 didn't have the source node (8) in its routing table, because >the RREQ has been sent by 4, therefore also no next hop towards the source >exists, and the reverse path is not properly build! >Each Paket arriving 7 from 8 does not update the times for source (8) and >next hop (7) towards (8). >Further more the routing table entry for (4) will expire although we are >receiving continuously packets from 4. > >Possible but complex alternative: >4 sends the RREQ on behalf of 8 however, temporary routing >tables and special handling for Request Id's will become necessary. > > >Are these consideration right? >Can someone give me a hint how (4) is able to repair the route without >losing the reverse path and without the upcomig expiration of 4. > > > >Regards > > Erik > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 28 08:32:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28178 for ; Fri, 28 Mar 2003 08:32:39 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SDsQr04570 for manet-archive@odin.ietf.org; Fri, 28 Mar 2003 08:54:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SDsPO04567 for ; Fri, 28 Mar 2003 08:54:25 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28171 for ; Fri, 28 Mar 2003 08:32:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SDMTO02287; Fri, 28 Mar 2003 08:22:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SDG3O02088 for ; Fri, 28 Mar 2003 08:16:03 -0500 Received: from janeway.comnets.rwth-aachen.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27173 for ; Fri, 28 Mar 2003 07:53:41 -0500 (EST) Received: from agnel (agnel [137.226.4.75]) by janeway.comnets.rwth-aachen.de (8.11.6+Sun/8.11.6) with ESMTP id h2SCtxl06293; Fri, 28 Mar 2003 13:55:59 +0100 (MET) Date: Fri, 28 Mar 2003 13:55:53 +0100 (CET) From: "Erik Weiss, ComNets" X-X-Sender: erw@agnel To: Sherif Khattab cc: manet@ietf.org Subject: Re: [manet] Question for: AODV Local Repair In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , First of all, thanks for your answer! > Hi Erik, > > For the first problem, the reverse path breakage, the reverse path will > be broken anyway when node (5) moves. The local-repair mechanism tries to > repair the forward path only but the reverse path will be repaired once node > (5) sends a packet to (8), in which case (7) will send a RERR and (5) will > issue RREQ for (8) and most probably it will be (4) who sends the RREP back > establishing a route entry in (7) for (8). i think this behavior of > on-demand repairing of the reverse path conforms with the reactive nature of > AODV. Of courcse you're true, however!!! > > For the second issue, packets from (8) to (5) are not going to update the > expiration time for the route entry of (8) anyway. Only entries of (5) will > get updated. So, i think the local repair mechanism is not causing a route > expiration problem. Well at AODV draft 12/13 page 11 you can find the following chaper, I just copied it. Each time a route is used to forward a data packet, its Active Route Lifetime field of the source, destination and the next hop on the path to the destination is updated to be no less than the current time plus ACTIVE_ROUTE_TIMEOUT. Since the route between each originator and destination pair are expected to be symmetric, the Active Route Lifetime for the previous hop, along the reverse path back to the IP source, is also updated to be no less than the current time plus ACTIVE_ROUTE_TIMEOUT. In the case of symetric links and in view that's the most propable case. >From my understanding, always source, destination and both next hops toward them are updated! Although the IP address from the next hops are only available from the routing table. Therfore we might updating stale entries: This leads to described exipration problem, isn't it? Cheers Erik > > > > >From: "Erik Weiss, ComNets" > >To: manet@ietf.org > >Subject: [manet] Question for: AODV Local Repair > >Date: Fri, 28 Mar 2003 09:54:40 +0100 (CET) > > > > > >Hi all, > > > >i have a question about AODV Local Repair, > > > >Considering the following case: > > > >This Route was built: > > > >(8) -> (9) -> (3) -> (4) -> (5) > > > >Now the node 5 moves and 4 initiates a local repair, it will end up > >something like the following. > > > >Expected 4 sends the RREQ for Dest 5 > >(8) -> (9) -> (3) -> (4) -> (7) -> (5) > > > > > >Now 7 got the request originated by 4 and with 7, the destination(5) is > >reachable again. > >However 7 didn't have the source node (8) in its routing table, because > >the RREQ has been sent by 4, therefore also no next hop towards the source > >exists, and the reverse path is not properly build! > >Each Paket arriving 7 from 8 does not update the times for source (8) and > >next hop (7) towards (8). > >Further more the routing table entry for (4) will expire although we are > >receiving continuously packets from 4. > > > >Possible but complex alternative: > >4 sends the RREQ on behalf of 8 however, temporary routing > >tables and special handling for Request Id's will become necessary. > > > > > >Are these consideration right? > >Can someone give me a hint how (4) is able to repair the route without > >losing the reverse path and without the upcomig expiration of 4. > > > > > > > >Regards > > > > Erik > > > > > >_______________________________________________ > >manet mailing list > >manet@ietf.org > >https://www1.ietf.org/mailman/listinfo/manet > > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 28 16:08:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18916 for ; Fri, 28 Mar 2003 16:08:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SLUsJ08139 for manet-archive@odin.ietf.org; Fri, 28 Mar 2003 16:30:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SLUsO08136 for ; Fri, 28 Mar 2003 16:30:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18876 for ; Fri, 28 Mar 2003 16:08:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SLI0O07472; Fri, 28 Mar 2003 16:18:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SLC9O07244 for ; Fri, 28 Mar 2003 16:12:09 -0500 Received: from tomts11-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18192 for ; Fri, 28 Mar 2003 15:49:42 -0500 (EST) Received: from yahoo.com ([65.93.182.118]) by tomts11-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030328205205.CMFJ1369.tomts11-srv.bellnexxia.net@yahoo.com> for ; Fri, 28 Mar 2003 15:52:05 -0500 Date: Fri, 28 Mar 2003 15:52:05 -0500 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: S Woodside To: manet@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <220081FD-615F-11D7-AFCA-000393414368@yahoo.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [manet] Hi there Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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'd like to introduce myself on this list. The reason I joined is that I'm interested in community wireless networks (CWNs) and in particular fixed mesh approaches for CWNs. There's a whole bunch of motivation not only in the "West" but also in developing nations where CWN might be the best way to get broadband (or access at all). Basically any rural area. I've got a nice list of "impossible things to do before breakfast" as some of my friends tell me ... including arbitrary multihoming of mesh nodes, routing internet traffic through the mesh, and self-configuration. In any case, I hope that is an OK topic to bring up on this list, I was pointed here by a few folks. simon -- www.simonwoodside.com -- 99% Devil, 1% Angel _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Fri Mar 28 18:21: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 SAA25295 for ; Fri, 28 Mar 2003 18:21:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2SNhkQ19190 for manet-archive@odin.ietf.org; Fri, 28 Mar 2003 18:43:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SNhkO19187 for ; Fri, 28 Mar 2003 18:43:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25287 for ; Fri, 28 Mar 2003 18:21:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SNRxO17339; Fri, 28 Mar 2003 18:27:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2SN9XO16077 for ; Fri, 28 Mar 2003 18:09:33 -0500 Received: from mailhost.iprg.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22625 for ; Fri, 28 Mar 2003 17:47:03 -0500 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA12460; Fri, 28 Mar 2003 14:49:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2SMnPe27786; Fri, 28 Mar 2003 14:49:25 -0800 X-mProtect: <200303282249> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduy7WXw; Fri, 28 Mar 2003 14:49:24 PST Message-ID: <3E84D174.1018C2BE@iprg.nokia.com> Date: Fri, 28 Mar 2003 14:49:24 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: S Woodside CC: manet@ietf.org Subject: Re: [manet] Hi there References: <220081FD-615F-11D7-AFCA-000393414368@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Simon, > Hi, I'd like to introduce myself on this list. The reason I joined is > that I'm interested in community wireless networks (CWNs) and in > particular fixed mesh approaches for CWNs. There's a whole bunch of > motivation not only in the "West" but also in developing nations where > CWN might be the best way to get broadband (or access at all). > Basically any rural area. I've got a nice list of "impossible things to > do before breakfast" as some of my friends tell me ... including > arbitrary multihoming of mesh nodes, routing internet traffic through > the mesh, and self-configuration. I think that all of these things are possible using published Internet Drafts. There is downloadable software from LocustWorld that offers features compatible with your objectives. For Internet access, one of the ad hoc nodes has to agree to be a gateway, and to advertise a routing prefix for use by the ad hoc nodes. There are drafts for IPv4 and for IPv6: http://www.ietf.org/internet-drafts/draft-royer-manet-globalv4-00.txt http://www.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-02.txt For autoconfiguration, a node can basically pick an address and try to discover a route to that address. If no route exists, then the node views the address as unclaimed and autoconfigures it. Please see: http://people.nokia.net/~charliep/txt/aodvid/autoconf.txt If a node has an Internet address, it should be able to continue using it in the ad hoc network. If the ad hoc network has a connection to the Internet, the node should be able to run Mobile IP{,v6} to continue seamless connectivity with the Internet using its home address. Prototype systems have been built to show this. I think this means that your expectations are in line with current capabilities. Unfortunately, standards for these features are nowhere near being published. It seems that things are slowing down in the IETF. I don't see multihoming as an issue, as long as ad hoc routes are not allowed to escape into the Internet routing fabric. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 31 00:04:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13500 for ; Mon, 31 Mar 2003 00:04:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2V5RwM25113 for manet-archive@odin.ietf.org; Mon, 31 Mar 2003 00:27:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V5RwO25110 for ; Mon, 31 Mar 2003 00:27:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13467 for ; Mon, 31 Mar 2003 00:04:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V54PO23424; Mon, 31 Mar 2003 00:04:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V4dDO22832 for ; Sun, 30 Mar 2003 23:39:13 -0500 Received: from xenia.media.mit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12601 for ; Sun, 30 Mar 2003 23:15:40 -0500 (EST) From: ankur.j@media.mit.edu Received: from MAP11 ([203.145.171.34]) by xenia.media.mit.edu (8.12.8/8.12.8/XENIA) with ESMTP id h2V4Hqaf289509 for ; Sun, 30 Mar 2003 23:18:01 -0500 (EST) Reply-To: To: Date: Mon, 31 Mar 2003 09:49:26 -0800 Organization: Media Lab Asia Message-ID: <000601c2f7ad$e7019a40$8401a8c0@MAP11> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [manet] Interlayer Interactions Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 This is regarding the interlayer interactions in the case of ad hoc networks. I think that if there is some mechanism that can give bidirectional status messages between MAC layer-IP layer and IP layer-Transport Layer, then we can take more intelligent (and faster) routing decisions. Moreover, congestion can be better signaled at Transport layer. In wireless networks, there are more packet losses due to link failure than the congestion in the network. So, we can send a signal from lower layer about the status of link. So, TCP doesn't have to backup of thinking that it's a packet loss. We can also add some mechanism on the lines of Snoop. That will give a lot of flexibility and will help in making better decisions at all layers. I wanted to know if there is any active research going on in this field (apart from the discussion on this mailing list in last few days). Can anybody send me useful links about this. Regards, Ankur _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 31 01:27: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 BAA15269 for ; Mon, 31 Mar 2003 01:27:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2V6ov330717 for manet-archive@odin.ietf.org; Mon, 31 Mar 2003 01:50:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V6ouO30714 for ; Mon, 31 Mar 2003 01:50:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15256 for ; Mon, 31 Mar 2003 01:27:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V6JaO28542; Mon, 31 Mar 2003 01:19:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V60gO27180 for ; Mon, 31 Mar 2003 01:00:42 -0500 Received: from gandalf.icr.a-star.edu.sg ([137.132.31.244]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14256 for ; Mon, 31 Mar 2003 00:37:05 -0500 (EST) Received: from mailer.icr.a-star.edu.sg (mailer.icr.a-star.edu.sg [137.132.31.243]) by gandalf.icr.a-star.edu.sg (8.12.8+Sun/8.12.2) with ESMTP id h2V5VgGi012083 for ; Mon, 31 Mar 2003 13:31:42 +0800 (SGT) Received: from localhost.localdomain ([172.16.2.215]) by mailer.icr.a-star.edu.sg; Mon, 31 Mar 2003 13:23:37 +0800 Received: by localhost.localdomain (Postfix, from userid 1000) id 9074A3055A; Mon, 31 Mar 2003 13:30:56 +0800 (SGT) Date: Mon, 31 Mar 2003 13:30:56 +0800 From: Sukanta Kumar Hazra To: manet@ietf.org Subject: Re: [manet] Interlayer Interactions Message-ID: <20030331053056.GA6769@localhost> Mail-Followup-To: manet@ietf.org References: <000601c2f7ad$e7019a40$8401a8c0@MAP11> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000601c2f7ad$e7019a40$8401a8c0@MAP11> User-Agent: Mutt/1.4i Organization: Institute for Infocomm Research Phone: +65 68709338 PGP-KEY: http://www.icr.a-star.edu.sg/~sukanta/skhkey.asc PGP-ID: 0x8E084AD5 Key-Fingerprint: 9C0D B00C C62A 7059 5314 99FC CE90 478A 8E08 4AD5 Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , > > This is regarding the interlayer interactions in the case of ad hoc > networks. I think that if there is some mechanism that can give > bidirectional status messages between MAC layer-IP layer and IP > layer-Transport Layer, then we can take more intelligent (and faster) > routing decisions. Goes back to question whether clear protocol layer seperation is something that must guide our work in MANET, or should be take advantage of the benefits provided by cross layer interactions to improve performance. I support the latter, but I have heard many convincing arguments of the former as well. > > Moreover, congestion can be better signaled at Transport layer. In > wireless networks, there are more packet losses due to link failure than > the congestion in the network. So, we can send a signal from lower layer > about the status of link. So, TCP doesn't have to backup of thinking > that it's a packet loss. In a multihop case, how does the TCP sender get the signal if the first hop is good but the last hop is not. Do you mean the TCP sender will know the link status of all the hops in the path? If wireless is being used only in the last hop, then yes congestion is not the main factor for packet drop. I am just wondering if that case is always true in a multihop wireless network such as MANET. - Sukanta _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 31 02:47:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28528 for ; Mon, 31 Mar 2003 02:47:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2V8Abt14899 for manet-archive@odin.ietf.org; Mon, 31 Mar 2003 03:10:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V8AaO14896 for ; Mon, 31 Mar 2003 03:10:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28521 for ; Mon, 31 Mar 2003 02:46:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V7bVO12030; Mon, 31 Mar 2003 02:37:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2V7K3O10316 for ; Mon, 31 Mar 2003 02:20:03 -0500 Received: from smtp1.utdallas.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15814 for ; Mon, 31 Mar 2003 01:56:25 -0500 (EST) Received: from infoserv.utdallas.edu (infoserv.utdallas.edu [129.110.16.2]) by smtp1.utdallas.edu (Postfix) with ESMTP id 8EABE388CD6; Mon, 31 Mar 2003 00:58:50 -0600 (CST) Received: from localhost (sanket@localhost) by infoserv.utdallas.edu (8.11.6+Sun/8.9.0) with ESMTP id h2V6woj27768; Mon, 31 Mar 2003 00:58:50 -0600 (CST) X-Authentication-Warning: infoserv.utdallas.edu: sanket owned process doing -bs Date: Mon, 31 Mar 2003 00:58:50 -0600 (CST) From: Sanket Nesargi To: ankur.j@media.mit.edu Cc: manet@ietf.org Subject: Re: [manet] Interlayer Interactions In-Reply-To: <000601c2f7ad$e7019a40$8401a8c0@MAP11> 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: , Ankur, There was work done on this by our lab a couple of years back. K. Chandran, S. Raghunathan, S. Venkatesan, and R. Prakash. A Feedback Based Scheme for Improving TCP Performance in Ad Hoc Networks. IEEE Personal Communication Systems (PCS) Magazine: special issue on Ad Hoc Networks, Volume 8, Number 1, Pages 34--39, February 2001 http://www.utdallas.edu/~ravip/papers/tcpf.icdcs98.pdf It relies on feedback from underlying layers to improve the performance of TCP in ad hoc networks. Thanks, - Sanket On Mon, 31 Mar 2003 ankur.j@media.mit.edu wrote: > > This is regarding the interlayer interactions in the case of ad hoc > networks. I think that if there is some mechanism that can give > bidirectional status messages between MAC layer-IP layer and IP > layer-Transport Layer, then we can take more intelligent (and faster) > routing decisions. > > Moreover, congestion can be better signaled at Transport layer. In > wireless networks, there are more packet losses due to link failure than > the congestion in the network. So, we can send a signal from lower layer > about the status of link. So, TCP doesn't have to backup of thinking > that it's a packet loss. > > We can also add some mechanism on the lines of Snoop. That will give a > lot of flexibility and will help in making better decisions at all > layers. > > I wanted to know if there is any active research going on in this field > (apart from the discussion on this mailing list in last few days). Can > anybody send me useful links about this. > > Regards, > Ankur > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > --------------------------------------------------------------------- All the world's indeed a stage and we are merely players, performers and portrayers, each another's audience outside the gilded cage. Sanket S. Nesargi Distributed Systems Lab University of Texas at Dallas, Richardson TX 75082 --------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 31 18:11:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01160 for ; Mon, 31 Mar 2003 18:11:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2VNYau26846 for manet-archive@odin.ietf.org; Mon, 31 Mar 2003 18:34:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNYaK26843 for ; Mon, 31 Mar 2003 18:34:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00925 for ; Mon, 31 Mar 2003 18:10:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VNGhK26069; Mon, 31 Mar 2003 18:16:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VMcIK24061 for ; Mon, 31 Mar 2003 17:38:18 -0500 Received: from s2.itd.nrl.navy.mil (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27962; Mon, 31 Mar 2003 17:14:20 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.12.8+Sun/8.12.8) with ESMTP id h2VMGkjZ002044; Mon, 31 Mar 2003 17:16:46 -0500 (EST) Received: from smtp.itd.nrl.navy.mil (localhost [127.0.0.1]) by smtp.itd.nrl.navy.mil (8.12.8+Sun/8.12.2) with SMTP id h2VMGeWi010931; Mon, 31 Mar 2003 17:16:41 -0500 (EST) Received: from SEXTANT.itd.nrl.navy.mil ([132.250.92.22]) by smtp.itd.nrl.navy.mil (SAVSMTP 3.1.0.29) with SMTP id M2003033117164009711 ; Mon, 31 Mar 2003 17:16:40 -0500 Message-Id: <5.1.1.5.2.20030331171515.033b7a28@pop.itd.nrl.navy.mil> X-Sender: macker@pop.itd.nrl.navy.mil X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 31 Mar 2003 17:15:56 -0500 To: minutes@ietf.org From: Joe Macker Cc: manet@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VMcJK24062 Subject: [manet] Manet minutes Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@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 56th IETF MANET Working Group Minutes 20 March 2003 Thanks to Brian Adamson for scribing the general meeting minutes. -------------------------------------------------------------- Mobile Ad Hoc Networks (manet) Agenda Thursday, Mar , 1500-1700 1. Agenda Bashing (5 min) 2. Review of Charter/Milestone and IRTF Update (10 min) Working Document Progress Updates 3. AODV Update (20 min) 4. DSR Update (20 min) 5. OLSR Update (20 min 6. TBRPF Update (20 min) 7. Further Progression of Documents (5 min) 8. Next Steps: Problem Statement Consensus and Standards Track Approach (20 min) --------------------------------------------------------------- Joe Macker (WG co-chair) presented the meeting agenda. Scott Corson (WG co- chair) was absent from this meeting. Rechartering Review (see updated IETF website) Joe Macker next presented the MANET rechartering status. A new charter and updated milestones have been approved and posted. In reviewing the charter text, it was pointed out IESG input added an item concerning congestion control of MANET routing protocols to the working group charter goals. There was Chair and WG consensus that the statement in the charter concerning this should be clarified. (I.e. make it clear that the congestion control mentioned does not imply “TCP fairness” but instead is intended to make sure that “implosion” avoidance of routing control, etc is addressed … and the protocols’ performance issues in these regards are understood.) An overview of the interim working group goals and milestones was provided. It was announced that the IESG had approved AODV for Experimental and that it should be in process with the RFC Editor. IRTF Update Elizabeth Belding-Royer provided an overview of IRTF Ad hoc Network Scaling (ANS). Contact and mailing list information was provided. Both Elizabeth and Scott Corson will be serving as co-chairs. See the IRTF ANS Website: http://ww.flarion.com/ans-research IRTF ANS goals were presented. Scalability with an emphasis on developing metrics for assessing protocol performance is a primary focus. There was some discussion concerned what problem spaces would be taken on within the IRTF. A “Bar BOF” was announced in the evening of 9:30 PM, 20 March 2003 to gather more interest and feedback for IRTF ANS topics, goals, etc. Hilton San Francisco hotel bar will be the location. The first intended ANS meeting was announced to take place with the ACM Mobihoc conference: Sunday 7-10PM 1 June, location Annapolis, Maryland with Mobihoc. AODV Status Charlie Perkins presented an AODV update. There were a few changes to the document as it made its way through the recent IESG review. There was added clarification for handling subnet routes. It was clarified that subnet routes are handled the same as host routes. If a specific host on a subnet is unreachable, the subnet leader may send an ICMP “host unreachable” instead of a route error message for the particular subnet host(s). Editorial changes, applicability statement, IANA considerations, etc. DSR Status Dave Johnson presented an update on the DSR ID status. A small number of changes occurred, mainly some rearrangement and integration. An optional flow state extension was, however, added back into the draft where it was previously in a separate “DSR Flow” draft. Q: If you lose the first packet with the full source route, what happens? A: A route error is sent back on packets with unknown flow id. Q: Is the interim packet loss a concern? A: DSR salvaging usually handles this and there are documented studies of packet delivery ratios. OLSR Status Thomas Clausen (INRIA) presented an update on the OLSR ID status. A recent ID was posted and included a number of changes, most of which were editorial and involved reorganization of the document to improve readability. A clarification was provided regarding the handling and discussion of multiple interfaces. Also, the document now clearly separates auxiliary features such as host/network association messages from core protocol features. A “validity time” has been added to the messages. One mistake was made in that proper updating of the internal routing table with 2-hop information was accidentally dropped in the transition from version 7 to version 8 of the spec. This will fixed ASAP. Thomas indicated that there have been a number of reviews and comments already since the version 8 draft release. What next? Chair comment: Single interface and multiple interface sections are pretty redundant. Could be integrated? Document would shorter, simpler. A: Yes with the consensus of the working group this could be done. Chair Comment: “Willingness” parameter can be zero and this MAY affect some of the election algorithms, state maintenance, etc. Recommend doublechecking this. A: Agreed. Thomas: Feels document is ready to move forward to Exp. RFC pending integrating current feedback and comments. The Working Chair recommended an additional quick revision cycle (or explanation of known changes) to provide working group members a little more time for review and input. Thomas: Will commit to quick turn-around. AD Comment: Read ID guidelines, etc to quickly meet IESG requirements. Thomas: Can the ADs review the current security considerations to help with this? AD: Yes. TBRPF Status Richard Ogier presented a TBRPF ID update. The document now references the Secure Neighbor Discovery (SEND) working group. Richard feels document is ready for Exp. RFC submission. Richard Ogier went on to present suggestions for merging proactive routing protocol ideas. Chair comments: With regards to not sending periodic topology updates when there are no topology changes? With regards to protocol robustness what is the current level of understanding, while a good scalability idea, is robustness questionable? … a lost update is now a more significant problem to be resolved. Agreed it is worth further discussion. There was some discussion among the OLSR and TBRPF authors that they were attempting to work together. An IPR discussion ensued relating to people’s level of comfort in working together on a future document. The authors were attempting to work these issues out. Further Work Strategy Joe Macker presented some strawman discussion topics for future work strategies. First and foremost the WG needs the authors’ commitment to revise the documents as needed and address any issues with present upcoming submission goals. We would like to see WG last call inputs occurring within 2 weeks or so. Relating to the chair’s schedule issues, most authors indicated a commitment to quickly respond to WG input. Upcoming WG issues beyond progression of the current documents are: - some level of problem statement consensus. - IETF vs. IRTF problem split considerations. - agreement on consensus-based engineering approach. Discussion ensued including any relationship with the previously briefed OSPFv3 with manet extensions work (Fred Baker). It was stated any proposals like this would be further brought up within the OSPF WG for possible consideration first. The chair and others expressed interest in this related work but the proper forum and scope had not been identified. This was not seen as a replacement for the manet routing work ongoing, but may provide some practical application. Relating to security it was stated that some degree of further threat assessment should be developed for helping in understanding MANET security considerations. WG Comment: Many of the ongoing security working areas need people with wireless experience involved. Suggest interested parties get involved. Ongoing work in more distributed security and routing area solutions may likely apply. The chair asked the WG to begin considering the details of appropriate engineering issues for the next phase of work. Open Discussion There was some discussion of a common problem statement understanding. Using numbers of nodes was considered non-exact because of the numerous problem dimensions involved in any performance scenario. The chair also commented that the WG should avoid the “bakeoff contest” method since this tended to stimulate more research-oriented approaches in the past and less group-based engineering. Comment: Need typical example networks in mind or we go down the rathole of the past. Chair: Agreed. Need some level of applicability and problem statement understanding is needed. Comment: There appears to be some competitive spirit here for what follows, but collaboration requires something different … what are thoughts on the overall architecture. Will the working group be split up into sub-components to tackle different areas? Chair: We’re not all going to agree 100% … we need to find the common overlapping areas through discussion and focus on core components that can be engineered…we will then build off “lessons learned” to date. Comment: Believes “component based architecture” can help the group to work together. Other WG comment: Agrees we need a family of components to work together … including support for connection/gateway to the Internet … More WG comments were raised relating to the specific approach that could be taken. Chair: Don’t forget, while I am sensing among some members a reluctance to target the simpler problem space, we presently don’t have “Standard” ways to do manet routing … even for small networks with moderate mobility…that would be useful specification output from this group (this group has already produced useful experimental output and a set of working prototype implementations) … but at the same time any design shouldn’t preclude the ability to scale well through design extensions (e.g., fuzzy-sighted link state extension) or simply based upon inherent design properties, etc. ultimately good core designs should be extensible and also work reasonable well on a moderate scale without extensions. Q: Are we committed to two protocols classes (proactive, reactive)? Chair: This is undecided … it is one taxonomy to consider (and has some rationale based upon previous WG development and work elements), but hybrid behavior and others issues may be addressed making the taxonomy less accurate. It is up to the WG to discuss what seems sensible in the near future … it is likely that “one size fits all” won’t make it, but the solution space should perhaps be limited to two at most … At this point, the meeting was adjourned. The chair asked the presenters to please submit their slides electronically if they had not already done so. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From mailnull@www1.ietf.org Mon Mar 31 23:28:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09891 for ; Mon, 31 Mar 2003 23:28:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h314phY15526 for manet-archive@odin.ietf.org; Mon, 31 Mar 2003 23:51:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h314phK15523 for ; Mon, 31 Mar 2003 23:51:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09881 for ; Mon, 31 Mar 2003 23:27:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h314WpK13762; Mon, 31 Mar 2003 23:32:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h314RKK13568 for ; Mon, 31 Mar 2003 23:27:20 -0500 Received: from web20109.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09469 for ; Mon, 31 Mar 2003 23:03:15 -0500 (EST) Message-ID: <20030401040541.25535.qmail@web20109.mail.yahoo.com> Received: from [130.203.18.28] by web20109.mail.yahoo.com via HTTP; Mon, 31 Mar 2003 20:05:41 PST Date: Mon, 31 Mar 2003 20:05:41 -0800 (PST) From: Siddharth Ray To: manet@ietf.org Subject: [manet] Simulating in Glomosim Sender: manet-admin@ietf.org Errors-To: manet-admin@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobile Ad-hoc Networks List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii I am implementing "Mitigating routing misbehavior in mobile ad hoc networks" using Glomosim. I am having doubts regarding how to use glomosim i.e., how to implement a credit based system which I plan to use in the code i.e., which part of the code to change. Altough I am having many ideas but am having trouble with the simulator. I would really appreciate any help... Siddharth Ray ===== "Keep me away from the wisdom which does not cry, the philosophy which does not laugh and the greatness which does not bow before children." - Kahlil Gibran MS, Department of Computer Sc. & Engg, Pond Lab, State College, PA - 16802, USA. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet