From manet-bounces@ietf.org Sun Apr 01 17:11:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY7IE-0006yO-R6; Sun, 01 Apr 2007 17:08:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY7IE-0006yH-74 for manet@ietf.org; Sun, 01 Apr 2007 17:08:54 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY7I3-0001ed-LV for manet@ietf.org; Sun, 01 Apr 2007 17:08:53 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1293682ugd for ; Sun, 01 Apr 2007 14:08:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:cc:subject:date:organization:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole:sender; b=SnXVRakGuXyp0Oh37lXV2eA4cFV15c5GjPuP6zpoqlmA6wFu1I/7VBLge1ifZ9PvhayxgOWSA6H65qwDeIppVKl/KBAsIaQ0wWbn1FFqUflCU3rQW2qWHHoZ2Dq0Ta8q4ESE199xPWgetQVd1A+dxjWvrS7V9R3DGq+qIzb1oqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:cc:subject:date:organization:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole:sender; b=iROm/BtP6/6348Ca5qNMBWcz9XQV1hUHPj50jHIuFUkaSrI8woq6keYw1MIWrUErBiLSgTQWREdEZqxNEb9ZUhqN3892t7ndXvNzc4SlYsKQ5KYms+UYnf3b3eg/Krl7jjANgoUdMgnW3WlKp8WIux0ldiZDfw3n4UPls7io0pA= Received: by 10.78.142.14 with SMTP id p14mr135198hud.1175461720418; Sun, 01 Apr 2007 14:08:40 -0700 (PDT) Received: from simula073 ( [193.157.236.253]) by mx.google.com with ESMTP id w5sm17124333mue.2007.04.01.14.08.38; Sun, 01 Apr 2007 14:08:39 -0700 (PDT) From: "Yan ZHANG" To: Date: Sun, 1 Apr 2007 23:08:35 +0200 Organization: Simula Research Laboratory, Norway Message-ID: <000901c774a1$eb7f65a0$fdec9dc1@simula.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd0mhqqcQKR7obrSE6RJIgveTIoDg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: hshwchen@ieee.org, 'Mohsen Guizani' Subject: [manet] [CFP] Call for Book Chapter on Cooperative Wireless Communications X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yanzhang@ieee.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org [Please accept our apologies if you receive multiple copies of this emails] CALL FOR BOOK CHAPTER Title: Cooperative Wireless Communications (to be published by Auerbach Publications, Taylor&Francis Group http://www.crcpress.com/) http://home.simula.no/~yanzhang/CooperativeWCCFP.html Introduction ============ Cooperative mechanisms are becoming increasingly important in wireless communications and networks to substantially enhance system performance with respect to much less power consumption, higher system capacity, smaller packet loss rate and higher network resilience. The concept cooperation can be applied in a variety of wireless systems and networks. The idea of cooperation can be traced back to the information theory investigation on relay channel in cellular network. Recently, the standard IEEE 802.16 WiMAX for future Broadband Wireless Access (BWA) established the 802.16j Relay Task Group to incorporate the cooperative relaying mechanism. In addition, the strategy of cooperation is believed to be even more suitable and have wider applications in mobile ad hoc networks, wireless mesh networks and sensor networks. The concept cooperation is widely applicable in addressing a number of different issues. From the system point of view, since Mobile Station (MS) has limitations in single antenna, power, cost and hardware, it is infeasible to use MIMO technology in MS. The cooperative communication explores the benefits of multi-user environment by creating a virtual MIMO system. For the protocol issues, the idea of cooperation can be found in designing and implementing routing, MAC, location management, resource allocation, scheduling, energy management, and packet forwarding. The objective of this book is going to systematically introduce and discuss various cooperative strategies in wireless communications and networks. This book provides readers with a comprehensive technical, practical, and deploying guidance in general on the cooperative strategies in wireless communications as well as the latest IEEE standard specifications. The subject will be explored with various key challenges and cooperative solutions in 3G, B3G, 4G, WiMAX, ad hoc networks, mesh networks, and sensor networks. Recommended Topics(not limited to) ================================== Cooperative diversity Virtual MIMO Channel capacity Cooperative channel coding Cooperative mechanisms in cognitive radio networks (e.g. Spectrum sensing, spectrum sharing) Performance analysis, simulation and experiment Services, applications and systems Testbed, prototype, practical system and case studies Resource management Mobility management Energy management Cross-layer cooperation and optimization Cooperative and distributed relaying Routing, packet forwarding, multicast Cooperative MAC protocol Power control Network Coding Security architecture and mechanisms QoS provisioning Topology control Cooperative schemes in Wireless PAN, LAN, MAN Copperative schemes in B3G, 4G System Cooperative schemes in wireless ad hoc, mesh and sensor networks peer-to-peer networks Cooperative schemes in IEEE 802.x families, e.g. 802.11, 802.15, 802.16, 802.20 Important Dates ================ * Submission of chapter proposal: 30, June 2007 (You are invited to submit a 1-2 pages proposal discribing the topic of your chapter. The proposal should include the chapter organization, number of pages of the final manuscript and contact authors. ) * Notification of proposal acceptance: 30, July 2007 * Full chapter submission: 30, Oct. 2007 * Review report received: 30, Dec. 2007 * Final version submission: 28, Feb. 2007 Manuscript Submission ===================== Set as double-spaced Estimated, each chapter should has about 35 pages with double-space format. ***Note***: each lead chapter author will get a free copy of the book. Contact ======= Please make correspondence and paper submissions to: Dr. Yan ZHANG Simula Research Laboratory, Norway Email: yanzhang@ieee.org Dr. Hsiao-Hwa Chen National Sun Yat-Sen University, Taiwan Email: hshwchen@ieee.org Dr. Mohsen Guizani Western Michigan University, USA Email: mguizani@cs.wmich.edu _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 02 02:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFtp-0002gk-NY; Mon, 02 Apr 2007 02:20:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFto-0002gc-ID for manet@ietf.org; Mon, 02 Apr 2007 02:20:16 -0400 Received: from insomnia.liquidweb.com ([64.91.225.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYFtk-0008Su-4c for manet@ietf.org; Mon, 02 Apr 2007 02:20:16 -0400 Received: from confprom by insomnia.liquidweb.com with local (Exim 4.63) (envelope-from ) id 1HYFtU-0006ms-DM; Mon, 02 Apr 2007 02:19:56 -0400 Received: from 213.47.231.184 ([213.47.231.184]) (SquirrelMail authenticated user andy@confpromo.com) by www.confpromo.com with HTTP; Mon, 2 Apr 2007 02:19:56 -0400 (EDT) Message-ID: <2132.213.47.231.184.1175494796.squirrel@www.confpromo.com> Date: Mon, 2 Apr 2007 02:19:56 -0400 (EDT) From: andy@confpromo.com To: manet@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - insomnia.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32132 32133] / [47 12] X-AntiAbuse: Sender Address Domain - confpromo.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.2 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: pdini@cisco.com Subject: [manet] SENSORCOMM 2007 & SECURWARE 2007 || October 14-20, 2007 || Valencia, Spain X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Call for Papers: SENSORCOMM 2007 & SECURWARE 2007, Valencia, Spain SUBMISSION DEADLINE: May 1, 2007 Invitation: Please consider contributing to the conferences SENSORCOMM 2007 and SECURWARE 2007, as well as the associated workshops listed below. October 14-20, 2007, Valencia, Spain Please forward the Call for Submissions to the appropriate groups. =============================== CALL FOR PAPERS, PANELS, TUTORIALS SENSORCOMM 2007, The First International Conference on Sensor Technologies and Applications http://www.iaria.org/conferences2007/SENSORCOMM07.html SECURWARE 2007, International Conference on Emerging Security Information, Systems and Technologies http://www.iaria.org/conferences2007/SECURWARE07.html _____________________________________ ________________________________ Important deadlines: Submission deadline May 1, 2007 Notification of acceptance June 2, 2007 Registration/camera ready June 15, 2007 ______________________________________________________________ Featuring the workshops: - PRODAM 2007: International Workshop on Profiling Data Mining http://www.iaria.org/conferences2007/PRODAM.html - SECHOME 2007: International Workshop on Advances in Smart Home Security http://www.iaria.org/conferences2007/SECHOME.html - SECDYN 2007: International Workshop on Security and Privacy in Dynamic Environments http://www.iaria.org/conferences2007/SECDYN.html - ENOPT 2007 : International Workshop on Energy Optimization in Wireless Sensors Networks http://www.iaria.org/conferences2007/ENOPT.html - UNWAT 2007 : International Workshop on Under Water Sensors and Systems http://www.iaria.org/conferences2007/UNWAT.html ______________________________________________________________ Conference Topics: SENSORCOMM Tracks (details in the CfP on site) APASN: Architectures, protocols and algorithms of sensor networks MECSN: Energy, management and control of sensor networks RASQOFT: Resource allocation, services, QoS and fault tolerance in sensor networks PESMOSN: Performance, simulation and modelling of sensor networks SEMOSN: Security and monitoring of sensor networks SECSED: Sensor circuits and sensor devices RIWISN: Radio issues in wireless sensor networks SAPSN: Software, applications and programming of sensor networks DAIPSN: Data allocation and information in sensor networks DISN: Deployments and implementations of sensor networks ======================================== SECURWARE Tracks (details in the CfP on site) ARCH: Security frameworks, architectures and protocols SECMAN: Security management SECTECH: Security technologies SYSSEC: System security INFOSEC: Information security THREATS: Security threats ANTIFO: Anti-forensic ======================================== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 02 05:12:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYIYd-00026c-GR; Mon, 02 Apr 2007 05:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYIYb-00026R-N2; Mon, 02 Apr 2007 05:10:33 -0400 Received: from mail.di.uniroma1.it ([151.100.17.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYIYZ-0003Hg-Si; Mon, 02 Apr 2007 05:10:33 -0400 Received: from [151.100.17.90] (unknown [151.100.17.90]) by mail.di.uniroma1.it (Postfix) with ESMTP id 442F31BD645; Mon, 2 Apr 2007 10:59:32 +0200 (CEST) Message-ID: <4610C872.1060303@di.uniroma1.it> Date: Mon, 02 Apr 2007 11:10:10 +0200 From: Gaia Maselli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: it, it-it, en-us, en MIME-Version: 1.0 To: manet@ietf.org, mip4@ietf.org, avt@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Subject: [manet] ACM/SIGMOBILE HEALTHNET 2007: Deadline is fast approaching! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: maselli@di.uniroma1.it List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org (Apologies for multiple reception of this CFP) **** DEADLINE APPROACHING **** ============================================================ Call for Papers ACM/SIGMOBILE HealthNet 2007 The 1st International Workshop on Systems and Networking Support for Healthcare and Assisted Living Environments http://healthnet07.cs.uiuc.edu In conjunction with MobiSys 2007 June 11, 2007 Puerto Rico, USA EXTENDED DEADLINE: APRIL 6, 2007 (5PM US EST) Selected papers will be considered for fast track publication in a special issue of ACM Monet. ============================================================ WORKSHOP SCOPE: ================ As the world's population grows older, healthcare and high-tech companies are joining forces. New technologies are being used to provide improved support for elderly and home bound people in their homes and in assisted living environments. The overall goal of these initiatives is to improve the quality of life by providing customized support to people in need of assistance. The main challenge is to provide this support according to the user's own specific situation in a non-intrusive and respectful way. These new technologies enable the automation of the observation and support for elderly and home bound people through the use of sensors, actuators, distributed intelligence, databases, ubiquitous connectivity and friendly adaptive interfaces, all connected mainly via a variety of wireless networking technologies. The ultimate goal is a system that can adapt to the users needs, helping them get through their daily routine in a way that is effective in providing support where needed without making them feel humiliated by excessive attention. To provide such support, it will be necessary to combine efforts from many areas of computer science, including networking, distributed systems, security, data management, HCI, AI and middleware. Given the inherent use of mobile and wireless communication and the need for comprehensive distributed systems as well as the multi-disciplinary nature of solutions for healthcare and assisted living environments, the goal of HealthNet is to provide a forum for the cross-area interactions that will be necessary for successful systems and applications. The specific focus of HealthNet will be on understanding what it takes to provide effective systems and communication support for healthcare and assisted living environments. Although the systems and networking community is very good at providing effective solutions to satisfying application requirements, they require input from experts in other disciples, including HCI, middleware, security, privacy and social networking, to provide a more accurate understanding of the specific requirements for these environments. Therefore, HealthNet aims to attract researchers working on cross-disciplinary projects, with a focus on understanding and supporting the requirements of these complex applications. Authors are invited to submit papers presenting new research related to the support of healthcare and assisted living environments. All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. Areas of interest include, but are not limited to: * Enabling technologies * Service and device discovery * Security and privacy * Reliability and fault tolerance * User and device localization * Resource management architecture * User data management * Middleware for heterogeneous networks * Mobility and connectivity management * Cross-layer system architecture design * Human-centered Computing * Task and behavior analysis * Impact of user interface design on system design and management * Test-beds and simulations environments IMPORTANT DATES: ================ Paper submission deadline: March 23, 2007 ***** EXTENDED TO APRIL 6, 2007 (5PM US EST) ****** Notification of acceptance: April 27, 2007 Camera ready version due: May 17, 2007 Workshop date: June 11, 2007 PAPER SUBMISSION INSTRUCTIONS: =============================== All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 6 pages, double-column, with a font size no smaller than 10 points, and must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. The first page of each paper should include the names and affiliations of the authors, i.e., the submissions should not be anonymous and reviewing is single-blind. Submissions will be judged on based on technical content and correctness, relevance to the workshop, as well as presentation of the research. Extended versions of selected workshop papers will be considered for fast track publication in a special issue of ACM Monet. ORGANIZING COMMITTEE ==================== WORKSHOP Co-Chairs: * Robin Kravets, University of Illinois, USA * Chiara Petrioli, Rome University "La Sapienza," Italy PUBLICITY Co-Chairs: * Stefano Basagni, Northeastern University, USA * Gaia Maselli, Rome University "La Sapienza," Italy TECHNICAL PROGRAM COMMITTEE * Amy Murphy, IRST-ITC * Archan Misra, IBM * Gene Tsudik, ISI * Hans Gellersen, Lancaster University * Henry Kautz, University of Rochester * Jack Stankovic, University of Virginia * Jean-Pierre Ebert, IHP Microelectronics * Karrie Karahalios, University of Illinois * Kay Connelly, Indiana University * Maria Ebling, IBM * Martha Pollack, University of Michigan * Nigel Davies, Lancaster University * Sunny Consolvo, Intel * Taieb Znati, University of Pittsburgh * Tarek Abdelzaher, University of Illinois * Wendi Heinzelman, University of Rochester * Yih-Chun Hu, University of Illinois Please email questions related to paper submission or the technical program to: healthnet07@cs.uiuc.edu. Organized by UIUC and Rome University "La Sapienza". -- Gaia Maselli, PhD HealthNet 2007 Publicity Chair _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From MAILER-DAEMON@lists.ietf.org Mon Apr 02 12:39:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPYg-0006C2-Df for manet-archive@lists.ietf.org; Mon, 02 Apr 2007 12:39:06 -0400 Received: from 232.red-80-35-214.staticip.rima-tde.net ([80.35.214.232] helo=[172.72.72.2]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HYPYf-00025P-0l for manet-archive@lists.ietf.org; Mon, 02 Apr 2007 12:39:06 -0400 Received: from no.name.available by [172.72.72.2] via smtpd (for chiedprmail1.ietf.ORG [156.154.24.150]) with SMTP; Mon, 2 Apr 2007 18:38:02 +0200 From: "Automatic Email Delivery Software" To: manet-archive@lists.ietf.org Subject: Delivery reports about your e-mail Date: Mon, 2 Apr 2007 18:37:28 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_6215C604.81A23692" 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 X-Spam-Score: 3.0 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. ------=_NextPart_000_0003_6215C604.81A23692 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear user of lists.ietf.org, We have received reports that your e-mail account has been used to send a large amount of unsolicited commercial email messages during this week. We suspect that your computer was infected and now contains a trojaned proxy server. We recommend you to follow our instructions in order to keep your computer safe. Have a nice day, The lists.ietf.org support team. ------=_NextPart_000_0003_6215C604.81A23692 Content-Type: application/octet-stream; name="=?utf-8?B?RGVsZXRlZDAudHh0?= " Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="=?utf-8?B?RGVsZXRlZDAudHh0?= " QSBmaWxlIHdhcyByZW1vdmVkIGJlY2F1c2UgaXQgY29udGFpbmVkIG1hbGljaW91cyBjb2Rl IHRoYXQgY291bGQgbm90IGJlIHJlcGFpcmVkLiAgRmlsZSBuYW1lIGlzIHRsei56aXAuICBW aXJ1cyBuYW1lIGlzIFczMi5NeWRvb20uTUBtbQ0K ------=_NextPart_000_0003_6215C604.81A23692-- From manet-bounces@ietf.org Mon Apr 02 17:45:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUJH-0000mw-Dy; Mon, 02 Apr 2007 17:43:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUJF-0000mr-QM for manet@ietf.org; Mon, 02 Apr 2007 17:43:29 -0400 Received: from mailservice.tudelft.nl ([130.161.131.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYUJB-0006NH-AY for manet@ietf.org; Mon, 02 Apr 2007 17:43:29 -0400 Received: from localhost (localhost [127.0.0.1]) by rav.antivirus (Postfix) with ESMTP id A286B22EF13 for ; Mon, 2 Apr 2007 23:43:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at tudelft.nl X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, BAYES_00=-2.599, PROLO_LEO3=0.01] Received: from mailservice.tudelft.nl ([127.0.0.1]) by localhost (tudelft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dkF9t0nvL2o6 for ; Mon, 2 Apr 2007 23:43:22 +0200 (CEST) Received: from [130.161.49.138] (ewi-49-138.ewi.tudelft.nl [130.161.49.138]) by mx2.tudelft.nl (Postfix) with ESMTP id C7D8822EEED for ; Mon, 2 Apr 2007 23:43:22 +0200 (CEST) From: Martin Jacobsson To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 02 Apr 2007 23:43:19 +0200 Message-Id: <1175550199.27999.2.camel@ewi-49-138.ewi.local> Mime-Version: 1.0 X-Mailer: Evolution 2.8.0-1.1mdv2007.0 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Subject: [manet] Personalized Networks'07: Deadline Extended X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Please accept our apologies if you received multiple copies of this call for papers CALL FOR PAPERS EXTENDED =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Second International Workshop on Personalized Networks http://pernets.org/ To be held in conjunction with: The 4th Annual International Conference on Mobile and Ubiquitous Systems: Networks and Services (MOBIQUITOUS 2007) August 10, 2007 - Philadelphia, Pennsylvania, USA =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Important Dates Paper Submission Deadline: April 7, 2007 (EXTENDED on Request) Notification of Acceptance: May 21, 2007 Camera-Ready Submissions: June 10, 2007 (Accepted papers will be published in the conference proceedings and the IEEE Digital Library) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Purpose of this workshop The ubiquitous nature of wireless networks has spawned many interesting applications that were unimagined hitherto. It has also brought many challenges for the communication and networking community to address. On one hand we see present day mobile devices are capable of providing many services that required several devices before. For example, most cell phones nowadays provide high speed data access, still and video cameras, PDA functionality, etc. These advances in device sophistication and service offerings, including wireless hotspots, have made a difference in the way we communicate. With increased user mobility and user's desire to always be connected, we have seen a growing interest in Personal Area Networks (PANs) and Body Area Networks (BANs). These networks can be tuned and applied meaningfully for individual users and their requirements. On the other hand the Internet has changed our way of interacting dramatically. These two major communication areas are having an in-depth influence on the way we communicate; it is worth considering them 'together' as the future communication vehicle. (Please visit http://pernets.org/ for more information and submission instructions) Scope of the submission We seek original contributions which are aimed at finding solutions to the problems that are outlined above towards realization of a Personalized Network. We have identified the following major topics under which we try to categorize the submissions. However, we will consider any other original, interesting, and imaginative ideas and thoughts towards meeting this goal of a Personalized Network. * The architectural framework of personalized networks * Context awareness and support * Resource, service and context discovery * Self-organization and adaptation * Addressing and routing * Interworking between PANs, ad hoc networks, etc, and infrastructure-based heterogeneous networks * Mobility of personalized networks * Security, privacy and accounting * Zero configuration methods and other enablers for ease-of-use * Dependability * Context-aware and application-driven communication substrates * Interactions between persons through their networks, federations of=20 such networks * Handling of QoS across heterogeneous and dynamically changing link=20 layers * New QoS concepts in personalized networks * Mapping of functional requirements to physical devices and resources * Modeling and simulation of personalized networks * P2P paradigm in personalized networks * Innovative applications or prototypes and demonstrations of such=20 person centric applications are equally valued Why should you participate in this workshop? Personalized Networks is a concrete vision of the future networks, yet very current, in the field of communications. It attracts researchers from both wired and wireless domains. This workshop is an ideal platform to share a vision of where we are heading, interact, and strongly advocate an exciting new avenue for researchers and practitioners in the field of communication. Further, the final program will consist of carefully selected - with at least three peer reviews - and high quality submissions with a large emphasis on new ideas rather than incremental contributions to the field. Submissions of shorter versions of full papers that can be submitted to other conferences/journal in the near future are discouraged. General Chairperson Ignas Niemegeers, Delft University of Technology, Netherlands Program Co-Chairpersons Sonia Heemstra de Groot, University of Twente, Netherlands Sai Shankar, Qualcomm, San Diego, USA Magda El Zarki, University of California, Irvine, USA Publicity Chairperson Paolo Bellavista, Universit=E0 degli Studi di Bologna, Italy Technical Program Committee Paolo Bellavista, Universit=E0 degli Studi di Bologna, Italy Milind M Buddhikot, Bell Laboratories, New Jersey, USA Chun-Ting Chou, Philips Research, New York, USA Carlos Cordeiro, Philips Research, New York, USA Piet Demeester, University of Ghent, Belgium Sudhir Dixit, Nokia, Boston, USA Minaxi Gupta, Indiana University, USA Carmelita G=F6rg, University of Bremen, Germany K. V. S. Hari, Indian Institute of Science, Bangalore, India Frank den Hartog, TNO, Netherlands Sonia Heemstra de Groot, TI-WMC, Netherlands Geert Heijenk, University of Twente, The Netherlands Ramin Hekmat, Delft University of Technology, Netherlands James Irvine, Strathclyde University, Scotland H. S. Jamadagni, Indian Institute of Science, Bangalore, India Ern=F6 Kovacs, NEC Europe, Heidelberg, Germany Anup Kumar, University of Louisville, Kentucky, USA Joy Kuri, Indian Institute of Science, Bangalore, India Guy Leduc, Universite de Liege, Belgium Anthony Lo, Delft University of Technology, Netherlands Ingrid Moerman, University of Ghent, Belgium Luis Mu=F1oz, University of Cantabria, Spain Ignas Niemegeers, Delft University of Technology, Netherlands Giovanni Pau, University of California Los Angeles, USA Jorge Pereira, European Commission, Brussels, Belgium Neeli Prasad, University of Aalborg, Denmark Ramjee Prasad, University of Aalborg, Denmark Tarek Saadawi, City University of New York, USA Paolo Santi, CNR Institute for Informatics and Telematics, Italy Amardeo Sarma, NEC Network Laboratories, Germany Sai Shankar, Qualcomm, San Diego, USA Sirin Tekinay, New Jersey Institute of Technology, New Jersey, USA Magda El Zarki, University of California, Irvine, USA Djamal Zeglache, INT, Paris, France _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 02 18:31:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYV2n-00023g-2X; Mon, 02 Apr 2007 18:30:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYV2l-00023b-7y for manet@ietf.org; Mon, 02 Apr 2007 18:30:31 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYV2i-0006HZ-Jb for manet@ietf.org; Mon, 02 Apr 2007 18:30:31 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1555826wxd for ; Mon, 02 Apr 2007 15:30:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=QWmNiE2DU88YQw0elyhRZ5ByaGiJjWfanmQGy6bodwrkvKq0t+UnCF0GXL5XXnHDaNRFMsd9hi81/ZLtBZBtC2N9wcTibPE+V1mq+ivTNS9tAZtQwhxraMP9boOvIhn3d290j/Ba4fDnAUr9aCb/qU28yMPVBPDZUolju4M9uhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=qiompiVardI1+RT4roREJ+IlaaOeMl+95pZDCkfCJ9SvEmvrUxtTmsTxwsTYVtEa8boSepQDx2mtbPnNEipgphkTLqxnowRCmMclTL4FMbbI+mxe2wb5EAY/06nh+9RS3CbO31U652PO751hTTwwIMugNFrn+fmvNyX0p6vdx0g= Received: by 10.114.174.2 with SMTP id w2mr1987602wae.1175553025595; Mon, 02 Apr 2007 15:30:25 -0700 (PDT) Received: by 10.114.255.11 with HTTP; Mon, 2 Apr 2007 15:30:25 -0700 (PDT) Message-ID: Date: Mon, 2 Apr 2007 18:30:25 -0400 From: "wenyuan xu" To: manet@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 5a06c284b99e2997 X-Spam-Score: 0.4 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Subject: [manet] IEEE Workshop on Networking Technologies for Software Defined Radio Networks (2007), deadline (April 9th) is approaching. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1317215776==" Errors-To: manet-bounces@ietf.org --===============1317215776== Content-Type: multipart/alternative; boundary="----=_Part_114212_5988677.1175553025545" ------=_Part_114212_5988677.1175553025545 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Apologies for cross-postings. Please send to interested colleagues and students * * *Second IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks* * (Held in Conjunction with IEEE SECON 2007) June 18, 2007, *San Diego, California, USA Wireless systems have historically operated in relatively static frequency bands allocated to a single type of service. This compartmentalization of spectrum offered few incentives for common designs across frequency bands and limited opportunities for dynamic spectrum sharing. More recently, there has been a push to make more spectrum available, and in response there has been significant research towards developing new classes of "cognitive" radios and their associated protocols. Cognitive radios (CRs), or more generally software defined radios (SDRs), can tune their communication stack to take advantage of spectrum opportunities, adapt to a wide variety of radio interference conditions, and employ protocols that allow for collaboration between previously incompatible technologies. Dynamic physical layer adaptation is achieved by scanning available spectrum, selection from a wide range of operating frequencies, rapid adjustment of modulation waveforms and adaptive power control. A suitably designed cognitive radio with a software-defined physical layer would be capable of collaborating with neighboring radios to ameliorate interference using higher-layer protocols. These higher layer coordination protocols could range from etiquette mechanisms to fully collaborative multi-hop forwarding. The potential impact of cognitive radios upon both commercial and military wireless communications is great as they could allow for improved spectrum utilization and improved interoperability between wireless data standards. The workshop builds upon the success of the First IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks. Although the potential for CR/SDR platforms is great, there remains a need for developing, testing, and prototyping the protocols that will allow the CR platforms to achieve their promise. The purpose of this workshop is to facilitate the exchange of cutting-edge research in cognitive radio and software defined radio technologies. The focus of this workshop is to explore the underlying networking and communication protocols needed to facilitate the interconnection of CR/SDR platforms. Since CR/SDR research is taking place across multiple communities, ranging from academic to government to industry, from physical layer to networking to hardware researchers, we intend for this workshop to serve as a forum for cross-pollination and collaboration that will accelerate the deployment and eventual success of CR/SDR platforms. Original manuscripts that focus on the analytical modeling, protocol/algorithm design, and/or experimental studies of the following topics of interest are sought: - Spectrum Sensing and Spectrum Management - Cognitive Radio Test-Beds and Hardware Prototypes - DSA/Cognitive Radio Standardization Activities (e.g. IEEE P1900, IEEE 802.22) - Accreditation, Trust, & Security Mechanisms for DSA Networks - Cross-Layer Protocol Design - Cooperation and Game-Theoretical Protocols for Cognitive Radios - Practical Experience and Systems Implementations *Submission Instructions:* All submissions must be full papers in .pdf format. Papers should be sent to the email address SDRWorkshop07@winlab.rutgers.edu . Papers must not exceed 8 single-spaced, two-column pages using at least 11 point size fonts on 8.5x 11 inch pages. The workshop website is http://www.winlab.rutgers.edu/~wenyuan/sdr07/index.htm . Important Dates: Manuscript Submission Due: April 9, 2007, 5pm EDT Acceptance Notification: April 18, 2007 Camera-Ready Paper Due: May 5, 2007 ------=_Part_114212_5988677.1175553025545 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Apologies for cross-postings. Please send to interested colleagues and students 


 

 

Second IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks

(Held in Conjunction with IEEE SECON 2007)
June 18, 2007, San Diego, California, USA

 

Wireless systems have historically operated in relatively static frequency bands allocated to a single type of service.  This compartmentalization of spectrum offered few incentives for common designs across frequency bands and limited opportunities for dynamic spectrum sharing.  More recently, there has been a push to make more spectrum available, and in response there has been significant research towards developing new classes of "cognitive" radios and their associated protocols. Cognitive radios (CRs), or more generally software defined radios (SDRs), can tune their communication stack to take advantage of spectrum opportunities, adapt to a wide variety of radio interference conditions, and employ protocols that allow for collaboration between previously incompatible technologies. Dynamic physical layer adaptation is achieved by scanning available spectrum, selection from a wide range of operating frequencies, rapid adjustment of modulation waveforms and adaptive power control.  A suitably designed cognitive radio with a software-defined physical layer would be capable of collaborating with neighboring radios to ameliorate interference using higher-layer protocols.  These higher layer coordination protocols could range from etiquette mechanisms to fully collaborative multi-hop forwarding.  The potential impact of cognitive radios upon both commercial and military wireless communications is great as they could allow for improved spectrum utilization and improved interoperability between wireless data standards.

 

The workshop builds upon the success of the First IEEE Workshop on Networking Technologies for Software Defined Radio (SDR) Networks. Although the potential for CR/SDR platforms is great, there remains a need for developing, testing, and prototyping the protocols that will allow the CR platforms to achieve their promise. The purpose of this workshop is to facilitate the exchange of cutting-edge research in cognitive radio and software defined radio technologies. The focus of this workshop is to explore the underlying networking and communication protocols needed to facilitate the interconnection of CR/SDR platforms. Since CR/SDR research is taking place across multiple communities, ranging from academic to government to industry, from physical layer to networking to hardware researchers, we intend for this workshop to serve as a forum for cross-pollination and collaboration that will accelerate the deployment and eventual success of CR/SDR platforms. Original manuscripts that focus on the analytical modeling, protocol/algorithm design, and/or experimental studies of the following topics of interest are sought:

  • Spectrum Sensing and Spectrum Management
  • Cognitive Radio Test-Beds and Hardware Prototypes
  • DSA/Cognitive Radio Standardization Activities (e.g. IEEE P1900, IEEE 802.22)
  • Accreditation, Trust, & Security Mechanisms for DSA Networks
  • Cross-Layer Protocol Design
  • Cooperation and Game-Theoretical Protocols for Cognitive Radios
  • Practical Experience and Systems Implementations

 

Submission Instructions:

 

All submissions must be full papers in .pdf format. Papers should be sent to the email address SDRWorkshop07@winlab.rutgers.edu . Papers must not exceed 8 single-spaced, two-column pages using at least 11 point size fonts on 8.5 x 11 inch pages. The workshop website is http://www.winlab.rutgers.edu/~wenyuan/sdr07/index.htm .

 

Important Dates:

 

Manuscript Submission Due: April 9, 2007, 5pm EDT

Acceptance Notification:  April 18, 2007

Camera-Ready Paper Due: May 5, 2007

------=_Part_114212_5988677.1175553025545-- --===============1317215776== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1317215776==-- From manet-bounces@ietf.org Mon Apr 02 18:53:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVNz-0000gn-RA; Mon, 02 Apr 2007 18:52:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVNx-0000gJ-G6 for manet@ietf.org; Mon, 02 Apr 2007 18:52:25 -0400 Received: from ee.tamu.edu ([165.91.241.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYVNv-0000Io-04 for manet@ietf.org; Mon, 02 Apr 2007 18:52:25 -0400 Received: from ECE149 (ece149.tamu.edu [165.91.208.72]) by ee.tamu.edu (8.13.6/8.13.6) with SMTP id l32MqFpF016962; Mon, 2 Apr 2007 17:52:15 -0500 (CDT) Message-ID: <001701c77579$905fab70$48d05ba5@ECE149> From: "Dr. Xi Zhang" To: Date: Mon, 2 Apr 2007 17:52:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Subject: [manet] April 10, 2007, Deadline extended: ACM IWCMC 2007, Aug 12, 2007, Honolulu, Hawaii, USA. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org *Sorry for receiving multiple copies* Submissions: EDAS --> Deadline extened to April 10, 2007. Call For Papers for ACM IWCMC 2007: _____________________ ACM IWCMC 2007 (http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) August 12-16, 2007, Honolulu, Hawaii, USA Technical Sponsors: ACM (Approved) and IEEE (Pending) Submissions: EDAS --> Deadline extended to April 10, 2007. "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" The ACM International Wireless Communications and Mobile Computing Conference 2007 (ACM IWCMC 2007) will be held in Turtle Bay Resort Hotel, Honolulu, Hawaii, USA during August 12-16, 2007. Under our new theme of "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" , IWCMC2007 is targeting at a wide spectrum of state-of-the-art as well as emerging topics pertaining to wireless networks, communications, and mobile computing. Continuing the great succeed of ACM IWCMC 2006 last year, IWCMC 2007 is anticipated to attract an even larger volume of high quality submissions and stimulate the cutting-edge research discussions amongst many academic pioneering researchers/scientists and industrial engineers/leaders attendees from all around the world as was evidenced during ACM IWCMC 2006. The ACM IWCMC 2007 program will feature a General Symposium, 8 Specific Technical Symposia, Workshop, and Tutorials Sessions. Prospective authors are invited to submit original technical papers to the corresponding IWCMC 2007 Symposia as listed below for oral presentation at IWCMC 2007 and publication in the IWCMC 2007 Conference Proceedings. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ We're pleased to announce the following: [1] Professor Gordon Stuber from Georgia Tech, USA, who is the world-class leader in mobile wireless communications/networking, communication signal processing, and many other areas, has agreed to be the Keynote Speaker for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [2] "NTT DoCoMo USA", which is one of most famous companies in the mobile communications industries, has officially become the Financial Sponsor for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [3] ACM has officially become the technical sponsor for IWCMC 2007 (this was notified earlier) and all the accepted IWCMC 2007 papers will be included into the ACM Database. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ IWCMC 2007 General Organizing Committee: General Co-Chairs: Mohsen Guizani, Western Michigan University, USA, Email: mguizani@ieee.org Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan, Email: hshwchen@comm.nsysu.edu.tw Technical Program Committee Chair: Xi Zhang, Texas A&M University, USA, Email: xizhang@ece.tamu.edu Financial Chair: Eun K. Park, University of Missouri at Kansas City, USA, Email: ekpark@umkc.edu IWCMC 2007 Technical Symposia: General Symposium: Chair: Xuemin (Sherman) Shen, University of Waterloo, Canada, xshen@bbcr.uwaterloo.ca Co-Chairs: Dongmei Zhao, McMaster University, Canada, dzhao@mail.ece.mcmaster.ca Hai Jiang, Princeton University, USA, haijiang@princeton.edu (1) Communication and Information Theory Symposium: Chair: Hamid Sadjadpour, University of California, Santa Cruz, USA, hamid@soe.ucsc.edu Ravi Narasimhan, University of California, Santa Cruz, USA ravi@soe.ucsc.edu (2) Computer and Network Security Symposium: Chair: Xiaojiang (James) Du, North Dakota State University, USA, xiaojiang.du@ndsu.edu Co-Chairs: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org, Yong Guan, Iowa State University, USA, guan@iastate.edu (3) Cross-Layer Optimized Wireless Networks Symposium: Chair: Xi Zhang, Texas A&M University, USA, xizhang@ece.tamu.edu Co-Chairs: Weihua Zhuang, University of Waterloo, Canada, wzhuang@ece.uwaterloo.ca Sunghyun Choi, Seoul National University, Korea, schoi@snu.ac.kr Kun Yang, University of Essex, UK, kunyang@essex.ac.uk (4) MIMO Systems Symposium: Chair: Zhengyuan Xu, University of California, Riverside, USA, dxu@ee.ucr.edu Co-Chairs (in alphabet order): Javier Garcia-Frias, University of Delaware, USA, jgarcia@ee.udel.edu Mounir Ghogho, Leeds University, UK, m.ghogho@leeds.ac.uk Weifeng Su, State University of New York (SUNY) at Buffalo, USA, weifeng@eng.buffalo.edu Liuqing Yang, University of Florida, USA, lqyang@ece.ufl.edu (5) Mobile Computing Symposium: Chair: Jie Li, University of Tsukuba, Japan, lijie@cs.tsukuba.ac.jp (6) Multimedia over Wireless Symposium: Chairs: Haohong Wang, Marvell Technology Group, USA, haohongwang@yahoo.com (7) Next Generation Mobile Networks Symposium (Website Link): Chair: Victor Leung, The University of British Columbia, Canada, vleung@ece.ubc.ca Co-Chairs: Ekram Hossain, University of Manitoba, Canada, ekram@ee.umanitoba.ca Javan Erfanian, Bell Mobility, Canada, javan.erfanian@bell.ca (8) Wireless Sensor Networks Symposium: Chair: Yang Yang, University College London, United Kingdom, y.yang@ee.ucl.ac.uk (9) Wireless LANs and Wireless PANs Symposium: Chair: Ehab Elmallah, University of Alberta, Canada, Canada, ehab@cs.ualberta.ca Co-Chair: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org (10) Workshop Chair: Song Ci, University of Nebraska-Lincoln, USA sci@engr.unl.edu Co-Chair: Yi Cui, Vanderbilt University, USA yi.cui@vanderbilt.edu IMPORTANT DATES: Full Paper Submission: April 10, 2007 (updated) Notification of Acceptance: May 30, 2007 Camera-Ready Version/Copyright Form Submission: June 11, 2007 Registration Deadline for Authors: June 11, 2007 Hotel Reservation Deadline: July 10, 2007 _____________________ ========================================================================= Xi Zhang Assistant Professor Dept. of Elec. & Comput. Engin. Phone: 979-458-1416 Texas A&M University Fax: 979-845-2630 333N WERC Building Email: xizhang@ece.tamu.edu College Station, Texas 77843, USA URL http://dropzone.tamu.edu/~xizhang ========================================================================= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 03 02:37:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYccj-0005OQ-Dq; Tue, 03 Apr 2007 02:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYcci-0005O5-68 for manet@ietf.org; Tue, 03 Apr 2007 02:36:08 -0400 Received: from web32205.mail.mud.yahoo.com ([68.142.207.136]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYccg-0001Gu-FN for manet@ietf.org; Tue, 03 Apr 2007 02:36:08 -0400 Received: (qmail 22186 invoked by uid 60001); 3 Apr 2007 06:36:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nZ90GYzERGfvDX+Rsq2WoqoFmvC9fzBbHwig8amxMDB39+c86JUDlwhRGtUhLrbKGZNfYV3Z0fqX/MAzfe/+ksXUhN8/FcfYvDyyVQS6+X4q/v7GdAzk8LWzfK1v8BfIy5TTwVCz+CPvP/8KiSXH5SF8CEcNG25yx1oJUeqq3Kg=; X-YMail-OSG: GpkzrqwVM1n174jl1u9EgxcrakRPDvgxfNd_sDYCoMpM_30oeBn8aCpIQFR0zB_BCqsQqxQJKLpWv3R2XWx9BZcBf8NZa5acDukC1wLCOEzMcMxwLGaw165rIXbJXQ-- Received: from [202.54.91.205] by web32205.mail.mud.yahoo.com via HTTP; Tue, 03 Apr 2007 07:36:05 BST Date: Tue, 3 Apr 2007 07:36:05 +0100 (BST) From: shivamurti To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <923135.21986.qm@web32205.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [manet] how to configure node in $opt(rp) adhoc routing protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org HI, all I am facing a problem of segmentation fault while configuring node address for base-station in wired-cum-wireless.tcl file. I am using a new protocol for routing other than existing DSDV/DSR routing protocol. with DSDV/DSR it works fine but when i configure with my new routing protocol it gives me segmentation fault. I am using ns2 under linux. being ns2 and linux user I know that segmentation prob occur in case pointers are not memory allocated(one of the reason of coarse) but I have checked for pointers and memory its ok. can anybody help me solve this problem. Thanks and Regards, -Shivamurti. ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 03 06:03:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfpo-0002vl-KK; Tue, 03 Apr 2007 06:01:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfpm-0002vX-Pa for manet@ietf.org; Tue, 03 Apr 2007 06:01:50 -0400 Received: from mail.ncc.up.pt ([193.136.39.16] helo=smtp.dcc.fc.up.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYfpk-0008Dt-DC for manet@ietf.org; Tue, 03 Apr 2007 06:01:50 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.dcc.fc.up.pt (Postfix) with ESMTP id 64033AEF1C; Tue, 3 Apr 2007 11:01:45 +0100 (WEST) Received: from smtp.dcc.fc.up.pt ([127.0.0.1]) by localhost (servicos.ncc.up.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 03786-01-2; Tue, 3 Apr 2007 11:01:31 +0100 (WEST) Received: from [10.0.0.128] (kharanguejo.ncc.up.pt [10.0.0.128]) by smtp.dcc.fc.up.pt (Postfix) with ESMTP id 36D2BB0E81; Tue, 3 Apr 2007 11:01:27 +0100 (WEST) Message-ID: <46122642.30504@dcc.online.pt> Date: Tue, 03 Apr 2007 11:02:42 +0100 From: =?ISO-8859-1?Q?Jo=E3o_Paulo_Vilela?= User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: "super.ismiti" , manet@ietf.org Subject: Re: [manet] manet simulation in ns-2 with scen-gen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: by amavisd-new at dcc.fc.up.pt Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear Ricardo, For generating mobility scenarios and selecting the corresponding mobility models, I find the following tool very useful: http://www.cs.rice.edu/~santa/research/mobility/ For the installation of OLSR within ns-2 you can follow these guidelines: http://masimum.dif.um.es/?Software:UM-OLSR:Installation Best regards, Jo=E3o Paulo Vilela super.ismiti wrote: > Hi, >=20 > I want to simulate a mobile ad-hoc network using the ns-2. > Well I have some questions, that I didn't find in the internet... >=20 > First, how can I use the scen-gen. Only the help of this tool don't say > too much things... I don't know how must I use the files that I made > with this tool. Where could I find some examples of the using of this > tool, specialy in mobile wireless networks? >=20 >=20 > Second, how can I use a mobility model in a simulation? I didn't find > any example of this... Where must I put the source (*.c) of the mobilit= y > model and where must I call it? >=20 > Third, how can I install a new protocol in the ns-2. I want to install > OLSR for example. I have the source of this protocol. What must I do to > take it working in the ns-2? >=20 > Thanks in advance for any help, > Ricardo. >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 03 06:06:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYfts-0006YQ-0m; Tue, 03 Apr 2007 06:06:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYftp-0006Wv-6z for manet@ietf.org; Tue, 03 Apr 2007 06:06:01 -0400 Received: from web56305.mail.re3.yahoo.com ([216.252.110.229]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYftk-0000nb-RP for manet@ietf.org; Tue, 03 Apr 2007 06:06:01 -0400 Received: (qmail 38033 invoked by uid 60001); 3 Apr 2007 10:05:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=je6Ii7nlF/GkVgMuMvMcowkKADcoMMIqxgvsxZmFY9DpiBXIGK4lG8qIoLZcaUXIrXcTdzZIeh6N8FmXp6L/8DZeHSpFDZ8CL5nNsDPTQllEwHsHzDi8u7Dlm824oaEB7dNA5yFCpaCmkxh6AR9U4AIBqZGqUjg2uCcYG4ylhmM=; X-YMail-OSG: YnyQCEAVM1nC4b0whIvXW5145SenTONi0D9xF19Zx3l9oDchdHH7aOVcKwiQie5JlZUA.Ung8Q4oV5YkW3kvw9Su55zbId929VtaRz8Y1vboZa_cThxkYTu8CK4zPw-- Received: from [84.241.8.46] by web56305.mail.re3.yahoo.com via HTTP; Tue, 03 Apr 2007 11:05:56 BST Date: Tue, 3 Apr 2007 11:05:56 +0100 (BST) From: alireza jomeiry To: manet@ietf.org MIME-Version: 1.0 Message-ID: <516090.28747.qm@web56305.mail.re3.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [manet] help GLS X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1150922114==" Errors-To: manet-bounces@ietf.org --===============1150922114== Content-Type: multipart/alternative; boundary="0-1534482188-1175594756=:28747" Content-Transfer-Encoding: 8bit --0-1534482188-1175594756=:28747 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello friends, how can I obtain GLS(Grid Location Service) code in glomosim? anybody have this code please send me. thanks. Send instant messages to your online friends http://uk.messenger.yahoo.com --0-1534482188-1175594756=:28747 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
hello friends,
how can I obtain GLS(Grid Location Service) code in glomosim?
anybody have this code please send me.
thanks.

Send instant messages to your online friends http://uk.messenger.yahoo.com --0-1534482188-1175594756=:28747-- --===============1150922114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1150922114==-- From manet-bounces@ietf.org Tue Apr 03 06:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYg32-0005dD-Kq; Tue, 03 Apr 2007 06:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYg31-0005W2-4d for manet@ietf.org; Tue, 03 Apr 2007 06:15:31 -0400 Received: from cassius.ee.usyd.edu.au ([129.78.13.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYg2y-0003zk-Pk for manet@ietf.org; Tue, 03 Apr 2007 06:15:31 -0400 Received: from ee.usyd.edu.au (localhost [127.0.0.1]) by cassius.ee.usyd.edu.au (8.13.6/8.13.6) with SMTP id l33ACXZF029227 for ; Tue, 3 Apr 2007 20:12:33 +1000 (EST) From: Guo Qiang Mao Received: from 220.233.86.132 (SquirrelMail authenticated user guoqiang) by www.ee.usyd.edu.au with HTTP; Tue, 3 Apr 2007 20:12:33 +1000 (EST) Message-ID: <13144.220.233.86.132.1175595153.squirrel@www.ee.usyd.edu.au> Date: Tue, 3 Apr 2007 20:12:33 +1000 (EST) To: X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal X-Mailer: SquirrelMail (version 1.2.7) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-ElectricalEngineering-MailScanner-Information: Please contact the ISP for more information X-ElectricalEngineering-MailScanner: Found to be clean X-ElectricalEngineering-MailScanner-From: guoqiang@ee.usyd.edu.au Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cassius.ee.usyd.edu.au id l33ACXZF029227 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [manet] Seven Days to Paper Registration Deadline X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org [Our apologies if you receive multiple copies of this message] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ACM SenSys 2007: Seven Days to Paper Registration Deadline The 5th ACM Conference on Embedded Networked Sensor Systems November 6-9, 2007 Sydney, Australia http://sensys.acm.org/2007/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sponsored by ACM SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS and SIGB= ED. The 5th ACM Conference on Embedded Networked Sensor Systems (SenSys) is a highly selective, single-track forum for the presentation of research results on systems issues in the area of embedded, networked sensors. Distributed systems based on networked sensors and actuators with embedde= d computation capabilities enable an instrumentation of the physical world at an unprecedented scale and density, thus enabling a new generation of monitoring and control applications. This conference provides an ideal venue to address the research challenges facing the design, deployment, use, and fundamental limits of these systems. Sensor networks require contributions from many fields, from wireless communication and networking, embedded systems and hardware, distributed systems, data management, and applications, so we welcome cross-disciplinary work. This year we particularly encourage papers that extend the scope of the conference beyond wireless mote-class sensor networks and we seek contributions from a broad range of sensing-related fields, such as actuator networks, RFID applications, mobile ad-hoc networks, camera networks, and others. We seek technical papers describing original, previously unpublished research results. Topics of interest include, but are not limited to, the following: =95 Sensor network architecture and protocols =95 Applications =95 Rich sensor systems leveraging RFID, mobile devices (e.g., cell phone= s), cameras, robotics, etc. =95 Analysis of real-world systems and fundamental limits =95 Sensor network planning, provisioning, calibration and deployment =95 Deployment experience and testbeds =95 Experimental methodology, including measurement, simulation, and=20 emulation infrastructure =95 Integration with back-end systems such as web-based information syste= ms, process control, and enterprise software =95 Programming methodology =95 Operating systems =95 Sensor network algorithms such as localization, routing, time synchronization, clustering, topology control, and coverage control algorithms =95 Failure resilience and fault isolation =95 Energy management =95 Data, information, and signal processing =95 Data storage and management =95 Distributed actuation and control =95 Security and privacy Important dates: Paper Registration and Abstract: April 10, 2007, midnight US Eastern Time Paper Submission Deadline: April 17, 2007, midnight US Eastern Time Notification of Paper Acceptance: July 2, 2007 Camera Ready Paper Copy: August 30, 2007 All deadlines are firm; we will not honor extensions. Papers must be original, unpublished work not under consideration elsewhere. All submissions will be handled electronically and must be in PDF format. Papers must not exceed 14 pages (US "Letter" size, 8.5 x 11 inches) including all material (text, figures and references). The font size must be at least 10 points. Papers should be in two-column format with no more than 59 lines of text per column and at least 0.75" margins on all sides. All submitted papers will be peer-reviewed. The review process is double-blind and hence, all submissions must be anonymized. Selected papers of particular merit will be proposed for publication in the ACM Transactions on Sensor Networks. For submission details, see the conference web site. Demos: Demonstrations showing innovative research and applications are solicited. SenSys is very interested in demonstrations of technology, platforms, and applications of sensor systems. Abstracts of accepted demo= s will be published in the SenSys conference proceedings. Submissions from both industry and academia are encouraged. For submission details, see th= e conference web site. A call for demos with submission dates, etc., will b= e posted at a later point. Posters: Posters showing exciting early work on sensor systems are solicited. Areas of interest are the same as those listed in the technica= l call for papers. While the poster need not describe completed work, it should report on research for which at least preliminary results are available. For submission details, see the conference web site. A call fo= r posters with submission dates, etc., will be posted at a later point. Organization: General Chair: Sanjay Jha (U. New South Wales) Program Co-Chairs: Phillip B. Gibbons (Intel Research), Akos Ledeczi (Vanderbilt) Poster Co-Chairs: Nirupama Bulusu (Portland State), Rachel Cardell-Oliver (U. Western Australia) Demo Co-Chairs: Suman Nath (Microsoft Research), Max Ott (NICTA, Australi= a) Workshop Chair: Andreas Savvides (Yale) Student Award Chair: Alberto Cerpa, UC Merced Local Arrangements Chairs: Subhash Challa (U. Technology, Sydney), Salil Kanhere, (U. New South Wales) Publicity Co-Chairs: Rajeev Shorey (GM Research, India), Guoqiang Mao (U. Sydney) Web Chair: Wen Hu (CSIRO, Australia) Registration Chair: Ren Liu (CSIRO, Australia) Publications Chair: Adam Dunkels, SICS Finance Chair: Chun Tung Chou (U. New South Wales) Steering Committee Chair: John Heidemann (USC) Program Committee: Tarek Abdelzaher (UIUC), Gaetano Borriello (U. Washington), Andrew Campbell (Dartmouth), Peter Corke (CSIRO, Australia), Richard Han (U. Colorado), Tien He (U. Minnesota), John Heidemann (USC), Ted Herman (Iowa), Polly Huang (National Taiwan U.), Brad Karp (U. Colleg= e London), Phil Levis (Stanford), Jie Liu (Microsoft Research), Chenyang Lu (Washington U. in St. Louis), Sam Madden (MIT), Miklos Maroti (U. Szeged, Hungary), Margaret Martonosi (Princeton), Lama Nachman (Intel Research), Kay R=F6mer (ETH Zurich), Mani Srivastava (UCLA), John Stankovic (U. Virginia), Subhash Suri (UCSB), Thiemo Voigt (SICS, Sweden) Sponsors: Academic sponsors: SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS, SIGBE= D Corporate sponsors: University of New South Wales, CSIRO, National ICT Australia, Arch Rock _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 03 16:21:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpUC-0006v6-2x; Tue, 03 Apr 2007 16:20:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpUA-0006uv-IR for manet@ietf.org; Tue, 03 Apr 2007 16:20:10 -0400 Received: from mu-out-0910.google.com ([209.85.134.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYpU8-0001bf-8l for manet@ietf.org; Tue, 03 Apr 2007 16:20:10 -0400 Received: by mu-out-0910.google.com with SMTP id g7so2027616muf for ; Tue, 03 Apr 2007 13:20:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=KLx9RefwiqHwbiTkd7E2mT+vmn5VwYD5kCZ7JsJbg/cHcd2mTwSvZqxUcjNlpDLItCnHouu8mtmq+37oT5xJvBzYpQo73bivAPh5CbZhbUNRjjPz0TY8hTl/iRnoHHy3mx8I0sZpxjnH6JJSXYjtinqvjxIXyRQVmkyvim1BJi4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=W2SUY4r0kPL317Jx6rADEpzC5/6jZi8TOweMhInkExzdJR+wypcIhCbQAFWG+y6C9lqdiarNBPUv7saBdc5dx8LaJBoFjzHpEPQL929xS15/kiKu14bKEhlGiqM25YU4HQf2TbJOHmnkdlhWAL1vCQsfi2YfDK3SaOvLHPt+/J8= Received: by 10.82.188.15 with SMTP id l15mr4032596buf.1175631607393; Tue, 03 Apr 2007 13:20:07 -0700 (PDT) Received: by 10.82.176.12 with HTTP; Tue, 3 Apr 2007 13:20:07 -0700 (PDT) Message-ID: Date: Tue, 3 Apr 2007 17:20:07 -0300 From: super.ismiti To: ns-users@isi.edu, manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [manet] running ad-hockey X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1558697180==" Errors-To: manet-bounces@ietf.org --===============1558697180== Content-Type: multipart/alternative; boundary="----=_Part_16587_15375507.1175631607349" ------=_Part_16587_15375507.1175631607349 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm trying hard to run ad-hockey, but some errors are showed me when I type "./ad-hockey": Tk::Error: Can't set borderwidth to '2' for Tk::Frame=HASH(0x868778c): unknown option "borderwidth" at /perl/Tk- 804.027_500/blib/lib/Tk/Configure.pm line 46 Could you tell me what it means, what must I do to solve this problem?! Thanks in advance, Ricardo. ------=_Part_16587_15375507.1175631607349 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I'm trying hard to run ad-hockey, but some errors are showed me when I type "./ad-hockey":

Tk::Error: Can't set borderwidth to '2' for Tk::Frame=HASH(0x868778c): unknown option "borderwidth" at /perl/Tk- 804.027_500/blib/lib/Tk/Configure.pm line 46

Could you tell me what it means, what must I do to solve this problem?!

Thanks in advance,
Ricardo.
------=_Part_16587_15375507.1175631607349-- --===============1558697180== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1558697180==-- From manet-bounces@ietf.org Tue Apr 03 16:48:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpu7-00063I-VX; Tue, 03 Apr 2007 16:46:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpu6-00062V-U0; Tue, 03 Apr 2007 16:46:58 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYpu5-00005Q-9n; Tue, 03 Apr 2007 16:46:58 -0400 Received: from [192.168.0.3] (AVelizy-152-1-6-143.w82-120.abo.wanadoo.fr [82.120.5.143]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l33Kkoxi022236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Apr 2007 22:46:51 +0200 Message-ID: <4612BD3C.4060407@inria.fr> Date: Tue, 03 Apr 2007 22:46:52 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 References: <019c01c76d85$0e6904f0$165cfa84@SEXTANT><4607DBF4.8060608@nokia.com> <06E6CE31-1A9A-4DA8-81EE-6ACFC9951664@hitachi.com> <002101c7720c$22f5da20$165cfa84@SEXTANT> <460BF127.5030608@nokia.com> <39A58386-1B21-4068-B9A4-9A531A470427@hitachi.com> In-Reply-To: <39A58386-1B21-4068-B9A4-9A531A470427@hitachi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4612BD3A.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'manet' , manet-dt@ietf.org Subject: [manet] Re: [Manet-dt] Review Request X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello, About SMF, I am asking some questions for clarification I don't understand very well the purpose of the protocol. Maybe this is because I don't have a clear view of its application context. Is SMF intended to be the only routing protocol running in a network or will it run together with a unicast protocol? Best regards, Philippe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 03 17:06:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqCv-000836-26; Tue, 03 Apr 2007 17:06:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqCt-000809-AS for manet@ietf.org; Tue, 03 Apr 2007 17:06:23 -0400 Received: from web23205.mail.ird.yahoo.com ([217.146.189.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYqCm-0006Sm-JM for manet@ietf.org; Tue, 03 Apr 2007 17:06:23 -0400 Received: (qmail 48945 invoked by uid 60001); 3 Apr 2007 21:06:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=flc6Jqu1mtW8V8kLkXy6XgjwOHg8IVl2cKRtbU5VIX/eSOe2ILevqh0kM2CzvrN6JtwkA/FDyzNuYL2gN4tr9rJfjeZg40skYOdEvKBJahLSobu+z0nP6NgdTwPxtLa464pIZbO7SdxjCzs+kvGEinLr8fYhT5HyFUjkWLbCe6Q=; X-YMail-OSG: fRXqchgVM1lyF.ekrhVcMctaxg1LWnIVV12TCS_KJ2DQFdAwLSk1tJ4srx9midMG4thzBL6Zrx2GsciUceJCtp8uQw_PUPvy1.DZ9oK1OrHT0VVm Received: from [41.201.240.220] by web23205.mail.ird.yahoo.com via HTTP; Tue, 03 Apr 2007 23:06:15 CEST Date: Tue, 3 Apr 2007 23:06:15 +0200 (CEST) From: moussaoui samira To: manet@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <863928.45599.qm@web23205.mail.ird.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Subject: [manet] 9 et 10 AVRIL ACM + Notification rapide X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --- manet-request@ietf.org a écrit : > Send manet mailing list submissions to > manet@ietf.org > > To subscribe or unsubscribe via the World Wide Web, > visit > https://www1.ietf.org/mailman/listinfo/manet > or, via email, send a message with subject or body > 'help' to > manet-request@ietf.org > > You can reach the person managing the list at > manet-owner@ietf.org > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of manet digest..." > > > Today's Topics: > > 1. Personalized Networks'07: Deadline Extended > (Martin Jacobsson) > 2. IEEE Workshop on Networking Technologies for > Software Defined > Radio Networks (2007), deadline (April 9th) is > approaching. > (wenyuan xu) > 3. April 10, 2007, Deadline extended: ACM IWCMC > 2007, Aug 12, > 2007, Honolulu, Hawaii, USA. (Dr. Xi Zhang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 02 Apr 2007 23:43:19 +0200 > From: Martin Jacobsson > Subject: [manet] Personalized Networks'07: Deadline > Extended > To: manet@ietf.org > Message-ID: > <1175550199.27999.2.camel@ewi-49-138.ewi.local> > Content-Type: text/plain; charset=ISO-8859-1 > > Please accept our apologies if you received multiple > copies > of this call for papers > > > CALL FOR PAPERS EXTENDED > > ============================================================ > > > Second International Workshop on Personalized > Networks > http://pernets.org/ > > To be held in conjunction with: > The 4th Annual International Conference on Mobile > and > Ubiquitous Systems: Networks and Services > (MOBIQUITOUS 2007) > August 10, 2007 - Philadelphia, Pennsylvania, > USA > > ============================================================ > > Important Dates > > Paper Submission Deadline: April 7, 2007 > (EXTENDED on Request) > Notification of Acceptance: May 21, 2007 > Camera-Ready Submissions: June 10, 2007 > > (Accepted papers will be published in the conference > proceedings and the IEEE Digital Library) > > ============================================================= > > > Purpose of this workshop > > The ubiquitous nature of wireless networks has > spawned many interesting > applications that were unimagined hitherto. It has > also brought many > challenges for the communication and networking > community to address. On > one hand we see present day mobile devices are > capable of providing many > services that required several devices before. For > example, most cell > phones nowadays provide high speed data access, > still and video cameras, > PDA functionality, etc. These advances in device > sophistication and > service offerings, including wireless hotspots, have > made a difference > in the way we communicate. With increased user > mobility and user's > desire to always be connected, we have seen a > growing interest in > Personal Area Networks (PANs) and Body Area Networks > (BANs). These > networks can be tuned and applied meaningfully for > individual users and > their requirements. On the other hand the Internet > has changed our way > of interacting dramatically. These two major > communication areas are > having an in-depth influence on the way we > communicate; it is worth > considering them 'together' as the future > communication vehicle. > > (Please visit http://pernets.org/ for more > information and submission > instructions) > > > Scope of the submission > > We seek original contributions which are aimed at > finding solutions to > the problems that are outlined above towards > realization of a > Personalized Network. We have identified the > following major topics > under which we try to categorize the submissions. > However, we will > consider any other original, interesting, and > imaginative ideas and > thoughts towards meeting this goal of a Personalized > Network. > > * The architectural framework of personalized > networks > * Context awareness and support > * Resource, service and context discovery > * Self-organization and adaptation > * Addressing and routing > * Interworking between PANs, ad hoc networks, etc, > and > infrastructure-based heterogeneous networks > * Mobility of personalized networks > * Security, privacy and accounting > * Zero configuration methods and other enablers for > ease-of-use > * Dependability > * Context-aware and application-driven communication > substrates > * Interactions between persons through their > networks, federations of > such networks > * Handling of QoS across heterogeneous and > dynamically changing link > layers > * New QoS concepts in personalized networks > * Mapping of functional requirements to physical > devices and resources > * Modeling and simulation of personalized networks > * P2P paradigm in personalized networks > * Innovative applications or prototypes and > demonstrations of such > person centric applications are equally valued > > > Why should you participate in this workshop? > > Personalized Networks is a concrete vision of the > future networks, yet > very current, in the field of communications. It > attracts researchers > from both wired and wireless domains. This workshop > is an ideal platform > to share a vision of where we are heading, interact, > and strongly > advocate an exciting new avenue for researchers and > practitioners in the > field of communication. Further, the final program > will consist of > carefully selected - with at least three peer > reviews - and high quality > submissions with a large emphasis on new ideas > rather than incremental > contributions to the field. Submissions of shorter > versions of full > papers that can be submitted to other > conferences/journal in the near > future are discouraged. > > > General Chairperson > > Ignas Niemegeers, Delft University of Technology, > Netherlands > > > Program Co-Chairpersons > > === message truncated === ___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 03 17:14:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqKB-0004rP-Rt; Tue, 03 Apr 2007 17:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqK9-0004r7-MU for manet@ietf.org; Tue, 03 Apr 2007 17:13:53 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYqEB-0006qE-PH for manet@ietf.org; Tue, 03 Apr 2007 17:08:03 -0400 Received: by ug-out-1314.google.com with SMTP id o38so394935ugd for ; Tue, 03 Apr 2007 14:07:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:subject:date:organization:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole:sender; b=FpZLZ2Z/4UzO9vBOZLFRl3r7UzdrDU3BNhkl5u3+mwnJQjH0ff9qrlX2X3Rnf7E9esIDIowJoo2HQ0nmrlD+dB/t5hGqMNIPukVlTARptUDdcwBfKh3E/8NRYVy7lTHXiAX1SQlsUivweMTRYfKp0Ru49NidN+SxeNw/8y4z+Lw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:subject:date:organization:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole:sender; b=DTp2fNmbUA2ySOZ3a2PuFRVN3t0wWMj8dB8BAllZhfBtpOFE420Pm8Kr59GLDP0ijJ2GSsDIKUvvcy0zbL1qkm8z+Gtle32NMqWOiPXnzI/TkbVTWypprg09wHHdb9MLj6f+ep6cc77dYYgr91c69FAIyLBLY4GZChN3u2TS90M= Received: by 10.82.138.6 with SMTP id l6mr10450501bud.1175634460590; Tue, 03 Apr 2007 14:07:40 -0700 (PDT) Received: from simula073 ( [193.157.236.253]) by mx.google.com with ESMTP id j2sm25471123mue.2007.04.03.14.07.38; Tue, 03 Apr 2007 14:07:39 -0700 (PDT) From: "Yan ZHANG" To: Date: Tue, 3 Apr 2007 23:07:37 +0200 Organization: Simula Research Laboratory, Norway Message-ID: <000401c77634$1c91c280$fdec9dc1@simula.no> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd2M78+sgq3VIkyTWiRSYvI+o6vPwAACLZQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [manet] FGCN2007 - Call for Workshop Proposals X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yanzhang@ieee.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The 2007 International Conference on Future Generation Communication and Networking (FGCN 2007) CALL FOR WORKSHOP PROPOSALS http://www.sersc.org/FGCN2007/ December 6th ~ 8th, 2007; Lotte Hotel Jeju, Jeju-Island, Korea OVERVIEW ======== The 2007 International Conference on Future Generation Communication and Networking (FGCN 2007) will be held on December 6th ~ 8th, 2007, in Jeju Island, Korea. Several workshops will be held in conjunction with FGCN 2007 with the aim to explore special topics and provide international forums for scientists, engineers, and computer users to exchange and share their experiences, new ideas, and research results on hot topics on future generation communication and networking. Workshops for presenting papers from industrial companies and papers on implementations of systems and services are very welcome. It is expected that the proceedings of the workshop programs will be published by IEEE CS. In general, a workshop takes one day, although multiple-day and half-day workshops are welcome. Please send a workshop proposal by May 15, 2007 to Workshop chairs. WHAT TO SUBMIT ============== The workshop proposal should include following information: 1. Title of the workshop: International Workshop on ... 2. Workshop chair(s): name, affiliation, address, phone and fax numbers, e-mail. 3. Brief description of the workshop (several hundred words) 4. Expected number of papers to be submitted 5. Call for paper of the workshop (draft version) 6. Tentative list of program committee members (Name, affiliation, country, email address) Each workshop will start to distribute a call for paper after receiving the notification. Papers submitted to each workshop will be reviewed by the program committee and external reviewers of the workshop. Financial Support for Workshop Organizor: ========================================= If workshops are constructed successfully, the organizer (1 organizer per 1 workshop) will get: - At least 8 papers registration: Free registration - At least 16 papers registration: Free registration and Free accommodation (max 3 nights). Workshop Chairs =============== Dr. Yan Zhang Simula Research Laboratory, Norway E-mail: yanzhang@ieee.org Dr. Yu Hua Huazhong University of Science and Technology, China E-mail: csyhua@hust.edu.cn Important Dates ================ Workshop Proposal Submission Due: May 15, 2007 Workshop Acceptance Notification: May 31, 2007 Camera Ready Due: September 10, 2007 Workshop Date: December 6-8, 2007 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 04 10:14:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6EY-00016l-TN; Wed, 04 Apr 2007 10:13:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6EX-00014K-6I for manet@ietf.org; Wed, 04 Apr 2007 10:13:09 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6ET-0007HA-Ib for manet@ietf.org; Wed, 04 Apr 2007 10:13:09 -0400 Received: by ug-out-1314.google.com with SMTP id 72so647274ugd for ; Wed, 04 Apr 2007 07:13:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=Zy7lOUbw/5OtEFacqciR1LWhzSFPt3NOqQc8HEl2XdG9mmcGu4GDV/XluLztAZhxFweTCjeuD61CMF0cJ9F5RtQWtSmt8JFjqpqUjoz1yYlR7IEZX9V2TQxWXDoKXapw5fA1Cq5zbjxM136+B/GLNzUAyw2QcRJflqBAq81WgvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=rvjwNaIg1ZQ0+9HkS5TGGkSh2dBNGqpl3reb7C85ZYM2xWdn7ehfjOSMFEp/wkIkSnbCq6rqI3KFSw8/X0A95C6LHZhQ1wZlQx50yLefCCBJI0Nq32z0EYFSk77PWPcMrraI+YqP7b7BGl5+2u2Z1Latc39RYdW8DX1YYD3Vc0w= Received: by 10.67.23.5 with SMTP id a5mr1472495ugj.1175695984247; Wed, 04 Apr 2007 07:13:04 -0700 (PDT) Received: by 10.67.57.5 with HTTP; Wed, 4 Apr 2007 07:13:04 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 07:13:04 -0700 From: "venki p" To: "manet@ietf.org" MIME-Version: 1.0 X-Spam-Score: 1.4 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [manet] very urgent need of qolsr execution help.... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1386670275==" Errors-To: manet-bounces@ietf.org --===============1386670275== Content-Type: multipart/alternative; boundary="----=_Part_8857_5415093.1175695984206" ------=_Part_8857_5415093.1175695984206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline i m venkatesh doing qolyester as my final year project ...i have installed the qolyester package.and when i execute the package as qolsrd -i eth0= 12.0.0.1 one error appears ie unknown server and it doesnt run afterwards. i dont know how to exec it in virtual mode, as i execute in virtual mode i found the qswitchd file on usr/local/bin,but i dont know to run tat qswitchd file .to run this package any env variable should be given r not.. when i run it virtual mode i found one qolsrd.switch file in /tmp ..explain me in detail... ------=_Part_8857_5415093.1175695984206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline i m venkatesh doing qolyester as my final year project ...i have installed the qolyester package.and when i execute the package as qolsrd -i eth0=12.0.0.1  one error appears ie unknown server and it doesnt run afterwards. i dont know how to exec it in virtual mode, as i execute in virtual mode i found the qswitchd file on usr/local/bin,but i dont know to run tat qswitchd file .to run this package any env  variable should be given r not..  when i run it virtual mode i found one qolsrd.switch file in /tmp  ..explain me in detail... ------=_Part_8857_5415093.1175695984206-- --===============1386670275== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1386670275==-- From manet-bounces@ietf.org Wed Apr 04 10:16:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6HN-0003vZ-2r; Wed, 04 Apr 2007 10:16:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6HL-0003vN-L4 for manet@ietf.org; Wed, 04 Apr 2007 10:16:03 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6HK-0000jd-Bt for manet@ietf.org; Wed, 04 Apr 2007 10:16:03 -0400 Received: by ug-out-1314.google.com with SMTP id 72so648300ugd for ; Wed, 04 Apr 2007 07:16:00 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=dITIC5z6TPqegZHp0NhmxCXqn0X+lT2Cuq+PtEpWeYqenwXJ3UfHGYhNM7gDIZ+pkBoZIwn+Fon9USv+R2LN9INKlQoykUQgZnz1Qv4LHDFZHzem6H5e74ANm99zRr+xIL9w5NqV9GFnix9nWFSw3ZT+Nj1BqtDMWu6QbSYnsAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=cgBcc2fnXpqO2ehbwRZrfSe4BOQI2yThH2VAS20wnXfr8Bf8QSEeA4zLyhSkj/2YKTa5RXpYdSVUj4+vmTDMaAFqNryIq1Aj0oTGnUBULjiT9bpzayq62Eick3onRN8y94gce2kmk5HhUgjrXAUgqeHI0qUkbhKXvn6Kfz2GZU4= Received: by 10.67.100.17 with SMTP id c17mr1453138ugm.1175696160001; Wed, 04 Apr 2007 07:16:00 -0700 (PDT) Received: by 10.67.57.5 with HTTP; Wed, 4 Apr 2007 07:15:59 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 07:15:59 -0700 From: "venki p" To: "manet@ietf.org" MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [manet] very urgent need of qolsr tcl script X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0250934325==" Errors-To: manet-bounces@ietf.org --===============0250934325== Content-Type: multipart/alternative; boundary="----=_Part_8881_29528737.1175696159940" ------=_Part_8881_29528737.1175696159940 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline i m doing qolsr protocol (qolyester _) as project in final year..i m focusing the oscillation avoidance and collision avoidance problem in adhoc networks..also using backoff timer ..i want the exact tcl scripts to rectify this problems very immediate... ------=_Part_8881_29528737.1175696159940 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline i m doing qolsr protocol (qolyester _) as project in final year..i m focusing the oscillation avoidance and collision avoidance problem in adhoc networks..also using backoff timer ..i want the exact tcl scripts to rectify this problems very immediate...
------=_Part_8881_29528737.1175696159940-- --===============0250934325== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0250934325==-- From manet-bounces@ietf.org Wed Apr 04 13:00:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8p1-00020T-LJ; Wed, 04 Apr 2007 12:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8p0-0001tu-Cr for manet@ietf.org; Wed, 04 Apr 2007 12:58:58 -0400 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ8mv-0003pr-HO for manet@ietf.org; Wed, 04 Apr 2007 12:56:50 -0400 Received: by mu-out-0910.google.com with SMTP id g7so377609muf for ; Wed, 04 Apr 2007 09:56:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=q/9WAjSy0RVlqFSbxwX6DmXGAV/NgAqXWnxR4eg5AfcxbP0OCF3MaktHWejb9dxphesITTZDDUzHQ+99o7djlbGgxR0XzCoPfKoHsWx9cF7bMSjCVeQLOYVrxYShNHx9L98YvQjgKFPYOxFX+1jBQDFoPCpsMSwr9Hrt9BCMQeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=aUO4Lgl32GXgAguaTv45inbsX3f6oKjqpX7NDfIb0t4OLxBT6xG2et85tgo+6L+ETd3dcTHqKWVJpfLw0BK9vxUwhgLRwuwBncsZPEggELx5WFuYmqaz9CAHLNAco/Nbdy0FXOW3G0hZgU/m+4GVx7NPVASk8yWsk81XsRj1kJo= Received: by 10.82.136.4 with SMTP id j4mr1071368bud.1175705808607; Wed, 04 Apr 2007 09:56:48 -0700 (PDT) Received: by 10.82.176.12 with HTTP; Wed, 4 Apr 2007 09:56:48 -0700 (PDT) Message-ID: Date: Wed, 4 Apr 2007 13:56:48 -0300 From: super.ismiti To: ns-users@isi.edu, manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [manet] Ad-hockey - borderwidth error X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0774583464==" Errors-To: manet-bounces@ietf.org --===============0774583464== Content-Type: multipart/alternative; boundary="----=_Part_32107_13069373.1175705808578" ------=_Part_32107_13069373.1175705808578 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Somebody could tell me what is "borderwidth"? Because when I run the ad-hockey an error happen and it seems be with something like "borderwidth"... Thanks, Ricardo. ------=_Part_32107_13069373.1175705808578 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

Somebody could tell me what is "borderwidth"?
Because when I run the ad-hockey an error happen and it seems be with something like "borderwidth"...

Thanks,
Ricardo.
------=_Part_32107_13069373.1175705808578-- --===============0774583464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0774583464==-- From manet-bounces@ietf.org Wed Apr 04 13:06:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8vo-00019k-4Z; Wed, 04 Apr 2007 13:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ8vm-00019L-CO; Wed, 04 Apr 2007 13:05:58 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ8vj-0006Zt-39; Wed, 04 Apr 2007 13:05:58 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l34H5iDQ028743; Wed, 4 Apr 2007 13:05:44 -0400 (EDT) Message-Id: <200704041705.l34H5iDQ028743@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007040413054407865 ; Wed, 04 Apr 2007 13:05:44 -0400 From: "Justin Dean" Subject: RE: [manet] Re: [Manet-dt] Review Request Date: Wed, 4 Apr 2007 13:08:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd2McHJbaZkvmq+SsaSTIjsY4EuTgAqMb6g In-Reply-To: <4612BD3C.4060407@inria.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'manet' , manet-dt@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org SMF is designed such that is may run in a stand alone mode where only multicast routing is required or it can be run alongside a unicast protocol (either sharing information or not). In the past there have been some implementations of OLSR which allow for encapsulating packets and using the s-mpr forwarding tree to disiminate the packets to all nodes in the network. This solution works for some networks but was tied to the running of OLSR. SMF takes away that requirement and allows for multicast routing which can be independent of what unicast routing protocol may or may not be running on the network. One application which may help understand the usage might be emergancy response teams using wireless VIP to communicate with others who are close without any specific need for point to point communication. Justin -----Original Message----- From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr] Sent: Tuesday, April 03, 2007 4:47 PM Cc: 'manet'; manet-dt@ietf.org Subject: [manet] Re: [Manet-dt] Review Request Hello, About SMF, I am asking some questions for clarification I don't understand very well the purpose of the protocol. Maybe this is because I don't have a clear view of its application context. Is SMF intended to be the only routing protocol running in a network or will it run together with a unicast protocol? Best regards, Philippe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 04 17:13:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCk4-0007i3-Dx; Wed, 04 Apr 2007 17:10:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZCk3-0007hy-6J for manet@ietf.org; Wed, 04 Apr 2007 17:10:07 -0400 Received: from smtp.humber.ca ([192.75.71.6] helo=artax.humber.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZCjw-0004cy-AW for manet@ietf.org; Wed, 04 Apr 2007 17:10:07 -0400 Received: from artax.humber.ca (127.0.0.1) by artax.humber.ca (MlfMTA v3.2r1b3) id h2ga2c0171ss for ; Wed, 4 Apr 2007 17:09:53 -0400 (envelope-from ) Received: from Denkomobility ([142.214.30.20]) by artax.humber.ca (MAILSCANNER) with ESMTP; Wed, 04 Apr 2007 17:09:53 -0400 Message-ID: <031d01c776fd$9d5475b0$2e02a8c0@Denkomobility> From: "Mieso Denko" To: Date: Wed, 4 Apr 2007 17:10:03 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mlf-Version: 5.0.2.8415 X-Mlf-UniqueId: o200704042109530007897 X-Spam-Score: 0.3 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Subject: [manet] CFP - IST-AWSN'07 - Submission Date: 10 April 2007 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1803794823==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1803794823== Content-Type: multipart/alternative; boundary="----=_NextPart_000_031A_01C776DC.16219210" This is a multi-part message in MIME format. ------=_NextPart_000_031A_01C776DC.16219210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable *** Our apologies if you receive multiple copies of this CFP *** The 2nd International Workshop on Intelligent Systems Techniques for Ad = hoc and Wireless Sensor Networks (IST-AWSN'07) 28 August - 1 September, 2007 http://cs.acadiau.ca/~eshakshu/IST-WSN-2007.htm in conjunction with The Fifth International Symposium on Parallel and Distributed Processing and Applications 28 August - 1 September, 2007 http://www.cs.umanitoba.ca/~ispa07/ Important Workshop Dates: Paper Submission: 10 April 2007 Author Notification: 10 May 2007 Camera-ready Due: 10 June 2007 Location: Niagara Falls, Ontario, Canada. Description: Recent developments of low-cost, low-power, multifunctional wireless sensors have enabled the fast growth of Wireless Sensor Network (WSN) applications, which include security, military, agriculture, automation, environmental and habitat monitoring. WSNs consist of numerous small inexpensive battery powered sensors; each sensor has the capability to process and store the sensor data. A combination of the dense deployment of numerous smart sensors, AI techniques, and intelligent agents can provide continuous real-time monitoring that is precise, accurate, reliable, and inexpensive. This workshop aims to bring together researchers and practitioners working on different aspects of ad-hoc and wireless sensor networks and software agent technology in an effort to highlight the state-of-the-art and discuss the challenges and opportunities to explore new research directions. We strongly welcome submissions that include results which advance the state of the art relating to the theme of the workshop. The main topics to be addressed include (but not limited to): - Adaptive agents in AWSN - Agent security and trust in AWSNs - Agent-based architectures for AWSNs - Agents design issues dealing with reliability, efficiency, and fault tolerance - Database management systems for AWSNs - Distributed management systems for AWSNs - Intelligent data fusion and aggregation - Intelligent query and data dissemination - Intelligent systems for AWSNs - Learning agents in AWSN - Mobile agents in AWSNs - Monitoring agents in AWSN - Peer-to-Peer systems for AWSNs - Power management and energy-efficient protocols - Routing protocols for AWSNs - Safe transmissions of data in AWSNs - Self-organization of AWSNs - Smart energy-efficient routing protocols Publication Only original papers will be considered that have neither been published nor submitted for publication elsewhere, including web publication. All submissions will be handled electronically. The length of the paper is limited to 15 pages. All papers will be reviewed by at least two independent reviewers. Accepted papers will be published in Springer's Lecture Notes in Computer Science workshops proceedings. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Authors of high quality papers presented in the workshop will be invited to submit extended version of their papers for publication in an international journal. Last year, selected papers were extended and accepted for publication in a special issue in the Journal of Information Fusion, Elsevier Science. Workshop Organizers: Elhadi Shakshuki, Acadia University Darcy Benoit, Acadia University Mieso Denko, University of Guelph, Canada ------=_NextPart_000_031A_01C776DC.16219210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

*** Our apologies if you receive multiple copies of this CFP = ***
 
The 2nd International Workshop on Intelligent Systems Techniques = for Ad hoc=20 and Wireless Sensor Networks (IST-AWSN'07)
28 August - 1 September,=20 2007
http://cs.acadiau.ca/~eshakshu/IST-WSN-2007.htm


= in=20 conjunction with The Fifth International Symposium on Parallel=20 and
Distributed Processing and Applications
28 August - 1 = September,=20 2007
http://www.cs.umanitoba.ca/~ispa07/

Important=20 Workshop Dates:
Paper Submission: 10 April 2007
Author = Notification: 10=20 May 2007
Camera-ready Due: 10 June 2007

Location: Niagara = Falls,=20 Ontario, Canada.

Description:

Recent developments of = low-cost,=20 low-power, multifunctional wireless
sensors have enabled the fast = growth of=20 Wireless Sensor Network (WSN)
applications, which include security, = military,=20 agriculture, automation,
environmental and habitat monitoring. WSNs = consist=20 of numerous small
inexpensive battery powered sensors; each sensor = has the=20 capability to
process and store the sensor data. A combination of the = dense=20 deployment
of numerous smart sensors, AI techniques, and intelligent = agents=20 can
provide continuous real-time monitoring that is precise,=20 accurate,
reliable, and inexpensive.

This workshop aims to = bring=20 together researchers and practitioners
working on different aspects = of ad-hoc=20 and wireless sensor networks and
software agent technology in an = effort to=20 highlight the state-of-the-art
and discuss the challenges and = opportunities=20 to explore new research
directions. We strongly welcome submissions = that=20 include results which
advance the state of the art relating to the = theme of=20 the workshop.

The main topics to be addressed include (but not = limited=20 to):

- Adaptive agents in AWSN
- Agent security and trust in=20 AWSNs
- Agent-based architectures for AWSNs
- Agents design issues = dealing=20 with reliability, efficiency, and fault
tolerance
- Database = management=20 systems for AWSNs
- Distributed management systems for AWSNs
- = Intelligent=20 data fusion and aggregation
- Intelligent query and data = dissemination
-=20 Intelligent systems for AWSNs
- Learning agents in AWSN
- Mobile = agents in=20 AWSNs
- Monitoring agents in AWSN
- Peer-to-Peer systems for = AWSNs
-=20 Power management and energy-efficient protocols
- Routing protocols = for=20 AWSNs
- Safe transmissions of data in AWSNs
- Self-organization of = AWSNs
- Smart energy-efficient routing=20 protocols

Publication

Only original papers will be = considered that=20 have neither been published
nor submitted for publication elsewhere,=20 including web publication. All
submissions will be handled = electronically.=20 The length of the paper is
limited to 15 pages. All papers will be = reviewed=20 by at least two
independent reviewers.

Accepted papers will be = published in Springer's Lecture Notes in
Computer Science workshops=20 proceedings. Submission of a paper should be
regarded as a commitment = that,=20 should the paper be accepted, at least
one of the authors will = register and=20 attend the conference to present
the work.

Authors of high = quality=20 papers presented in the workshop will be invited
to submit extended = version=20 of their papers for publication in an
international journal. Last = year,=20 selected papers were extended and
accepted for publication in a = special issue=20 in the Journal of
Information Fusion, Elsevier = Science.


Workshop=20 Organizers:
Elhadi Shakshuki, Acadia University
Darcy Benoit, = Acadia=20 University
Mieso Denko, University of Guelph,=20 Canada
------=_NextPart_000_031A_01C776DC.16219210-- --===============1803794823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1803794823==-- From manet-bounces@ietf.org Thu Apr 05 04:20:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZN9x-0007YN-9H; Thu, 05 Apr 2007 04:17:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZN9w-0007Y8-6k for manet@ietf.org; Thu, 05 Apr 2007 04:17:32 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZN9t-0007zF-Pk for manet@ietf.org; Thu, 05 Apr 2007 04:17:32 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 10:17:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Apr 2007 10:17:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: Acd3WtadohRy7LlqTZWiclOvbP1BUg== From: "zze-FAYAD Elie RD-CORE-CAE" To: X-OriginalArrivalTime: 05 Apr 2007 08:17:20.0635 (UTC) FILETIME=[D4EC0CB0:01C7775A] X-Spam-Score: 1.6 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0824171320==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============0824171320== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7775A.D6DCCAAD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7775A.D6DCCAAD Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Could somebody help me finding a tutorial that teaches how to implement a routing adhoc protocole in the linux core The protocole uses layer Ip and Tcp =20 Regards Elie=20 ------_=_NextPart_001_01C7775A.D6DCCAAD Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

Could somebody help me finding a = tutorial that teaches how to implement a routing adhoc protocole in the = linux core
The protocole uses layer Ip and = Tcp
 

Regards
Elie

------_=_NextPart_001_01C7775A.D6DCCAAD-- --===============0824171320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0824171320==-- From manet-bounces@ietf.org Thu Apr 05 05:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZO7H-0004oB-If; Thu, 05 Apr 2007 05:18:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZO7F-0004o3-EO for manet@ietf.org; Thu, 05 Apr 2007 05:18:49 -0400 Received: from ee.tamu.edu ([165.91.241.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZO7E-0003uJ-0h for manet@ietf.org; Thu, 05 Apr 2007 05:18:49 -0400 Received: from ECE149 (ece149.tamu.edu [165.91.208.72]) by ee.tamu.edu (8.13.6/8.13.6) with SMTP id l359IgE6009834; Thu, 5 Apr 2007 04:18:43 -0500 (CDT) Message-ID: <002201c77763$6913a030$48d05ba5@ECE149> From: "Dr. Xi Zhang" To: Date: Thu, 5 Apr 2007 04:18:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: Subject: [manet] April 10, 2007, Deadline extended: ACM IWCMC 2007, Aug 12, 2007, Honolulu, Hawaii, USA. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org *Sorry for receiving multiple copies* Submissions: EDAS --> Deadline extened to April 10, 2007. Call For Papers for ACM IWCMC 2007: _____________________ ACM IWCMC 2007 (http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) August 12-16, 2007, Honolulu, Hawaii, USA Technical Sponsors: ACM (Approved) and IEEE (Pending) Submissions: EDAS --> Deadline extended to April 10, 2007. "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" The ACM International Wireless Communications and Mobile Computing Conference 2007 (ACM IWCMC 2007) will be held in Turtle Bay Resort Hotel, Honolulu, Hawaii, USA during August 12-16, 2007. Under our new theme of "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" , IWCMC2007 is targeting at a wide spectrum of state-of-the-art as well as emerging topics pertaining to wireless networks, communications, and mobile computing. Continuing the great succeed of ACM IWCMC 2006 last year, IWCMC 2007 is anticipated to attract an even larger volume of high quality submissions and stimulate the cutting-edge research discussions amongst many academic pioneering researchers/scientists and industrial engineers/leaders attendees from all around the world as was evidenced during ACM IWCMC 2006. The ACM IWCMC 2007 program will feature a General Symposium, 8 Specific Technical Symposia, Workshop, and Tutorials Sessions. Prospective authors are invited to submit original technical papers to the corresponding IWCMC 2007 Symposia as listed below for oral presentation at IWCMC 2007 and publication in the IWCMC 2007 Conference Proceedings. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ We're pleased to announce the following: [1] Professor Gordon Stuber from Georgia Tech, USA, who is the world-class leader in mobile wireless communications/networking, communication signal processing, and many other areas, has agreed to be the Keynote Speaker for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [2] "NTT DoCoMo USA", which is one of most famous companies in the mobile communications industries, has officially become the Financial Sponsor for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [3] ACM has officially become the technical sponsor for IWCMC 2007 (this was notified earlier) and all the accepted IWCMC 2007 papers will be included into the ACM Database. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ IWCMC 2007 General Organizing Committee: General Co-Chairs: Mohsen Guizani, Western Michigan University, USA, Email: mguizani@ieee.org Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan, Email: hshwchen@comm.nsysu.edu.tw Technical Program Committee Chair: Xi Zhang, Texas A&M University, USA, Email: xizhang@ece.tamu.edu Financial Chair: Eun K. Park, University of Missouri at Kansas City, USA, Email: ekpark@umkc.edu IWCMC 2007 Technical Symposia: General Symposium: Chair: Xuemin (Sherman) Shen, University of Waterloo, Canada, xshen@bbcr.uwaterloo.ca Co-Chairs: Dongmei Zhao, McMaster University, Canada, dzhao@mail.ece.mcmaster.ca Hai Jiang, Princeton University, USA, haijiang@princeton.edu (1) Communication and Information Theory Symposium: Chair: Hamid Sadjadpour, University of California, Santa Cruz, USA, hamid@soe.ucsc.edu Ravi Narasimhan, University of California, Santa Cruz, USA ravi@soe.ucsc.edu (2) Computer and Network Security Symposium: Chair: Xiaojiang (James) Du, North Dakota State University, USA, xiaojiang.du@ndsu.edu Co-Chairs: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org, Yong Guan, Iowa State University, USA, guan@iastate.edu (3) Cross-Layer Optimized Wireless Networks Symposium: Chair: Xi Zhang, Texas A&M University, USA, xizhang@ece.tamu.edu Co-Chairs: Weihua Zhuang, University of Waterloo, Canada, wzhuang@ece.uwaterloo.ca Sunghyun Choi, Seoul National University, Korea, schoi@snu.ac.kr Kun Yang, University of Essex, UK, kunyang@essex.ac.uk (4) MIMO Systems Symposium: Chair: Zhengyuan Xu, University of California, Riverside, USA, dxu@ee.ucr.edu Co-Chairs (in alphabet order): Javier Garcia-Frias, University of Delaware, USA, jgarcia@ee.udel.edu Mounir Ghogho, Leeds University, UK, m.ghogho@leeds.ac.uk Weifeng Su, State University of New York (SUNY) at Buffalo, USA, weifeng@eng.buffalo.edu Liuqing Yang, University of Florida, USA, lqyang@ece.ufl.edu (5) Mobile Computing Symposium: Chair: Jie Li, University of Tsukuba, Japan, lijie@cs.tsukuba.ac.jp (6) Multimedia over Wireless Symposium: Chairs: Haohong Wang, Marvell Technology Group, USA, haohongwang@yahoo.com (7) Next Generation Mobile Networks Symposium (Website Link): Chair: Victor Leung, The University of British Columbia, Canada, vleung@ece.ubc.ca Co-Chairs: Ekram Hossain, University of Manitoba, Canada, ekram@ee.umanitoba.ca Javan Erfanian, Bell Mobility, Canada, javan.erfanian@bell.ca (8) Wireless Sensor Networks Symposium: Chair: Yang Yang, University College London, United Kingdom, y.yang@ee.ucl.ac.uk (9) Wireless LANs and Wireless PANs Symposium: Chair: Ehab Elmallah, University of Alberta, Canada, Canada, ehab@cs.ualberta.ca Co-Chair: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org (10) Workshop Chair: Song Ci, University of Nebraska-Lincoln, USA sci@engr.unl.edu Co-Chair: Yi Cui, Vanderbilt University, USA yi.cui@vanderbilt.edu IMPORTANT DATES: Full Paper Submission: April 10, 2007 (updated) Notification of Acceptance: May 30, 2007 Camera-Ready Version/Copyright Form Submission: June 11, 2007 Registration Deadline for Authors: June 11, 2007 Hotel Reservation Deadline: July 10, 2007 _____________________ ========================================================================= Xi Zhang Assistant Professor Dept. of Elec. & Comput. Engin. Phone: 979-458-1416 Texas A&M University Fax: 979-845-2630 333N WERC Building Email: xizhang@ece.tamu.edu College Station, Texas 77843, USA URL http://dropzone.tamu.edu/~xizhang ========================================================================= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 05 10:06:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSZu-00069u-Ve; Thu, 05 Apr 2007 10:04:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZSZs-00068S-S9 for manet@ietf.org; Thu, 05 Apr 2007 10:04:40 -0400 Received: from engmail.uwaterloo.ca ([129.97.50.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZSZq-00042a-DP for manet@ietf.org; Thu, 05 Apr 2007 10:04:40 -0400 Received: from Lingling (CPE001346f55609-CM0018c0b394a4.cpe.net.cable.rogers.com [74.109.117.25]) (authenticated bits=0) by engmail.uwaterloo.ca (8.13.1/8.13.1) with ESMTP id l35E4XoI058363 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 5 Apr 2007 10:04:34 -0400 (EDT) (envelope-from j7luo@engmail.uwaterloo.ca) Message-ID: <004a01c7778b$5e2a52e0$6400a8c0@Lingling> From: "UWaterloo-Luo" To: Date: Thu, 5 Apr 2007 10:04:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Virus-Scanned: ClamAV version 0.90, clamav-milter version devel-120207 on engmail.uwaterloo.ca X-Virus-Status: Clean X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, DK_POLICY_SIGNSOME autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on engmail.uwaterloo.ca X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Subject: [manet] Last Call For Papers -- WiMAN 2007: Workshop on Wireless Mesh and Ad Hoc Networks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org [Apologies if you receive multiple copies of this CFP] ---------------------------------------------------------------------------------------- First International Workshop on Wireless Mesh and Ad Hoc Networks (WiMAN'07) Honolulu, Hawaii, USA, August 16, 2007 in conjunction with ICCCN 2007. http://www.cs.iusb.edu/~liqzhang/WiMAN2007/index.htm Submission Deadline: April 6th, 2007 (extended, firm) Distinguished papers will be invited to extend to full version for a special issue of Elsevier's Computer Communications Journal (ComCom). ************************************************************************** Recently, wireless mesh networking is attracting significant interest from academia, industry, and standard organizations. With several favorable characteristics, such as dynamic self-organization, self-configuration, self-healing, easy maintenance, high scalability and reliable services, wireless mesh networks have been advocated as a cost-effective approach to support high-speed last mile connectivity and ubiquitous broadband access in the context of home networking, enterprise networking, or community networking. Despite recent advances, and the technical accumulations from more than a decade's research effort in mobile ad hoc networks, many research issues remain in all protocol layers of wireless mesh networks. For example, the introducing of mixed (infrastructure and ad hoc) architecture, multi-radio, multi-channel, and multi-antenna, have brought new challenges in the design of physical, MAC, and routing protocols. New application scenarios, such as all-wireless office, are urging researchers to address enhanced QoS support and various security issues in the design of different protocol layers for wireless mesh networks. This workshop aims to bring together the technologies and researchers who share interest in the area of wireless mesh and ad hoc networks. The main purpose is to promote discussions of research and relevant activities in the design of architectures, protocols, algorithms, services, and applications for wireless networks. It also aims at increasing the synergy between academic and industry professionals working in this area. We plan to seek papers that address theoretical, experimental, and work in-progress at the all layers of wireless mesh and ad hoc networks, from application layer to the physical layer. Topics covered by the workshop will include, but are not limited to, the following: Multi-radio and multi-channel wireless mesh networking Wireless LAN, PAN, MAN and WAN Multi-hop wireless communications and ad hoc networking MAC protocols (IEEE 802.11, 802.15, 802.16, 802.20, and beyond) Routing, scheduling, and channel assignment protocols Implications of smart antennas on MAC and routing protocols Quality of Services provisioning Multimedia communications over mesh and ad hoc networks Network deployment, localization, and synchronization Topology construction and maintenance Methods and tools for mesh and ad hoc networks simulation Modeling and performance evaluations Physical layer techniques Cross layer optimizations Power-aware and energy-efficient protocols and algorithms Self-organization, self-configuration network architectures Intelligent system techniques for mesh and ad hoc networks Security-related issues in mesh and ad hoc networks Testbed, prototype, and practical systems Novel applications of mesh and ad hoc networks Wireless sensor networks and RFID Important Dates --------------- Paper submission due: 11:59PM EDT, April 6, 2007 (extended, firm) Acceptance notification: May 11, 2007 Camera-ready due: June 1, 2007 Workshop: August 16, 2007 Submissions and Publications ---------------------------- Technical papers describing original, previously unpublished research, not currently under review somewhere else, are solicited. Submissions should include an abstract, key words, the e-mail address of the corresponding author. The length of the papers should be limited up to 6 pages in standard IEEE camera-ready format (double-column, 10-pt font). Please check the workshop webpage for detailed submission instructions. http://www.cs.iusb.edu/~liqzhang/WiMAN2007/index.htm Submission of a paper should be regarded as an undertaking that, should the paper be accepted, at least one of the authors will register and attend the workshop to present the work. All papers will be peer reviewed and the comments will be provided to the authors. All accepted papers will be published in workshop proceeding by IEEE Communications Society and IEEE Digital Library, or Springer's Lecture Notes in Computer Science. Distinguished papers will be invited to extend to full version for a special issue of Elsevier's Computer Communications Journal (ComCom) on Wireless Mesh Networks. The special issue will be published in early 2008. Organizing Committees --------------------- Workshop Program Co-Chairs Liqiang Zhang, Indiana University South Bend, USA (liqzhang@cs.iusb.edu) Dakai Zhu, University of Texas at San Antonio, USA (dzhu@cs.utsa.edu) Publicity Chair Jun Luo, University of Waterloo, Canada (j7luo@engmail.uwaterloo.ca) Technical Program Committee Malik Audeh, Tropos Networks, USA Edoardo S. Biagioni, University of Hawaii at Manoa, USA Luciano Bononi, University of Bologna, Italy Raffaele Bruno, IIT-CNR, Italy Surendar Chandra, University of Notre Dame, USA Guihai Chen, Nanjing University, China Christian Hartmann, Technical University of Munich, Germany Anders Host-Madsen, University of Hawaii at Manoa, USA Holger Karl, University of Paderborn, Germany Daeyoung Kim, Information and Communications University, Korea Sandeep Kulkarni, Michigan State University, USA Hyunjeong hannah Lee, Intel Research, USA Guoqing Li, Intel Research, USA Hock Beng Lim, Nanyang Technological University, Singapore Wei Lou, Hong Kong Polytechnic University, Hongkong Jun Luo, University of Waterloo, Canada Frank Reichenbach, University of Rostock, Germany Paolo Santi, IIT-CNR, Italy Kaoru Sezaki, University of Tokyo, Japan Weisong Shi, Wayne State University, USA Pavan Sikka, CSIRO, Australia David Surma, Indiana University South Bend, USA Ali Tosun, University of Texas at San Antonio, USA Jean-Phillippe Vasseur, Cisco Systems, USA Zhijun Wang, Hong Kong Polytechnic University, Hongkong Yuan Xue, Vanderbilt University, USA Stephen Yang, National Central University, Taiwan Advisory Committee Hossein Hakimzadeh, Indiana University South Bend, USA Sharon Hu, University of Notre Dame, USA Yingbo Hua, University of California Riverside, USA Sitharama Iyengar, Louisiana State University, USA Bahar Sadeghi, Intel Research, USA Loren Schwiebert, Wayne State University, USA Wei Zhao, Texas A&M University, USA ****************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 05 13:51:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZW6K-0008BG-0H; Thu, 05 Apr 2007 13:50:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZW6I-0008BB-IX for manet@ietf.org; Thu, 05 Apr 2007 13:50:22 -0400 Received: from syssoft.uni-trier.de ([136.199.54.243] helo=tamdhu.uni-trier.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZW6E-0001K6-T3 for manet@ietf.org; Thu, 05 Apr 2007 13:50:22 -0400 Received: from notebookhannes (tamdhu.uni-trier.de [136.199.54.243]) by tamdhu.uni-trier.de (Postfix) with ESMTP id 0D5721D009D for ; Thu, 5 Apr 2007 19:50:11 +0200 (CEST) From: "Hannes Frey" To: Date: Thu, 5 Apr 2007 19:49:41 +0200 Message-ID: <003001c777aa$ca31b770$b02f3557@notebookhannes> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd3qsnGfryoUAqRQyiZLb4dIM8wPQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Subject: [manet] Final Call for Papers - LOCALGOS 2007 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org = ----------------------------------------------------------------------- Our apologies if you receive duplicates of this posting. Please feel free to distribute it to those who might be interested. = ----------------------------------------------------------------------- = *********************************************************************** * CALL FOR PAPERS = * * = * * LOCALGOS 2007 = * * = * * First International Workshop on Localized Algorithms and Protocols = * * for Wireless Sensor Networks = * * http://ants.dif.um.es/localgos07 = * * = * * In conjunction with the IEEE International Conference on = * * Distributed Computing in Sensor Systems (DCOSS 2007) = * * www.dcoss.org = * * = * * June 18 - 20, 2007 = * * Santa Fe, New Mexico, USA = * * = * * Extended Submission Deadline: April 13, 2007 = * = *********************************************************************** Wireless sensor networks consist of a large set of embedded devices each having limited computation and communication capabilities. By using = wireless multihop communication, small chunks of collected data are aggregated = and sent towards some selected data sinks. In this way individual = measurements emerge to a global picture of the entire physical phenomenon. Wireless sensor networks enable rapid deployment, require minimum maintenance = effort, and have minimum influence on the measured phenomenon. It is envisioned = that in many application scenarios sensor networks will lead us beyond the = scale, precision, and detail of what we can measure with traditional techniques today. Sensor networks may have hundreds or thousands of nodes, with limited = energy supplies and communication capabilities. Thus, it is of paramount = importance for the networking algorithms and protocols to be able to scale with a = very large number of devices. The main paradigm shift to achieve those = desirable properties is to apply localized (or greedy) schemes as opposed to = existing protocols requiring global information. Localized algorithms are = distributed algorithms where simple local node behavior achieves a desired global objective. Localized protocols provide scalable solutions, that is, solutions for wireless networks with an arbitrary number of nodes, which = is the main goal of this plan. This workshop will bring together researchers working in the field of localized algorithms and protocols for wireless sensor networks. The = main objective is on data communication, topology control, sensor coverage, = and sensor localization. Data communication problems are those in which one = or multiple sources need to send data to one or multiple destinations. They include among others, unicast and multicast routing, geocasting and data gathering. In the routing problem a path is created to allow the data = source to send packets to one (unicast) or multiple (multicast) destinations. Geocasting consist of sending a data packet to all sensor nodes within a pre-defined geographic area. In the data gathering problem, data from a = set of sensor nodes is collected and transmitted toward one or multiple (eventually mobile) base stations. Topology control algorithms and = protocols include problems such as neighbor detection, boundary detection, and = network organization problems in which a subset of the original topology = satisfying some properties is obtained. Examples of topology control problems are computation of dominating sets, planar graphs, and energy efficient sub topologies. Sensor coverage denotes the ability of a sensor network to = cover each point in a given area by a certain minimum number of sensor nodes. Localized coverage control includes energy conserving sleep cycles, and autonomous mobile sensor nodes which collaboratively move to achieve a desired area coverage. The majority of localized protocols require that nodes are aware of their physical position. In relative positioning such information is made available by means of distance measurements between neighboring nodes and triangulation, while the distance between two = neighbor nodes is estimated by measuring the received signal strength. SCOPE ----- The main objective of the workshop is to present state of the art = research results in the area of localized algorithms and protocols for wireless sensor networks. The workshop covers among others the following research topics (not limited to): - Unicast and multicast routing - Broadcasting - Energy-efficient and bandwidth-efficient communication=20 - Security in wireless sensor networks - Data management, query processing and data delivery - Topology construction and maintenance in wireless sensor networks - Localized protocols for duty-cycled sensor networks - Geocasting techniques for wireless sensor networks - Auto-configuration and network formation protocols and algorithms - Relative positioning algorithms - Lower bounds on information exchange required for localized solutions - Network graph properties supporting localized protocols - Worst and average case analysis on the deviation from optimal = solutions IMPORTANT DATES --------------- Manuscript Submission: April 13, 2007 Acceptance Notification: April 27, 2007 Final Manuscript Due: May 10, 2007 PAPER SUBMISSION ---------------- Submitted manuscripts may not exceed 12 single-spaced pages using = 12-point size font on 8.5x11 inch pages, including figures and tables. References = may be included in addition to the 12 pages. Submissions will be judged on correctness, originality, technical strength, significance, quality of presentation, and interest and relevance to the workshop attendees. Submitted papers may not have appeared in or be under consideration for another conference or a journal. Accepted papers will be published in = the workshop proceedings of the International Conference on Distributed Computing in Sensor Systems (DCOSS 2007). Please submit papers via Easy Chair by using the following URL: http://www.easychair.org/LOCALGOS07/. In case of trouble with the = submission you may send your publication by email to both program co-chairs (pedrom = at dif.um.es, frey at imada.sdu.dk). GENERAL CHAIR ------------- Ivan Stojmenovic, SITE, University of Ottawa PROGRAM CO-CHAIR ---------------- Pedro M. Ruiz Martinez, University of Murcia, Spain Hannes Frey, IMADA, University of Southern Denmark=20 PROGRAM COMMITTEE ----------------- Raffaele Bruno, IIT-CNR, Italy=20 Silvia Giordano, University of Applied Science, SUPSI, Switzerland=20 Isabelle Guerin Lassous, INRIA Rhone Alpes, France=20 Francois Ingelrest, EPFL, Lausanne, Swizerland=20 Lars M. Kristensen, University of Aarhus, Denmark=20 Thomas Kunz, Carleton University, Canada=20 Miguel A. Labrador, Univ. South Florida, USA=20 Hai Liu, SITE, University of Ottawa, Canada=20 Norbert Luttenberger, Universitat Kiel, Germany=20 Pietro Manzoni, Univ. Politecnica de Valencia, Spain=20 Mikhail Nesterenko, Kent State University, USA Luis Orozco, Univ. Castilla La Mancha, Spain=20 Josep Paradells, Technical University of Catalonia (UPC), Spain=20 Sumesh J Philip, Western Illinois University, USA S. S. Ravi, State University of New York at Albany, USA=20 Steffen Rothkugel, University of Luxemburg=20 Stefan Ruehrup, SITE, University of Ottawa, Canada=20 Gregor Schiele, Universit=E4t Mannheim _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 05 14:56:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZX77-0002l2-DD; Thu, 05 Apr 2007 14:55:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZX75-0002ep-2Z; Thu, 05 Apr 2007 14:55:15 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZWx8-0001VP-Oo; Thu, 05 Apr 2007 14:45:00 -0400 Received: from [192.168.0.3] (AVelizy-152-1-33-192.w82-120.abo.wanadoo.fr [82.120.124.192]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l35IipP4006831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Apr 2007 20:44:52 +0200 Message-ID: <461543A5.4070400@inria.fr> Date: Thu, 05 Apr 2007 20:44:53 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Justin Dean Subject: Re: [manet] Re: [Manet-dt] Review Request References: <200704041705.l34H5iDQ028743@s2.itd.nrl.navy.mil> In-Reply-To: <200704041705.l34H5iDQ028743@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at discorde with ID 461543A3.004 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by discorde.inria.fr id l35IipP4006831 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'manet' , manet-dt@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A network with never a call to unicast routing? Do you have an example=20 of this? Philippe Justin Dean a =E9crit : > SMF is designed such that is may run in a stand alone mode where only > multicast routing is required or it can be run alongside a unicast prot= ocol > (either sharing information or not). In the past there have been some > implementations of OLSR which allow for encapsulating packets and using= the > s-mpr forwarding tree to disiminate the packets to all nodes in the net= work. > This solution works for some networks but was tied to the running of OL= SR. > SMF takes away that requirement and allows for multicast routing which = can > be independent of what unicast routing protocol may or may not be runni= ng on > the network. =20 >=20 > One application which may help understand the usage might be emergancy > response teams using wireless VIP to communicate with others who are cl= ose > without any specific need for point to point communication. >=20 > Justin >=20 > -----Original Message----- > From: Philippe Jacquet [mailto:philippe.jacquet@inria.fr]=20 > Sent: Tuesday, April 03, 2007 4:47 PM > Cc: 'manet'; manet-dt@ietf.org > Subject: [manet] Re: [Manet-dt] Review Request >=20 > Hello, >=20 > About SMF, I am asking some questions for clarification >=20 > I don't understand very well the purpose of the protocol. Maybe this is > because I don't have a clear view of its application context. >=20 > Is SMF intended to be the only routing protocol running in a network or= will > it run together with a unicast protocol? >=20 > Best regards, >=20 > Philippe >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 > _______________________________________________ > Manet-dt mailing list > Manet-dt@ietf.org > https://www1.ietf.org/mailman/listinfo/manet-dt >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 05 18:18:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZaGL-0003TE-JB; Thu, 05 Apr 2007 18:17:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZaGJ-0003T5-DA for manet@ietf.org; Thu, 05 Apr 2007 18:16:59 -0400 Received: from psmtp02.wxs.nl ([195.121.247.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZaGI-0004Fa-3N for manet@ietf.org; Thu, 05 Apr 2007 18:16:59 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by psmtp02.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JG10049OPW6P1@psmtp02.wxs.nl> for manet@ietf.org; Fri, 06 Apr 2007 00:16:57 +0200 (MEST) Date: Fri, 06 Apr 2007 00:18:14 +0200 From: Teco Boot To: macker@itd.nrl.navy.mil, ian.chakeres@gmail.com Message-id: <003601c777d0$4eb7f4d0$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acd3z4JNv0zhymm0Rq+Q9McsGDRkdQAAIgzQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: manet@ietf.org Subject: [manet] FW: Intended status of produced IDs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0342106085==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============0342106085== Content-type: multipart/alternative; boundary="Boundary_(ID_MFhufAJgQe59Ks1f3ncEeA)" This is a multi-part message in MIME format. --Boundary_(ID_MFhufAJgQe59Ks1f3ncEeA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, During the IETF-68 MANET WG meeting, I heard the target for the current I-D MANET protocols is Experimental. The drafts itself mention Standards Track (OLSRv2 mentions nothing). Are there minutes of the meeting published? Can the chair provide the target for the drafts? Teco --Boundary_(ID_MFhufAJgQe59Ks1f3ncEeA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

 

During the IETF-68 MANET WG meeting, I heard the target for the current I-D MANET protocols is Experimental.

The drafts itself mention Standards Track (OLSRv2 mentions nothing).

Are there minutes of the meeting published?

Can the chair provide the target for the drafts?

 

Teco

--Boundary_(ID_MFhufAJgQe59Ks1f3ncEeA)-- --===============0342106085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0342106085==-- From manet-bounces@ietf.org Thu Apr 05 18:54:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZapr-0000cN-DJ; Thu, 05 Apr 2007 18:53:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZapq-0000cI-7K for manet@ietf.org; Thu, 05 Apr 2007 18:53:42 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZapo-0003NE-Nf for manet@ietf.org; Thu, 05 Apr 2007 18:53:42 -0400 Received: from [192.168.0.2] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l35MrU7w014826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Apr 2007 00:53:30 +0200 Message-ID: <46157DE8.10803@inria.fr> Date: Fri, 06 Apr 2007 00:53:28 +0200 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: manet@ietf.org Subject: Re: [manet] FW: Intended status of produced IDs References: <003601c777d0$4eb7f4d0$0202a8c0@Teco> In-Reply-To: <003601c777d0$4eb7f4d0$0202a8c0@Teco> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at discorde with ID 46157DEA.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by discorde.inria.fr id l35MrU7w014826 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Teco, SMF is targeted as experimental. OLSRv2 and DYMO are targeted as=20 standards track. Emmanuel Teco Boot a =E9crit : > Hi, >=20 > =20 >=20 > During the IETF-68 MANET WG meeting, I heard the target for the current= =20 > I-D MANET protocols is Experimental. >=20 > The drafts itself mention Standards Track (OLSRv2 mentions nothing). >=20 > Are there minutes of the meeting published? >=20 > Can the chair provide the target for the drafts? >=20 > =20 >=20 > Teco >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 06 04:44:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZk1I-0005vu-Mf; Fri, 06 Apr 2007 04:42:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZk1H-0005vg-2h for manet@ietf.org; Fri, 06 Apr 2007 04:42:07 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZk1F-0007sF-OZ for manet@ietf.org; Fri, 06 Apr 2007 04:42:07 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1175848922!6059490!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 2953 invoked from network); 6 Apr 2007 08:42:02 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-12.tower-128.messagelabs.com with SMTP; 6 Apr 2007 08:42:02 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l368g0ox026647; Fri, 6 Apr 2007 03:42:02 -0500 (CDT) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l368fxOe006016; Fri, 6 Apr 2007 03:41:59 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l368fvcc006005; Fri, 6 Apr 2007 03:41:58 -0500 (CDT) Message-ID: <461607D5.4060000@gmail.com> Date: Fri, 06 Apr 2007 10:41:57 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [manet] FW: Intended status of produced IDs References: <003601c777d0$4eb7f4d0$0202a8c0@Teco> <46157DE8.10803@inria.fr> In-Reply-To: <46157DE8.10803@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Emmanuel Baccelli wrote: > Hi Teco, > SMF is targeted as experimental. OLSRv2 and DYMO are targeted as > standards track. Why two standards track documents? Why can't it be just one protocol? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 06 05:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZkcU-0003yg-HC; Fri, 06 Apr 2007 05:20:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZkcT-0003x9-7a for manet@ietf.org; Fri, 06 Apr 2007 05:20:33 -0400 Received: from smtp15.wxs.nl ([195.121.247.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZkcQ-00061u-P2 for manet@ietf.org; Fri, 06 Apr 2007 05:20:33 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by smtp15.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JG2000NPKLQGN@smtp15.wxs.nl> for manet@ietf.org; Fri, 06 Apr 2007 11:20:17 +0200 (CEST) Date: Fri, 06 Apr 2007 11:21:33 +0200 From: Teco Boot In-reply-to: <46157DE8.10803@inria.fr> To: 'Emmanuel Baccelli' Message-id: <005001c7782c$f87e0110$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd31cYuNnnekDfCRe+XrLi1dWWj2QAVWzvg X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: manet@ietf.org Subject: [manet] Intended status of produced IDs X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thanks for clarification. Be aware getting a standards track RFC approved could be hard. It needs consensus in the WG. And would alternative Experimental protocols (3561, 3626, 3684, 4728) get obsolete? My personal idea on SMF, the DPD part is ready for standards track; it fills in something missing and it can be reused for unicast traffic also, for protecting a network for melting down due to routing loops. Unsynchronized routing table updates introduce routing loops, a problem when using proactive protocols. Teco Emmanuel wrote: > SMF is targeted as experimental. OLSRv2 and DYMO are targeted as > standards track. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 06 08:18:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZnMf-0003O9-8y; Fri, 06 Apr 2007 08:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZnMe-0003O4-DQ for manet@ietf.org; Fri, 06 Apr 2007 08:16:24 -0400 Received: from smtp14.wxs.nl ([195.121.247.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZnMd-0004ta-1T for manet@ietf.org; Fri, 06 Apr 2007 08:16:24 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by smtp14.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JG2006E8SQS1H@smtp14.wxs.nl> for manet@ietf.org; Fri, 06 Apr 2007 14:16:08 +0200 (CEST) Date: Fri, 06 Apr 2007 14:17:24 +0200 From: Teco Boot Subject: RE: [manet] Re: [Manet-dt] Review Request In-reply-to: <461543A5.4070400@inria.fr> To: 'Philippe Jacquet' , 'Justin Dean' Message-id: <005101c77845$890aee60$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd3tLeD7+AWA3RETUG5P6iUmeSbCwAj11DA X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Philippe wrote: > A network with never a call to unicast routing? Do you have an example > of this? [Teco] In military and public safety / emergency response networks, situational awareness is the primary application. Most of these applications are multicast only. For voice, netted voice (push-to-talk) is used, also multicast only. Some applications use unicast for signaling, but this could introduce server dependency which is not always acceptable. Some think "always not acceptable". Unicast support is secondary. Background: current infrastructures use single hop broadcast type radios and data over these radios is broadcast / multicast by nature. Newly designed infrastructures inherit the characteristics. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 06 09:24:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZoP1-00035k-9O; Fri, 06 Apr 2007 09:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZoP0-00035c-2F for manet@ietf.org; Fri, 06 Apr 2007 09:22:54 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZoOv-00034T-NC for manet@ietf.org; Fri, 06 Apr 2007 09:22:54 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l36DMWpp005576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Apr 2007 06:22:47 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l36DMWmW018978; Fri, 6 Apr 2007 08:22:32 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l36DMGpk018620; Fri, 6 Apr 2007 08:22:31 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 06:22:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: [Manet-dt] Review Request Date: Fri, 6 Apr 2007 06:22:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6A2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <005101c77845$890aee60$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: [Manet-dt] Review Request Thread-Index: Acd3tLeD7+AWA3RETUG5P6iUmeSbCwAj11DAAAJy+LA= References: <461543A5.4070400@inria.fr> <005101c77845$890aee60$0202a8c0@Teco> From: "Templin, Fred L" To: "Teco Boot" X-OriginalArrivalTime: 06 Apr 2007 13:22:21.0645 (UTC) FILETIME=[9B964FD0:01C7784E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Teco, I don't disagree that multicast is important, but I think you would have to agree that other uses require careful consideration. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Friday, April 06, 2007 5:17 AM > To: 'Philippe Jacquet'; 'Justin Dean' > Cc: 'manet' > Subject: RE: [manet] Re: [Manet-dt] Review Request >=20 >=20 > Philippe wrote: > > A network with never a call to unicast routing? Do you have=20 > an example > > of this? >=20 > [Teco]=20 > In military and public safety / emergency response networks,=20 > situational > awareness is the primary application. Most of these applications are > multicast only. For voice, netted voice (push-to-talk) is used, also > multicast only. Some applications use unicast for signaling,=20 > but this could > introduce server dependency which is not always acceptable. Some think > "always not acceptable". > Unicast support is secondary. > Background: current infrastructures use single hop broadcast=20 > type radios and > data over these radios is broadcast / multicast by nature.=20 > Newly designed > infrastructures inherit the characteristics. >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 06 10:12:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpAB-0002xE-99; Fri, 06 Apr 2007 10:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpA9-0002mk-08 for manet@ietf.org; Fri, 06 Apr 2007 10:11:37 -0400 Received: from bay0-omc3-s23.bay0.hotmail.com ([65.54.246.223]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZpA7-0002h8-MV for manet@ietf.org; Fri, 06 Apr 2007 10:11:36 -0400 Received: from BAY108-W17 ([65.54.162.117]) by bay0-omc3-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 6 Apr 2007 07:11:35 -0700 Message-ID: X-Originating-IP: [193.49.124.107] From: mohammad diab To: Date: Fri, 6 Apr 2007 14:11:35 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 06 Apr 2007 14:11:35.0112 (UTC) FILETIME=[7BFD9C80:01C77855] X-Spam-Score: 3.8 (+++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0166875129==" Errors-To: manet-bounces@ietf.org --===============0166875129== Content-Type: multipart/alternative; boundary="_1774c06f-ef1c-461c-9ce4-8ab3bca4119e_" --_1774c06f-ef1c-461c-9ce4-8ab3bca4119e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello every body, Please can anybody tell me why broadcast messages(hello packets in OLSR for= example) are sent at 2 Mbits/s in a multihop network, and consequently in = an ad hoc networks? Where this information is defined? in the standard ? The rate we define in the iwconfig is the rate of what? of data packets onl= y? =20 I'm doing a training in on order to achieve my Masters degree. Thank you in advance =20 Sincerly, Mohammad Diab. _________________________________________________________________ Take a break and play crossword puzzles - FREE! http://games.msn.com/en/flexicon/default.htm?icid=3Dflexicon_ wlmemailtagli= nemarch07= --_1774c06f-ef1c-461c-9ce4-8ab3bca4119e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello every body,
Please can anybody tell me why broadcast messages(hello packets in OLSR for= example) are sent at 2 Mbits/s in a multihop network, and consequently in = an ad hoc networks?
Where this information is defined? in the standard ?
The rate we define in the iwconfig is the rate of what? of data packets onl= y?
 
I'm doing a training in on order to achieve my Masters degree.
Thank you in advance
 
Sincerly,
Mohammad Diab.

Take a break and play crossword puzzles - FRE= E! Play Now! = --_1774c06f-ef1c-461c-9ce4-8ab3bca4119e_-- --===============0166875129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0166875129==-- From manet-bounces@ietf.org Fri Apr 06 12:30:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZrJN-00068F-QI; Fri, 06 Apr 2007 12:29:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZrJM-000689-UX for manet@ietf.org; Fri, 06 Apr 2007 12:29:16 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZrJL-0002bv-FZ for manet@ietf.org; Fri, 06 Apr 2007 12:29:16 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l36GSEA8029709; Fri, 6 Apr 2007 19:29:04 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 19:28:14 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 11:28:12 -0500 Received: from [10.162.67.120] ([10.162.67.120]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 11:28:11 -0500 Message-ID: <4616750C.2080805@nokia.com> Date: Fri, 06 Apr 2007 09:27:56 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Alexandru Petrescu Subject: Re: [manet] FW: Intended status of produced IDs References: <003601c777d0$4eb7f4d0$0202a8c0@Teco> <46157DE8.10803@inria.fr> <461607D5.4060000@gmail.com> In-Reply-To: <461607D5.4060000@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2007 16:28:11.0601 (UTC) FILETIME=[917A9410:01C77868] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Emmanuel Baccelli , manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Alex, Your short question hides several Ph.Ds worth of answers. In fact, there can be one protocol, but it is far from trivial to do it. First, you must allow some routes to be proactively maintained, and which ones are to be reactively maintained. Then, you must ask yourself to design a mechanism by which proactively maintained routes do not disturb uninvolved nodes. Once you have answered these difficult questions, you can progress to answering the impossible question: - How are policies set to determine which routes are proactively maintained and which are reactive. My opinion is that this is a very subtle matter and should be controlled by application requirements, and by service availabilities. Alternatively, you could take the sledge hammer approach and just invalidate either OLSR or DYMO (or both :-). On the positive side, I am very much in favor of making a single protocol. I think we are a few months away from being able to initiate that effort. Regards, Charlie P. ext Alexandru Petrescu wrote: > Emmanuel Baccelli wrote: >> Hi Teco, >> SMF is targeted as experimental. OLSRv2 and DYMO are targeted as >> standards track. > > Why two standards track documents? Why can't it be just one protocol? > > Alex _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 08 06:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaUqL-0004jy-M4; Sun, 08 Apr 2007 06:41:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaUqJ-0004jl-KQ for manet@ietf.org; Sun, 08 Apr 2007 06:41:55 -0400 Received: from smtp.ustc.edu.cn ([202.38.64.16] helo=ustc.edu.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HaUqD-0006k8-1o for manet@ietf.org; Sun, 08 Apr 2007 06:41:55 -0400 Received: (eyou send program); Sun, 08 Apr 2007 18:41:25 +0800 Message-ID: <376028885.00786@ustc.edu.cn> Received: from 211.86.146.106 by email.ustc.edu.cn with HTTP; Sun, 08 Apr 2007 18:41:25 +0800 X-WebMAIL-MUA: [211.86.146.106] From: "RuiZhe Wu" To: manet@ietf.org Date: Sun, 08 Apr 2007 18:41:25 +0800 X-Priority: 3 Content-Type: text/plain X-Spam-Score: 2.8 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: RuiZhe Wu List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi: Some articles mentioned that TORA can support "Multicast", but DSDV or CGSR can not. I want to know why some protocol can support "Multicast", some can not. Best regards, Rz _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 08 16:28:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HadyM-00015o-J7; Sun, 08 Apr 2007 16:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HadyL-00015i-AC for manet@ietf.org; Sun, 08 Apr 2007 16:26:49 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HadyJ-0006ZX-RJ for manet@ietf.org; Sun, 08 Apr 2007 16:26:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l38KQa8u007133 for ; Sun, 8 Apr 2007 23:26:40 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Apr 2007 23:26:38 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Apr 2007 15:26:36 -0500 Received: from [10.162.84.230] ([10.162.84.230]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Apr 2007 15:26:35 -0500 Message-ID: <46194FF4.2060604@nokia.com> Date: Sun, 08 Apr 2007 13:26:28 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: manet@ietf.org References: <005001c7782c$f87e0110$0202a8c0@Teco> In-Reply-To: <005001c7782c$f87e0110$0202a8c0@Teco> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2007 20:26:35.0868 (UTC) FILETIME=[345001C0:01C77A1C] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070408232640-1A1BDBB0-20E38F23/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [manet] Need for DPD header (SMF document discussion) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello folks, The SMF document mentions hashing as a tool for identifying separate network-layer broadcasts. We decided to test out the efficiency of various hash functions for this purpose. An ideal hash function would provide two different values for two different IP headers, so that different broadcasts could be disambiguated by a simple test. If a hash function has this property, then there would be little need for a separate IPv4 protocol element to make the distinction between various broadcast packets. We have found out that well known hash functions such as SHA-1 already have the desired property. If one takes the source IP address of an IP header, and adjoins to it the ip_id field (16 bits), and uses this as input for SHA-1, then the 160-bit resulting values have 0.0000000% overlap over the range of all 65,536 ip_id values. We can probably do with less than 160-bit values, to minimize storage requirements. For this reason, I am in favor of specifying (at least for most IPv4 systems) that the sender should be able to use different ip_id values for each successive broadcast packet, and that receivers should be able to run a hash function to obtain a unique identification for each received multicast (e.g., broadcast) packet. This also goes along with the philosophy of absolutely minimizing bytes over the air when a small amount of extra processing can be done instead. For IPv6, the situation is different and there is a need to specify another network-layer extension header, as has already been done in SMF (or else specify the use of the fragmentation header in a certain way). I am not sure when the "tagger" function would ever be needed, given the availability of the fragmentation header. If the problem is that packets from the Internet are destined for nodes in an ad hoc network, how will the tagger distinguish between duplicate packets and distinct new multicasts? What happens nowadays when a multicast router gets a duplicate packet? Presumably, broadcast packets will not emerge from the Internet for injection into a manet; we might even prohibit such a thing from happening. What is the likelihood that there would be reluctance to standardize the newly specified DPD header as an IPv6 extension header? If there is any reluctance, this would translate into further delays for SMF, and would swing the balance towards using the fragment header instead. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 08 22:41:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hajn6-0005EC-9f; Sun, 08 Apr 2007 22:39:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hajn4-0005E4-TM for manet@ietf.org; Sun, 08 Apr 2007 22:39:34 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hajmu-0003Lv-8v for manet@ietf.org; Sun, 08 Apr 2007 22:39:34 -0400 Received: by an-out-0708.google.com with SMTP id d30so1572482and for ; Sun, 08 Apr 2007 19:39:24 -0700 (PDT) Received: by 10.114.25.3 with SMTP id 3mr2122838way.1176086362880; Sun, 08 Apr 2007 19:39:22 -0700 (PDT) Received: by 10.114.53.8 with HTTP; Sun, 8 Apr 2007 19:39:22 -0700 (PDT) Message-ID: Date: Sun, 8 Apr 2007 19:39:22 -0700 From: "Sudheendra Murthy" To: tccc@cs.columbia.edu, manet@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: Subject: [manet] CFP: Dial M-POMC 2007 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0724237981==" Errors-To: manet-bounces@ietf.org --===============0724237981== Content-Type: multipart/alternative; boundary="----=_Part_25072_17415864.1176086362822" ------=_Part_25072_17415864.1176086362822 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [Please accept our apologies if you receive multiple copies of this emails] ***************************************************************************= ***** Call for Papers Dial M-POMC 2007 The Fourth ACM SIGACT-SIGOPS International Workshop on Foundations of Mobile Computing In Conjunction with ACM PODC 2007 August 16, 2007 Portland, Oregon, USA http://www.asu.edu/DialM/ ***************************************************************************= ***** SCOPE: =3D=3D=3D=3D=3D=3D Mobile computing and communications devices will have an enormous impact on our lifestyle over the next several decades. The mobility of distributed computing components raises a number of interesting, and difficult, algorithmic issues. This workshop is devoted to algorithms and methods in the context of mobile and wireless computing and communications. The workshop is intended to foster cooperation among researchers in mobile computing and researchers in discrete and distributed algorithms. DIAL M-POMC will be composed of invited and peer-reviewed contributed talks. All submitted papers will be rigorously reviewed by technical program committee members. Accepted papers will be published in the workshop proceedings. Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. Contributions are solicited in all areas related to mobile and wireless computing and communications where discrete algorithms and methods are utilized. Specific topics include, but are not limited to: * Channel assignment and management * Cryptography and security * Handover (handoff) * Routing, multicast and broadcast * Scheduling * Synchronization * Selfish behavior and cooperation * Ad hoc and sensor networking * Localization and location tracking * Error correcting codes * Protocol optimization * Dynamic networks * Cooperation enforcement * Dynamic graph algorithms * Modeling * Energy saving methods and protocols IMPORTANT DATES: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paper submission due: May 15, 2007 Notification of acceptance: June 15, 2007 Camera-ready paper submission: June 30, 2007 PAPER SUBMISSION INSTRUCTIONS: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Authors should prepare an electronic version of their full paper (see conference website for details). Papers must not exceed 8 pages (US Letter size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 11 points. ORGANIZING COMMITTEE: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Program Co-Chairs * Arunabha Sen, Arizona State University * Torsten Braun, Universit=E4t Bern Publicity Chair * Goran Konjevod, Arizona State University Steering Committee * Maurizio Bonuccelli (U. of Pisa) * Errol Lloyd (U. of Delaware) * Nancy Lynch (MIT) * Andre Schiper (EPFL) * Arunabha Sen (ASU) * Nitin Vaidya (UIUC) Technical Program Committee * Goran Konjevod * Andrea Richa * Guoliang Xue * Nitin Vaidya * B. P. Sinha * Jennifer L. Welch * Cynthia Phyllips * Andras Farago * Pierre Fraigniaud * Yevgeni Koucheryavy * Vassilis Tsaoussidis * L. van den Berg * Jochen Schiller * Ivan Stojmenovic * Ozgur Ercetin * Eric Fleury Please email questions regarding the technical program or paper submission to asen [at] asu [dot] edu. ------=_Part_25072_17415864.1176086362822 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline [Please accept our apologies if you receive mul= tiple copies of this emails]

********************************= ************************************************
    = ;            &n= bsp;            = ;     Call for Papers
           
 &nbs= p;            &= nbsp;           &nbs= p;    Dial M-POMC 2007
      &nb= sp;     
      The Fourth = ACM SIGACT-SIGOPS International Workshop on
            = ;          Foundations of Mobi= le Computing

         &= nbsp;      In Conjunction with ACM PODC 2007
            &= nbsp;           &nbs= p;      August 16, 2007
   &nbs= p;            &= nbsp;        Portland, Oregon, USA
            &nb= sp;          http://www.asu.edu/DialM/

*****************= ***************************************************************

SCOPE:
=3D=3D=3D=3D=3D=3D

Mobile computing and communicat= ions devices will have an enormous impact on our=20
lifestyle over the next several decades. The mobility of distributed co= mputing
components raises a number of interesting, and difficult, algor= ithmic issues.
This workshop is devoted to algorithms and methods in th= e context of mobile and=20
wireless computing and communications. The workshop is intended to fost= er
cooperation among researchers in mobile computing and researchers in= discrete
and distributed algorithms. DIAL M-POMC will be composed of i= nvited and=20
peer-reviewed contributed talks.

All submitted papers will be r= igorously reviewed by technical program committee
members. Accepted pap= ers will be published in the workshop proceedings.
Technical papers des= cribing original, previously unpublished research, not=20
currently under review by another conference or journal, are solicited.=
Contributions are solicited in all areas related to mobile and wireles= s
computing and communications where discrete algorithms and methods ar= e utilized.
Specific topics include, but are not limited to:

* Channel assig= nment and management
* Cryptography and security
* Handover (handoff)=
* Routing, multicast and broadcast
* Scheduling
* Synchronization
* Selfish behavior and cooperation
* Ad hoc and sensor networking* Localization and location tracking
* Error correcting codes
* Prot= ocol optimization
* Dynamic networks
* Cooperation enforcement
* Dynamic graph algorithms
* Modeling
* Energy saving methods and pro= tocols


IMPORTANT DATES:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Paper submission due:       = ;         May 15, 2007
Notificat= ion of acceptance:         &nb= sp; June 15, 2007
Camera-ready paper submission: June 30, 2007


PAPER SUBMISSIO= N INSTRUCTIONS:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Authors should prepare an electron= ic version of their full paper (see conference
website for details). Pap= ers must not exceed 8 pages (US Letter size,=20 8.5 x 11
inches) including text, figures and references. The font size = must be at least
11 points.


ORGANIZING COMMITTEE:
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Program Co-Chairs=
   * Arunabha Sen, Arizona State University
   * Torsten Braun, Universit=E4t Bern

Publicity Chair=
   * Goran Konjevod, Arizona State University

Steering= Committee
   * Maurizio Bonuccelli (U. of Pisa)
 &nbs= p; * Errol Lloyd (U. of Delaware)
   * Nancy Lynch (MIT)
   * Andre Schiper (EPFL)
   * Arunabha Sen (ASU= )
   * Nitin Vaidya (UIUC)

Technical Program Committee<= br>   * Goran Konjevod
   * Andrea Richa
 &n= bsp; * Guoliang Xue
   * Nitin Vaidya
   * B. P. = Sinha
   * Jennifer L. Welch
   * Cynthia Phyllips
=    * Andras Farago
   * Pierre Fraigniaud
 &= nbsp; * Yevgeni Koucheryavy
   * Vassilis Tsaoussidis
 = ;  * L. van den Berg
   * Jochen Schiller
  = * Ivan Stojmenovic
   * Ozgur Ercetin
   * Eric Fleury

Pleas= e email questions regarding the technical program or paper submission toasen [at] asu [dot] edu.
------=_Part_25072_17415864.1176086362822-- --===============0724237981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0724237981==-- From manet-bounces@ietf.org Mon Apr 09 07:54:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HasPV-0006PZ-14; Mon, 09 Apr 2007 07:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HasPS-0006P6-G1 for manet@ietf.org; Mon, 09 Apr 2007 07:51:46 -0400 Received: from ik-out-1112.google.com ([66.249.90.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HasPQ-0005cr-6j for manet@ietf.org; Mon, 09 Apr 2007 07:51:46 -0400 Received: by ik-out-1112.google.com with SMTP id c21so1134436ika for ; Mon, 09 Apr 2007 04:51:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e06cuLNfi4Mr3GMOxJ52qb5woI0rtD4H/J5aXfXPLIB9kFKkktpF1/dUs2IznkaEVRjlWGz57qIVVNSWCFVuozY7pjlgpNlkQC9VAWtttttvJluWKJN3onzaHKb8Q+JzS5qZqrAEauLLwwAimJFHEtO6WRaMnx/J/0l9VwbsLUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hcTlEChWt/l22J6a0SLR8PU7ZTFlD+rX+/p4r867qs2XD/U/D5pYX/v7oCE5akIcX/3rcU+ybLefbYjn4OA7ERU4PGfvrpHlvOlLboxm6LXQJH02IkJVM+hCOM1mcQiW48s7zEDxMtTBZ2CYfDP2Y9wJCuoICUgGErcm0X1cnBg= Received: by 10.78.185.16 with SMTP id i16mr844572huf.1176119503436; Mon, 09 Apr 2007 04:51:43 -0700 (PDT) Received: by 10.78.58.3 with HTTP; Mon, 9 Apr 2007 04:51:43 -0700 (PDT) Message-ID: <374005f30704090451p59212900n18b2b90184ead2a7@mail.gmail.com> Date: Mon, 9 Apr 2007 17:21:43 +0530 From: "Ian Chakeres" To: "Charles E. Perkins" Subject: Re: [manet] Need for DPD header (SMF document discussion) In-Reply-To: <46194FF4.2060604@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <005001c7782c$f87e0110$0202a8c0@Teco> <46194FF4.2060604@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. > For IPv6, the situation is different and there is a need to > specify another network-layer extension header, as has > already been done in SMF (or else specify the use of the > fragmentation header in a certain way). I am not sure > when the "tagger" function would ever be needed, given > the availability of the fragmentation header. If the problem > is that packets from the Internet are destined for nodes in > an ad hoc network, how will the tagger distinguish between > duplicate packets and distinct new multicasts? What > happens nowadays when a multicast router gets a > duplicate packet? Presumably, broadcast packets will > not emerge from the Internet for injection into a manet; > we might even prohibit such a thing from happening. The tagger id is useful when the source does not include the DPD option, another box (tagger) is responsible for adding the DPD IPv6 option, and the tagger cannot be sure that it is the only tagger. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 09 10:56:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavHB-0005yq-6y; Mon, 09 Apr 2007 10:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavH9-0005yW-MA for manet@ietf.org; Mon, 09 Apr 2007 10:55:23 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HavH8-0007s9-3n for manet@ietf.org; Mon, 09 Apr 2007 10:55:23 -0400 Received: from GIOVANNIT42 (extranet242-50.cc.telcordia.com [192.4.242.50]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id l39EtLt2002335 for ; Mon, 9 Apr 2007 10:55:21 -0400 (EDT) From: "Giovanni Di Crescenzo" To: Date: Mon, 9 Apr 2007 10:55:59 -0400 Message-ID: <003701c77ab7$2f721d00$6501a8c0@dte.telcordia.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcczSlg7jij2qWhgRHCwGMiYisvtjRB/g8hgAGvSPiAA779YoA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ca81a19b939ce054f98c8f830c2d7742 Subject: [manet] WCAN 07 - 3rd Workshop on Cryptography for Ad-hocNetworks (satellite workshop of ICALP 07) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0408558531==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============0408558531== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C77A95.A8607D00" This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C77A95.A8607D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit (apologies if you receive multiple postings for this) CALL FOR PAPERS: WCAN '07 (3rd Workshop on Cryptography for Ad hoc Networks) A Satellite Workshop of the 34th International Colloquium on Automata, Languages and Programming (ICALP 2007) Workshop Date: July 8th, 2007 Submission Date: July 23rd, 2007 Location: Wroclaw, Poland Web page: http://www.argreenhouse.com/society/wcan07/wcan07page.html Submission Instructions: go to https://wcan2007.research.telcordia.com/myreview/index.php?authorsInstructio ns=1 and follow the simple instructions in there Contact: wcan07chair AT research DOT telcordia DOT com ---------------------------------------------------------------------------- ---- Workshop Theme and Motivations: Wireless ad hoc networks are today receiving much attention for military, commercial and civilian applications, thus becoming a challenging area in security research. The security research community has mainly focused on securing routing and is only recently widening its scope of analysis. The cryptography research community has mainly focused on abstract models of networks like the Internet; however, cryptographic protocols for the Internet face serious challenges to be adapted to the ad-hoc, partial-connectivity, mobile, resource-constrained and infrastructureless nature of ad-hoc networks. The aim of this workshop is to help bridging this gap, towards a more comprehensive investigation of security and cryptographic tools, analysis and modeling methodologies over ad hoc networks, by bringing together the cryptography, network security, and wireless networking communities. We seek submissions containing original research on all aspects of cryptology that are motivated by their applicability to ad hoc networks, including wireless, cellular, sensor, mesh, peer-to-peer, vehicular and RFID-based networks. Short surveys of related sub-areas are also encouraged. The following is a non-exhaustive list of topics that are of interest to this workshop, when clearly motivated by and clearly focusing on ad hoc networks (cryptology papers not focusing on or not describing applications to ad hoc networks do not fit in the workshop interest area): Modeling of cryptographic tasks Solutions to cryptographic tasks under party mobility Solutions to cryptographic tasks under resource constraints Secure routing Bootstrapping of security associations Distributed public-key infrastructures Key-agreement, key-management and key-(pre)distribution Entity authentication Trust establishment Privacy-enhancing technologies Threshold cryptography Identity-Based cryptography Policy-based cryptography Secure multi-party protocols Security in distributed algorithms and protocols ------=_NextPart_000_0038_01C77A95.A8607D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [mycolleagues] ESAS 2007 - Fourth European Workshop on Security = and Privacy in Ad hoc and Sensor Networks, Cambridge, England

 

 (apologies if you receive = multiple postings for this)

 

CALL FOR PAPERS: WCAN '07 (3rd = Workshop on Cryptography for Ad hoc Networks)

 

A Satellite Workshop of the 34th International Colloquium on Automata, Languages and Programming (ICALP = 2007)

 

Workshop Date: July 8th, = 2007

 

Submission Date: July = 23rd, 2007

 

Location: Wroclaw, Poland

 

Web page: = http://www.argreenhouse.com/society/wcan07/wcan07page.html

 

Submission Instructions: go to =

 https://wcan2007.research.telc= ordia.com/myreview/index.php?authorsInstructions=3D1

 and follow the simple = instructions in there

 

Contact: wcan07chair AT research = DOT telcordia DOT com

 

------------------------------------= --------------------------------------------

=

 

Workshop Theme and = Motivations:

 

Wireless ad hoc networks are today receiving much attention for military, commercial =

and civilian applications, thus = becoming a challenging area in security research.

The security research community has = mainly focused on securing routing and is only

recently widening its scope of = analysis. The cryptography research community has mainly =

focused on abstract models of = networks like the Internet; however, cryptographic protocols =

for the Internet face serious = challenges to be adapted to the ad-hoc, partial-connectivity, =

mobile, resource-constrained and infrastructureless nature of ad-hoc networks. =

The aim of this workshop is to help bridging this gap, towards a more comprehensive =

investigation of security and cryptographic tools, analysis and modeling methodologies =

over ad hoc networks, by bringing = together the cryptography, network security,

and wireless networking = communities.

 

We seek submissions containing = original research on all aspects of cryptology that

are motivated by their = applicability to ad hoc networks, including wireless, cellular, =

sensor, mesh, peer-to-peer, = vehicular and RFID-based networks. Short surveys of related =

sub-areas are also encouraged. The following is a non-exhaustive list of topics that are =

of interest to this workshop, when = clearly motivated by and clearly focusing on ad hoc networks =

(cryptology papers not focusing on = or not describing applications to ad hoc networks

do not fit in the workshop interest = area):

 

Modeling of cryptographic tasks =

Solutions to cryptographic tasks = under party mobility

Solutions to cryptographic tasks = under resource constraints

Secure routing =

Bootstrapping of security = associations

Distributed public-key = infrastructures

Key-agreement, key-management and key-(pre)distribution

Entity authentication =

Trust establishment =

Privacy-enhancing technologies =

Threshold cryptography =

Identity-Based cryptography =

Policy-based cryptography =

Secure multi-party protocols =

Security in distributed algorithms = and protocols

 

 

------=_NextPart_000_0038_01C77A95.A8607D00-- --===============0408558531== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0408558531==-- From manet-bounces@ietf.org Mon Apr 09 12:08:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HawP8-00067v-TY; Mon, 09 Apr 2007 12:07:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HawP6-00065v-Ie for manet@ietf.org; Mon, 09 Apr 2007 12:07:40 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HawOl-0004N8-M1 for manet@ietf.org; Mon, 09 Apr 2007 12:07:40 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l39G6Rhl019878; Mon, 9 Apr 2007 19:07:11 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 19:06:38 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 11:06:33 -0500 Received: from [10.162.64.226] ([10.162.64.226]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 11:06:32 -0500 Message-ID: <461A647F.3090209@nokia.com> Date: Mon, 09 Apr 2007 09:06:23 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <005001c7782c$f87e0110$0202a8c0@Teco> <46194FF4.2060604@nokia.com> <374005f30704090451p59212900n18b2b90184ead2a7@mail.gmail.com> In-Reply-To: <374005f30704090451p59212900n18b2b90184ead2a7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2007 16:06:32.0891 (UTC) FILETIME=[0AA068B0:01C77AC1] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070409190712-4D3EBBB0-0E1870FB/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian, I must be missing something, please excuse my Monday morning density... ext Ian Chakeres wrote: > The tagger id is useful when the source does not include the DPD > option, another box (tagger) is responsible for adding the DPD IPv6 > option, and the tagger cannot be sure that it is the only tagger. If the purpose of the option is to disambiguate multicast packets, why does it matter? No matter which node performs the disambiguation, it only needs to be done once...(?) In fact, shouldn't we specify that the DPD option should appear AT MOST once in a packet? Furthermore, I would strongly suggest that the DPD option _only_ be used when a hash function would otherwise give the same result as it did for another recent packet from the same source. In other words, even for IPv6 we should rely on hashing for 99.999% of the cases and specify the use of the DPD option for only the rarity of a duplicated hash result. Then we have to decide on which hash function to use. More on that later :-) The main point for now is to agree that SMF should make some such specification, and relegate the DPD option to only very rare use. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 09 20:15:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3zd-0000Ve-PQ; Mon, 09 Apr 2007 20:13:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb3zc-0000UR-0Q for manet@ietf.org; Mon, 09 Apr 2007 20:13:52 -0400 Received: from web50908.mail.re2.yahoo.com ([206.190.38.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hb3zX-0000lU-L1 for manet@ietf.org; Mon, 09 Apr 2007 20:13:51 -0400 Received: (qmail 54428 invoked by uid 60001); 10 Apr 2007 00:13:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=RXmZgNGAf6abu8LCWPBfbTMZL2JxpUtYneXLh51SI9ThIdxpYraozSMh+jMJq46LOkehFZ+bOe1IjXZzkqjeX8pXpYFF/Waenh2mWqNgQWuJri2SRrTwJuOH4BxKm928GjgqKpBieoLuOvHGv6ePqSemr2ii7/FmtPKkTA3CLMc=; X-YMail-OSG: w3mCyOQVM1m8OIQSLmB2xtQMnTB4CXhIMYg9O0ME8gsyBmdbs_S_VJx04bQ6US0RO7h2m.NuVfKDMIT0zgPCHcYYFwc9Sfc0khdjTZ0_4iTnGteFCTH.OF7LQAlOag-- Received: from [193.63.148.178] by web50908.mail.re2.yahoo.com via HTTP; Mon, 09 Apr 2007 17:13:45 PDT Date: Mon, 9 Apr 2007 17:13:45 -0700 (PDT) From: chitra balakrishnan To: manet@ietf.org MIME-Version: 1.0 Message-ID: <428147.53799.qm@web50908.mail.re2.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [manet] Tutorial Workshop on IMS X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0565662475==" Errors-To: manet-bounces@ietf.org --===============0565662475== Content-Type: multipart/alternative; boundary="0-1393416868-1176164025=:53799" Content-Transfer-Encoding: 8bit --0-1393416868-1176164025=:53799 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit ====>>> HALF A DAY TUTORIAL on IP Multimedia Subsystem (IMS) International Conference and Exhibition on NEXT GENERATION MOBILE APPLICATIONS, SERVICES and TECHNOLOGIES Building Bridges in the Mobile World Cardiff, Wales, UK 12-14 September 2007 http://www.ngmast.com/ (Paper Submission Deadline Extended to 30th April 07) Half Day Tutorial on the topic "The IMS Service Platform: A Solution for Next Generation Network Operators to Be More Than Bit Pipes" Speaker: Professor Antonio Cuevas Casado, Universidad Carlos III de Madrid, Spain For more information visit the website (http://www.ngmast.com/ ) for announcement regarding the Indexation of the proceedings, Keynote speakers, new tutorials and exciting events within the conference. You can also contact us on ngmast07@glam.ac.uk Professor Khalid Al-Begain Chairman of the European Council for Modelling and Simulation . Director of ICRC The Integrated Communications Research Centre Faculty of Advanced Technology University of Glamorgan Pontypridd (Cardiff) CF37 1DL, Wales, UK Tel.: 0044 1443 482780 Fax.: 0044 1443 482715 e-mail: kbegain@glam.ac.uk URL: http://www.comp.glam.ac.uk/staff/kbegain/webpage/index.htm MoCoNet: http://www.moconet.net/ NGMAST07, Cardiff, 12-14 Sept. 2007: http://www.comp.glam.ac.uk/NGMAST07 See also: ASMTA07: http://www.comp.glam.ac.uk/ASMTA2007/index.html --------------------------------- 8:00? 8:25? 8:40? Find a flick in no time with theYahoo! Search movie showtime shortcut. --0-1393416868-1176164025=:53799 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
====>>> HALF A DAY TUTORIAL on IP Multimedia Subsystem (IMS)
 
 
 
International Conference and Exhibition on
 
NEXT GENERATION MOBILE APPLICATIONS, SERVICES and TECHNOLOGIES
 
Building Bridges in the Mobile World
 
Cardiff, Wales, UK 12-14 September 2007
 
 
(Paper Submission Deadline Extended to 30th April 07)
 
Half Day Tutorial on the topic
 
"The IMS Service Platform: A Solution for Next Generation Network Operators to Be More Than Bit Pipes"
 
Speaker: Professor Antonio Cuevas Casado, Universidad Carlos III de
Madrid, Spain
 
For more information visit the website (http://www.ngmast.com/ ) for
announcement regarding the Indexation of the proceedings, Keynote
speakers, new tutorials and exciting events within the conference.
 
You can also contact us on ngmast07@glam.ac.uk
 
 
Professor Khalid Al-Begain
 
Chairman of the European Council for Modelling and Simulation
 Director of ICRC
 The Integrated Communications Research Centre Faculty of Advanced
 Technology University of Glamorgan Pontypridd (Cardiff)
 CF37 1DL, Wales, UK
 Tel.: 0044 1443 482780
 Fax.: 0044 1443 482715
 e-mail: kbegain@glam.ac.uk
 
NGMAST07, Cardiff, 12-14 Sept. 2007:
 
 

8:00? 8:25? 8:40? Find a flick in no time
with theYahoo! Search movie showtime shortcut. --0-1393416868-1176164025=:53799-- --===============0565662475== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0565662475==-- From manet-bounces@ietf.org Mon Apr 09 20:58:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4fv-0007ik-I6; Mon, 09 Apr 2007 20:57:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4ft-0007if-SC for manet@ietf.org; Mon, 09 Apr 2007 20:57:33 -0400 Received: from falcon.cqu.edu.au ([138.77.5.11] helo=mx.cqu.edu.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb4fs-000168-3O for manet@ietf.org; Mon, 09 Apr 2007 20:57:33 -0400 Received: from [127.0.0.1] (helo=falcon.cqu.edu.au) by mx.cqu.edu.au with esmtp (Exim 4.63) (envelope-from ) id 1Hb4fn-0006Lb-Rd for manet@ietf.org; Tue, 10 Apr 2007 10:57:27 +1000 Received: from UNIMAIL.staff.ad.cqu.edu.au (remus.staff.ad.cqu.edu.au [138.77.34.93]) by falcon.cqu.edu.au (8.13.8/8.13.8) with ESMTP id l3A0vN7Q024396 for ; Tue, 10 Apr 2007 10:57:27 +1000 (EST) (envelope-from a.gyasi-agyei@cqu.edu.au) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Apr 2007 10:52:56 +1000 Message-ID: In-Reply-To: <428147.53799.qm@web50908.mail.re2.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CFP ICASTDN 10-12 Dec 2007, Accra Ghana thread-index: Acd7Bf9oEX7EKPRfR2eXDqM+cLHc+wABG2Kw References: <428147.53799.qm@web50908.mail.re2.yahoo.com> From: "Amoakoh Gyasi-Agyei" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [manet] CFP ICASTDN 10-12 Dec 2007, Accra Ghana X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1380074231==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1380074231== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77B0A.943435CC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77B0A.943435CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, =20 You're hereby invited to submit papers, tutorials, panel sessions, etc. to the ICT division of this multi-conference to be held in GHANA 10-12 Dec 2007. Besides professional experience, this conference will allow some of us to explore various opportunities in Ghana [a thriving economy in West Africa] for the first time, including investment opportunities. =20 Details of the conference can be found at http://home.vicnet.net.au/~icastdn/ =20 =20 Details on freatures areas/disciplines/divisions if ICASTDN can be found at http://home.vicnet.net.au/~icastdn/condivisions.html =20 Those interested in investment may check the panel sessions at http://home.vicnet.net.au/~icastdn/panels.html for profitable investment areas. =20 Paper submission deadline: 30 June 2007 Conference date: 10-12 Dec 2007 =20 Thanks, Amoakoh ------_=_NextPart_001_01C77B0A.943435CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear All,
 
You're hereby invited to submit papers,=20 tutorials, panel sessions, etc.  to the ICT = division=20 of this multi-conference to be held in GHANA 10-12 Dec = 2007.=20 Besides professional experience, this conference will allow some of us=20 to explore various opportunities in Ghana [a thriving economy = in West=20 Africa] for the first time, including investment=20 opportunities.
 
Details of the conference can be found at http://home.vicnet.net.au/~icastdn/=
 
Details on freatures = areas/disciplines/divisions if=20 ICASTDN can be found at http://home= .vicnet.net.au/~icastdn/condivisions.html
 
Those interested in investment may check the = panel=20 sessions at http://home.vicne= t.net.au/~icastdn/panels.html for=20 profitable investment areas.
 
Paper submission deadline: = 30 June=20 2007
Conference date: 10-12 Dec=20 2007
 
Thanks,
Amoakoh
------_=_NextPart_001_01C77B0A.943435CC-- --===============1380074231== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1380074231==-- From manet-bounces@ietf.org Tue Apr 10 04:03:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbBIv-0006JX-Q3; Tue, 10 Apr 2007 04:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbBIt-0006JO-Qe for manet@ietf.org; Tue, 10 Apr 2007 04:02:15 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbBIs-0007lh-1J for manet@ietf.org; Tue, 10 Apr 2007 04:02:15 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3A82CD3022093 for ; Tue, 10 Apr 2007 09:02:12 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3A826de028056 for ; Tue, 10 Apr 2007 09:02:06 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 10 Apr 2007 09:02:20 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Apr 2007 09:02:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] FW: Intended status of produced IDs Date: Tue, 10 Apr 2007 09:02:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] FW: Intended status of produced IDs Thread-Index: Acd4J6mWLi3F5JW0SHSbIc6Eassi6ADHl+Ug From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "Emmanuel Baccelli" X-OriginalArrivalTime: 10 Apr 2007 08:02:20.0427 (UTC) FILETIME=[906BF5B0:01C77B46] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Charlie has pointed out some issues, and there's history. But at this point, note that this (two protocols) is what the WG is chartered to produce. With regard to one protocol, my view is that such work would currently be at the pre-experimental stage. Good for research work (which I would be interested in) but not for IETF standardisation. -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: 06 April 2007 09:42 To: Emmanuel Baccelli Cc: manet@ietf.org Subject: Re: [manet] FW: Intended status of produced IDs *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Emmanuel Baccelli wrote: > Hi Teco, > SMF is targeted as experimental. OLSRv2 and DYMO are targeted as=20 > standards track. Why two standards track documents? Why can't it be just one protocol? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email=20 ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 04:50:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbC2f-0004Z7-CA; Tue, 10 Apr 2007 04:49:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbC2d-0004Yo-1P for manet@ietf.org; Tue, 10 Apr 2007 04:49:31 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbC2b-0004Gr-Pv for manet@ietf.org; Tue, 10 Apr 2007 04:49:31 -0400 Received: by wr-out-0506.google.com with SMTP id i20so1570436wra for ; Tue, 10 Apr 2007 01:49:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WiagixNjWDYVCnFQso2a8gojrMMpEXMyFKHw7Jhzj7ac3+vugfHuK3zhiE4J760/eAbP81zlOHG+k3ABcPHo/vqfaI1jPtcppZbI/TpUXWTCyjVHHQZVUEzrJxTR4e2xbmEu2DXGVkIbHpXRUYKP2m8fQDG3Y6u4F/el6NffAjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fNymeTB8CGWZQHIApWNQfviGah218sN6RWVWQeQsMaHbDqyeDiBe5uDoFMi6x4LocZH1WIkgenDJnlnSS/aZBl+uf4rXMcEq3gMvZ4KHg58z7bjD2tb5ty7wEuJVNMh6tLx6g/Crj8jScKmWr4hiDWvyCND+UtbWKL5rowaG+Q0= Received: by 10.78.201.15 with SMTP id y15mr1002993huf.1176194968493; Tue, 10 Apr 2007 01:49:28 -0700 (PDT) Received: by 10.78.58.3 with HTTP; Tue, 10 Apr 2007 01:49:27 -0700 (PDT) Message-ID: <374005f30704100149j6173d973hd6f2c0134621fc39@mail.gmail.com> Date: Tue, 10 Apr 2007 14:19:27 +0530 From: "Ian Chakeres" To: "Charles E. Perkins" Subject: Re: [manet] Need for DPD header (SMF document discussion) In-Reply-To: <461A647F.3090209@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <005001c7782c$f87e0110$0202a8c0@Teco> <46194FF4.2060604@nokia.com> <374005f30704090451p59212900n18b2b90184ead2a7@mail.gmail.com> <461A647F.3090209@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 4/9/07, Charles E. Perkins wrote: > > Hello Ian, > > I must be missing something, please excuse my Monday > morning density... > > ext Ian Chakeres wrote: > > The tagger id is useful when the source does not include the DPD > > option, another box (tagger) is responsible for adding the DPD IPv6 > > option, and the tagger cannot be sure that it is the only tagger. > If the purpose of the option is to disambiguate multicast > packets, why does it matter? No matter which node performs > the disambiguation, it only needs to be done once...(?) In fact, > shouldn't we specify that the DPD option should appear > AT MOST once in a packet? The purpose is to uniquely identify the packet. If a node other than the source inserts the option, and there might be multiple taggers, then the tagger id must be included. I agree the DPD option should appear at most once. Imagine there a manet with multiple points of attachment. If the source did not include the option field, then these attachment points should tag the packets. If each attachment points includes on the ID, the DPD matching might overlap. If this occurs various bad things happen. To avoid this situation the tagger id, disambiguates who performed the tagging operation. > Furthermore, I would strongly suggest that the DPD option > _only_ be used when a hash function would otherwise give > the same result as it did for another recent packet from the > same source. In other words, even for IPv6 we should rely > on hashing for 99.999% of the cases and specify the use of > the DPD option for only the rarity of a duplicated hash result. I believe the problem is that the tagger (sometimes not the source) cannot determine which packets are duplicates and which are not (unless they contain an ID). If you have a simple method for taggers to determine whether the ID is needed or not, I would be interested in hearing about it. Also (this has been discussed before) hash operations can be heavy weight for weak devices. For these reasons, I do not think hashing should be the normal operation. Instead tagging packets with good sequence numbers should be the default operation. Note that hashing (without including a unique ID) can result in several false collisions for video data, since video data can produce identical packets often. Joe has mentioned this a few times in the past. I believe he might have even presented some data long ago. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 08:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFjt-0001uj-82; Tue, 10 Apr 2007 08:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFjq-0001qt-ND for manet@ietf.org; Tue, 10 Apr 2007 08:46:22 -0400 Received: from mail93.messagelabs.com ([194.106.220.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbFfA-0005u1-Fq for manet@ietf.org; Tue, 10 Apr 2007 08:41:43 -0400 X-VirusChecked: Checked X-Env-Sender: Ronald.intVelt@tno.nl X-Msg-Ref: server-6.tower-93.messagelabs.com!1176208890!3155963!1 X-StarScan-Version: 5.5.10.7.1; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 10992 invoked from network); 10 Apr 2007 12:41:30 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-6.tower-93.messagelabs.com with SMTP; 10 Apr 2007 12:41:30 -0000 Received: from ms-dt01thalia.tsn.tno.nl (ms-dt01thalia.tno.nl [134.221.225.157]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id l3ACfUx10021 for ; Tue, 10 Apr 2007 14:41:30 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] FW: Intended status of produced IDs Date: Tue, 10 Apr 2007 14:41:29 +0200 Message-ID: <7877C5C0B5CC894AB26113CF06CF88631EA557@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <46157DE8.10803@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] FW: Intended status of produced IDs Thread-Index: Acd31bWcVfTSEJQYQs2tivIKLqEaEADlsw6A References: <003601c777d0$4eb7f4d0$0202a8c0@Teco> <46157DE8.10803@inria.fr> From: "Velt, R. \(Ronald\) in 't" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, >=20-----Original=20Message----- >=20From:=20Emmanuel=20Baccelli=20[mailto:Emmanuel.Baccelli@inria.fr]=20 >=20Sent:=20vrijdag=206=20april=202007=200:53 >=20To:=20manet@ietf.org >=20Subject:=20Re:=20[manet]=20FW:=20Intended=20status=20of=20produced=20I= Ds >=20 >=20Hi=20Teco, >=20SMF=20is=20targeted=20as=20experimental.=20OLSRv2=20and=20DYMO=20are=20= targeted=20 >=20as=20standards=20track. However,=20draft-ietf-manet-smf-04=20says=20(as=20noted=20by=20Teco):=20"I= ntended=20status:=20Standards=20Track".=20Is=20this=20a=20glitch? Ronald >=20Emmanuel >=20 >=20Teco=20Boot=20a=20=E9crit=20: >=20>=20Hi, >=20>=20 >=20>=20=20 >=20>=20 >=20>=20During=20the=20IETF-68=20MANET=20WG=20meeting,=20I=20heard=20the=20= target=20for=20the=20 >=20>=20current=20I-D=20MANET=20protocols=20is=20Experimental. >=20>=20 >=20>=20The=20drafts=20itself=20mention=20Standards=20Track=20(OLSRv2=20me= ntions=20nothing). >=20>=20 >=20>=20Are=20there=20minutes=20of=20the=20meeting=20published? >=20>=20 >=20>=20Can=20the=20chair=20provide=20the=20target=20for=20the=20drafts? >=20>=20 >=20>=20=20 >=20>=20 >=20>=20Teco >=20>=20 >=20>=20 >=20>=20 >=20----------------------------------------------------------------------= >=20>=20-- >=20>=20 >=20>=20_______________________________________________ >=20>=20manet=20mailing=20list >=20>=20manet@ietf.org >=20>=20https://www1.ietf.org/mailman/listinfo/manet >=20 >=20_______________________________________________ >=20manet=20mailing=20list >=20manet@ietf.org >=20https://www1.ietf.org/mailman/listinfo/manet >=20 This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 08:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFjW-0001fd-0X; Tue, 10 Apr 2007 08:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFjU-0001cK-Gs for manet@ietf.org; Tue, 10 Apr 2007 08:46:00 -0400 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbFiU-0007IC-2d for manet@ietf.org; Tue, 10 Apr 2007 08:45:01 -0400 Received: from GIOVANNIT42 ([192.4.222.223]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id l3ACivb1008422 for ; Tue, 10 Apr 2007 08:44:57 -0400 (EDT) From: "Giovanni Di Crescenzo" To: References: <003701c77ab7$2f721d00$6501a8c0@dte.telcordia.com> <2CAE5634D52E194BA393187E0568E1AC0236E5CA@ftrdmel1.rd.francetelecom.fr> Date: Tue, 10 Apr 2007 08:45:36 -0400 Message-ID: <000301c77b6e$22efac20$6501a8c0@dte.telcordia.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2CAE5634D52E194BA393187E0568E1AC0236E5CA@ftrdmel1.rd.francetelecom.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcczSlg7jij2qWhgRHCwGMiYisvtjRB/g8hgAGvSPiAA779YoAArRr4gAAKQhoA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 81ca0cebdb446e1ff4e2b634791f24a9 Subject: [manet] WCAN 07 - 3rd Workshop on Cryptography for Ad-hoc Networks (satellite workshop of ICALP 07) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1651744593==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1651744593== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C77B4C.9BDE0C20" This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C77B4C.9BDE0C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit (apologies if you receive multiple postings for this) CALL FOR PAPERS: WCAN '07 (3rd Workshop on Cryptography for Ad hoc Networks) A Satellite Workshop of the 34th International Colloquium on Automata, Languages and Programming (ICALP 2007) Workshop Date: July 8th, 2007 Submission Date: April 23rd, 2007 Location: Wroclaw, Poland Web page: http://www.argreenhouse.com/society/wcan07/wcan07page.html Submission Instructions: go to https://wcan2007.research.telcordia.com/myreview/index.php?authorsInstructio ns=1 and follow the simple instructions in there Contact: wcan07chair AT research DOT telcordia DOT com ---------------------------------------------------------------------------- ---- Workshop Theme and Motivations: Wireless ad hoc networks are today receiving much attention for military, commercial and civilian applications, thus becoming a challenging area in security research. The security research community has mainly focused on securing routing and is only recently widening its scope of analysis. The cryptography research community has mainly focused on abstract models of networks like the Internet; however, cryptographic protocols for the Internet face serious challenges to be adapted to the ad-hoc, partial-connectivity, mobile, resource-constrained and infrastructureless nature of ad-hoc networks. The aim of this workshop is to help bridging this gap, towards a more comprehensive investigation of security and cryptographic tools, analysis and modeling methodologies over ad hoc networks, by bringing together the cryptography, network security, and wireless networking communities. We seek submissions containing original research on all aspects of cryptology that are motivated by their applicability to ad hoc networks, including wireless, cellular, sensor, mesh, peer-to-peer, vehicular and RFID-based networks. Short surveys of related sub-areas are also encouraged. The following is a non-exhaustive list of topics that are of interest to this workshop, when clearly motivated by and clearly focusing on ad hoc networks (cryptology papers not focusing on or not describing applications to ad hoc networks do not fit in the workshop interest area): Modeling of cryptographic tasks Solutions to cryptographic tasks under party mobility Solutions to cryptographic tasks under resource constraints Secure routing Bootstrapping of security associations Distributed public-key infrastructures Key-agreement, key-management and key-(pre)distribution Entity authentication Trust establishment Privacy-enhancing technologies Threshold cryptography Identity-Based cryptography Policy-based cryptography Secure multi-party protocols Security in distributed algorithms and protocols ------=_NextPart_000_0004_01C77B4C.9BDE0C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [mycolleagues] ESAS 2007 - Fourth European Workshop on Security = and Privacy in Ad hoc and Sensor Networks, Cambridge, England

 

 

 (apologies if you receive = multiple postings for this)

 

CALL FOR PAPERS: WCAN '07 (3rd = Workshop on Cryptography for Ad hoc Networks)

 

A Satellite Workshop of the 34th = International Colloquium on Automata, Languages and Programming (ICALP = 2007)

 

Workshop Date: July 8th, = 2007

 

Submission Date: April = 23rd, 2007

 

Location: Wroclaw, Poland

 

Web page: http://www.argreenhouse.com/society/wcan07/wcan07page.html

 

Submission Instructions: go to =

 https://wcan2007.research.telc= ordia.com/myreview/index.php?authorsInstructions=3D1

 and follow the simple = instructions in there

 

Contact: wcan07chair AT research = DOT telcordia DOT com

 

------------------------------------= --------------------------------------------

=

 

Workshop Theme and = Motivations:

 

Wireless ad hoc networks are today receiving much attention for military, commercial =

and civilian applications, thus = becoming a challenging area in security research.

The security research community has = mainly focused on securing routing and is only

recently widening its scope of = analysis. The cryptography research community has mainly =

focused on abstract models of = networks like the Internet; however, cryptographic protocols =

for the Internet face serious = challenges to be adapted to the ad-hoc, partial-connectivity, =

mobile, resource-constrained and infrastructureless nature of ad-hoc networks. =

The aim of this workshop is to help bridging this gap, towards a more comprehensive =

investigation of security and cryptographic tools, analysis and modeling methodologies =

over ad hoc networks, by bringing = together the cryptography, network security,

and wireless networking = communities.

 

We seek submissions containing = original research on all aspects of cryptology that

are motivated by their = applicability to ad hoc networks, including wireless, cellular, =

sensor, mesh, peer-to-peer, = vehicular and RFID-based networks. Short surveys of related =

sub-areas are also encouraged. The following is a non-exhaustive list of topics that are =

of interest to this workshop, when = clearly motivated by and clearly focusing on ad hoc networks =

(cryptology papers not focusing on = or not describing applications to ad hoc networks

do not fit in the workshop interest = area):

 

Modeling of cryptographic tasks =

Solutions to cryptographic tasks = under party mobility

Solutions to cryptographic tasks = under resource constraints

Secure routing =

Bootstrapping of security = associations

Distributed public-key = infrastructures

Key-agreement, key-management and key-(pre)distribution

Entity authentication =

Trust establishment =

Privacy-enhancing technologies =

Threshold cryptography =

Identity-Based cryptography =

Policy-based cryptography =

Secure multi-party protocols =

Security in distributed algorithms = and protocols

 

 

------=_NextPart_000_0004_01C77B4C.9BDE0C20-- --===============1651744593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1651744593==-- From manet-bounces@ietf.org Tue Apr 10 09:00:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFwl-0000VW-RX; Tue, 10 Apr 2007 08:59:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFwj-0000UQ-Ry for manet@ietf.org; Tue, 10 Apr 2007 08:59:41 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbFwi-0003Mx-FK for manet@ietf.org; Tue, 10 Apr 2007 08:59:41 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3ACxd6Q016103 for ; Tue, 10 Apr 2007 13:59:39 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3ACxYjD010703 for ; Tue, 10 Apr 2007 13:59:34 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 10 Apr 2007 13:59:48 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Apr 2007 13:58:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] FW: Intended status of produced IDs Date: Tue, 10 Apr 2007 13:58:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] FW: Intended status of produced IDs Thread-Index: Acd31bWcVfTSEJQYQs2tivIKLqEaEADlsw6AAACmmbA= From: "Dearlove, Christopher \(UK\)" To: "Velt, R. \(Ronald\) in 't" , X-OriginalArrivalTime: 10 Apr 2007 12:58:55.0755 (UTC) FILETIME=[FF4385B0:01C77B6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org From: Velt, R. (Ronald) in 't [mailto:Ronald.intVelt@tno.nl]=20 > However, draft-ietf-manet-smf-04 says (as noted by Teco): > "Intended status: Standards Track". Is this a glitch? I'm not an author of that one, but I believe it is. draft-ietf-manet-olsrv2-03 doesn't say Standards Track, but should. That is a glitch. draft-ietf-manet-nhdp-02 draft-ietf-manet-nhdp-02 and draft-ietf-manet-dymo-08 (the latter I'm also not an author) say Standards Track, and should. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 11:35:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIM0-0000S6-Ha; Tue, 10 Apr 2007 11:33:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbILz-0000Ro-DC for manet@ietf.org; Tue, 10 Apr 2007 11:33:55 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbILx-0003co-SU for manet@ietf.org; Tue, 10 Apr 2007 11:33:55 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3AFXaNu006552; Tue, 10 Apr 2007 18:33:41 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 18:33:24 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:33:21 -0500 Received: from [10.162.77.214] ([10.162.77.214]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:33:20 -0500 Message-ID: <461BAE34.6000706@nokia.com> Date: Tue, 10 Apr 2007 08:33:08 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <005001c7782c$f87e0110$0202a8c0@Teco> <46194FF4.2060604@nokia.com> <374005f30704090451p59212900n18b2b90184ead2a7@mail.gmail.com> <461A647F.3090209@nokia.com> <374005f30704100149j6173d973hd6f2c0134621fc39@mail.gmail.com> In-Reply-To: <374005f30704100149j6173d973hd6f2c0134621fc39@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 15:33:20.0862 (UTC) FILETIME=[91B2A7E0:01C77B85] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070410183345-17280BB0-6A5F2863/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian, ext Ian Chakeres wrote: > > The purpose is to uniquely identify the packet. If a node other than > the source inserts the option, and there might be multiple taggers, > then the tagger id must be included. Do you mean to imply that the tagger becomes the source IP address for the packet? If the source IP address stays the same, then why does the identity of the tagger matter? > Imagine there a manet with multiple points of attachment. If the > source did not include the option field, then these attachment points > should tag the packets. If each attachment points includes on the ID, > the DPD matching might overlap. If this occurs various bad things > happen. To avoid this situation the tagger id, disambiguates who > performed the tagging operation. Now I am even more confused. If two different taggers add two different options to the same broadcast/multicast packet, how can a manet node tell they are the same packet after all, and (to fulfill the whole point of the exercise) suppress duplicates? >> Furthermore, I would strongly suggest that the DPD option >> _only_ be used when a hash function would otherwise give >> the same result as it did for another recent packet from the >> same source. In other words, even for IPv6 we should rely >> on hashing for 99.999% of the cases and specify the use of >> the DPD option for only the rarity of a duplicated hash result. > > I believe the problem is that the tagger (sometimes not the source) > cannot determine which packets are duplicates and which are not > (unless they contain an ID). If you have a simple method for taggers > to determine whether the ID is needed or not, I would be interested in > hearing about it. My method is simple: 1 Run a hash function on the packet. 2. Compare to previous packets 3. If there is a match, add the option. 4. Otherwise, do not. What's needed here is agreement on which hash function to use. It looks like we can devise a perfect hash, at least until the ip_id field rolls over. By that time, the previous packet that might have collided in hash space will be a distant forgotten memory of the manet. > > Also (this has been discussed before) hash operations can be heavy > weight for weak devices. I strongly disagree with this claim. To my understanding, it is practically always the other way around. Adding bytes over the air is typically more energy intensive than additional computation. I'm not talking about full-blown zillion-bit privacy here. Some hash functions that work are much lighter weight. > > For these reasons, I do not think hashing should be the normal > operation. Instead tagging packets with good sequence numbers should > be the default operation. I strongly disagree with this. I would like to see any documentation to the effect that this saves energy. If there is a rare system for which it is true, then those few devices could add the option. For most devices, the option SHOULD NOT be used... > > Note that hashing (without including a unique ID) can result in > several false collisions for video data, since video data can produce > identical packets often. Joe has mentioned this a few times in the > past. I believe he might have even presented some data long ago. We just proved otherwise -- that a good hash function completely disambiguates based on IP header alone. There is no need to include payload data. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 11:55:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIg3-0004xo-Ml; Tue, 10 Apr 2007 11:54:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIg2-0004xj-T2 for manet@ietf.org; Tue, 10 Apr 2007 11:54:38 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbIg1-0008Dn-78 for manet@ietf.org; Tue, 10 Apr 2007 11:54:38 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3AFkxgb029589; Tue, 10 Apr 2007 18:47:39 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 18:46:56 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:46:48 -0500 Received: from [10.162.77.214] ([10.162.77.214]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:46:47 -0500 Message-ID: <461BB161.9000000@nokia.com> Date: Tue, 10 Apr 2007 08:46:41 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ext Dearlove, Christopher (UK)" Subject: Re: [manet] FW: Intended status of produced IDs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 15:46:47.0841 (UTC) FILETIME=[72B1E110:01C77B87] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Chris, ext Dearlove, Christopher (UK) wrote: > With regard to one protocol, my view is that such work > would currently be at the pre-experimental stage. What is the difference between experimental and pre-experimental? > Good > for research work (which I would be interested in) but > not for IETF standardisation. > If a good candidate were put forward, implemented by several people, and shown to work, then I think it would be suitable for standardization. This has not happened yet. However, there is little doubt that a single protocol would be better for the user community. As it is, I think it will be crucial to have detailed applicability statements in the protocols. For instance, as I mentioned in my rushed-through presentation at the last IETF, the user should be alerted to choose proactive vs. reactive based on estimates of traffic density, which should be quantified in the applicabililty statements. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 12:16:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJ0J-0000B7-La; Tue, 10 Apr 2007 12:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJ0I-0000An-8r for manet@ietf.org; Tue, 10 Apr 2007 12:15:34 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJ0F-0004mH-SP for manet@ietf.org; Tue, 10 Apr 2007 12:15:34 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3AGFVGL007310 for ; Tue, 10 Apr 2007 17:15:31 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3AGFQxb024822 for ; Tue, 10 Apr 2007 17:15:26 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 10 Apr 2007 17:15:40 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Apr 2007 17:15:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] FW: Intended status of produced IDs Date: Tue, 10 Apr 2007 17:15:36 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] FW: Intended status of produced IDs Thread-Index: Acd7iKa3bHupIeA6TB+ZFlQAAF+jcQAAAbNw From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" X-OriginalArrivalTime: 10 Apr 2007 16:15:38.0114 (UTC) FILETIME=[7A049620:01C77B8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > What is the difference between experimental and pre-experimental? Not a formal terminology, but what I meant was that AODV, OLSRv1 etc. are experimental, pre-experimental is things that haven't even got to that stage yet. >> Good >> for research work (which I would be interested in) but >> not for IETF standardisation. > If a good candidate were put forward, implemented by several > people, and shown to work, then I think it would be suitable for > standardization. This has not happened yet. This is not viable in a timescale which would work for the IETF process, or for many of us involved in it. This is not the time for holding up the current work to go back into research mode, quite the opposite. Outside the MANET WG, yes, in a hypothetical future rechartering of the WG, maybe. > However, there is little doubt that a single protocol would be > better for the user community. A single protocol a further two years in the future (which is, in my opinion, an optimistic estimate based on precedent) or two protocols now? I would definitely go for the latter. > As it is, I think it will be crucial > to have detailed applicability statements in the protocols. Somewhere, maybe. In the formal protocol specifications, I disagree, especially with the word detailed. The bounds on where DYMO and OLSRv2 can be use are not firm, and the permitted applicability of various optimisation techniques in OLSRv2 (that aren't fully there in OLSRv1) and I suspect similarly in DYMO, make setting hard boundaries in the protocol specification a bad idea. A separate informative document discussing the issues, perhaps (though I for one don't have the effort to work on it right now, and nor do I think delaying matters to create it warranted). > For > instance, as I mentioned in my rushed-through presentation at > the last IETF, the user should be alerted to choose proactive > vs. reactive based on estimates of traffic density, which should > be quantified in the applicabililty statements. Traffic density is not all. Network size, traffic pattern stability and so on all also matter. There's a lot of research there, which the WG cannot afford to be sidetracked by. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 12:24:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJ8H-0005d3-0X; Tue, 10 Apr 2007 12:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJ8F-0005cy-De for manet@ietf.org; Tue, 10 Apr 2007 12:23:47 -0400 Received: from exchange-fe2a.nmsu.edu ([128.123.34.179] helo=exchange-fe2.ACN.ad.nmsu.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJ8D-00066R-TH for manet@ietf.org; Tue, 10 Apr 2007 12:23:47 -0400 Received: from EXCHANGE-BE1.ACN.ad.nmsu.edu ([128.123.34.119]) by exchange-fe2.ACN.ad.nmsu.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 10:23:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] FW: Intended status of produced IDs Date: Tue, 10 Apr 2007 10:23:39 -0600 Message-ID: In-Reply-To: <461BB161.9000000@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [manet] FW: Intended status of produced IDs Thread-index: Acd7iI8Q3w30zoFXQBmNp2jKPygEIQAAvW6w References: <461BB161.9000000@nokia.com> From: "Mullen, John" To: X-OriginalArrivalTime: 10 Apr 2007 16:23:40.0896 (UTC) FILETIME=[99C74600:01C77B8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Charles, I agree, but it seems to me that traffic density, node density, propagation conditions, etc. can be expected to vary greatly throughout any practical MANET. For example, a plot of random points distributed according to a uniform distribution will have local areas of very high and very low density. If we assume Poisson distributions of traffic initiation, there will be relatively long gaps during which little traffic flows and intervals during which several times the average number of messages are generated. As a result, I'm not sure that designers can make such choices, except in very general terms. Putting it another way, I think the descriptions (and validation) of density, load, etc., would be better stated as distributions, rather than averages. Otherwise, it may be difficult to relate these statements to real-world situations. Bye for now, John P. Mullen, Ph.D. (505) 646-2958 jomullen@nmsu.edu =20 -----Original Message----- From: Charles E. Perkins [mailto:charles.perkins@nokia.com]=20 Sent: Tuesday, April 10, 2007 9:47 AM To: ext Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] FW: Intended status of produced IDs Hello Chris, ext Dearlove, Christopher (UK) wrote: > With regard to one protocol, my view is that such work > would currently be at the pre-experimental stage. What is the difference between experimental and pre-experimental? > Good > for research work (which I would be interested in) but > not for IETF standardisation. > =20 If a good candidate were put forward, implemented by several people, and shown to work, then I think it would be suitable for standardization. This has not happened yet. However, there is little doubt that a single protocol would be better for the user community. As it is, I think it will be crucial to have detailed applicability statements in the protocols. For instance, as I mentioned in my rushed-through presentation at the last IETF, the user should be alerted to choose proactive vs. reactive based on estimates of traffic density, which should be quantified in the applicabililty statements. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 12:40:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJNs-00058t-KN; Tue, 10 Apr 2007 12:39:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJNq-00058l-Gv for manet@ietf.org; Tue, 10 Apr 2007 12:39:54 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJNp-0008Oy-12 for manet@ietf.org; Tue, 10 Apr 2007 12:39:54 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3AGdXCd024184; Tue, 10 Apr 2007 19:39:37 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 19:39:21 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:38:48 -0500 Received: from [10.162.77.214] ([10.162.77.214]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:38:47 -0500 Message-ID: <461BBD90.30204@nokia.com> Date: Tue, 10 Apr 2007 09:38:40 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ext Dearlove, Christopher (UK)" Subject: Re: [manet] FW: Intended status of produced IDs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 16:38:48.0271 (UTC) FILETIME=[B69DB5F0:01C77B8E] X-eXpurgate-Category: 1/4 X-eXpurgate-ID: 149371::070410193937-5D5AFBB0-36040B4F/0-0/0-17 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Chris, ext Dearlove, Christopher (UK) wrote: > >> If a good candidate were put forward, implemented by several >> people, and shown to work, then I think it would be suitable for >> standardization. This has not happened yet. >> > > This is not viable in a timescale which would work for the IETF > process, or for many of us involved in it. This is not the time > for holding up the current work to go back into research mode, > quite the opposite. Outside the MANET WG, yes, in a hypothetical > future rechartering of the WG, maybe. > I do not suggest holding up current work until a single protocol could be developed. > >> However, there is little doubt that a single protocol would be >> better for the user community. >> > > A single protocol a further two years in the future (which is, in > my opinion, an optimistic estimate based on precedent) or two > protocols now? I would definitely go for the latter. > I do not suggest holding up current work until a single protocol could be developed (*). > >> As it is, I think it will be crucial >> to have detailed applicability statements in the protocols. >> > > Somewhere, maybe. In the formal protocol specifications, I disagree, > especially with the word detailed. The bounds on where DYMO and > OLSRv2 can be use are not firm, and the permitted applicability > of various optimisation techniques in OLSRv2 (that aren't fully > there in OLSRv1) and I suspect similarly in DYMO, make setting > hard boundaries in the protocol specification a bad idea. A > separate informative document discussing the issues, perhaps > (though I for one don't have the effort to work on it right now, > and nor do I think delaying matters to create it warranted). > Documents in the IETF have been required to have applicability statements before they could be standardized. I think it would be very appropriate in this case. > >> For >> instance, as I mentioned in my rushed-through presentation at >> the last IETF, the user should be alerted to choose proactive >> vs. reactive based on estimates of traffic density, which should >> be quantified in the applicabililty statements. >> > > Traffic density is not all. Network size, traffic pattern stability > and so on all also matter. There's a lot of research there, which > the WG cannot afford to be sidetracked by. > Well, it is the developers and, ultimately, the users who need to know. I doubt that you are suggesting we hide these issues from the people who would use the protocols. Many answers are quite clear, and not requiring additional research to be understood. I can recite some, but I doubt you would dispute this. There's an old joke along the lines, "I'm busy, don't bother me with facts"... And I would in no way suggest that you consciously hold to that philosophy. And I do not suggest delaying the documents (*). However, I do strongly suggest that applicability statements clearly state where the protocols are applicable, and where possible cite existing work to back up the claimed applicability. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 12:55:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJcB-0003bq-Gk; Tue, 10 Apr 2007 12:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJc9-0003bj-Cc for manet@ietf.org; Tue, 10 Apr 2007 12:54:41 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJc1-00049s-6R for manet@ietf.org; Tue, 10 Apr 2007 12:54:41 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3AGsWuO013067 for ; Tue, 10 Apr 2007 17:54:32 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3AGsRA6028104 for ; Tue, 10 Apr 2007 17:54:27 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 10 Apr 2007 17:54:41 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Tue, 10 Apr 2007 17:54:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] FW: Intended status of produced IDs Date: Tue, 10 Apr 2007 17:54:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] FW: Intended status of produced IDs Thread-Index: Acd7jux59CpvZqnETeSZdlo9MndH2AAAGnLA From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" X-OriginalArrivalTime: 10 Apr 2007 16:54:41.0646 (UTC) FILETIME=[EEDF30E0:01C77B90] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I do not suggest holding up current work until a single protocol > could be developed. OK, good, we're on the same page there. And we're on the same page with regard to the desirability of work somewhere in this area too, but I can't take that discussion much further at the moment. > Documents in the IETF have been required to have applicability > statements before they could be standardized. I think it would be > very appropriate in this case. I agree they should have applicability statements, and indeed OLSRv2 and NHDP (and other documents) have them. But I don't think OLSRv2 should have an applicability statement that says "don't use OLSRv2 here, use DYMO", or indeed vice versa. (In fact the two are better independent, both technically and in terms of procedures, with any references to both in other documents.) Roughly speaking I wouldn't say "don't use protocol X with more than N nodes or where nodes are sparse" (for example) but rather "protocol X is particularly suited to cases with less than N nodes, and where these are dense". Or something like that. We already go down that route. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 13:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJu4-0008VT-R9; Tue, 10 Apr 2007 13:13:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJu3-0008VL-Cx for manet@ietf.org; Tue, 10 Apr 2007 13:13:11 -0400 Received: from web50507.mail.re2.yahoo.com ([206.190.38.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbJu1-0000ln-NY for manet@ietf.org; Tue, 10 Apr 2007 13:13:11 -0400 Received: (qmail 92323 invoked by uid 60001); 10 Apr 2007 17:13:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=QRubD22lxvpFrEmkJN4pXm0vs0o9s9DC8qDhBeY/Qk+39VsmTGWoPs+CKHGs5b9GoNVRJxWnm+M8F9QABrCOM2GO3hEbNggTMS/v9MuIry/jzNhlOtNRZsHAo+zYOPLgg3fKyq6jN6dGpM1ShgyUdadr8uS/aVSd/2ePV+sVlbA=; X-YMail-OSG: 4FwU2WcVM1l9pHFrcmDOluolbOKO7SoSoXqoP3sNffp6idL1oxpYJ7WC0ZVUR5xP_Q-- Received: from [59.92.87.209] by web50507.mail.re2.yahoo.com via HTTP; Tue, 10 Apr 2007 10:13:09 PDT Date: Tue, 10 Apr 2007 10:13:09 -0700 (PDT) From: Evelyn Stephen To: manet@ietf.org In-Reply-To: <7877C5C0B5CC894AB26113CF06CF88631EA557@ms-dt01thalia.tsn.tno.nl> MIME-Version: 1.0 Message-ID: <447973.91479.qm@web50507.mail.re2.yahoo.com> X-Spam-Score: 3.4 (+++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [manet] unsubsribe X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0416376841==" Errors-To: manet-bounces@ietf.org --===============0416376841== Content-Type: multipart/alternative; boundary="0-1284141416-1176225189=:91479" Content-Transfer-Encoding: 8bit --0-1284141416-1176225189=:91479 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit i like to unsubscribe "Velt, R. (Ronald) in 't" wrote: Hi, > -----Original Message----- > From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr] > Sent: vrijdag 6 april 2007 0:53 > To: manet@ietf.org > Subject: Re: [manet] FW: Intended status of produced IDs > > Hi Teco, > SMF is targeted as experimental. OLSRv2 and DYMO are targeted > as standards track. However, draft-ietf-manet-smf-04 says (as noted by Teco): "Intended status: Standards Track". Is this a glitch? Ronald > Emmanuel > > Teco Boot a écrit : > > Hi, > > > > > > > > During the IETF-68 MANET WG meeting, I heard the target for the > > current I-D MANET protocols is Experimental. > > > > The drafts itself mention Standards Track (OLSRv2 mentions nothing). > > > > Are there minutes of the meeting published? > > > > Can the chair provide the target for the drafts? > > > > > > > > Teco > > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --------------------------------- Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. --0-1284141416-1176225189=:91479 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

i like to unsubscribe

"Velt, R. (Ronald) in 't" <Ronald.intVelt@tno.nl> wrote:
Hi,

> -----Original Message-----
> From: Emmanuel Baccelli [mailto:Emmanuel.Baccelli@inria.fr]
> Sent: vrijdag 6 april 2007 0:53
> To: manet@ietf.org
> Subject: Re: [manet] FW: Intended status of produced IDs
>
> Hi Teco,
> SMF is targeted as experimental. OLSRv2 and DYMO are targeted
> as standards track.

However, draft-ietf-manet-smf-04 says (as noted by Teco): "Intended status: Standards Track". Is this a glitch?

Ronald

> Emmanuel
>
> Teco Boot a écrit :
> > Hi,
> >
> >
> >
> > During the IETF-68 MANET WG meeting, I heard the target for the
> > current I-D MANET protocols is Experimental.
> >
> > The drafts itself mention Standards Track (OLSRv2 mentions nothing).
> >
> > Are there minutes of the meeting published?
> >
> > Can the chair provide the target for the drafts?
> >
> >
> >
> > Teco
> >
> >
> >
> ----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

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

Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. --0-1284141416-1176225189=:91479-- --===============0416376841== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0416376841==-- From manet-bounces@ietf.org Tue Apr 10 13:55:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKY0-0003K8-0P; Tue, 10 Apr 2007 13:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbKXx-0003If-So for manet@ietf.org; Tue, 10 Apr 2007 13:54:25 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbKXw-0000de-CQ for manet@ietf.org; Tue, 10 Apr 2007 13:54:25 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3AHrdaK026165; Tue, 10 Apr 2007 20:54:12 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 20:53:58 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 12:53:51 -0500 Received: from [10.162.77.214] ([10.162.77.214]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 12:53:50 -0500 Message-ID: <461BCF28.8060806@nokia.com> Date: Tue, 10 Apr 2007 10:53:44 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ext Mullen, John" Subject: Re: [manet] FW: Intended status of produced IDs References: <461BB161.9000000@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 17:53:51.0204 (UTC) FILETIME=[3292C240:01C77B99] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello John, ext Mullen, John wrote: > Hi Charles, > > I agree, but it seems to me that traffic density, node density, > propagation conditions, etc. can be expected to vary greatly throughout > any practical MANET. For example, a plot of random points distributed > according to a uniform distribution will have local areas of very high > and very low density. If we assume Poisson distributions of traffic > initiation, there will be relatively long gaps during which little > traffic flows and intervals during which several times the average > number of messages are generated. > This is definitely true. I translate it to mean that an adaptive protocol that can dynamically determine the best response to the network would be the best solution, if such a thing existed. In the meantime, we have to deal with time averaged behaviors. My intuition is that the phenomena that vary do not have very much memory so that variations in time can be smoothly integrated to find a useful average. > As a result, I'm not sure that designers can make such choices, except > in very general terms. Putting it another way, I think the descriptions > (and validation) of density, load, etc., would be better stated as > distributions, rather than averages. Otherwise, it may be difficult to > relate these statements to real-world situations. > Well, I am pretty sure we can make definitive statements of at least a rudimentary nature, and even offer some quantification. For instance, it is clear that if 30% of the nodes in a 100-node network are at all times communicating with all other nodes, then OLSR is substantially more efficient. In fact, at 100 nodes, I think it would be true if only 10% of the nodes were communicating with all other nodes. We can also make statements about latency. If we measure that reactive route discovery takes 200 ms in a certain network, then we can say that reactive operations are not favored for applications that require faster launch times. For instance, if a nuclear power plant used controls configured as an ad hoc network, I am pretty sure they would want a proactive routing protocol. Certain military layouts are probably more realistic and would similarly need to have proactive operations. My belief is that we know enough to make some useful applicability statements, and that we do need to make them now. Over time, we will learn more and be able to make sharper statements. That does not mean we are clueless at the current time. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 16:01:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMWL-0005Ib-Bh; Tue, 10 Apr 2007 16:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMWJ-0005IE-OH for manet@ietf.org; Tue, 10 Apr 2007 16:00:51 -0400 Received: from mail141.messagelabs.com ([85.158.137.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HbMWI-0003uQ-2h for manet@ietf.org; Tue, 10 Apr 2007 16:00:51 -0400 X-VirusChecked: Checked X-Env-Sender: Ronald.intVelt@tno.nl X-Msg-Ref: server-13.tower-141.messagelabs.com!1176235248!11561185!1 X-StarScan-Version: 5.5.10.7.1; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 29390 invoked from network); 10 Apr 2007 20:00:48 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-13.tower-141.messagelabs.com with SMTP; 10 Apr 2007 20:00:48 -0000 Received: from ms-dt01thalia.tsn.tno.nl (ms-dt01thalia.tno.nl [134.221.225.157]) by zeus.tno.nl (8.11.7p1+Sun/8.11.7) with ESMTP id l3AK0mx28233 for ; Tue, 10 Apr 2007 22:00:48 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Tue, 10 Apr 2007 22:00:48 +0200 Message-ID: <7877C5C0B5CC894AB26113CF06CF88631EA558@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <461BAE34.6000706@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Need for DPD header (SMF document discussion) Thread-Index: Acd7hmJIgK9nNV/iS62WBZflj6rwtQAGMq3w References: <005001c7782c$f87e0110$0202a8c0@Teco> <46194FF4.2060604@nokia.com> <374005f30704090451p59212900n18b2b90184ead2a7@mail.gmail.com> <461A647F.3090209@nokia.com><374005f30704100149j6173d973hd6f2c0134621fc39@mail.gmail.com> <461BAE34.6000706@nokia.com> From: "Velt, R. \(Ronald\) in 't" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello=20Charles, Very=20probably,=20I=20am=20several=20orders=20of=20magnitude=20denser=20a= ny=20given=20day=20of the=20week=20than=20you=20may=20have=20been=20on=20Monday=20morning,=20but= ... >=20-----Original=20Message----- >=20From:=20Charles=20E.=20Perkins=20[mailto:charles.perkins@nokia.com]=20= >=20Sent:=20dinsdag=2010=20april=202007=2017:33 >=20To:=20ext=20Ian=20Chakeres >=20Cc:=20manet@ietf.org >=20Subject:=20Re:=20[manet]=20Need=20for=20DPD=20header=20(SMF=20document= =20discussion) >=20 >=20 >=20Hello=20Ian, >=20 >=20ext=20Ian=20Chakeres=20wrote: >=20> >=20>=20The=20purpose=20is=20to=20uniquely=20identify=20the=20packet.=20If= =20a=20node=20 >=20other=20than=20 >=20>=20the=20source=20inserts=20the=20option,=20and=20there=20might=20be=20= multiple=20taggers,=20 >=20>=20then=20the=20tagger=20id=20must=20be=20included. >=20Do=20you=20mean=20to=20imply=20that=20the=20tagger=20becomes=20the=20s= ource=20IP=20 >=20address=20for=20the=20packet?=20=20If=20the=20source=20IP=20address=20= stays=20the=20 >=20same,=20then=20why=20does=20the=20identity=20of=20the=20tagger=20matte= r? >=20 >=20>=20Imagine=20there=20a=20manet=20with=20multiple=20points=20of=20atta= chment.=20If=20the=20 >=20>=20source=20did=20not=20include=20the=20option=20field,=20then=20thes= e=20 >=20attachment=20points=20 >=20>=20should=20tag=20the=20packets.=20If=20each=20attachment=20points=20= includes=20 >=20on=20the=20ID,=20 >=20>=20the=20DPD=20matching=20might=20overlap.=20If=20this=20occurs=20var= ious=20bad=20things=20 >=20>=20happen.=20To=20avoid=20this=20situation=20the=20tagger=20id,=20dis= ambiguates=20who=20 >=20>=20performed=20the=20tagging=20operation. >=20Now=20I=20am=20even=20more=20confused.=20=20If=20two=20different=20tag= gers=20add=20 >=20two=20different=20options=20to=20the=20same=20broadcast/multicast=20pa= cket,=20 >=20how=20can=20a=20manet=20node=20tell=20they=20are=20the=20same=20packet= =20after=20all,=20 >=20and=20(to=20fulfill=20the=20whole=20point=20of=20the=20exercise)=20sup= press=20duplicates? >=20 I=20just=20read=20the=20relevant=20portion=20of=20the=20SMF=20draft.=20Can= =20I=20test=20my understanding=20by=20"explaining"=20this=20to=20you?=20My=20interpretation= =20is=20that=20the 'tagger=20ID'=20helps=20in=20the=20case=20where=20multicast=20packets=20fr= om=20a=20single source=20_outside_=20the=20manet=20can=20somehow=20follow=20different=20pa= ths=20to different=20gateways=20('points=20of=20attachment'),=20where=20they=20are=20= to=20be injected=20_into_=20the=20manet.=20At=20this=20point,=20these=20packets=20= would=20be=20tagged. Since=20this=20would=20happen=20only=20once=20per=20packet,=20there=20is=20= never=20more=20than one=20DPD=20option=20per=20packet.=20However,=20each=20'tagger'=20takes=20= its=20packet identifiers=20from=20its=20own=20independent=20number=20space.=20Therefore= ,=20without the=20'tagger=20ID',=20Murphy=20will=20ensure=20that=20sometimes=20two=20'= taggers'=20will add=20an=20equal=20packet=20ID=20on=20two=20packets,=20that=20in=20actuali= ty=20are=20different, but=20have=20the=20same=20source=20address=20and=20multicast=20destination= =20address. Thus,=20'false=20duplicates'=20would=20be=20created.=20Within=20the=20mane= t,=20these=20would be=20indistinguishable=20for=20DPD,=20leading=20to=20incorrect=20discardin= g.=20[SMF authors,=20please=20correct...] >=20>>=20Furthermore,=20I=20would=20strongly=20suggest=20that=20the=20DPD=20= option=20 >=20_only_=20=20be=20 >=20>>=20used=20when=20a=20hash=20function=20would=20otherwise=20give=20th= e=20same=20 >=20result=20as=20it=20 >=20>>=20did=20for=20another=20recent=20packet=20from=20the=20same=20sourc= e.=20=20In=20 >=20other=20words,=20 >=20>>=20even=20for=20IPv6=20we=20should=20rely=20on=20hashing=20for=2099.= 999%=20of=20the=20 >=20cases=20and=20 >=20>>=20specify=20the=20use=20of=20the=20DPD=20option=20for=20only=20the=20= rarity=20of=20a=20 >=20duplicated=20 >=20>>=20hash=20result. >=20> >=20>=20I=20believe=20the=20problem=20is=20that=20the=20tagger=20(sometime= s=20not=20the=20source)=20 >=20>=20cannot=20determine=20which=20packets=20are=20duplicates=20and=20wh= ich=20are=20not=20 >=20>=20(unless=20they=20contain=20an=20ID).=20If=20you=20have=20a=20simpl= e=20method=20 >=20for=20taggers=20 >=20>=20to=20determine=20whether=20the=20ID=20is=20needed=20or=20not,=20I=20= would=20be=20 >=20interested=20in=20 >=20>=20hearing=20about=20it. >=20My=20method=20is=20simple: >=201=20=20Run=20a=20hash=20function=20on=20the=20packet. >=202.=20Compare=20to=20previous=20packets >=203.=20If=20there=20is=20a=20match,=20add=20the=20option. >=204.=20Otherwise,=20do=20not. >=20 >=20What's=20needed=20here=20is=20agreement=20on=20which=20hash=20function= =20to=20use. >=20It=20looks=20like=20we=20can=20devise=20a=20perfect=20hash,=20at=20lea= st=20until=20 >=20the=20ip_id=20field=20rolls=20over.=20=20By=20that=20time,=20the=20pre= vious=20 >=20packet=20that=20might=20have=20collided=20in=20hash=20space=20will=20b= e=20a=20 >=20distant=20forgotten=20memory=20of=20the=20manet. >=20> >=20>=20Also=20(this=20has=20been=20discussed=20before)=20hash=20operation= s=20can=20be=20heavy=20 >=20>=20weight=20for=20weak=20devices. >=20I=20strongly=20disagree=20with=20this=20claim.=20=20To=20my=20understa= nding,=20it=20 >=20is=20practically=20always=20the=20other=20way=20around.=20=20Adding=20= bytes=20 >=20over=20the=20air=20is=20typically=20more=20energy=20intensive=20than=20= >=20additional=20computation. >=20=20 >=20I'm=20not=20talking=20about=20full-blown=20zillion-bit=20privacy=20her= e.=20=20 >=20Some=20hash=20functions=20that=20work=20are=20much=20lighter=20weight.= >=20 >=20> >=20>=20For=20these=20reasons,=20I=20do=20not=20think=20hashing=20should=20= be=20the=20normal=20 >=20>=20operation.=20Instead=20tagging=20packets=20with=20good=20sequence=20= >=20numbers=20should=20 >=20>=20be=20the=20default=20operation. >=20I=20strongly=20disagree=20with=20this.=20=20I=20would=20like=20to=20se= e=20any=20 >=20documentation=20to=20the=20effect=20that=20this=20saves=20energy. >=20 >=20If=20there=20is=20a=20rare=20system=20for=20which=20it=20is=20true,=20= then=20those=20 >=20few=20devices=20could=20add=20the=20option.=20=20For=20most=20devices,= =20the=20 >=20option=20SHOULD=20NOT=20be=20used... >=20> >=20>=20Note=20that=20hashing=20(without=20including=20a=20unique=20ID)=20= can=20result=20in=20 >=20>=20several=20false=20collisions=20for=20video=20data,=20since=20video= =20data=20 >=20can=20produce=20 >=20>=20identical=20packets=20often.=20Joe=20has=20mentioned=20this=20a=20= few=20times=20in=20the=20 >=20>=20past.=20I=20believe=20he=20might=20have=20even=20presented=20some=20= data=20long=20ago. >=20We=20just=20proved=20otherwise=20--=20that=20a=20good=20hash=20functio= n=20 >=20completely=20disambiguates=20based=20on=20IP=20header=20alone.=20=20Th= ere=20is=20 >=20no=20need=20to=20include=20payload=20data. Now=20I=20am=20_really_=20in=20dense=20mode.=20How=20would=20this=20ever=20= work=20for=20a 'vanilla'=20IPv6=20header?=20Which=20header=20fields=20would=20distinguish= =20subsequent packets=20coming=20from=20the=20same=20source,=20sent=20to=20the=20same=20= multicast=20group? Payload=20length?=20Could=20easily=20be=20the=20same,=20if=20packets=20bel= ong=20to=20a=20bulk transfer=20and=20full=20MTU=20is=20exploited.=20Hop=20count?=20Not=20neces= sarily different.=20Flow=20label????=20What=20am=20I=20missing=20here? Best=20regards, Ronald >=20 >=20Regards, >=20Charlie=20P. >=20 >=20 >=20 >=20 >=20 >=20_______________________________________________ >=20manet=20mailing=20list >=20manet@ietf.org >=20https://www1.ietf.org/mailman/listinfo/manet >=20 This=20e-mail=20and=20its=20contents=20are=20subject=20to=20the=20DISCLAIM= ER=20at=20http://www.tno.nl/disclaimer/email.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 10 18:27:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbOmn-0000f0-FJ; Tue, 10 Apr 2007 18:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbOml-0000eu-Vg for manet@ietf.org; Tue, 10 Apr 2007 18:25:59 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbOmk-0008US-Gh for manet@ietf.org; Tue, 10 Apr 2007 18:25:59 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3AMPKO0003587; Wed, 11 Apr 2007 01:25:52 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 01:25:34 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 17:25:32 -0500 Received: from [10.162.77.214] ([10.162.77.214]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 17:25:30 -0500 Message-ID: <461C0ED2.6030204@nokia.com> Date: Tue, 10 Apr 2007 15:25:22 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ext Velt, R. (Ronald) in 't" Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <005001c7782c$f87e0110$0202a8c0@Teco> <46194FF4.2060604@nokia.com> <374005f30704090451p59212900n18b2b90184ead2a7@mail.gmail.com> <461A647F.3090209@nokia.com><374005f30704100149j6173d973hd6f2c0134621fc39@mail.gmail.com> <461BAE34.6000706@nokia.com> <7877C5C0B5CC894AB26113CF06CF88631EA558@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <7877C5C0B5CC894AB26113CF06CF88631EA558@ms-dt01thalia.tsn.tno.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2007 22:25:32.0508 (UTC) FILETIME=[26E859C0:01C77BBF] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070411012553-0CF24BB0-41241B8C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ronald, ext Velt, R. (Ronald) in 't wrote: > My interpretation is that the > 'tagger ID' helps in the case where multicast packets from a single > source _outside_ the manet can somehow follow different paths to > different gateways ('points of attachment'), where they are to be > injected _into_ the manet. At this point, these packets would be tagged. > This is also my understanding. > Since this would happen only once per packet, there is never more than > one DPD option per packet. However, each 'tagger' takes its packet > identifiers from its own independent number space. Therefore, without > the 'tagger ID', Murphy will ensure that sometimes two 'taggers' will > add an equal packet ID on two packets, that in actuality are different, > but have the same source address and multicast destination address. > Well, maybe, but only if the taggers are operating independently of each other. But, as noted in an earlier e-mail, it has the effect also of disabling duplicate suppression for packets that ought to be the same. I wonder which is the more frequent effect. > Thus, 'false duplicates' would be created. Within the manet, these would > be indistinguishable for DPD, leading to incorrect discarding. > So for this case, tagger-ID enables nodes to avoid incorrect discarding, whereas for the other case tagger-ID disables duplicate suppression, unless the taggers are cooperating with each other. But then we don't need tagger-ID. I'm not sure which is worse. Losing some broadcasts because of collision in DPD option space would resemble the effects of unreliable broadcast over the wireless medium. Propagating unwanted duplicates would congest the network. It surely depends on which bad thing happens more often. I wonder if there has been a study of this effect. >> We just proved otherwise -- that a good hash function >> completely disambiguates based on IP header alone. There is >> no need to include payload data. >> > > Now I am _really_ in dense mode. How would this ever work for a > 'vanilla' IPv6 header? You are right. I was forgetting about the this case when I said that payload was not needed. But I already agreed that the DPD option would be useful for cases where the hash function did not uniquely identify different broadcasts. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 11 01:27:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbVLd-00046o-OH; Wed, 11 Apr 2007 01:26:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbVLb-00046g-UH for manet@ietf.org; Wed, 11 Apr 2007 01:26:23 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbVLX-0001O1-Iy for manet@ietf.org; Wed, 11 Apr 2007 01:26:23 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3B5QF5n029241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Apr 2007 22:26:16 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3B5QFml003773; Tue, 10 Apr 2007 22:26:15 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3B5QF4N003766; Tue, 10 Apr 2007 22:26:15 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 22:26:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Tue, 10 Apr 2007 22:26:14 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <461BAE34.6000706@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Need for DPD header (SMF document discussion) Thread-Index: Acd7hhkzrRmA7wLGQ+6SS05LJo6R+gAcaiag From: "Henderson, Thomas R" To: "Charles E. Perkins" , "ext Ian Chakeres" X-OriginalArrivalTime: 11 Apr 2007 05:26:15.0016 (UTC) FILETIME=[EC9D6680:01C77BF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Charlie, Ian,=20 > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com]=20 > Sent: Tuesday, April 10, 2007 8:33 AM > To: ext Ian Chakeres > Cc: manet@ietf.org > Subject: Re: [manet] Need for DPD header (SMF document discussion) >=20 >=20 > Hello Ian, >=20 > ext Ian Chakeres wrote: > > > > The purpose is to uniquely identify the packet. If a node other than > > the source inserts the option, and there might be multiple taggers, > > then the tagger id must be included. > Do you mean to imply that the tagger becomes the source IP > address for the packet? If the source IP address stays the same, > then why does the identity of the tagger matter? >=20 > > Imagine there a manet with multiple points of attachment. If the > > source did not include the option field, then these=20 > attachment points > > should tag the packets. If each attachment points includes=20 > on the ID, > > the DPD matching might overlap. If this occurs various bad things > > happen. To avoid this situation the tagger id, disambiguates who > > performed the tagging operation. > Now I am even more confused. If two different taggers > add two different options to the same broadcast/multicast > packet, how can a manet node tell they are the same packet > after all, and (to fulfill the whole point of the exercise) > suppress duplicates? My understanding is that the DPD would need to be extended to consistently use the same tagger, if multiple gateways were tagging. That is, if there are two gateways A and B tagging the same packet and injecting it into SMF, the DPD would need to pick packets from one of these gateways and discard packets from the other, for a given source/destination pair, to suppress unwanted duplicates. I think this is explained in section 5.2.1 of the current draft. > We just proved otherwise -- that a good hash function completely > disambiguates based on IP header alone. There is no need to > include payload data. It would be nice to see some data regarding how heavyweight the hashing is for the classes of devices under consideration. Is that posted in a previous list message or presentation? I agree that if it is inexpensive, a hash on the packet would be preferable to the tagger ID solution. =20 However, I do not see why you would need (or want) to hash just the header; the hash output will be larger than or commensurate with storing the header fields themselves. Plus, I have been told that many multicast sources do not have distinguishing IP ID fields. Regards, Tom _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From nobody@rcmdxwebc01.cavtel.net Wed Apr 11 08:05:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbba7-0000rn-Fc for Manet-archive@lists.ietf.org; Wed, 11 Apr 2007 08:05:47 -0400 Received: from rcmdxweb_c01.cavtel.net ([64.83.1.51] helo=rcmdxwebc01.cavtel.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbba7-0008DR-8x for Manet-archive@lists.ietf.org; Wed, 11 Apr 2007 08:05:47 -0400 Received: by rcmdxwebc01.cavtel.net (Postfix, from userid 60001) id 9B9931CE20; Wed, 11 Apr 2007 03:51:01 -0400 (EDT) To: Manet-archive@lists.ietf.org Subject: Your E-mail address has won you £850,000.00. From: Mr Jerry Fidelix. Reply-To: towergatecourierservicesuae@yahoo.de MIME-Version: 1.0 Content-Type: text/plain Message-Id: <20070411081044.9B9931CE20@rcmdxwebc01.cavtel.net> Date: Wed, 11 Apr 2007 03:51:01 -0400 (EDT) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.4 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa =0D Your E-mail address has won you =A3850,000.00.=0D AFRICA LOTTERY ORGANIZATION=0D TEL: 234-2057 4481=0D TICKET FREE/ONLINE E-MAIL ADDRESS WINNINGS DEPARTMENT.=0D =0D If you are the correct owner of this email address then be glad this day = as the result of the Africa lotto free ticket online e-mail address winni= ng draws and sweepstakes held in DUBAI-UNITED ARAB EMIRATE on the 29th of= March. 2007 has just been released and we are glad to announce to you th= at your e-mail address has won you the free ticket online lottery in the = first winning category and you are entitled to claim the sum of =A3850,00= 0.00.=0D =0D Your email addresses was entered for the online draw on this Free Ticket = Number: APP236566301307 and won on this Lucky Number: MX014926583. All wi= nners cheque are certified cashiers and are cashable in any bank of any c= ountry.=0D =0D For your won prize certified cashiers cheque redemption contact the Couri= er Company incharge of all winners cheque delivery on the below informati= on:=0D =0D TOWER GATE COURIER SERVICES NIGERIA LIMITED=0D Address: #130 Allen Avenue, Ikeja,Lagos-Nigeria=0D Email: towergatecourierservicesuae@yahoo.de=0D Contact Officer: Mr. Anthony Okolie=0D Tel #: +234 1 816 5543=0D =0D You will be expected to contact the TOWER GATE COURIER SERVICES NIGERIA L= IMITED with the below winning claims information:-=0D =0D Your country, complete official names, address, amount won, free ticket a= nd lucky numbers,date/venue of draw, contact telephone, mobile and fax nu= mbers, sex, age, occupation and job title.=0D =0D Goodluck.=0D =0D Mr Jerry Fidelix.=0D Co-ordinator.=0D AFRICA LOTTERY ORGANIZATION=0D =0D =0D From manet-bounces@ietf.org Wed Apr 11 13:39:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbglE-0001Lp-S3; Wed, 11 Apr 2007 13:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbgkx-0001Cl-7J for manet@ietf.org; Wed, 11 Apr 2007 13:37:19 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbgjI-0004Zh-Q2 for manet@ietf.org; Wed, 11 Apr 2007 13:35:38 -0400 Received: by nz-out-0506.google.com with SMTP id z6so207620nzd for ; Wed, 11 Apr 2007 10:35:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=pdxd/fJysfvfKxEEB2EwAs3lpAy/lOX54WN00Nlzj2J3ZgszeU0Gqc32/Dvk/Ns58pO9wqHuf9960JTyLOD9l0oeet6oSgFo2nmYlQIXByWxCTjXuY+YMpE7jJ9gFarbpdGcgW77xmnxmoz+MSOrzUujkHxoXJHC2gmy7ysMsns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=uXm2WL9uy3/led5tc5DifpiKr3ZSV24VA5BevMc5YXMBue1WMnE7OoIY8UKkSwMbCguBU6lqy5DE05cFiF0mOVQS/OkPOcDfSnSflKSQo/Lpqm+EcshIt7jDtzw9peXV6BQdeZI1kwPX2F80MsDrFQrwC+aEOY/785AXW8dEcAM= Received: by 10.114.53.1 with SMTP id b1mr365337waa.1176312935646; Wed, 11 Apr 2007 10:35:35 -0700 (PDT) Received: by 10.114.169.18 with HTTP; Wed, 11 Apr 2007 10:35:35 -0700 (PDT) Message-ID: <6f9cb4f10704111035w496d3475p71b5ae37aabbab0f@mail.gmail.com> Date: Wed, 11 Apr 2007 23:05:35 +0530 From: "shilpa sharma" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [manet] Illegal Constant Pool Index X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1020008486==" Errors-To: manet-bounces@ietf.org --===============1020008486== Content-Type: multipart/alternative; boundary="----=_Part_19411_9056984.1176312935595" ------=_Part_19411_9056984.1176312935595 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello everyone.. I am using JIST/SWANS to simulate a wireless network.. I am running a program CBR.java (constant bit rate) that is present in the src/driver directory of JIST/SWANS.. I am able to compile this program but when i try to run it using this command.. java -cp.;..\libs\jargs.jar;..\libs\jist.jar..;\libs\bcel.jar;..\libs\bsh.jar;..\libs\checkstyle-al l.jar;..\libs\jython.jar;..\libs\log4j.jar;..\libs\swans.jar jist.runtime.Main jist.swans.Main driver.CBR -n 10 -c 5 where n is nodes and c is number of clients.. i get the following error.. Simulation exception! java.lang.VerifyError: (class: driver/CBR$Client, method: signature: (Lji st/swans/trans/TransInterface$TransUdpInterface;ILjist/swans/net/NetAddress;Ljis t/swans/net/NetAddress;)V) Illegal constant pool index at driver.CBR.buildField(CBR.java:609) at driver.CBR.main(CBR.java:645) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at jist.runtime.Bootstrap$JavaMain.startSimulation(Bootstrap.java :163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at jist.runtime.Controller.processEvent(Controller.java:650) at jist.runtime.Controller.eventLoop(Controller.java:428) at jist.runtime.Controller.run(Controller.java:457) at java.lang.Thread.run(Unknown Source) once i get this error Illegal Constant Pool Index I am never able to run this program again.. It sort of gets corrupted.. i had directly run the class file once but after i tried to compile it and run it gives me this error.. Even on compiling and running other files like aodvsim i am getting the same error.. If these files are compiled and then run successfully, then only i can try something of my own My java version is Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Plz anyone help me fix this error.. I'l be really thankfull.. ------=_Part_19411_9056984.1176312935595 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hello everyone..
I am using JIST/SWANS to simulate a wireless network..
I am running a program CBR.java (constant bit rate) that is present in the src/driver directory of JIST/SWANS.. I am able to compile this program but when i try to run it using this command..

 

java -cp.;..\libs\jargs.jar;..\libs\jist.jar..;\libs\bcel.jar;..\libs\bsh.jar;..\libs\checkstyle-al l.jar;..\libs\jython.jar;..\libs\log4j.jar;..\libs\swans.jar jist.runtime.Main jist.swans.Main driver.CBR -n 10 -c 5

 

where n is nodes and c is number of clients.. i get the following error..
 
 
Simulation exception!
java.lang.VerifyError: (class: driver/CBR$Client, method: <init> signature: (Lji
st/swans/trans/TransInterface$TransUdpInterface;ILjist/swans/net/NetAddress;Ljis
t/swans/net/NetAddress;)V) Illegal constant pool index
        at driver.CBR.buildField(CBR.java:609)
        at driver.CBR.main(CBR.java:645)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke (Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at jist.runtime.Bootstrap$JavaMain.startSimulation(Bootstrap.java :163)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Unknown Source)
        at jist.runtime.Controller.processEvent(Controller.java:650)
        at jist.runtime.Controller.eventLoop(Controller.java:428)
        at jist.runtime.Controller.run (Controller.java:457)
        at java.lang.Thread.run(Unknown Source)
 
once i get this error Illegal Constant Pool Index I am never able to run this program again.. It sort of gets corrupted.. i had directly run the class file once but after i tried to compile it and run it gives me this error.. Even on compiling and running other files like aodvsim i am getting the same error.. If these files are compiled and then run successfully, then only i can try something of my own
 
My java version is Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
 
Plz anyone help me fix this error.. I'l be really thankfull..
 
 
------=_Part_19411_9056984.1176312935595-- --===============1020008486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1020008486==-- From manet-bounces@ietf.org Wed Apr 11 14:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbhHZ-00008d-Eh; Wed, 11 Apr 2007 14:11:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbhHX-00008Y-MF for manet@ietf.org; Wed, 11 Apr 2007 14:10:59 -0400 Received: from mailgw4.technion.ac.il ([132.68.238.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbhHT-0007gO-E2 for manet@ietf.org; Wed, 11 Apr 2007 14:10:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 405D423FA6E for ; Wed, 11 Apr 2007 21:10:54 +0300 (IDT) X-Virus-Scanned: by amavisd-new at technion.ac.il Received: from mailgw4.technion.ac.il ([127.0.0.1]) by localhost (mailgw4.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gWn6t4ALk2sj for ; Wed, 11 Apr 2007 21:10:54 +0300 (IDT) Received: from csm.cs.technion.ac.il (csm.cs.technion.ac.il [132.68.32.31]) by mailgw4.technion.ac.il (Postfix) with ESMTP id 0371723FA3C for ; Wed, 11 Apr 2007 21:10:53 +0300 (IDT) Received: from gabiklap (gabik-lap.cs.technion.ac.il [132.68.41.248]) by csm.cs.technion.ac.il (Postfix) with ESMTP id 8384518C449; Wed, 11 Apr 2007 21:10:49 +0300 (IDT) From: "gabik" To: "'shilpa sharma'" , Subject: RE: [manet] Illegal Constant Pool Index Date: Wed, 11 Apr 2007 21:10:32 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6f9cb4f10704111035w496d3475p71b5ae37aabbab0f@mail.gmail.com> Thread-Index: Acd8YW3Za0Ta9uXaROC2LivBCH+jUgAAg4fw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070411181049.8384518C449@csm.cs.technion.ac.il> X-Spam-Score: 0.1 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1807582294==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1807582294== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0164_01C77C7D.D74AFAC0" This is a multi-part message in MIME format. ------=_NextPart_000_0164_01C77C7D.D74AFAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello You can Google "Illegal constant pool index" and find for example: http://www.jpox.org/servlet/forum/viewthread?thread=2506 I am not 100% sure, but it seems to be related to some inconsistencies between the version of BCEL used in JiST and the version of Java that you use. Probably updating bcel.jar or the java version will solve the problem. JIST/SWANS works perfectly fine for me with java 1.4. I also suggest that you ask Rimon Barr < rb83@cornell.edu> http://jist.ece.cornell.edu/people.html directly, and I am sure he will be able to give you the full answer. Best regards, Gabi Kliot _____ From: shilpa sharma [mailto:shilpasharma85@gmail.com] Sent: Wednesday, April 11, 2007 8:36 PM To: manet@ietf.org Subject: [manet] Illegal Constant Pool Index Hello everyone.. I am using JIST/SWANS to simulate a wireless network.. I am running a program CBR.java (constant bit rate) that is present in the src/driver directory of JIST/SWANS.. I am able to compile this program but when i try to run it using this command.. java -cp.;..\libs\jargs.jar;..\libs\jist.jar..;\libs\bcel.jar;..\libs\bsh.jar;..\ libs\checkstyle-al l.jar;..\libs\jython.jar;..\libs\log4j.jar;..\libs\swans.jar jist.runtime.Main jist.swans.Main driver.CBR -n 10 -c 5 where n is nodes and c is number of clients.. i get the following error.. Simulation exception! java.lang.VerifyError: (class: driver/CBR$Client, method: signature: (Lji st/swans/trans/TransInterface$TransUdpInterface;ILjist/swans/net/NetAddress; Ljis t/swans/net/NetAddress;)V) Illegal constant pool index at driver.CBR.buildField(CBR.java:609) at driver.CBR.main(CBR.java:645) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at jist.runtime.Bootstrap$JavaMain.startSimulation(Bootstrap.java :163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at jist.runtime.Controller.processEvent(Controller.java:650) at jist.runtime.Controller.eventLoop(Controller.java:428) at jist.runtime.Controller.run (Controller.java:457) at java.lang.Thread.run(Unknown Source) once i get this error Illegal Constant Pool Index I am never able to run this program again.. It sort of gets corrupted.. i had directly run the class file once but after i tried to compile it and run it gives me this error.. Even on compiling and running other files like aodvsim i am getting the same error.. If these files are compiled and then run successfully, then only i can try something of my own My java version is Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05) Plz anyone help me fix this error.. I'l be really thankfull.. ------=_NextPart_000_0164_01C77C7D.D74AFAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
You=20 can Google "Illegal constant pool index" and find for=20 example:
 
http:= //www.jpox.org/servlet/forum/viewthread?thread=3D2506
 
I am=20 not 100% sure, but it seems to be related to some inconsistencies = between the=20 version of BCEL used in JiST and the version of Java that you=20 use.
Probably updating bcel.jar or the java version will solve the=20 problem.
JIST/SWANS = works=20 perfectly fine for me with java 1.4.
 
I also suggest that you ask Rimon Barr <rb83@cornell.edu> http://jist.ece.cornell.= edu/people.html 
directly, and I am sure he will be able to give you the = full=20 answer.
 
Best=20 regards,
 
Gabi=20 Kliot
 
 
 
 
 

From: shilpa sharma=20 [mailto:shilpasharma85@gmail.com]
Sent: Wednesday, April 11, = 2007=20 8:36 PM
To: manet@ietf.org
Subject: [manet] Illegal = Constant=20 Pool Index

Hello everyone..
I am using JIST/SWANS to simulate a wireless network..
I am running a program CBR.java (constant bit rate) that is present = in the=20 src/driver directory of JIST/SWANS.. I am able to compile this program = but when=20 i try to run it using this command..

 

java=20 -cp.;..\libs\jargs.jar;..\libs\jist.jar..;\libs\bcel.jar;..\libs\bsh.jar;= ..\libs\checkstyle-al=20 l.jar;..\libs\jython.jar;..\libs\log4j.jar;..\libs\swans.jar=20 jist.runtime.Main jist.swans.Main driver.CBR -n 10 -c 5

 

where n is nodes and c is number of clients.. i get the following=20 error..
 
 
Simulation exception!
java.lang.VerifyError: (class: = driver/CBR$Client,=20 method: <init> signature:=20 (Lji
st/swans/trans/TransInterface$TransUdpInterface;ILjist/swans/net/= NetAddress;Ljis
t/swans/net/NetAddress;)V)=20 Illegal constant pool index =
        at=20 driver.CBR.buildField(CBR.java:609)
     &nbs= p; =20 at = driver.CBR.main(CBR.java:645)
      &nbs= p;=20 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native=20 Method)
        at=20 sun.reflect.NativeMethodAccessorImpl.invoke (Unknown=20 Source)
        at=20 sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown=20 Source)
        at=20 java.lang.reflect.Method.invoke(Unknown=20 Source)
        at=20 jist.runtime.Bootstrap$JavaMain.startSimulation(Bootstrap.java=20 :163)
        at=20 sun.reflect.NativeMethodAccessorImpl.invoke0(Native=20 Method)
        at=20 sun.reflect.NativeMethodAccessorImpl.invoke(Unknown=20 Source)
        at=20 sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)=20
        at=20 java.lang.reflect.Method.invoke(Unknown=20 Source)
        at=20 jist.runtime.Controller.processEvent(Controller.java:650)
  =      =20 at=20 jist.runtime.Controller.eventLoop(Controller.java:428)
  &nb= sp;    =20 at jist.runtime.Controller.run=20 (Controller.java:457)
        at=20 java.lang.Thread.run(Unknown Source)
 
once i get this error Illegal Constant Pool Index I am never able = to run=20 this program again.. It sort of gets corrupted.. i had directly run the = class=20 file once but after i tried to compile it and run it gives me this = error.. Even=20 on compiling and running other files like aodvsim i am getting the same = error..=20 If these files are compiled and then run successfully, then only i can = try=20 something of my own
 
My java version is Java(TM) 2 Runtime Environment, Standard Edition = (build=20 1.5.0_04-b05)
 
Plz anyone help me fix this error.. I'l be really = thankfull..
 
 
------=_NextPart_000_0164_01C77C7D.D74AFAC0-- --===============1807582294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1807582294==-- From manet-bounces@ietf.org Wed Apr 11 17:20:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkDG-0001EF-LD; Wed, 11 Apr 2007 17:18:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbkDD-0001E7-1m for manet@ietf.org; Wed, 11 Apr 2007 17:18:43 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HbkDB-0006CJ-He for manet@ietf.org; Wed, 11 Apr 2007 17:18:42 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3BLIHBQ008045; Thu, 12 Apr 2007 00:18:31 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 00:18:27 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 16:18:24 -0500 Received: from [10.162.79.221] ([10.162.79.221]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 16:18:23 -0500 Message-ID: <461D509A.1050209@nokia.com> Date: Wed, 11 Apr 2007 14:18:18 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ext Henderson, Thomas R" Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Apr 2007 21:18:24.0459 (UTC) FILETIME=[F06A99B0:01C77C7E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070412001831-1B823BB0-184CA252/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Tom, ext Henderson, Thomas R wrote: > >> We just proved otherwise -- that a good hash function completely >> disambiguates based on IP header alone. There is no need to >> include payload data. >> > > It would be nice to see some data regarding how heavyweight the hashing > is for the classes of devices under consideration. Is that posted in a > previous list message or presentation? I agree that if it is > inexpensive, a hash on the packet would be preferable to the tagger ID > solution. I am in the process of finding out what inexpensive hash functions are sufficiently effective for the job. So far, we have found that SHA-1 can completely disambiguate packets that are different only in the ip_id field, storing only 32 bits of the hash result (e.g., not 160 bits). To me, that means SHA-1 is "too good", and we can make do with less. I'll also try to get a count of the instruction cycles needed. > However, I do not see why you would need (or want) to hash just the > header; the hash output will be larger than or commensurate with storing > the header fields themselves. Plus, I have been told that many > multicast sources do not have distinguishing IP ID fields. > I don't claim that we should avoid including the payload. Exactly what needs to be hashed is a matter for further clarification. My statement was really targeted towards making the case that hashing is good and cheap. If we can get away with hashing only 512 bits of data, that would be nice, but it is not a showstopper if we need to use more. And, again, for cases where hashing does not disambiguate, then we can use the DPD option. This would, of course, be fine as a backup strategy. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 11 19:28:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbmEz-0006EM-1j; Wed, 11 Apr 2007 19:28:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbmEx-0006EH-3Z for manet@ietf.org; Wed, 11 Apr 2007 19:28:39 -0400 Received: from che.ojctech.com ([64.198.255.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbmEv-0004ts-Nj for manet@ietf.org; Wed, 11 Apr 2007 19:28:39 -0400 Received: from che.ojctech.com (localhost [127.0.0.1]) by che.ojctech.com (8.12.8/8.12.8) with ESMTP id l3BNSahH002931 for ; Wed, 11 Apr 2007 18:28:36 -0500 Received: (from dyoung@localhost) by che.ojctech.com (8.12.8/8.12.8/Submit) id l3BNSavg002929 for manet@ietf.org; Wed, 11 Apr 2007 18:28:36 -0500 Date: Wed, 11 Apr 2007 18:28:36 -0500 From: David Young To: manet@ietf.org Subject: Re: [manet] Need for DPD header (SMF document discussion) Message-ID: <20070411232836.GI13224@che.ojctech.com> Mail-Followup-To: manet@ietf.org References: <461BAE34.6000706@nokia.com> <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Tue, Apr 10, 2007 at 10:26:14PM -0700, Henderson, Thomas R wrote: > Hi Charlie, Ian, > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > > Sent: Tuesday, April 10, 2007 8:33 AM > > To: ext Ian Chakeres > > Cc: manet@ietf.org > > Subject: Re: [manet] Need for DPD header (SMF document discussion) > > > > > > Hello Ian, > > > > ext Ian Chakeres wrote: > > > > > > The purpose is to uniquely identify the packet. If a node other than > > > the source inserts the option, and there might be multiple taggers, > > > then the tagger id must be included. > > Do you mean to imply that the tagger becomes the source IP > > address for the packet? If the source IP address stays the same, > > then why does the identity of the tagger matter? > > > > > Imagine there a manet with multiple points of attachment. If the > > > source did not include the option field, then these > > attachment points > > > should tag the packets. If each attachment points includes > > on the ID, > > > the DPD matching might overlap. If this occurs various bad things > > > happen. To avoid this situation the tagger id, disambiguates who > > > performed the tagging operation. > > Now I am even more confused. If two different taggers > > add two different options to the same broadcast/multicast > > packet, how can a manet node tell they are the same packet > > after all, and (to fulfill the whole point of the exercise) > > suppress duplicates? > > My understanding is that the DPD would need to be extended to > consistently use the same tagger, if multiple gateways were tagging. > That is, if there are two gateways A and B tagging the same packet and > injecting it into SMF, the DPD would need to pick packets from one of > these gateways and discard packets from the other, for a given > source/destination pair, to suppress unwanted duplicates. I think this > is explained in section 5.2.1 of the current draft. > > > > We just proved otherwise -- that a good hash function completely > > disambiguates based on IP header alone. There is no need to > > include payload data. > > It would be nice to see some data regarding how heavyweight the hashing > is for the classes of devices under consideration. Is that posted in a > previous list message or presentation? I agree that if it is > inexpensive, a hash on the packet would be preferable to the tagger ID > solution. Ian, Tom, and Charlie, I cannot tell whether or not you each mean the same thing when you say a hash is "heavyweight." I took Ian to mean system resources such as CPU and bus/memory bandwidth---that is, a heavyweight hash reduces total system performance. Charlie is concerned with how fast the device draws down its battery. I am concerned with the total system performance, and I will say a bit about that. I expect that some MANET routers will be portable devices containing an ARM CPU with a modest data cache size. Let us say the cache size is 8kB. If you are forwarding 1kB multicast packets, and the CPU hashes each packet payload for the purpose of duplicate detection, then the rate of cache turnover as you compute the hash function over every byte of every packet is potentially very high (up to 1/8th of your cache per packet). The danger is that the operating system and applications (MP3 player, telephone, photo/movie display, web browser) slow tremendously as they get kicked out of the cache by multicast traffic. [Contrast that with the usual unicast forwarding case: provided that the NIC has verified the IP checksum (not too unusual, these days), the CPU need only read the IP header of any packet to make a forwarding decision, so the cache impact is small.] Incidentally, some ARM "systems on a chip" have coprocessors for CRC32. Will comparison of CRC32s suffice to detect duplicates? Dave -- David Young OJC Technologies dyoung@ojctech.com Urbana, IL * (217) 278-3933 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 00:51:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbrGp-0006dA-Aq; Thu, 12 Apr 2007 00:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbrGn-0006aU-U7 for manet@ietf.org; Thu, 12 Apr 2007 00:50:53 -0400 Received: from ee.tamu.edu ([165.91.241.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbrGl-0001H9-GT for manet@ietf.org; Thu, 12 Apr 2007 00:50:53 -0400 Received: from eesun1.tamu.edu (eesun1.tamu.edu [165.91.243.35]) by ee.tamu.edu (8.13.6/8.13.6) with ESMTP id l3C4mYCY003348; Wed, 11 Apr 2007 23:48:34 -0500 (CDT) Date: Wed, 11 Apr 2007 23:48:34 -0500 (CDT) From: Xi Zhang X-Sender: xizhang@eesun1.tamu.edu To: tccc@cs.columbia.edu, mycolleagues@grid.lrg.ufsc.br, manet@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: Subject: [manet] April 15, 2007, New Deadline: ACM IWCMC 2007, Aug 12, 2007, Honolulu, Hawaii, USA. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Due to many requests, the ACM IWCMC 2007 Organizing Committee decide to extend the paper submission due to the following: Submissions: EDAS --> Deadline extened to April 15, 2007. Submission papers' fontsize can be either 9pt or 10 pt. Call For Papers for ACM IWCMC 2007: _____________________ ACM IWCMC 2007 (http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) August 12-16, 2007, Honolulu, Hawaii, USA Technical Sponsors: ACM (Approved) and IEEE (Pending) Submissions: EDAS --> Deadline extended to April 15, 2007. "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" The ACM International Wireless Communications and Mobile Computing Conference 2007 (ACM IWCMC 2007) will be held in Turtle Bay Resort Hotel, Honolulu, Hawaii, USA during August 12-16, 2007. Under our new theme of "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" , IWCMC2007 is targeting at a wide spectrum of state-of-the-art as well as emerging topics pertaining to wireless networks, communications, and mobile computing. Continuing the great succeed of ACM IWCMC 2006 last year, IWCMC 2007 is anticipated to attract an even larger volume of high quality submissions and stimulate the cutting-edge research discussions amongst many academic pioneering researchers/scientists and industrial engineers/leaders attendees from all around the world as was evidenced during ACM IWCMC 2006. The ACM IWCMC 2007 program will feature a General Symposium, 8 Specific Technical Symposia, Workshop, and Tutorials Sessions. Prospective authors are invited to submit original technical papers to the corresponding IWCMC 2007 Symposia as listed below for oral presentation at IWCMC 2007 and publication in the IWCMC 2007 Conference Proceedings. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ We're pleased to announce the following: [1] Professor Gordon Stuber from Georgia Tech, USA, who is the world-class leader in mobile wireless communications/networking, communication signal processing, and many other areas, has agreed to be the Keynote Speaker for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [2] "NTT DoCoMo USA", which is one of most famous companies in the mobile communications industries, has officially become the Financial Sponsor for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [3] ACM has officially become the technical sponsor for IWCMC 2007 (this was notified earlier) and all the accepted IWCMC 2007 papers will be included into the ACM Database. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ IWCMC 2007 General Organizing Committee: General Co-Chairs: Mohsen Guizani, Western Michigan University, USA, Email: mguizani@ieee.org Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan, Email: hshwchen@comm.nsysu.edu.tw Technical Program Committee Chair: Xi Zhang, Texas A&M University, USA, Email: xizhang@ece.tamu.edu Financial Chair: Eun K. Park, University of Missouri at Kansas City, USA, Email: ekpark@umkc.edu IWCMC 2007 Technical Symposia: General Symposium: Chair: Xuemin (Sherman) Shen, University of Waterloo, Canada, xshen@bbcr.uwaterloo.ca Co-Chairs: Dongmei Zhao, McMaster University, Canada, dzhao@mail.ece.mcmaster.ca Hai Jiang, Princeton University, USA, haijiang@princeton.edu (1) Communication and Information Theory Symposium: Chair: Hamid Sadjadpour, University of California, Santa Cruz, USA, hamid@soe.ucsc.edu Ravi Narasimhan, University of California, Santa Cruz, USA ravi@soe.ucsc.edu (2) Computer and Network Security Symposium: Chair: Xiaojiang (James) Du, North Dakota State University, USA, xiaojiang.du@ndsu.edu Co-Chairs: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org, Yong Guan, Iowa State University, USA, guan@iastate.edu (3) Cross-Layer Optimized Wireless Networks Symposium: Chair: Xi Zhang, Texas A&M University, USA, xizhang@ece.tamu.edu Co-Chairs: Weihua Zhuang, University of Waterloo, Canada, wzhuang@ece.uwaterloo.ca Sunghyun Choi, Seoul National University, Korea, schoi@snu.ac.kr Kun Yang, University of Essex, UK, kunyang@essex.ac.uk (4) MIMO Systems Symposium: Chair: Zhengyuan Xu, University of California, Riverside, USA, dxu@ee.ucr.edu Co-Chairs (in alphabet order): Javier Garcia-Frias, University of Delaware, USA, jgarcia@ee.udel.edu Mounir Ghogho, Leeds University, UK, m.ghogho@leeds.ac.uk Weifeng Su, State University of New York (SUNY) at Buffalo, USA, weifeng@eng.buffalo.edu Liuqing Yang, University of Florida, USA, lqyang@ece.ufl.edu (5) Mobile Computing Symposium: Chair: Jie Li, University of Tsukuba, Japan, lijie@cs.tsukuba.ac.jp (6) Multimedia over Wireless Symposium: Chairs: Haohong Wang, Marvell Technology Group, USA, haohongwang@yahoo.com (7) Next Generation Mobile Networks Symposium (Website Link): Chair: Victor Leung, The University of British Columbia, Canada, vleung@ece.ubc.ca Co-Chairs: Ekram Hossain, University of Manitoba, Canada, ekram@ee.umanitoba.ca Javan Erfanian, Bell Mobility, Canada, javan.erfanian@bell.ca (8) Wireless Sensor Networks Symposium: Chair: Yang Yang, University College London, United Kingdom, y.yang@ee.ucl.ac.uk (9) Wireless LANs and Wireless PANs Symposium: Chair: Ehab Elmallah, University of Alberta, Canada, Canada, ehab@cs.ualberta.ca Co-Chair: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org (10) Workshop Chair: Song Ci, University of Nebraska-Lincoln, USA sci@engr.unl.edu Co-Chair: Yi Cui, Vanderbilt University, USA yi.cui@vanderbilt.edu IMPORTANT DATES: Full Paper Submission: April 15, 2007 (updated) Notification of Acceptance: May 25, 2007 Camera-Ready Version/Copyright Form Submission: June 11, 2007 Registration Deadline for Authors: June 11, 2007 Hotel Reservation Deadline: July 10, 2007 _____________________ ========================================================================= Xi Zhang Assistant Professor Dept. of Elec. & Comput. Engin. Phone: 979-458-1416 Texas A&M University Fax: 979-845-2630 333N WERC Building Email: xizhang@ece.tamu.edu College Station, Texas 77843, USA URL http://dropzone.tamu.edu/~xizhang ========================================================================= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 02:19:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbsek-00038R-SW; Thu, 12 Apr 2007 02:19:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbsei-00038J-TB for manet@ietf.org; Thu, 12 Apr 2007 02:19:40 -0400 Received: from ee.tamu.edu ([165.91.241.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbseh-0002Md-G1 for manet@ietf.org; Thu, 12 Apr 2007 02:19:40 -0400 Received: from ECE149 (ece149.tamu.edu [165.91.208.72]) by ee.tamu.edu (8.13.6/8.13.6) with SMTP id l3C6JZie008857; Thu, 12 Apr 2007 01:19:35 -0500 (CDT) Message-ID: <002001c77cd2$ed728430$48d05ba5@ECE149> From: "Dr. Xi Zhang" To: Date: Thu, 12 Apr 2007 01:19:31 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: ekpark@umkc.edu, hshwchen@comm.nsysu.edu.tw, mguizani@uaeu.ac.ae Subject: [manet] Deadline Extended to April 15, 2007: ACM IWCMC 2007, Aug 12, 2007, Honolulu, Hawaii, USA. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org *Sorry for receiving multiple copies* Submissions: EDAS --> Deadline extened to April 15, 2007. Call For Papers for ACM IWCMC 2007: _____________________ ACM IWCMC 2007 (http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) August 12-16, 2007, Honolulu, Hawaii, USA Technical Sponsors: ACM (Approved) and IEEE (Pending) Submissions: EDAS --> Deadline extended to April 15, 2007. "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" The ACM International Wireless Communications and Mobile Computing Conference 2007 (ACM IWCMC 2007) will be held in Turtle Bay Resort Hotel, Honolulu, Hawaii, USA during August 12-16, 2007. Under our new theme of "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" , IWCMC2007 is targeting at a wide spectrum of state-of-the-art as well as emerging topics pertaining to wireless networks, communications, and mobile computing. Continuing the great succeed of ACM IWCMC 2006 last year, IWCMC 2007 is anticipated to attract an even larger volume of high quality submissions and stimulate the cutting-edge research discussions amongst many academic pioneering researchers/scientists and industrial engineers/leaders attendees from all around the world as was evidenced during ACM IWCMC 2006. The ACM IWCMC 2007 program will feature a General Symposium, 8 Specific Technical Symposia, Workshop, and Tutorials Sessions. Prospective authors are invited to submit original technical papers to the corresponding IWCMC 2007 Symposia as listed below for oral presentation at IWCMC 2007 and publication in the IWCMC 2007 Conference Proceedings. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ We're pleased to announce the following: [1] Professor Gordon Stuber from Georgia Tech, USA, who is the world-class leader in mobile wireless communications/networking, communication signal processing, and many other areas, has agreed to be the Keynote Speaker for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [2] "NTT DoCoMo USA", which is one of most famous companies in the mobile communications industries, has officially become the Financial Sponsor for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [3] ACM has officially become the technical sponsor for IWCMC 2007 (this was notified earlier) and all the accepted IWCMC 2007 papers will be included into the ACM Database. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ IWCMC 2007 General Organizing Committee: General Co-Chairs: Mohsen Guizani, Western Michigan University, USA, Email: mguizani@ieee.org Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan, Email: hshwchen@comm.nsysu.edu.tw Technical Program Committee Chair: Xi Zhang, Texas A&M University, USA, Email: xizhang@ece.tamu.edu Financial Chair: Eun K. Park, University of Missouri at Kansas City, USA, Email: ekpark@umkc.edu IWCMC 2007 Technical Symposia: General Symposium: Chair: Xuemin (Sherman) Shen, University of Waterloo, Canada, xshen@bbcr.uwaterloo.ca Co-Chairs: Dongmei Zhao, McMaster University, Canada, dzhao@mail.ece.mcmaster.ca Hai Jiang, Princeton University, USA, haijiang@princeton.edu (1) Communication and Information Theory Symposium: Chair: Hamid Sadjadpour, University of California, Santa Cruz, USA, hamid@soe.ucsc.edu Ravi Narasimhan, University of California, Santa Cruz, USA ravi@soe.ucsc.edu (2) Computer and Network Security Symposium: Chair: Xiaojiang (James) Du, North Dakota State University, USA, xiaojiang.du@ndsu.edu Co-Chairs: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org, Yong Guan, Iowa State University, USA, guan@iastate.edu (3) Cross-Layer Optimized Wireless Networks Symposium: Chair: Xi Zhang, Texas A&M University, USA, xizhang@ece.tamu.edu Co-Chairs: Weihua Zhuang, University of Waterloo, Canada, wzhuang@ece.uwaterloo.ca Sunghyun Choi, Seoul National University, Korea, schoi@snu.ac.kr Kun Yang, University of Essex, UK, kunyang@essex.ac.uk (4) MIMO Systems Symposium: Chair: Zhengyuan Xu, University of California, Riverside, USA, dxu@ee.ucr.edu Co-Chairs (in alphabet order): Javier Garcia-Frias, University of Delaware, USA, jgarcia@ee.udel.edu Mounir Ghogho, Leeds University, UK, m.ghogho@leeds.ac.uk Weifeng Su, State University of New York (SUNY) at Buffalo, USA, weifeng@eng.buffalo.edu Liuqing Yang, University of Florida, USA, lqyang@ece.ufl.edu (5) Mobile Computing Symposium: Chair: Jie Li, University of Tsukuba, Japan, lijie@cs.tsukuba.ac.jp (6) Multimedia over Wireless Symposium: Chairs: Haohong Wang, Marvell Technology Group, USA, haohongwang@yahoo.com (7) Next Generation Mobile Networks Symposium (Website Link): Chair: Victor Leung, The University of British Columbia, Canada, vleung@ece.ubc.ca Co-Chairs: Ekram Hossain, University of Manitoba, Canada, ekram@ee.umanitoba.ca Javan Erfanian, Bell Mobility, Canada, javan.erfanian@bell.ca (8) Wireless Sensor Networks Symposium: Chair: Yang Yang, University College London, United Kingdom, y.yang@ee.ucl.ac.uk (9) Wireless LANs and Wireless PANs Symposium: Chair: Ehab Elmallah, University of Alberta, Canada, Canada, ehab@cs.ualberta.ca Co-Chair: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org (10) Workshop Chair: Song Ci, University of Nebraska-Lincoln, USA sci@engr.unl.edu Co-Chair: Yi Cui, Vanderbilt University, USA yi.cui@vanderbilt.edu IMPORTANT DATES: Full Paper Submission: April 15, 2007 (extended) Notification of Acceptance: May 30, 2007 Camera-Ready Version/Copyright Form Submission: June 11, 2007 Registration Deadline for Authors: June 11, 2007 Hotel Reservation Deadline: July 10, 2007 _____________________ ========================================================================= Xi Zhang Assistant Professor Dept. of Elec. & Comput. Engin. Phone: 979-458-1416 Texas A&M University Fax: 979-845-2630 333N WERC Building Email: xizhang@ece.tamu.edu College Station, Texas 77843, USA URL http://dropzone.tamu.edu/~xizhang ========================================================================= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 08:13:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbyAv-0004x1-HU; Thu, 12 Apr 2007 08:13:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbyAt-0004wu-6l for manet@ietf.org; Thu, 12 Apr 2007 08:13:15 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbyAs-0000CJ-Rs for manet@ietf.org; Thu, 12 Apr 2007 08:13:15 -0400 Received: by wx-out-0506.google.com with SMTP id h31so539521wxd for ; Thu, 12 Apr 2007 05:13:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dGl4AWG0HYBjB+o2rlsUiW0TW3HIQ7tzW4nxKMzovhDlQBrmArSTHcZUrte5r7em8WeqlCEDFQnJM76cSa2TQ6+Fx9kQv5H/QWN07Rj2zta+W6MdoeNLefKjfGx0Tuu5lcdE/2MOGsw1trrggrsZChaw0e4/qI1RmEWeSeF0gn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f071l7G9tGcFnQZFitpF3QdY5jpAiOmxBuXWXy5n2geBZZ6BzRuDu32lKRv1ZajgOwgrBEhuio52TFo+/Y51yNFmBaNQUtXY4PdLWy3V6BZAkFAZvVS3zvCy7LHx2AOyQPAqoMI3sq51oih2x/9TXatZ7gfR51vHajPlHLtL9oM= Received: by 10.78.39.16 with SMTP id m16mr311197hum.1176379993176; Thu, 12 Apr 2007 05:13:13 -0700 (PDT) Received: by 10.78.58.3 with HTTP; Thu, 12 Apr 2007 05:13:12 -0700 (PDT) Message-ID: <374005f30704120513k3a956c59lc23e16958b21f088@mail.gmail.com> Date: Thu, 12 Apr 2007 17:43:12 +0530 From: "Ian Chakeres" To: dyoung@pobox.com Subject: Re: [manet] Need for DPD header (SMF document discussion) In-Reply-To: <20070411232836.GI13224@che.ojctech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <461BAE34.6000706@nokia.com> <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <20070411232836.GI13224@che.ojctech.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org David, The current SMF document describes a simple DPD procedure that is very lightweight in terms of CPU, state, energy, etc. I think it should be preferred over other DPD mechanisms, e.g. hashing. Ian On 4/12/07, David Young wrote: > On Tue, Apr 10, 2007 at 10:26:14PM -0700, Henderson, Thomas R wrote: > > Hi Charlie, Ian, > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > > > Sent: Tuesday, April 10, 2007 8:33 AM > > > To: ext Ian Chakeres > > > Cc: manet@ietf.org > > > Subject: Re: [manet] Need for DPD header (SMF document discussion) > > > > > > > > > Hello Ian, > > > > > > ext Ian Chakeres wrote: > > > > > > > > The purpose is to uniquely identify the packet. If a node other than > > > > the source inserts the option, and there might be multiple taggers, > > > > then the tagger id must be included. > > > Do you mean to imply that the tagger becomes the source IP > > > address for the packet? If the source IP address stays the same, > > > then why does the identity of the tagger matter? > > > > > > > Imagine there a manet with multiple points of attachment. If the > > > > source did not include the option field, then these > > > attachment points > > > > should tag the packets. If each attachment points includes > > > on the ID, > > > > the DPD matching might overlap. If this occurs various bad things > > > > happen. To avoid this situation the tagger id, disambiguates who > > > > performed the tagging operation. > > > Now I am even more confused. If two different taggers > > > add two different options to the same broadcast/multicast > > > packet, how can a manet node tell they are the same packet > > > after all, and (to fulfill the whole point of the exercise) > > > suppress duplicates? > > > > My understanding is that the DPD would need to be extended to > > consistently use the same tagger, if multiple gateways were tagging. > > That is, if there are two gateways A and B tagging the same packet and > > injecting it into SMF, the DPD would need to pick packets from one of > > these gateways and discard packets from the other, for a given > > source/destination pair, to suppress unwanted duplicates. I think this > > is explained in section 5.2.1 of the current draft. > > > > > > > We just proved otherwise -- that a good hash function completely > > > disambiguates based on IP header alone. There is no need to > > > include payload data. > > > > It would be nice to see some data regarding how heavyweight the hashing > > is for the classes of devices under consideration. Is that posted in a > > previous list message or presentation? I agree that if it is > > inexpensive, a hash on the packet would be preferable to the tagger ID > > solution. > > Ian, Tom, and Charlie, > > I cannot tell whether or not you each mean the same thing when you say > a hash is "heavyweight." I took Ian to mean system resources such as > CPU and bus/memory bandwidth---that is, a heavyweight hash reduces total > system performance. Charlie is concerned with how fast the device draws > down its battery. I am concerned with the total system performance, > and I will say a bit about that. > > I expect that some MANET routers will be portable devices containing an > ARM CPU with a modest data cache size. Let us say the cache size is 8kB. > If you are forwarding 1kB multicast packets, and the CPU hashes each > packet payload for the purpose of duplicate detection, then the rate of > cache turnover as you compute the hash function over every byte of every > packet is potentially very high (up to 1/8th of your cache per packet). > The danger is that the operating system and applications (MP3 player, > telephone, photo/movie display, web browser) slow tremendously as they > get kicked out of the cache by multicast traffic. > > [Contrast that with the usual unicast forwarding case: provided that the > NIC has verified the IP checksum (not too unusual, these days), the CPU > need only read the IP header of any packet to make a forwarding decision, > so the cache impact is small.] > > Incidentally, some ARM "systems on a chip" have coprocessors for CRC32. > Will comparison of CRC32s suffice to detect duplicates? > > Dave > > -- > David Young OJC Technologies > dyoung@ojctech.com Urbana, IL * (217) 278-3933 > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 08:49:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbykM-0006S3-OM; Thu, 12 Apr 2007 08:49:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbykJ-0006Rk-FD; Thu, 12 Apr 2007 08:49:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HbykH-0005Il-Ut; Thu, 12 Apr 2007 08:49:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2007 08:49:51 -0400 X-IronPort-AV: i="4.14,401,1170651600"; d="scan'208,217"; a="57434564:sNHT81309932" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3CCnn8m009293; Thu, 12 Apr 2007 08:49:49 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3CCneGd003604; Thu, 12 Apr 2007 12:49:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 08:49:40 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 08:49:36 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: 6lowpan@ietf.org, manet@ietf.org, manemo@ietf.org Message-Id: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com> From: JP Vasseur Date: Thu, 12 Apr 2007 08:49:21 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 12 Apr 2007 12:49:40.0326 (UTC) FILETIME=[09074860:01C77D01] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4537; t=1176382189; x=1177246189; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20New=20Mailing=20List=3A=20Routing=20for=20Sensor=20Network |Sender:=20 |To:=206lowpan@ietf.org,=20manet@ietf.org,=20manemo@ietf.org; bh=NUzm1bNYwR/9jRsxn/9lb5n/nnyYcMAWRsmDI89qZlk=; b=keQboR57bgAXh3d1nz0bMwF8jJd+wNOj+jUhrFF6A5/UwZ+FxrFdvMJP+RL2aZxFlzN96GSh nT2R7+uY8kU0t6GbUtCKQ8pnos3HB59RpzHESuMpKilBujc2BlHXm3ky; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Ross Callon , Mark Townsley , David Culler , David Ward Subject: [manet] New Mailing List: Routing for Sensor Network X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1310691298==" Errors-To: manet-bounces@ietf.org --===============1310691298== Content-Type: multipart/alternative; boundary=Apple-Mail-1-506465484 --Apple-Mail-1-506465484 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, We wanted to inform you that a new Mailing List has been set up, the aim of which is to discuss Routing for Sensor Networks (at the IP layer). Anybody interested in contributing to the work is of course more than welcome to subscribe and collaborate. To register: https:// www1.ietf.org/mailman/listinfo/rsn Several of you already expressed some real interest in this work and several documents (with currently no home WG) already exist. David and I posted are about to post an ID on the routing requirements for Sensor Networks (probably early next week) to kick off the discussion. What is the overall objective ? 1) As you know a plethora of proprietary routing protocols (thus outside of the IETF) have been developed and there is within the IETF currently no clear answer on which protocol(s) can satisfy the very specific requirements of Sensor Networks. This triggered this initiative so as to define a routing architecture and routing protocol at the IETF for Sensor Nets, thus this new mailing list. Note that we may not be able to come up with a single set of requirements but a few requirement documents accompanied with some applicability IDs if it turns out that a unique solution cannot satisfy them all. 2) There is at this stage no a priori on the routing protocol that could be used: it could either be (1) existing routing protocol(s) (AODV, DYMO, OLSR, Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with enhancements or (3) new routing protocol(s). Possible next steps If enough interest for this work is shown on the list, we will request a BOF for Chicago, which may lead to forming a new WG. JP and David. --Apple-Mail-1-506465484 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi,

We wanted to inform you that a new Mailing = List has been set up, the aim of which is to discuss Routing for Sensor = Networks (at the IP layer). Anybody interested in contributing to the = work is of course more than welcome to subscribe and collaborate. To = register:=A0https://www1.ietf.org/mailman/listinfo/rsn=

Several of you already = expressed some real interest in this work and several documents (with = currently no home WG) already exist. David and I posted are about to = post an ID on the routing requirements for Sensor Networks (probably = early next week) to kick off the discussion.

What is the overall = objective ?
1) As you know a plethora of proprietary = routing protocols (thus outside of the IETF)=A0have been developed=A0and = there is within the IETF currently no clear answer on which protocol(s) = can satisfy the very specific requirements of Sensor Networks. This = triggered this initiative so as to define a routing architecture and = routing protocol at the IETF for Sensor Nets, thus this new mailing = list. Note that we may not be able to come up with a single set of = requirements but a few requirement documents accompanied with some = applicability IDs if it turns out that a unique solution cannot satisfy = them all.
2) There is at this stage no a priori on the routing = protocol that could be used: it could either be (1) existing routing = protocol(s) (AODV, DYMO, OLSR, Triggered RIP, NEMO, ...) (1) existing = routing protocol(s) with enhancements or (3) new routing = protocol(s).

Possible next = steps
If enough interest for this work is shown on the = list, we will request a BOF for Chicago, which may lead to forming a new = WG.

JP and = David.


= --Apple-Mail-1-506465484-- --===============1310691298== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1310691298==-- From manet-bounces@ietf.org Thu Apr 12 09:48:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbzek-0007HS-Kq; Thu, 12 Apr 2007 09:48:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbzei-0007HC-Ax for manet@ietf.org; Thu, 12 Apr 2007 09:48:08 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbzei-0007Mf-0m for manet@ietf.org; Thu, 12 Apr 2007 09:48:08 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3CDm7eF027545 for ; Thu, 12 Apr 2007 09:48:07 -0400 (EDT) Received: (from chiron [132.250.93.53]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007041209480728480 for ; Thu, 12 Apr 2007 09:48:07 -0400 From: "Jeff Weston" To: References: Subject: Re: [manet] Need for DPD header (SMF document discussion) Date: Thu, 12 Apr 2007 09:48:01 -0400 Message-ID: <001601c77d09$2ff23a90$355dfa84@chiron> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd8kZxvfDn4A8NMS2CFV5Eze3bzLQAbh7/Q In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > From: "Charles E. Perkins" > Subject: Re: [manet] Need for DPD header (SMF document discussion) > To: "ext Henderson, Thomas R" > Cc: manet@ietf.org > Message-ID: <461D509A.1050209@nokia.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Hello Tom, > > ext Henderson, Thomas R wrote: > > > >> We just proved otherwise -- that a good hash function completely > >> disambiguates based on IP header alone. There is no need to > >> include payload data. > >> > > > > It would be nice to see some data regarding how heavyweight > the hashing > > is for the classes of devices under consideration. Is that > posted in a > > previous list message or presentation? I agree that if it is > > inexpensive, a hash on the packet would be preferable to > the tagger ID > > solution. > I am in the process of finding out what inexpensive hash functions > are sufficiently effective for the job. So far, we have found > that SHA-1 can completely disambiguate packets that are > different only in the ip_id field, storing only 32 bits of the hash > result (e.g., not 160 bits). To me, that means SHA-1 is > "too good", and we can make do with less. Maybe I'm just misunderstanding something, but it seems to me as if you're saying "hashing is good enough as long as the IP_ID field is changed, so we don't need the DPD option header". But the DPD option header only applies to IPv6, which doesn't have an IP_ID field in the first place, so the point is moot, no? (not to mention, that the IP_ID field is not incremented on all systems -- many Linux 2.4 kernels always set it to zero for UDP packets, IIRC) > I'll also try to get a count of the instruction cycles needed. > > > However, I do not see why you would need (or want) to hash just the > > header; the hash output will be larger than or commensurate > with storing > > the header fields themselves. Plus, I have been told that many > > multicast sources do not have distinguishing IP ID fields. > > > I don't claim that we should avoid including the payload. > Exactly what > needs > to be hashed is a matter for further clarification. My > statement was really > targeted towards making the case that hashing is good and > cheap. If we > can get away with hashing only 512 bits of data, that would > be nice, but > it is not a showstopper if we need to use more. > > And, again, for cases where hashing does not disambiguate, > then we can use the DPD option. This would, of course, be > fine as a backup strategy. I don't think hashing is as reliable as you think it is. Here are a few potential problems I see with your solution (which, as I understand it, is simply "compare hash to an arbitrary number of previously stored hashes, and add the DPD option header if there's a conflict"): 1) In a heterogeneous MANET, where different devices have different memory and CPU capabilities, you may have nodes that are capable of storing only a very small subset of the hashes stored by other nodes. If these nodes source any data, then it is possible that they may not notice a hash conflict while the forwarding nodes do, dropping the packet... 2) Multicast packets may be received out-of-order, which could cause problems if a conflicting hash has just been thrown out by the source node, but not on some forwarding nodes (so they drop the packet). 3) Similarly, if any node sources multicast packets such that they have a TTL/max hop count that does not allow propogation throughout the entire MANET, then the source node will undoubtedly throw old hashes out faster than some of its forwarders... 4) The same problem will happen if a MANET fragments, and comes back together some time later. These are potential problems with IPv6 no matter how good your hashing is (even if your hash is "store the entire packet"), since plain vanilla IPv6 packets with identical payloads are indistinguishable, AFAIK. As previously mentioned, these aren't uncommon, with video, VOIP "hello" packets, etc. Honestly, I just don't see the need to bring in the complications of hashing ... it creates more problems than it solves, IMHO... Creating a potentially unreliable multicast network in favor of saving a few bytes on the air just doesn't seem right to me. -Jeff Weston _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 11:59:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1hd-0002BG-MJ; Thu, 12 Apr 2007 11:59:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1hb-0002BB-7y for manet@ietf.org; Thu, 12 Apr 2007 11:59:15 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc1hZ-0000k6-Mw for manet@ietf.org; Thu, 12 Apr 2007 11:59:15 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3CFwxva011399; Thu, 12 Apr 2007 18:59:11 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 18:58:59 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:58:36 -0500 Received: from [10.162.27.44] ([10.162.27.44]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 10:58:34 -0500 Message-ID: <461E5720.1070209@nokia.com> Date: Thu, 12 Apr 2007 08:58:24 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Jeff Weston Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <001601c77d09$2ff23a90$355dfa84@chiron> In-Reply-To: <001601c77d09$2ff23a90$355dfa84@chiron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 15:58:35.0154 (UTC) FILETIME=[6D1CC720:01C77D1B] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070412185911-294A1BB0-734A9045/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Jeff, ext Jeff Weston wrote: > >> And, again, for cases where hashing does not disambiguate, >> then we can use the DPD option. This would, of course, be >> fine as a backup strategy. >> > > I don't think hashing is as reliable as you think it is. Here are a few potential problems I see with your solution (which, as I > understand it, is simply "compare hash to an arbitrary number of previously stored hashes, and add the DPD option header if there's > a conflict"): > You seem to characterize conflicting hash results as a frequent occurrence, which does not in any way match our experiemental results. Besides, any IPv4 source which is equipped to put in the DPD option will much more easily be equipped for correctly manipulating the ip_id field, which almost completely invalidates most of your arguments as far as I can tell. But even for IPv6 ... > 1) In a heterogeneous MANET, where different devices have different memory and CPU capabilities, you may have nodes that are capable > of storing only a very small subset of the hashes stored by other nodes. If these nodes source any data, then it is possible that > they may not notice a hash conflict while the forwarding nodes do, dropping the packet... > How does the DPD option enable nodes to have more slots for for storing data about past packets? > 2) Multicast packets may be received out-of-order, which could cause problems if a conflicting hash has just been thrown out by the > source node, but not on some forwarding nodes (so they drop the packet). > Do you mean the source of the multicast packet? If so, I guess your point is that the source node may not have a "complete" record of previous hashes, nd other nodes may have more complete records for that source. I find this to be very, very unlikely, because: 1. A certain number of hash results would be mandated for memory 2. They don't have to be more than 32 bits long, probably less. 3. Anyway hash collisions seem to be rare, and you are proposing something that would happen even more rarely. I did not get a consistent answer to my previous questions about multiple taggers vs. increased congestion because of the effect of _disabling_ duplicate suppression. > 3) Similarly, if any node sources multicast packets such that they have a TTL/max hop count that does not allow propogation > throughout the entire MANET, then the source node will undoubtedly throw old hashes out faster than some of its forwarders... > This seems to be effectively the same scenario as before -- except that using limited TTL seems already to indicate that the source is happy if transmissions are limited, so probably throwing out a few more is even less of a problem (in the very rare subset of the very rare case). > 4) The same problem will happen if a MANET fragments, and comes back together some time later. > Do you mean that the DPD option is solving problems that arise because of manet fragmentation/rejoining? I'm very surprised to hear this. > These are potential problems with IPv6 no matter how good your hashing is (even if your hash is "store the entire packet"), since > plain vanilla IPv6 packets with identical payloads are indistinguishable, AFAIK. As previously mentioned, these aren't uncommon, > with video, VOIP "hello" packets, etc. > Do you mean the DPD option is a mechanism for disambiguating otherwise undistinguishable packets? Then we are in perfect agreement, as I have already stated in several previous messages to this mailing list. My claim is that this is a very small proportion of total broadcasts, and that the DPD option will most often be used in just these cases. > Honestly, I just don't see the need to bring in the complications of hashing ... it creates more problems than it solves, IMHO... > Creating a potentially unreliable multicast network in favor of saving a few bytes on the air just doesn't seem right to me > Saving bytes over the air can dramatically increase the lifetime of many networks. Nobody seems to be talking about creating an unreliable multicast network, least of all me. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 12:06:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1oK-0005QU-Ez; Thu, 12 Apr 2007 12:06:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc1oJ-0005QP-Bh for manet@ietf.org; Thu, 12 Apr 2007 12:06:11 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc1oI-0003Fb-3r for manet@ietf.org; Thu, 12 Apr 2007 12:06:11 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3CG693t014277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Apr 2007 11:06:09 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3CG67BS028404; Thu, 12 Apr 2007 11:06:07 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3CG5ova027614; Thu, 12 Apr 2007 11:06:04 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 09:05:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Thu, 12 Apr 2007 09:05:55 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6DE@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <461E5720.1070209@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Need for DPD header (SMF document discussion) Thread-Index: Acd9G5EGKUJtkoxJTp+Ar3NCBr/UuwAAB32Q References: <001601c77d09$2ff23a90$355dfa84@chiron> <461E5720.1070209@nokia.com> From: "Templin, Fred L" To: "Charles E. Perkins" , "ext Jeff Weston" X-OriginalArrivalTime: 12 Apr 2007 16:05:56.0693 (UTC) FILETIME=[744A4850:01C77D1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Charlie, > You seem to characterize conflicting hash results as a frequent > occurrence, which does not in any way match our experiemental > results. Besides, any IPv4 source which is equipped to put in the > DPD option will much more easily be equipped for correctly > manipulating the ip_id field, which almost completely invalidates > most of your arguments as far as I can tell. But even for IPv6 ... I disagree; it is up to the sending host to choose its ip_id in such a way that two packets that may be alive in the network at the same time would not have the same ip_id value. But, there are many factors that may weigh in as to the exact strategy a host chooses for setting ip_id and it is unrealistic to require hosts to abandon those other considerations solely for providing a unique identifier for DPD. Fred fred.l.templin@boeing.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 12:24:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc25q-0007sk-Gu; Thu, 12 Apr 2007 12:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc25o-0007rZ-BW for manet@ietf.org; Thu, 12 Apr 2007 12:24:16 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc25n-0000TP-SR for manet@ietf.org; Thu, 12 Apr 2007 12:24:16 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3CGNl4h010443; Thu, 12 Apr 2007 19:24:13 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 19:23:58 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 11:23:45 -0500 Received: from [10.162.27.44] ([10.162.27.44]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 11:23:43 -0500 Message-ID: <461E5D09.4020101@nokia.com> Date: Thu, 12 Apr 2007 09:23:37 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dyoung@pobox.com Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <461BAE34.6000706@nokia.com> <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <20070411232836.GI13224@che.ojctech.com> In-Reply-To: <20070411232836.GI13224@che.ojctech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 16:23:43.0694 (UTC) FILETIME=[F045B6E0:01C77D1E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello David, As you point out, minimizing system impact for DPD is not a simple, one-dimensional problem. The new option would require fewer instruction cycles, but more radio transmission power. If the processing time is faster than the time it takes to send data over the air, then I am wondering how the cache problem you describe would affect performance. Sending a byte over the air at 1 Mb/sec would take 10 microseconds, and a lot of processors can do numerous instructions in that amount of time. This means that sending extra bytes could be a losing strategy time-wise, even separate from the energy considerations. It seems to me that the very systems that would have limited cache space would be the ones most likely to benefit from energy conservation by way of packet size reduction. Moreover, I believe this imbalance will only increase in the future. We can expect to see more years of reduced feature size in chips, and thus reduced energy expenditure for processing. We will always have to have a certain amount of energy to push radio waves over the air, and can only hope for more efficiency in the circuitry for transmission and reception. I do not know yet whether CRC32 will suffice for the purpose of good hashing. Most likely, we will have a choice between almost perfect hashing that is relatively expensive in processing (but still far less energy expensive than radio transmission) vs. pretty darned good hashing that is a lot less expensive in processing requirement. We need more data. But I would not have brought it up in the first place except for my understanding that a bit over the air can be literally millions of times more expensive than a processor cycle, in terms of energy cost. From this perspective, throwing in another 32-bit field needs a lot of justification before it can be accepted by designers of, say, sensor networks. Regards, Charlie P. ext David Young wrote: > Ian, Tom, and Charlie, > > I cannot tell whether or not you each mean the same thing when you say > a hash is "heavyweight." I took Ian to mean system resources such as > CPU and bus/memory bandwidth---that is, a heavyweight hash reduces total > system performance. Charlie is concerned with how fast the device draws > down its battery. I am concerned with the total system performance, > and I will say a bit about that. > > I expect that some MANET routers will be portable devices containing an > ARM CPU with a modest data cache size. Let us say the cache size is 8kB. > If you are forwarding 1kB multicast packets, and the CPU hashes each > packet payload for the purpose of duplicate detection, then the rate of > cache turnover as you compute the hash function over every byte of every > packet is potentially very high (up to 1/8th of your cache per packet). > The danger is that the operating system and applications (MP3 player, > telephone, photo/movie display, web browser) slow tremendously as they > get kicked out of the cache by multicast traffic. > > [Contrast that with the usual unicast forwarding case: provided that the > NIC has verified the IP checksum (not too unusual, these days), the CPU > need only read the IP header of any packet to make a forwarding decision, > so the cache impact is small.] > > Incidentally, some ARM "systems on a chip" have coprocessors for CRC32. > Will comparison of CRC32s suffice to detect duplicates? > > Dave > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 12:26:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc27f-0003F3-WF; Thu, 12 Apr 2007 12:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc27d-0003Dr-SS for manet@ietf.org; Thu, 12 Apr 2007 12:26:09 -0400 Received: from smtp.humber.ca ([192.75.71.6] helo=artax.humber.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc27c-0000nQ-HO for manet@ietf.org; Thu, 12 Apr 2007 12:26:09 -0400 Received: from artax.humber.ca (127.0.0.1) by artax.humber.ca (MlfMTA v3.2r1b3) id h3peqk0171sg for ; Thu, 12 Apr 2007 12:26:18 -0400 (envelope-from ) Received: from Denkomobility ([142.214.30.20]) by artax.humber.ca (MAILSCANNER) with ESMTP; Thu, 12 Apr 2007 12:26:17 -0400 Message-ID: <010a01c77d1f$4c8d8630$2e02a8c0@Denkomobility> From: "Mieso Denko" To: Date: Thu, 12 Apr 2007 12:25:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mlf-Version: 5.0.2.8415 X-Mlf-UniqueId: o200704121626170035829 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [manet] CFP:IST-AWSN'07: Deadline extended X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org **** our apologies if you receive multiple copies of this CFP **** ================== Deadline Extended to April 20, 2007 ================ The 2nd International Workshop on Intelligent Systems Techniques for Ad hoc and Wireless Sensor Networks (IST-AWSN'07) 28 August - 1 September, 2007 http://cs.acadiau.ca/~eshakshu/IST-WSN-2007.htm in conjunction with The Fifth International Symposium on Parallel and Distributed Processing and Applications 28 August - 1 September, 2007 http://www.cs.umanitoba.ca/~ispa07/ Important Workshop Dates: Paper Submission: 10 April 2007 (20 April Extended) Author Notification: 10 May 2007 Camera-ready Due: 10 June 2007 Location: Niagara Falls, Ontario, Canada. Description: Recent developments of low-cost, low-power, multifunctional wireless sensors have enabled the fast growth of Wireless Sensor Network (WSN) applications, which include security, military, agriculture, automation, environmental and habitat monitoring. WSNs consist of numerous small inexpensive battery powered sensors; each sensor has the capability to process and store the sensor data. A combination of the dense deployment of numerous smart sensors, AI techniques, and intelligent agents can provide continuous real-time monitoring that is precise, accurate, reliable, and inexpensive. This workshop aims to bring together researchers and practitioners working on different aspects of wireless sensor networks and software agent technology in an effort to highlight the state-of-the-art and discuss the challenges and opportunities to explore new research directions. We strongly welcome submissions that include results which advance the state of the art relating to the theme of the workshop. The main topics to be addressed include (but not limited to): - Adaptive agents in AWSN - Agent security and trust in AWSNs - Agent-based architectures for WSNs - Agents design issues dealing with reliability, efficiency, and fault tolerance - Database management systems for AWSNs - Distributed management systems for AWSNs - Intelligent data fusion and aggregation - Intelligent query and data dissemination - Intelligent systems for AWSNs - Learning agents in AWSN - Mobile agents in AWSNs - Monitoring agents in AWSN - Peer-to-Peer systems for AWSNs - Power management and energy-efficient protocols - Routing protocols for AWSNs - Safe transmissions of data in AWSNs - Self-organization of AWSNs - Smart energy-efficient routing protocols Publication Only original papers will be considered that have neither been published nor submitted for publication elsewhere, including web publication. All submissions will be handled electronically. The length of the paper is limited to 15 pages. All papers will be reviewed by at least two independent reviewers. Accepted papers will be published in Springer's Lecture Notes in Computer Science workshops proceedings. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Authors of high quality papers presented in the workshop will be invited to submit extended version of their papers for publication in an international journal. Last year, selected papers were extended and accepted for publication in a special issue in the Journal of Information Fusion, Elsevier Science. Workshop Organizers: Elhadi Shakshuki, Acadia University Darcy Benoit, Acadia University Mieso Denko, University of Guelph, Canada _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 12:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc2C4-00074q-N1; Thu, 12 Apr 2007 12:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc2C3-00074d-HG for manet@ietf.org; Thu, 12 Apr 2007 12:30:43 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc2C1-0002NC-0c for manet@ietf.org; Thu, 12 Apr 2007 12:30:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3CGUaHD005153; Thu, 12 Apr 2007 19:30:38 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 19:28:43 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 11:28:37 -0500 Received: from [10.162.27.44] ([10.162.27.44]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 11:28:36 -0500 Message-ID: <461E5E2F.7050304@nokia.com> Date: Thu, 12 Apr 2007 09:28:31 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <461BAE34.6000706@nokia.com> <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <20070411232836.GI13224@che.ojctech.com> <374005f30704120513k3a956c59lc23e16958b21f088@mail.gmail.com> In-Reply-To: <374005f30704120513k3a956c59lc23e16958b21f088@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2007 16:28:36.0868 (UTC) FILETIME=[9F048440:01C77D1F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070412193038-12B93BB0-50F95E82/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian, ext Ian Chakeres wrote: > The current SMF document describes a simple DPD procedure that is very > lightweight in terms of CPU, state, energy, etc. I think it should be > preferred over other DPD mechanisms, e.g. hashing. I don't think so. I reckon the DPD mechanism will be more expensive in terms of energy and, sometimes, time required for processing. In fact, in most cases, the energy imbalance might be drastically worse for more bytes over the air. The CPU state requirement could be relatively small -- e.g, 24 bits per recent packet. This is a matter to be settled, but I do not see it as a large burden, even for systems saving dozens of recent hash results. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 13:54:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3VV-0000ri-LG; Thu, 12 Apr 2007 13:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc3VT-0000rY-Dt for manet@ietf.org; Thu, 12 Apr 2007 13:54:51 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc3VS-0008Pj-5Y for manet@ietf.org; Thu, 12 Apr 2007 13:54:51 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3CHsjpu013075; Thu, 12 Apr 2007 13:54:45 -0400 (EDT) Received: (from chiron [132.250.93.53]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007041213544430009 ; Thu, 12 Apr 2007 13:54:44 -0400 From: "Jeff Weston" To: "'Charles E. Perkins'" References: <001601c77d09$2ff23a90$355dfa84@chiron> <461E5720.1070209@nokia.com> Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Thu, 12 Apr 2007 13:54:42 -0400 Message-ID: <001a01c77d2b$a5ef2f10$355dfa84@chiron> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd9G4c/YLrQfOMWRgeL6erG6SbOZAACG/Hw In-Reply-To: <461E5720.1070209@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Charlie, > > 1) In a heterogeneous MANET, where different devices have different > > memory and CPU capabilities, you may have nodes that are capable of > > storing only a very small subset of the hashes stored by > other nodes. If these nodes source any data, then it is > possible that they may not notice a hash conflict while the > forwarding nodes do, dropping the packet... > > > How does the DPD option enable nodes to have more slots for > for storing data about past packets? It doesn't allow more slots, but it doesn't need them either. Multicast source nodes only need to know the last used sequence number for each destination address. Therefore, this particular situation would never arise with use of the DPD option (unless a node were storing the entire DPD sequence number space, which doesn't make much sense from a design standpoint anyways). > > These are potential problems with IPv6 no matter how good > your hashing > > is (even if your hash is "store the entire packet"), since plain > > vanilla IPv6 packets with identical payloads are > indistinguishable, AFAIK. As previously mentioned, these > aren't uncommon, with video, VOIP "hello" packets, etc. > > > Do you mean the DPD option is a mechanism for disambiguating > otherwise undistinguishable packets? Then we are in perfect > agreement, as I have already stated in several previous > messages to this mailing list. My claim is that this is a > very small proportion of total broadcasts, That depends greatly on the application(s) being used in the MANET, IMHO. -Jeff _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 17:16:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc6eu-0004lf-Ff; Thu, 12 Apr 2007 17:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc6es-0004la-Rp for manet@ietf.org; Thu, 12 Apr 2007 17:16:46 -0400 Received: from syssoft.uni-trier.de ([136.199.54.243] helo=tamdhu.uni-trier.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc6er-0005bR-2s for manet@ietf.org; Thu, 12 Apr 2007 17:16:46 -0400 Received: from notebookhannes (tamdhu.uni-trier.de [136.199.54.243]) by tamdhu.uni-trier.de (Postfix) with ESMTP id 7489E1D009F for ; Thu, 12 Apr 2007 23:16:43 +0200 (CEST) From: "Hannes Frey" To: Date: Thu, 12 Apr 2007 23:16:01 +0200 Message-ID: <01a901c77d47$c5ef8ff0$b000a8c0@notebookhannes> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9R8WL6EjtprqARNCGPWmQjLAWAQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Subject: [manet] Final Call for Papers - LOCALGOS 2007 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org = ----------------------------------------------------------------------- Our apologies if you receive duplicates of this posting. Please feel free to distribute it to those who might be interested. = ----------------------------------------------------------------------- = *********************************************************************** * CALL FOR PAPERS = * * = * * LOCALGOS 2007 = * * = * * First International Workshop on Localized Algorithms and Protocols = * * for Wireless Sensor Networks = * * http://ants.dif.um.es/localgos07 = * * = * * In conjunction with the IEEE International Conference on = * * Distributed Computing in Sensor Systems (DCOSS 2007) = * * www.dcoss.org = * * = * * June 18 - 20, 2007 = * * Santa Fe, New Mexico, USA = * * = * * Extended Submission Deadline: April 13, 2007 = * = *********************************************************************** Wireless sensor networks consist of a large set of embedded devices each having limited computation and communication capabilities. By using = wireless multihop communication, small chunks of collected data are aggregated = and sent towards some selected data sinks. In this way individual = measurements emerge to a global picture of the entire physical phenomenon. Wireless sensor networks enable rapid deployment, require minimum maintenance = effort, and have minimum influence on the measured phenomenon. It is envisioned = that in many application scenarios sensor networks will lead us beyond the = scale, precision, and detail of what we can measure with traditional techniques today. Sensor networks may have hundreds or thousands of nodes, with limited = energy supplies and communication capabilities. Thus, it is of paramount = importance for the networking algorithms and protocols to be able to scale with a = very large number of devices. The main paradigm shift to achieve those = desirable properties is to apply localized (or greedy) schemes as opposed to = existing protocols requiring global information. Localized algorithms are = distributed algorithms where simple local node behavior achieves a desired global objective. Localized protocols provide scalable solutions, that is, solutions for wireless networks with an arbitrary number of nodes, which = is the main goal of this plan. This workshop will bring together researchers working in the field of localized algorithms and protocols for wireless sensor networks. The = main objective is on data communication, topology control, sensor coverage, = and sensor localization. Data communication problems are those in which one = or multiple sources need to send data to one or multiple destinations. They include among others, unicast and multicast routing, geocasting and data gathering. In the routing problem a path is created to allow the data = source to send packets to one (unicast) or multiple (multicast) destinations. Geocasting consist of sending a data packet to all sensor nodes within a pre-defined geographic area. In the data gathering problem, data from a = set of sensor nodes is collected and transmitted toward one or multiple (eventually mobile) base stations. Topology control algorithms and = protocols include problems such as neighbor detection, boundary detection, and = network organization problems in which a subset of the original topology = satisfying some properties is obtained. Examples of topology control problems are computation of dominating sets, planar graphs, and energy efficient sub topologies. Sensor coverage denotes the ability of a sensor network to = cover each point in a given area by a certain minimum number of sensor nodes. Localized coverage control includes energy conserving sleep cycles, and autonomous mobile sensor nodes which collaboratively move to achieve a desired area coverage. The majority of localized protocols require that nodes are aware of their physical position. In relative positioning such information is made available by means of distance measurements between neighboring nodes and triangulation, while the distance between two = neighbor nodes is estimated by measuring the received signal strength. SCOPE ----- The main objective of the workshop is to present state of the art = research results in the area of localized algorithms and protocols for wireless sensor networks. The workshop covers among others the following research topics (not limited to): - Unicast and multicast routing - Broadcasting - Energy-efficient and bandwidth-efficient communication=20 - Security in wireless sensor networks - Data management, query processing and data delivery - Topology construction and maintenance in wireless sensor networks - Localized protocols for duty-cycled sensor networks - Geocasting techniques for wireless sensor networks - Auto-configuration and network formation protocols and algorithms - Relative positioning algorithms - Lower bounds on information exchange required for localized solutions - Network graph properties supporting localized protocols - Worst and average case analysis on the deviation from optimal = solutions IMPORTANT DATES --------------- Manuscript Submission: April 13, 2007 Acceptance Notification: April 27, 2007 Final Manuscript Due: May 10, 2007 PAPER SUBMISSION ---------------- Submitted manuscripts may not exceed 12 single-spaced pages using = 12-point size font on 8.5x11 inch pages, including figures and tables. References = may be included in addition to the 12 pages. Submissions will be judged on correctness, originality, technical strength, significance, quality of presentation, and interest and relevance to the workshop attendees. Submitted papers may not have appeared in or be under consideration for another conference or a journal. Accepted papers will be published in = the workshop proceedings of the International Conference on Distributed Computing in Sensor Systems (DCOSS 2007). Please submit papers via Easy Chair by using the following URL: http://www.easychair.org/LOCALGOS07/. In case of trouble with the = submission you may send your publication by email to both program co-chairs (pedrom = at dif.um.es, frey at imada.sdu.dk). GENERAL CHAIR ------------- Ivan Stojmenovic, SITE, University of Ottawa PROGRAM CO-CHAIR ---------------- Pedro M. Ruiz Martinez, University of Murcia, Spain Hannes Frey, IMADA, University of Southern Denmark=20 PROGRAM COMMITTEE ----------------- Raffaele Bruno, IIT-CNR, Italy=20 Silvia Giordano, University of Applied Science, SUPSI, Switzerland=20 Isabelle Guerin Lassous, INRIA Rhone Alpes, France=20 Francois Ingelrest, EPFL, Lausanne, Swizerland=20 Lars M. Kristensen, University of Aarhus, Denmark=20 Thomas Kunz, Carleton University, Canada=20 Miguel A. Labrador, Univ. South Florida, USA=20 Hai Liu, SITE, University of Ottawa, Canada=20 Norbert Luttenberger, Universitat Kiel, Germany=20 Pietro Manzoni, Univ. Politecnica de Valencia, Spain=20 Mikhail Nesterenko, Kent State University, USA Luis Orozco, Univ. Castilla La Mancha, Spain=20 Josep Paradells, Technical University of Catalonia (UPC), Spain=20 Sumesh J Philip, Western Illinois University, USA S. S. Ravi, State University of New York at Albany, USA=20 Steffen Rothkugel, University of Luxemburg=20 Stefan Ruehrup, SITE, University of Ottawa, Canada=20 Gregor Schiele, Universit=E4t Mannheim _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 12 21:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcB3S-0008Th-T0; Thu, 12 Apr 2007 21:58:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcB3R-0008TU-Ur for manet@ietf.org; Thu, 12 Apr 2007 21:58:25 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcB3R-0005RD-AR for manet@ietf.org; Thu, 12 Apr 2007 21:58:25 -0400 Received: by py-out-1112.google.com with SMTP id f31so584739pyh for ; Thu, 12 Apr 2007 18:58:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GMfZ2LrQfdIV7k1lHEn3IiLGf9E7MOE4phOShodcBDLEaCK/UouIlOpBsy3cPZ9z5+OATBSXEutk1MZ71QvhXNewWTOQA85ZKVfaOhfuaPeNc1IAed7hqRRyTwIlpOqYNlHtB+c2/A1sMulZrnYfs2uC+eJE+I3fesFpxCwVAjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tZIYSIm5fmN6dNqr0NUfQEk74+HDjfesNgIKojujKcxsc55OfYawwvLcJ1oabi9GVdjdtLbzjYDkUPyhRs7QjD7lXFOhUKk9kuhSvleS16gBpAf1LonN6PsP7m8qpRzvCnHsliRnn5WsrV5vucUf+BM1M+mGNRe0KYlxn0BMpKg= Received: by 10.35.84.16 with SMTP id m16mr4219297pyl.1176429504964; Thu, 12 Apr 2007 18:58:24 -0700 (PDT) Received: by 10.35.38.20 with HTTP; Thu, 12 Apr 2007 18:58:24 -0700 (PDT) Message-ID: <2a3692de0704121858u6d934aeckd891f381a138dec7@mail.gmail.com> Date: Fri, 13 Apr 2007 10:58:24 +0900 From: "Dominik Kaspar" To: "JP Vasseur" Subject: Re: [manet] New Mailing List: Routing for Sensor Network In-Reply-To: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6938145F-DB59-4A13-97A2-B0F4CA8EFA7F@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: manemo@mobileip.jp, David Culler , manet@ietf.org, 6lowpan@lists.ietf.org, David Ward , Ross Callon , Mark Townsley X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org JP, David, I would like to refer to our 6lowpan Routing Requirements draft, which discusses the issues of routing in "sensor networks". The draft provides design goals and a list of requirements for IP-based routing solutions in low-rate WPANs. At IETF-68 in Prague, we presented our work and solicited advice from both MANET and 6lowpan folks. There seemed to be a general consent that routing is a very important task to solve, however, it is heavily dependent on the network architecture itself, and what exactly this "architecture" is should be clarified first. If you haven't done it yet, please read our draft; we appreciate any constructive comments: http://tools.ietf.org/wg/6lowpan/draft-dokaspar-6lowpan-routreq-01.txt Sincerely, Dominik On 4/12/07, JP Vasseur wrote: > Hi, > > We wanted to inform you that a new Mailing List has been set up, the aim of > which is to discuss Routing for Sensor Networks (at the IP layer). Anybody > interested in contributing to the work is of course more than welcome to > subscribe and collaborate. To register: > https://www1.ietf.org/mailman/listinfo/rsn > > Several of you already expressed some real interest in this work and several > documents (with currently no home WG) already exist. David and I posted are > about to post an ID on the routing requirements for Sensor Networks > (probably early next week) to kick off the discussion. > > What is the overall objective ? > 1) As you know a plethora of proprietary routing protocols (thus outside of > the IETF) have been developed and there is within the IETF currently no > clear answer on which protocol(s) can satisfy the very specific requirements > of Sensor Networks. This triggered this initiative so as to define a routing > architecture and routing protocol at the IETF for Sensor Nets, thus this new > mailing list. Note that we may not be able to come up with a single set of > requirements but a few requirement documents accompanied with some > applicability IDs if it turns out that a unique solution cannot satisfy them > all. > 2) There is at this stage no a priori on the routing protocol that could be > used: it could either be (1) existing routing protocol(s) (AODV, DYMO, OLSR, > Triggered RIP, NEMO, ...) (1) existing routing protocol(s) with enhancements > or (3) new routing protocol(s). > > Possible next steps > If enough interest for this work is shown on the list, we will request a BOF > for Chicago, which may lead to forming a new WG. > > JP and David. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 13 04:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcGoh-0004no-I4; Fri, 13 Apr 2007 04:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcGog-0004nb-N4 for manet@ietf.org; Fri, 13 Apr 2007 04:07:34 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcGof-0007ee-Eo for manet@ietf.org; Fri, 13 Apr 2007 04:07:34 -0400 Received: by wx-out-0506.google.com with SMTP id h31so837605wxd for ; Fri, 13 Apr 2007 01:07:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KJ4k6yZZ1an3lsfEwcMORleUToTHqtPa93Qkqk7dF2lAAaycPtRPcuM9i11GVhrBicUyHRhyFH8mYwXD0CfWqknbtW8gKBeQCql0kdm/s9GQmvqxlWLLqCEbRiBeU/MO/ZVm89b5x+bdFel0plAMCB9ALVxtkJk8Es1ZbL7V4Vg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rbyTUfNa0+UwV6N2hM0BEPzHdSbGpl3O8+OxNHxIiohab+Y3pPo76gUK/RSxjKaxtI9jxMnEAD4r2CLNJcFdFamHrOBPpSpv87CH17/BTMu4aHJkkRltQ5KGOd7onvb6NPZrBn0dv82yYCkD3mHroyMz15wmyqqlRm7/SGtJN9U= Received: by 10.78.164.9 with SMTP id m9mr584356hue.1176451652229; Fri, 13 Apr 2007 01:07:32 -0700 (PDT) Received: by 10.78.58.3 with HTTP; Fri, 13 Apr 2007 01:07:31 -0700 (PDT) Message-ID: <374005f30704130107x6ed261fegc22f9afa7dfe2cc7@mail.gmail.com> Date: Fri, 13 Apr 2007 13:37:31 +0530 From: "Ian Chakeres" To: "Charles E. Perkins" Subject: Re: [manet] Need for DPD header (SMF document discussion) In-Reply-To: <461E5E2F.7050304@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <461BAE34.6000706@nokia.com> <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <20070411232836.GI13224@che.ojctech.com> <374005f30704120513k3a956c59lc23e16958b21f088@mail.gmail.com> <461E5E2F.7050304@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Let me simply respond regarding IPv4 packets. A - DPD based on IPID There is no additional packet overhead (when the source inserts a sequence number into the IPID field as specified in the SMF document). On the DPD detection side, a node need only keep a sequence number and window (for a particular tuple). I believe this is extremely light weight. B - Hashing For comparison, hashing would require a unique ID in the packets - so no additional overhead here. On the DPD detection side, nodes need to perform the hash, for every packet including duplicates. They must also maintain the previous hashes for comparison. Finally the hash & past hashes need to be compared to detect duplicates. I think procedure B is much heavier weight in terms of state, CPU, etc than procedure A. If you disagree please explain. Ian On 4/12/07, Charles E. Perkins wrote: > > Hello Ian, > > ext Ian Chakeres wrote: > > > The current SMF document describes a simple DPD procedure that is very > > lightweight in terms of CPU, state, energy, etc. I think it should be > > preferred over other DPD mechanisms, e.g. hashing. > > I don't think so. I reckon the DPD mechanism will be > more expensive in terms of energy and, sometimes, > time required for processing. In fact, in most cases, > the energy imbalance might be drastically worse for > more bytes over the air. The CPU state requirement > could be relatively small -- e.g, 24 bits per recent > packet. This is a matter to be settled, but I do not see > it as a large burden, even for systems saving dozens of > recent hash results. > > Regards, > Charlie P. > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 13 05:06:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHjL-0005qY-AB; Fri, 13 Apr 2007 05:06:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHjJ-0005qQ-Sf for manet@ietf.org; Fri, 13 Apr 2007 05:06:05 -0400 Received: from smtp17.wxs.nl ([195.121.247.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcHjI-00077B-IK for manet@ietf.org; Fri, 13 Apr 2007 05:06:05 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by smtp17.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JGF00DC0ILW3U@smtp17.wxs.nl> for manet@ietf.org; Fri, 13 Apr 2007 11:06:03 +0200 (CEST) Date: Fri, 13 Apr 2007 11:07:04 +0200 From: Teco Boot Subject: RE: [manet] Need for DPD header (SMF document discussion) In-reply-to: <374005f30704130107x6ed261fegc22f9afa7dfe2cc7@mail.gmail.com> To: 'Ian Chakeres' , "'Charles E. Perkins'" Message-id: <000701c77dab$1ecf2500$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9oyGWtgRw/zBtQm+6ZSEa5AEhQQAAdV+Q X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On hashing; this introduces a new requirement: sent packets shall be unique. This requirement could be hard to fulfill, for example there could be keep-alive packets without sequence numbers or other unique field and there could be retransmits of the same packet. Many IETF protocols behave this way, so why asking upper layer applications to do otherwise? Question on IPv4 / IPID and the tagger functionality: I don't understand when using IPv6 there is a valid reason to use the tagger option and when using IPv4 / IPID lack of the tagger option is acceptable. I think we need a better analysis why and when the tagger is needed and we could look for alternative solutions. Teco > -----Original Message----- > From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Sent: vrijdag 13 april 2007 10:08 > To: Charles E. Perkins > Cc: manet > Subject: Re: [manet] Need for DPD header (SMF document discussion) > > Let me simply respond regarding IPv4 packets. > > A - DPD based on IPID > > There is no additional packet overhead (when the source inserts a > sequence number into the IPID field as specified in the SMF document). > On the DPD detection side, a node need only keep a sequence number and > window (for a particular tuple). I believe this is extremely light > weight. > > B - Hashing > > For comparison, hashing would require a unique ID in the packets - so > no additional overhead here. On the DPD detection side, nodes need to > perform the hash, for every packet including duplicates. They must > also maintain the previous hashes for comparison. Finally the hash & > past hashes need to be compared to detect duplicates. > > I think procedure B is much heavier weight in terms of state, CPU, etc > than procedure A. If you disagree please explain. > > Ian > > On 4/12/07, Charles E. Perkins wrote: > > > > Hello Ian, > > > > ext Ian Chakeres wrote: > > > > > The current SMF document describes a simple DPD procedure that is very > > > lightweight in terms of CPU, state, energy, etc. I think it should be > > > preferred over other DPD mechanisms, e.g. hashing. > > > > I don't think so. I reckon the DPD mechanism will be > > more expensive in terms of energy and, sometimes, > > time required for processing. In fact, in most cases, > > the energy imbalance might be drastically worse for > > more bytes over the air. The CPU state requirement > > could be relatively small -- e.g, 24 bits per recent > > packet. This is a matter to be settled, but I do not see > > it as a large burden, even for systems saving dozens of > > recent hash results. > > > > Regards, > > Charlie P. > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 13 05:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcI4b-0003Qa-LZ; Fri, 13 Apr 2007 05:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcI4Z-0003QR-Uj for manet@ietf.org; Fri, 13 Apr 2007 05:28:03 -0400 Received: from web27611.mail.ukl.yahoo.com ([217.146.177.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcI4Y-0003no-Hy for manet@ietf.org; Fri, 13 Apr 2007 05:28:03 -0400 Received: (qmail 49169 invoked by uid 60001); 13 Apr 2007 09:28:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=k2imV1VrpkPyeVNi6RogVCtV8eJ3n8MeZaiSRddn1Bj+GXhg+K9gmUbEqGfMGhBhoxte5/05LHP9yM7Llbl1isnMsXnzp2fnPTBJ852sHmsKzVNKPhkyQPF/Gc628zC+ntaBZywSZ/Bh2uYsZvHHdbFM3yKFEsBmXB+r/BonbiQ=; X-YMail-OSG: VZCRCWYVM1nlpOcBuhShPbWASKS1bHt.GPgec5qYd_Acll1KD_DT.SeMAJwdXadGD7sBLHfWNaF55RqBjJ7g0ymlMLE8ejog18u4LJKwB5q6fi5QEFg9jyrAiQA- Received: from [193.95.37.75] by web27611.mail.ukl.yahoo.com via HTTP; Fri, 13 Apr 2007 09:28:01 GMT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Fri, 13 Apr 2007 09:28:01 +0000 (GMT) From: nadia mansouri To: manet MIME-Version: 1.0 Message-ID: <854703.48413.qm@web27611.mail.ukl.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [manet] implement new protocol in glomosim X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2067850526==" Errors-To: manet-bounces@ietf.org --===============2067850526== Content-Type: multipart/alternative; boundary="0-432456877-1176456481=:48413" --0-432456877-1176456481=:48413 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello,=0AHow can i implement new protocol in glomosim such as AOMDV or MSR= .=0Athanks in advance.=0A=0A=0A =0A___________________________________= ________________________________________ =0AD=E9couvrez une nouvelle fa=E7o= n d'obtenir des r=E9ponses =E0 toutes vos questions ! =0AProfitez des conna= issances, des opinions et des exp=E9riences des internautes sur Yahoo! Ques= tions/R=E9ponses =0Ahttp://fr.answers.yahoo.com --0-432456877-1176456481=:48413 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
How can i implement  new protocol in gl= omosim such as AOMDV or MSR.
thanks in advance.

=0A= =0A=0A =0A=0A
=0AD=E9couvrez une nouvelle fa=E7on= d'obtenir des r=E9ponses =E0 toutes vos questions ! =0AProfitez des connai= ssances, des opinions et des exp=E9riences des internautes sur Yahoo! Ques= tions/R=E9ponses. --0-432456877-1176456481=:48413-- --===============2067850526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============2067850526==-- From manet-bounces@ietf.org Fri Apr 13 06:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcIff-0002cs-B7; Fri, 13 Apr 2007 06:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcIfd-0002cl-CK for manet@ietf.org; Fri, 13 Apr 2007 06:06:21 -0400 Received: from web27606.mail.ukl.yahoo.com ([217.146.177.225]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcIfc-0002CI-18 for manet@ietf.org; Fri, 13 Apr 2007 06:06:21 -0400 Received: (qmail 75349 invoked by uid 60001); 13 Apr 2007 10:06:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=THEgZC6b/S2NVLAh/9udwg+gyw27ZjQKT3KVNac4NIE0hHyJ9eisjGSIxDwLY7U4zufz+9o5taEdd5/5hMwGtAe0UWNSG1D2I3+qkV5WQYakd3RY2Y5AfrNXauiYmorD3t6vvLJXJfRa5gIWaHyRXpXXycjDrKDEpdXutQ/iuk4=; X-YMail-OSG: okPhzQUVM1l7iWMjxja18hiIZPtO0fPuGcJ027xjdfv71PIp0x7Yaxx45nWj3JrC6Ji2mJSFFbEoQg_bvXwEQWI8YTHqCa3F6kxNrvGxRy29TSWGOmmCkFOn2iQ- Received: from [193.95.37.75] by web27606.mail.ukl.yahoo.com via HTTP; Fri, 13 Apr 2007 10:06:19 GMT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Fri, 13 Apr 2007 10:06:19 +0000 (GMT) From: nadia mansouri To: manet MIME-Version: 1.0 Message-ID: <431069.73665.qm@web27606.mail.ukl.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [manet] how can i run AODV or any other protocol in Glomosim X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1569524818==" Errors-To: manet-bounces@ietf.org --===============1569524818== Content-Type: multipart/alternative; boundary="0-1939122051-1176458779=:73665" --0-1939122051-1176458779=:73665 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello,=0AI'am new user inGlomosim, I cannot run any protocol such as AODV = or DSR, =0APlease help me about how can i run this protocol and what are th= e instructions that I need do to run this protocol.=0Athanks in advance.=0A= =0A=0A =0A____________________________________________________________= _______________ =0AD=E9couvrez une nouvelle fa=E7on d'obtenir des r=E9ponse= s =E0 toutes vos questions ! =0AProfitez des connaissances, des opinions et= des exp=E9riences des internautes sur Yahoo! Questions/R=E9ponses =0Ahttp:= //fr.answers.yahoo.com --0-1939122051-1176458779=:73665 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
=0A
I'am new user inGlomosim, I cannot= run any  protocol such as AODV or DSR,
=0A
Please help me a= bout how can i run this protocol and what are the instructions that I need = do to run this protocol.
=0A
thanks in advance.

=0A= =0A=0A =0A=0A
=0AD=E9couvrez une nouvelle fa=E7on= d'obtenir des r=E9ponses =E0 toutes vos questions ! =0AProfitez des connai= ssances, des opinions et des exp=E9riences des internautes sur Yahoo! Ques= tions/R=E9ponses. --0-1939122051-1176458779=:73665-- --===============1569524818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1569524818==-- From manet-bounces@ietf.org Fri Apr 13 06:17:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcIpu-0008BF-Ed; Fri, 13 Apr 2007 06:16:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcIpt-0008BA-Pb for manet@ietf.org; Fri, 13 Apr 2007 06:16:57 -0400 Received: from web27602.mail.ukl.yahoo.com ([217.146.177.221]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcIps-000742-D1 for manet@ietf.org; Fri, 13 Apr 2007 06:16:57 -0400 Received: (qmail 2908 invoked by uid 60001); 13 Apr 2007 10:16:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=dqGg2iNtv8ahfEf9UmvURiu1eNHmUdUQ88IvK+lHFTb+1Udcv6bf2o6BEPLe8EVMJqA1JwZgaXD4J76MVHHw6v12rx6VJ8C9WPXwX/f/R/Zr42vw8iKkzSQZEOQpCy8XcIAFrkTxSVJIttHY1Y7S4Hva962gCFnHLNn24vNkgdw=; X-YMail-OSG: tkiZbvoVM1m4JC0b5SC1CfPQnxmqUCbXRR445kJ154uksUkbjLsuA3KDs3nko1917NQEMKjzxmBY1pULCQQcRZY6wz3SIAUUhCXqyEBWJszv49kBPeP1Caf_gBI- Received: from [193.95.37.75] by web27602.mail.ukl.yahoo.com via HTTP; Fri, 13 Apr 2007 10:16:55 GMT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Fri, 13 Apr 2007 10:16:55 +0000 (GMT) From: nadia mansouri To: manet MIME-Version: 1.0 Message-ID: <831596.1686.qm@web27602.mail.ukl.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [manet] implement AOMDV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1542083175==" Errors-To: manet-bounces@ietf.org --===============1542083175== Content-Type: multipart/alternative; boundary="0-617568571-1176459415=:1686" --0-617568571-1176459415=:1686 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello=0ADoes anybody know how can Iimplement AOMDV in glomosim?=0AThanks in= advance.=0A=0A=0A =0A________________________________________________= ___________________________ =0AD=E9couvrez une nouvelle fa=E7on d'obtenir d= es r=E9ponses =E0 toutes vos questions ! =0AProfitez des connaissances, des= opinions et des exp=E9riences des internautes sur Yahoo! Questions/R=E9pon= ses =0Ahttp://fr.answers.yahoo.com --0-617568571-1176459415=:1686 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello
=0A
Does anybody know how can Iimplemen= t AOMDV in glomosim?
=0A
Thanks in advance.

=0A= =0A=0A =0A=0A
=0AD=E9couvrez une nouvelle fa=E7on= d'obtenir des r=E9ponses =E0 toutes vos questions ! =0AProfitez des connai= ssances, des opinions et des exp=E9riences des internautes sur Yahoo! Ques= tions/R=E9ponses. --0-617568571-1176459415=:1686-- --===============1542083175== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1542083175==-- From manet-bounces@ietf.org Fri Apr 13 06:57:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJT6-0007op-SB; Fri, 13 Apr 2007 06:57:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJT4-0007in-Tz for manet@ietf.org; Fri, 13 Apr 2007 06:57:26 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcJT4-0003EH-KS for manet@ietf.org; Fri, 13 Apr 2007 06:57:26 -0400 Received: by wr-out-0506.google.com with SMTP id 71so783148wri for ; Fri, 13 Apr 2007 03:57:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=p43qUmXD3fuXJ0TzzTkbDRaaUHrxyk7EBhJ30EIPcy0OILnTJk9PL+M6le9d1ayjjwonzBok42UxSgoAit/RevcFooSyjDafj9z7aDUy6+S9X/qCPHpHhPWCFtDPfJiuNnfPzuub9dbdeYP9NzuT4I0zH+0YWmgIU4MD24xRr5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=lo+ES60zGpctDUPIhazrw1TlX4SRjNFvCGnanRv+c++YqysPELLz8zLLbbr0uV1vZn2S5uEvwKAmLAcZsLgs0vE67XNI5qKXcni+gYfLMzwB2Vbl+41kBoLIX1ClXdZhb7EYIvQC4yUFYYse4CokoQZgINX54plcq2AQHXF/2zQ= Received: by 10.78.146.11 with SMTP id t11mr593535hud.1176461845587; Fri, 13 Apr 2007 03:57:25 -0700 (PDT) Received: by 10.78.58.3 with HTTP; Fri, 13 Apr 2007 03:57:25 -0700 (PDT) Message-ID: <374005f30704130357r4852deb2qa270ddf6140a4bd0@mail.gmail.com> Date: Fri, 13 Apr 2007 16:27:25 +0530 From: "Ian Chakeres" To: "Teco Boot" Subject: Re: [manet] Need for DPD header (SMF document discussion) - Valid Reason for Tagger ID MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The tagger id is needed to differentiate between taggers, in the event that the source itself (or other ensure-ably unique path element) has not tagged the packet. Since IPv6 requires a new option to carry the IPID, the new option optionally includes the tagger id. The tagger id disambiguates the ID space of different taggers. Ian On 4/13/07, Teco Boot wrote: > > On hashing; this introduces a new requirement: sent packets shall be unique. > This requirement could be hard to fulfill, for example there could be > keep-alive packets without sequence numbers or other unique field and there > could be retransmits of the same packet. Many IETF protocols behave this > way, so why asking upper layer applications to do otherwise? > > Question on IPv4 / IPID and the tagger functionality: I don't understand > when using IPv6 there is a valid reason to use the tagger option and when > using IPv4 / IPID lack of the tagger option is acceptable. I think we need a > better analysis why and when the tagger is needed and we could look for > alternative solutions. > > Teco > > > -----Original Message----- > > From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > > Sent: vrijdag 13 april 2007 10:08 > > To: Charles E. Perkins > > Cc: manet > > Subject: Re: [manet] Need for DPD header (SMF document discussion) > > > > Let me simply respond regarding IPv4 packets. > > > > A - DPD based on IPID > > > > There is no additional packet overhead (when the source inserts a > > sequence number into the IPID field as specified in the SMF document). > > On the DPD detection side, a node need only keep a sequence number and > > window (for a particular tuple). I believe this is extremely light > > weight. > > > > B - Hashing > > > > For comparison, hashing would require a unique ID in the packets - so > > no additional overhead here. On the DPD detection side, nodes need to > > perform the hash, for every packet including duplicates. They must > > also maintain the previous hashes for comparison. Finally the hash & > > past hashes need to be compared to detect duplicates. > > > > I think procedure B is much heavier weight in terms of state, CPU, etc > > than procedure A. If you disagree please explain. > > > > Ian > > > > On 4/12/07, Charles E. Perkins wrote: > > > > > > Hello Ian, > > > > > > ext Ian Chakeres wrote: > > > > > > > The current SMF document describes a simple DPD procedure that is very > > > > lightweight in terms of CPU, state, energy, etc. I think it should be > > > > preferred over other DPD mechanisms, e.g. hashing. > > > > > > I don't think so. I reckon the DPD mechanism will be > > > more expensive in terms of energy and, sometimes, > > > time required for processing. In fact, in most cases, > > > the energy imbalance might be drastically worse for > > > more bytes over the air. The CPU state requirement > > > could be relatively small -- e.g, 24 bits per recent > > > packet. This is a matter to be settled, but I do not see > > > it as a large burden, even for systems saving dozens of > > > recent hash results. > > > > > > Regards, > > > Charlie P. > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 13 09:19:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLgr-0004bR-Fe; Fri, 13 Apr 2007 09:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLgp-0004bI-HJ for manet@ietf.org; Fri, 13 Apr 2007 09:19:47 -0400 Received: from mail0.cs.utsa.edu ([129.115.29.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcLgl-0001xG-ER for manet@ietf.org; Fri, 13 Apr 2007 09:19:47 -0400 Received: from pandora2.cs.utsa.edu (pandora2.cs.utsa.edu [129.115.29.24]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail0.cs.utsa.edu (Postfix) with ESMTP id 0079E2BE0; Fri, 13 Apr 2007 08:19:39 -0500 (CDT) Date: Fri, 13 Apr 2007 08:19:39 -0500 (CDT) From: "Xu (Kevin) Su" To: nadia mansouri Subject: Re: [manet] implement AOMDV In-Reply-To: <831596.1686.qm@web27602.mail.ukl.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org You can find the source code in the following link: http://www.icis.ntu.edu.sg/wagio/simtools.htm best, Kevin On Fri, 13 Apr 2007, nadia mansouri wrote: > Hello Does anybody know how can Iimplement AOMDV in glomosim? Thanks in advance. ___________________________________________________________________________ D=E9couvrez une nouvelle fa=E7on d'obtenir des r=E9ponses =E0 toutes vos qu= estions ! Profitez des connaissances, des opinions et des exp=E9riences des internaut= es sur Yahoo! Questions/R=E9ponses http://fr.answers.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 13 21:45:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXJz-0006Ub-JH; Fri, 13 Apr 2007 21:44:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HcXJy-0006UW-7q for manet-confirm+ok@megatron.ietf.org; Fri, 13 Apr 2007 21:44:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcXJx-0006UO-Gx for manet@ietf.org; Fri, 13 Apr 2007 21:44:57 -0400 Received: from ee.tamu.edu ([165.91.241.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcXJw-0004Ux-1P for manet@ietf.org; Fri, 13 Apr 2007 21:44:57 -0400 Received: from ECE149 (ece149.tamu.edu [165.91.208.72]) by ee.tamu.edu (8.13.6/8.13.6) with SMTP id l3E1in52014262; Fri, 13 Apr 2007 20:44:49 -0500 (CDT) Message-ID: <003c01c77e3e$e127c2e0$48d05ba5@ECE149> From: "Dr. Xi Zhang" To: Date: Fri, 13 Apr 2007 20:44:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: ekpark@umkc.edu, hshwchen@comm.nsysu.edu.tw, mguizani@uaeu.ac.ae Subject: [manet] Deadline Extended to April 15, 2007: ACM IWCMC 2007, Aug 12, 2007, Honolulu, Hawaii, USA. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org *Sorry for receiving multiple copies* Submissions: EDAS --> Deadline extened to April 15, 2007. Call For Papers for ACM IWCMC 2007: _____________________ ACM IWCMC 2007 (http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) August 12-16, 2007, Honolulu, Hawaii, USA Technical Sponsors: ACM (Approved) and IEEE (Pending) Submissions: EDAS --> Deadline extended to April 15, 2007. "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" The ACM International Wireless Communications and Mobile Computing Conference 2007 (ACM IWCMC 2007) will be held in Turtle Bay Resort Hotel, Honolulu, Hawaii, USA during August 12-16, 2007. Under our new theme of "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" , IWCMC2007 is targeting at a wide spectrum of state-of-the-art as well as emerging topics pertaining to wireless networks, communications, and mobile computing. Continuing the great succeed of ACM IWCMC 2006 last year, IWCMC 2007 is anticipated to attract an even larger volume of high quality submissions and stimulate the cutting-edge research discussions amongst many academic pioneering researchers/scientists and industrial engineers/leaders attendees from all around the world as was evidenced during ACM IWCMC 2006. The ACM IWCMC 2007 program will feature a General Symposium, 8 Specific Technical Symposia, Workshop, and Tutorials Sessions. Prospective authors are invited to submit original technical papers to the corresponding IWCMC 2007 Symposia as listed below for oral presentation at IWCMC 2007 and publication in the IWCMC 2007 Conference Proceedings. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ We're pleased to announce the following: [1] Professor Gordon Stuber from Georgia Tech, USA, who is the world-class leader in mobile wireless communications/networking, communication signal processing, and many other areas, has agreed to be the Keynote Speaker for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [2] "NTT DoCoMo USA", which is one of most famous companies in the mobile communications industries, has officially become the Financial Sponsor for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [3] ACM has officially become the technical sponsor for IWCMC 2007 (this was notified earlier) and all the accepted IWCMC 2007 papers will be included into the ACM Database. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ IWCMC 2007 General Organizing Committee: General Co-Chairs: Mohsen Guizani, Western Michigan University, USA, Email: mguizani@ieee.org Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan, Email: hshwchen@comm.nsysu.edu.tw Technical Program Committee Chair: Xi Zhang, Texas A&M University, USA, Email: xizhang@ece.tamu.edu Financial Chair: Eun K. Park, University of Missouri at Kansas City, USA, Email: ekpark@umkc.edu IWCMC 2007 Technical Symposia: General Symposium: Chair: Xuemin (Sherman) Shen, University of Waterloo, Canada, xshen@bbcr.uwaterloo.ca Co-Chairs: Dongmei Zhao, McMaster University, Canada, dzhao@mail.ece.mcmaster.ca Hai Jiang, Princeton University, USA, haijiang@princeton.edu (1) Communication and Information Theory Symposium: Chair: Hamid Sadjadpour, University of California, Santa Cruz, USA, hamid@soe.ucsc.edu Ravi Narasimhan, University of California, Santa Cruz, USA ravi@soe.ucsc.edu (2) Computer and Network Security Symposium: Chair: Xiaojiang (James) Du, North Dakota State University, USA, xiaojiang.du@ndsu.edu Co-Chairs: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org, Yong Guan, Iowa State University, USA, guan@iastate.edu (3) Cross-Layer Optimized Wireless Networks Symposium: Chair: Xi Zhang, Texas A&M University, USA, xizhang@ece.tamu.edu Co-Chairs: Weihua Zhuang, University of Waterloo, Canada, wzhuang@ece.uwaterloo.ca Sunghyun Choi, Seoul National University, Korea, schoi@snu.ac.kr Kun Yang, University of Essex, UK, kunyang@essex.ac.uk (4) MIMO Systems Symposium: Chair: Zhengyuan Xu, University of California, Riverside, USA, dxu@ee.ucr.edu Co-Chairs (in alphabet order): Javier Garcia-Frias, University of Delaware, USA, jgarcia@ee.udel.edu Mounir Ghogho, Leeds University, UK, m.ghogho@leeds.ac.uk Weifeng Su, State University of New York (SUNY) at Buffalo, USA, weifeng@eng.buffalo.edu Liuqing Yang, University of Florida, USA, lqyang@ece.ufl.edu (5) Mobile Computing Symposium: Chair: Jie Li, University of Tsukuba, Japan, lijie@cs.tsukuba.ac.jp (6) Multimedia over Wireless Symposium: Chairs: Haohong Wang, Marvell Technology Group, USA, haohongwang@yahoo.com (7) Next Generation Mobile Networks Symposium (Website Link): Chair: Victor Leung, The University of British Columbia, Canada, vleung@ece.ubc.ca Co-Chairs: Ekram Hossain, University of Manitoba, Canada, ekram@ee.umanitoba.ca Javan Erfanian, Bell Mobility, Canada, javan.erfanian@bell.ca (8) Wireless Sensor Networks Symposium: Chair: Yang Yang, University College London, United Kingdom, y.yang@ee.ucl.ac.uk (9) Wireless LANs and Wireless PANs Symposium: Chair: Ehab Elmallah, University of Alberta, Canada, Canada, ehab@cs.ualberta.ca Co-Chair: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org (10) Workshop Chair: Song Ci, University of Nebraska-Lincoln, USA sci@engr.unl.edu Co-Chair: Yi Cui, Vanderbilt University, USA yi.cui@vanderbilt.edu IMPORTANT DATES: Full Paper Submission: April 15, 2007 (extended) Notification of Acceptance: May 30, 2007 Camera-Ready Version/Copyright Form Submission: June 11, 2007 Registration Deadline for Authors: June 11, 2007 Hotel Reservation Deadline: July 10, 2007 _____________________ ========================================================================= Xi Zhang Assistant Professor Dept. of Elec. & Comput. Engin. Phone: 979-458-1416 Texas A&M University Fax: 979-845-2630 333N WERC Building Email: xizhang@ece.tamu.edu College Station, Texas 77843, USA URL http://dropzone.tamu.edu/~xizhang ========================================================================= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Apr 14 00:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcZif-0007a9-6p; Sat, 14 Apr 2007 00:18:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HcZid-0007a1-SA for manet-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 00:18:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcZid-0007Zt-HM for manet@ietf.org; Sat, 14 Apr 2007 00:18:35 -0400 Received: from web53903.mail.re2.yahoo.com ([206.190.36.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcZic-0004Tu-9s for manet@ietf.org; Sat, 14 Apr 2007 00:18:35 -0400 Received: (qmail 72175 invoked by uid 60001); 14 Apr 2007 04:18:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=wXRTXeMl/tlOAInauUOzVYXsPGK0wjuWQW10G6Oe5TxBndNdK/HwkQq1QE/nJoH8v54T8p5NSyc8hgKEm+xES+o8Nd9fLxpNDhRMDaQZp7PDY4sWeMtcHNXkQmXJ0OSdtyp8ObL1LyJvgpyA/LdWRoywOUdhXCNoVR6tRyzgHeI=; X-YMail-OSG: 8dBLQsMVM1lJMP6N0.6gjemaEiqUEPy7dZ_RixYeyFGVjUe4EdaT0PMbPbWbzeciPEupYlqodenKQvyizsb82FDwtBkHep4snrpGEtkhtiukLwt8X0VUV0H9uI0Pd7ihoXCIlDqsNDOwb00XzQSyCyyeGA-- Received: from [202.131.137.1] by web53903.mail.re2.yahoo.com via HTTP; Fri, 13 Apr 2007 21:18:34 PDT Date: Fri, 13 Apr 2007 21:18:34 -0700 (PDT) From: vasantha vallinayagam To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <160424.71871.qm@web53903.mail.re2.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [manet] Help to implement new protocol in NS2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello, I'am new user in NS2, I cannot run any protocol such as AODV or DSR, Please help me about how can i run this protocol and what are the instructions that I need do to run this protocol.Also help me to include my new protocol using NS2. Anybody having code to calculate and draw graphs for analysing various routing metrics? Please its urgent for my project. thanks in advance. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Apr 14 01:25:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcalE-0002RV-Se; Sat, 14 Apr 2007 01:25:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HcalB-0002Qt-UU for manet-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 01:25:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcal6-0002IE-5K for manet@ietf.org; Sat, 14 Apr 2007 01:25:12 -0400 Received: from web33508.mail.mud.yahoo.com ([68.142.206.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcahS-0004XA-4D for manet@ietf.org; Sat, 14 Apr 2007 01:21:28 -0400 Received: (qmail 63233 invoked by uid 60001); 14 Apr 2007 05:21:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Pxp1J5Gpsfg/19BNyYWruKSXlhLh1R7YsYZkZUalmH4hyjEfOG56QtEzroRr2Jb/icteys3et/BeP9nBiBiqIGuTMM5zeT9jnEmmYqStv2nir1pyWtZ1YElwxOlsOL2LwXFzwaRG4SsX0hkJsnF1qRCQCUV5v2KK6zd9U0DJ+d4=; X-YMail-OSG: mJvy2NQVM1kXgK5l1zOqqhBX0XL.lZe9nxqcYQT7FqJe9VBzp188hJ9HY0syaE7W1vTCw8dZ.1Usu9fFwSmHvgLLher7dgRLJOSH3xf9htdQmmYf7es- Received: from [130.160.46.125] by web33508.mail.mud.yahoo.com via HTTP; Fri, 13 Apr 2007 22:21:25 PDT Date: Fri, 13 Apr 2007 22:21:25 -0700 (PDT) From: Yang Xiao To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <581054.61106.qm@web33508.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [manet] Journal Special issue about Biomedical sensor Networks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangxiao@ieee.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Journal Special issue about Biomedical sensor Networks Topics (not limited to): Biomedical sensors Biomedical sensor Networks Computing and Communications of Biomedical sensor Networks Routing for Biomedical sensor Networks MAC for Biomedical sensor Networks etc. Submission: http://www.hindawi.com/journals/wcn/si/telemed.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Apr 14 09:33:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HciNU-00072i-Ps; Sat, 14 Apr 2007 09:33:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HciNT-00072d-2d for manet-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 09:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HciNS-00072V-PR for manet@ietf.org; Sat, 14 Apr 2007 09:33:18 -0400 Received: from gw4.outgw.tn ([193.95.17.174] helo=rissala174.outgw.tn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HciNQ-0007O4-FK for manet@ietf.org; Sat, 14 Apr 2007 09:33:18 -0400 Received: from smtp.hexabyte.tn (smtp.hexabyte.tn [213.150.189.11]) Received: from www.hexabyte.tn ([196.203.35.2]) by smtp.hexabyte.tn with SMTP id l3EDX5KR006416 Received: from www.hexabyte.tn (www [127.0.0.1]) by www.hexabyte.tn (8.13.4/8.13.4) with ESMTP id l3EDX4vM024958 for ; Sat, 14 Apr 2007 15:33:04 +0200 Received: (from apache@localhost) by www.hexabyte.tn (8.13.4/8.13.4/Submit) id l3EDX4S2024957; Sat, 14 Apr 2007 15:33:04 +0200 Date: Sat, 14 Apr 2007 15:33:04 +0200 Message-Id: <200704141333.l3EDX4S2024957@www.hexabyte.tn> To: manet@ietf.org MIME-Version: 1.0 From: Ali X-Spam-Score: 1.7 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [manet] Bonjour, regarde ca ...!!! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0592334043==" Errors-To: manet-bounces@ietf.org --===============0592334043== content-type: text/html; charset=iso-8859-1

Salut,

Voici le meilleur site tunisien de rencontres: http://www.hexalove.com/?idFriend=603
Je sait que vous étes a la recherche de l'ame soeur,on ne sait jamais...

Ali

--===============0592334043== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0592334043==-- From manet-bounces@ietf.org Sat Apr 14 09:35:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HciPA-0007lS-2U; Sat, 14 Apr 2007 09:35:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HciP8-0007lM-SS for manet-confirm+ok@megatron.ietf.org; Sat, 14 Apr 2007 09:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HciP8-0007lE-GV for manet@ietf.org; Sat, 14 Apr 2007 09:35:02 -0400 Received: from gw4.outgw.tn ([193.95.17.174] helo=rissala174.outgw.tn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HciP7-0007a0-5j for manet@ietf.org; Sat, 14 Apr 2007 09:35:02 -0400 Received: from smtp.hexabyte.tn (smtp.hexabyte.tn [213.150.189.11]) Received: from www.hexabyte.tn ([196.203.35.2]) by smtp.hexabyte.tn with SMTP id l3EDYsKR006805 Received: from www.hexabyte.tn (www [127.0.0.1]) by www.hexabyte.tn (8.13.4/8.13.4) with ESMTP id l3EDYsdq025051 for ; Sat, 14 Apr 2007 15:34:54 +0200 Received: (from apache@localhost) by www.hexabyte.tn (8.13.4/8.13.4/Submit) id l3EDYsNA025050; Sat, 14 Apr 2007 15:34:54 +0200 Date: Sat, 14 Apr 2007 15:34:54 +0200 Message-Id: <200704141334.l3EDYsNA025050@www.hexabyte.tn> To: manet@ietf.org MIME-Version: 1.0 From: Ali X-Spam-Score: 1.7 (+) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [manet] Bonjour, regarde ca ...!!! X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1166485270==" Errors-To: manet-bounces@ietf.org --===============1166485270== content-type: text/html; charset=iso-8859-1

Salut,

Voici le meilleur site tunisien de rencontres: http://www.hexalove.com/?idFriend=603
Je sait que vous étes a la recherche de l'ame soeur,on ne sait jamais...

Ali

--===============1166485270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1166485270==-- From manet-bounces@ietf.org Sun Apr 15 02:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcyfn-0004pI-VJ; Sun, 15 Apr 2007 02:57:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hcyfm-0004pA-Hr for manet-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 02:57:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hcyfm-0004p2-8Q for manet@ietf.org; Sun, 15 Apr 2007 02:57:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcyej-0004ht-2Z for manet@ietf.org; Sun, 15 Apr 2007 02:56:13 -0400 Received: from kagura.jp.toyota-itc.com ([61.200.198.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcyef-0008G8-Es for manet@ietf.org; Sun, 15 Apr 2007 02:56:13 -0400 Received: from shokuan1.meguro.toyota-itc.com (ooigawa [192.168.119.252]) by kagura.jp.toyota-itc.com (Postfix) with ESMTP id 4352012 for ; Sun, 15 Apr 2007 15:56:08 +0900 (JST) Received: from [192.168.119.131] (onur-pc.meguro.toyota-itc.com [192.168.119 .131])by shokuan1.meguro.toyota-itc.com (8.11.6-20030924/8.11.6) with ESMTP id l3F6u7q11694;Sun, 15 Apr 2007 15:56:07 +0900 (JST) Message-ID: <4621CC87.4080502@jp.toyota-itc.com> Date: Sun, 15 Apr 2007 15:56:07 +0900 From: Onur Altintas User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: manet@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 X-TMDA-Confirmed: Sun, 15 Apr 2007 02:57:18 -0400 Subject: [manet] Call for Papers: V2VCOM 2007 (Vehicle-to-Vehicle Communications Wor kshop) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit CALL FOR PAPERS The Third International Workshop on Vehicle-to-Vehicle Communications 2007 (V2VCOM 2007) in conjunction with IEEE Intelligent Vehicles Symposium 2007 June 12, 2007, Istanbul, Turkey http://www.iv2007.itu.edu.tr/workshop.php Important Dates Paper Submission Deadline: April 20, 2007 Notification of Acceptance: May 11, 2007 Camera-Ready Submissions: May 25, 2007 Scope of the Workshop Following the success of the First and Second V2VCOM, this one-day workshop intends to bring together researchers, professionals, and practitioners to discuss and address recent developments and challenges in deploying vehicle-to-vehicle and infrastructure-to-vehicle networking technologies, as well as their subsequent applications. Specifically, we solicit original research contributions addressing the following areas: * Vehicular mobile ad-hoc networks * Potential applications of vehicular networks * Vehicle-to-infrastructure communications * Role of V2V and V2R communications in ITS * Routing protocols for V2V and V2R communications * High-speed mobility management for V2V and V2R communications * MAC layer technologies for V2V and V2R communications * Physical layer and RF level technologies for V2V and V2R communications * Antenna technologies for V2V and V2R communications * Security and authentication issues in V2V and V2R communications * Cross-layer designs in V2V and V2R communications * Radio resource management and QoS support in V2V and V2R communications * Experimental systems and testbeds for V2V and V2R communications * Algorithms, protocols and systems for data dissemination in V2V and V2R communications Submission Instructions Authors are invited to submit full papers of up to 20 double-spaced pages, including references, figures and tables. All submissions should be submitted electronically in Postscript or Adobe PDF format to both of the workshop chairs: Onur Altintas (e-mail:onur@jp.toyota-itc.com) and Wai Chen (e-mail:wchen@research.telcordia.com) ------------------- Program Advisor Tadao Saito Professor Emeritus, Univ. of Tokyo, and CTO, Toyota InfoTechnology Center, Japan Technical Program Committee Tankut Acarman, Galatasaray University, Turkey Bart van Arem, University of Twente, The Netherlands Stephane Amarger, Hitachi Europe, France Fan Bai, GM Research Center, USA Jasmine Chennikara-Varghese, Telcordia Technologies, USA Luca Delgrossi, DaimlerChrysler Research, USA Mario Gerla, UCLA, USA Marco Gruteser, WINLAB, Rutgers University, USA Hisato Iwai, Doshisha University, Japan Hariharan Krishnan, GM Research Center, USA Jae Hong Lee, Seoul National University, South Korea Thomas Luckenbach, FOKUS, Germany David Matolak, Ohio Univ, USA Guevara Noubir, Northeastern University, USA Sadao Obana, ATR, Japan Hyun Seo Oh, ETRI, South Korea Yuji Oie, Kyushu Institute of Technology, Japan Umit Ozguner, Ohio State University, USA Dipankar Raychaudhuri, WINLAB, Rutgers University, USA Sadayuki Tsugawa, Meijo University, Japan Uf Tureli, Stevens Institute of Technology, USA Tomoyuki Yashiro, Chiba Institute of Technology, Japan Ryuji Wakikawa, Keio University, Japan Richard Wolff, Montana State Univ, USA Workshop Chairs Onur Altintas Toyota InfoTechnology Center, Japan onur@jp.toyota-itc.com Wai Chen Telcordia Technologies, USA wchen@research.telcordia.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 15 02:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcyhm-0005QV-Iz; Sun, 15 Apr 2007 02:59:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hcyhk-0005QH-Iq for manet-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 02:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcyhk-0005Q9-9I for manet@ietf.org; Sun, 15 Apr 2007 02:59:20 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcyhi-00032m-Td for manet@ietf.org; Sun, 15 Apr 2007 02:59:20 -0400 Received: by ug-out-1314.google.com with SMTP id 72so674822ugd for ; Sat, 14 Apr 2007 23:59:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=In/WotWfHxEkARB3xhpxmcAoRc6P7J+583YYSFbHaAZQqCyOWAJTDfT9a/FHS/H2ulNWZw5s6i8lP8DLB72dAEW9yIcxJKM7UNzQ7jWmj9chMDYMAlkQNM9H7pA82BDK6ioPv6y7Ql9I0Jux7+jAG1W5//Z8anh9b+O1ltznhmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=coQAfJrUyWdezuItjD3VDAs4lbpwISJ1nFY8VEtb4LvQruLVvLOoBJaG1Gx/FSZUyLDyN8wkwZKCZ7ZGpuzADTgSnX70c3vktdh1E6ePkgSdMIzfvBJM9PZQrYwqfrh5A3B1Rnjm7TT7eL7YtsZFher/DYOt15r9KgUrJpyZwDQ= Received: by 10.66.237.9 with SMTP id k9mr3337288ugh.1176620357786; Sat, 14 Apr 2007 23:59:17 -0700 (PDT) Received: from ?192.168.16.100? ( [122.167.146.85]) by mx.google.com with ESMTP id p32sm5231871ugc.2007.04.14.23.59.15; Sat, 14 Apr 2007 23:59:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45C5A8BC-D8BE-4521-B611-C28304F4A82C@gmail.com> Content-Transfer-Encoding: 7bit From: Ian Chakeres Date: Sun, 15 Apr 2007 12:29:02 +0530 To: manet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.9 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [manet] Minutes Posted & Please review WG Documents X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I have posted the MANET WG minutes from Prague. They are available at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68 I would also like to use this mail to urge you to review the WG documents. We will be issuing a working group last call on several of the documents in the next month. Links to all the WG documents can be found on the charter page at http://www.ietf.org/html.charters/manet-charter.html. Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 15 06:27:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd1x0-0005Hk-NN; Sun, 15 Apr 2007 06:27:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hd1wz-0005Hf-Fa for manet-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 06:27:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd1wy-0005HX-VW for manet@ietf.org; Sun, 15 Apr 2007 06:27:16 -0400 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd1wx-0007ox-C5 for manet@ietf.org; Sun, 15 Apr 2007 06:27:16 -0400 Received: by an-out-0708.google.com with SMTP id d30so1465337and for ; Sun, 15 Apr 2007 03:27:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=pLPvIqP6TwpL64ZUdOqAGT1lojMHFq7mAzA3ubuu7NHNHXoOtA99fgfNEH4l+FSucSF9X6ycL2z5ueuV50RSsW72f2pDAmvY0i8AvT476ezvuVsWSa4eIRFHwAS7Ab7jLHW+AJOyQGZoZ3iJYtYv4hxcGgkVLunO9Wxe/470Ub8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Lc9qdgasBRgWJGZOBYSytal4bUMMyUA5w8tIl9bHYllpXBVfd6QEoxC90ra1QIko5iHeBRnVAV5ZPckwgARp+l8TVl8fgiwaC1wUqwOaTOeziMd/39G1EnYO2q0SQg+YYGNe83PfNx+y0vkcrYyUdf8JuTB5bRp2ZpUZHVqxU8U= Received: by 10.115.23.12 with SMTP id a12mr1643917waj.1176632834557; Sun, 15 Apr 2007 03:27:14 -0700 (PDT) Received: by 10.114.169.18 with HTTP; Sun, 15 Apr 2007 03:27:14 -0700 (PDT) Message-ID: <6f9cb4f10704150327x5219695ahe7b907872b263895@mail.gmail.com> Date: Sun, 15 Apr 2007 15:57:14 +0530 From: "shilpa sharma" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [manet] CBR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0763914848==" Errors-To: manet-bounces@ietf.org --===============0763914848== Content-Type: multipart/alternative; boundary="----=_Part_30217_26673042.1176632834502" ------=_Part_30217_26673042.1176632834502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline hello everyone, I was going through CBR.java.. I want to know is it actually using any protocol for sending message between client and server?? As far as i could see there is a switch case for the choice of protocols zrp, aodv, dsr... but after that client and server are being initialized to send messages.. but nowhere i could see the role of any protocol to send message between them.. if i give -p dsr or -p aodv, both are giving the same output.. does choosing a protocol make any difference to the code?? ------=_Part_30217_26673042.1176632834502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
hello everyone,
I was going through CBR.java.. I want to know is it actually using any protocol for sending message between client and server?? As far as i could see there is a switch case for the choice of protocols zrp, aodv, dsr... but after that client and server are being initialized to send messages.. but nowhere i could see the role of any protocol to send message between them.. if i give -p dsr or -p aodv, both are giving the same output.. does choosing a protocol make any difference to the code??
------=_Part_30217_26673042.1176632834502-- --===============0763914848== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0763914848==-- From manet-bounces@ietf.org Sun Apr 15 07:21:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd2nL-0003UN-AE; Sun, 15 Apr 2007 07:21:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hd2nJ-0003UF-Ar for manet-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 07:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd2nJ-0003U7-15 for manet@ietf.org; Sun, 15 Apr 2007 07:21:21 -0400 Received: from mailgw2.technion.ac.il ([132.68.238.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd2nI-0002Ym-2o for manet@ietf.org; Sun, 15 Apr 2007 07:21:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 240273901BF for ; Sun, 15 Apr 2007 14:21:19 +0300 (IDT) X-Virus-Scanned: by amavisd-new at technion.ac.il Received: from mailgw2.technion.ac.il ([127.0.0.1]) by localhost (mailgw2.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z17D9gs9ggUW for ; Sun, 15 Apr 2007 14:21:18 +0300 (IDT) Received: from csm.cs.technion.ac.il (csm.cs.technion.ac.il [132.68.32.31]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 718C739029A for ; Sun, 15 Apr 2007 14:21:13 +0300 (IDT) Received: from gabiklap (gabik-lap.cs.technion.ac.il [132.68.41.248]) by csm.cs.technion.ac.il (Postfix) with ESMTP id 9E85F18C6E6; Sun, 15 Apr 2007 14:21:12 +0300 (IDT) From: "gabik" To: "'shilpa sharma'" , Subject: RE: [manet] CBR Date: Sun, 15 Apr 2007 14:20:53 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6f9cb4f10704150327x5219695ahe7b907872b263895@mail.gmail.com> Thread-Index: Acd/SNkYpt0A4W2+S2SUIXFgg+O2xAABp24g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070415112112.9E85F18C6E6@csm.cs.technion.ac.il> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1197162359==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1197162359== Content-Type: multipart/alternative; boundary="----=_NextPart_000_024E_01C77F69.46435560" This is a multi-part message in MIME format. ------=_NextPart_000_024E_01C77F69.46435560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Client and server use UDP transport to send message to each other. At the IP/routing level they use the routing protocol according to what you have picked (dsr/aodv/...) You can see it very clearly at the lines: NetIp net = new NetIp(address, protMap, loss, loss); RouteInterface route = ... ........ net.setRouting(route); .... udp.setNetEntity(net.getProxy()); Gabi _____ From: shilpa sharma [mailto:shilpasharma85@gmail.com] Sent: Sunday, April 15, 2007 1:27 PM To: manet@ietf.org Subject: [manet] CBR hello everyone, I was going through CBR.java.. I want to know is it actually using any protocol for sending message between client and server?? As far as i could see there is a switch case for the choice of protocols zrp, aodv, dsr... but after that client and server are being initialized to send messages.. but nowhere i could see the role of any protocol to send message between them.. if i give -p dsr or -p aodv, both are giving the same output.. does choosing a protocol make any difference to the code?? ------=_NextPart_000_024E_01C77F69.46435560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello=20
 
Client=20 and server use UDP transport to send message to each = other.
At the=20 IP/routing level they use the routing protocol according to what you = have picked=20 (dsr/aodv/...)
 
You=20 can see it very clearly at the lines:

NetIp net =3D new=20 NetIp(address, protMap, loss, loss);
RouteInterface route =3D=20 ...
........
net.setRouting(route);
....
udp.setNetEntity(net.getProxy());

 
Gabi
 


From: shilpa sharma=20 [mailto:shilpasharma85@gmail.com]
Sent: Sunday, April 15, = 2007 1:27=20 PM
To: manet@ietf.org
Subject: [manet]=20 CBR

hello everyone,
I was going through CBR.java.. I want to know is it actually using = any=20 protocol for sending message between client and server?? As far as i = could see=20 there is a switch case for the choice of protocols zrp, aodv, dsr... but = after=20 that client and server are being initialized to send messages.. but = nowhere i=20 could see the role of any protocol to send message between them.. if i = give -p=20 dsr or -p aodv, both are giving the same output.. does choosing a = protocol make=20 any difference to the code??
------=_NextPart_000_024E_01C77F69.46435560-- --===============1197162359== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1197162359==-- From manet-bounces@ietf.org Sun Apr 15 13:34:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd8br-0000ST-JD; Sun, 15 Apr 2007 13:33:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hd8bq-0000SM-O5 for manet-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 13:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd8bq-0000SE-EW for manet@ietf.org; Sun, 15 Apr 2007 13:33:54 -0400 Received: from web51107.mail.re2.yahoo.com ([206.190.38.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hd8bq-0003ya-0A for manet@ietf.org; Sun, 15 Apr 2007 13:33:54 -0400 Received: (qmail 75469 invoked by uid 60001); 15 Apr 2007 17:33:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=oRGL7tUlQpQHLfA0qf1hTaLizChUrTJ6z84ul+ajCEugEzGyeI4+OAA1db3U7DPkiXPuFzWX+q9oq8Cs5Kj/BqPAgDHaaEPJL+CvbQyLjk468kfLW/0xoZcgIedEg5ygBlDOXY7z0OH0O+p654IBA/wwjkLp6RfRmc47Jd8X0gY=; X-YMail-OSG: fKckHv0VM1lNnJF4gGE1zZON1FIVaatP1w8nShBOoruP.W917ir7EKvJ5GjvR68WvvO98GFIY8XSLrsyMt_Tbh5rbeblaE5iKLKuE0psC2_pyeUQcUqr6PfJ5D3q5c.QLBR3YF_KDSUg9QxmZ95sZzgP Received: from [62.135.70.149] by web51107.mail.re2.yahoo.com via HTTP; Sun, 15 Apr 2007 10:33:53 PDT Date: Sun, 15 Apr 2007 10:33:53 -0700 (PDT) From: AHMED SALAH To: manet@ietf.org MIME-Version: 1.0 Message-ID: <861959.73301.qm@web51107.mail.re2.yahoo.com> X-Spam-Score: 1.0 (+) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Subject: [manet] I have already setup ns2 but I have the following error X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1113773501==" Errors-To: manet-bounces@ietf.org --===============1113773501== Content-Type: multipart/alternative; boundary="0-2120436606-1176658433=:73301" Content-Transfer-Encoding: 8bit --0-2120436606-1176658433=:73301 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit dear all, I decide to run (geogride,lbm gamer) geocast routing protocls on my pc oprating system(linux plus fedora) I have already setup 2.1b7a but when i tray to run ( Geocast-prtocols ) the following error message can you help me to correct that error ********************************************************************** ************ ************************************************************ the error message is [root@localhost ns-allinone-2.1b7a]# cd ns-2.1b7a [root@localhost ns-2.1b7a]# cd gamer [root@localhost gamer]# ns actGamer_study1.tcl 30 mob30-1 setting other default settings... num_nodes is set 30 creating channel... invalid command name "Mac/NULL" while executing "Mac/NULL create _o19 " invoked from within "catch "$className create $o $args" msg" (procedure "new" line 3) invoked from within "new $mactype" (procedure "_o14" line 10) (Node/MobileNode add-interface line 10) invoked from within "$node add-interface $chan $propInstance_ $llType_ $macType_ $ifqType_ $ifqlen_ $phyType_ $antType_" (procedure "_o3" line 46) (Simulator create-wireless-node line 46) invoked from within "_o3 create-wireless-node" ("eval" body line 1) invoked from within "eval $self create-wireless-node $args" (procedure "_o3" line 14) (Simulator node line 14) invoked from within "$ns_ node" ("for" body line 2) invoked from within "for {set i 0} {$i <= $val(nn) } {incr i} { set node_($i) [$ns_ node] $node_($i) random-motion 0 ;# disable random motion }" (file "actGamer_study1.tcl" line 129) ********************************************************************** *** [root@localhost gamer]# cd .. [root@localhost ns-2.1b7a]# cd lbm [root@localhost lbm]# ns box_study1.tcl 30 mob30-1 setting other default settings... removing unecessary packet headers... num_nodes is set 30 creating channel... invalid command name "Mac/NULL" while executing "Mac/NULL create _o19 " invoked from within "catch "$className create $o $args" msg" (procedure "new" line 3) invoked from within "new $mactype" (procedure "_o14" line 10) (Node/MobileNode add-interface line 10) invoked from within "$node add-interface $chan $propInstance_ $llType_ $macType_ $ifqType_ $ifqlen_ $phyType_ $antType_" (procedure "_o3" line 46) (Simulator create-wireless-node line 46) invoked from within "_o3 create-wireless-node" ("eval" body line 1) invoked from within "eval $self create-wireless-node $args" (procedure "_o3" line 14) (Simulator node line 14) invoked from within "$ns_ node" ("for" body line 2) invoked from within "for {set i 0} {$i <= $val(nn) } {incr i} { set node_($i) [$ns_ node] $node_($i) random-motion 0 ;# disable random motion }" (file "box_study1.tcl" line 130) ********************************************************************** ************ [root@localhost lbm]# cd .. [root@localhost ns-2.1b7a]# cd geogride bash: cd: geogride: No such file or directory [ root@localhost ns-2.1b7a]# cd geogrid [root@localhost geogrid]# ns run_study1.tcl 30 mob30-1 invalid command name "Agent/GeoGRID" while executing "Agent/GeoGRID instproc sendMulticastData {minExtX minExtY maxExtX maxExtY size {forwardMethod ""}} { set ns [Simulator instance] ;# Figure out ..." (file "sendmulticastdata.tcl" line 38) invoked from within "source.orig sendmulticastdata.tcl" ("uplevel" body line 1) invoked from within "uplevel source.orig $fileName" (procedure "source" line 12) invoked from within "source sendmulticastdata.tcl" (file "run_study1.tcl" line 25) [root@localhost geogrid]# --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. --0-2120436606-1176658433=:73301 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit dear all, 
I decide to run (geogride,lbm gamer) geocast routing protocls   on my pc oprating
system(linux plus fedora)


I have already setup 2.1b7a  but when i tray to run  ( Geocast-prtocols  )  the following error message can you help  me to  correct that error 


********************************************************************** ************



************************************************************
the error message is


[root@localhost ns-allinone-2.1b7a]# cd ns-2.1b7a



[root@localhost ns-2.1b7a]# cd gamer



[root@localhost gamer]# ns actGamer_study1.tcl 30  mob30-1

setting other default
settings...

num_nodes is set 30

creating channel...

invalid command name "Mac/NULL"

while executing
"Mac/NULL create _o19 "

invoked from within
"catch "$className create $o $args" msg"

(procedure "new" line 3)

invoked from within
"new $mactype"

(procedure "_o14" line 10)

(Node/MobileNode add-interface line 10)

invoked from within
"$node add-interface $chan $propInstance_ $llType_ $macType_   $ifqType_ $ifqlen_ $phyType_ $antType_"

(procedure "_o3" line 46)

(Simulator create-wireless-node line 46)

invoked from within
"_o3 create-wireless-node"

("eval" body line 1)

invoked from within
"eval $self create-wireless-node $args"

(procedure "_o3" line 14)

(Simulator node line 14)

   invoked from within
"$ns_ node"

("for" body line 2)


invoked from within
"for {set i 0} {$i <= $val(nn) } {incr i} {
set node_($i) [$ns_ node]
$node_($i)

random-motion 0           ;# disable random motion
}"

(file "actGamer_study1.tcl" line 129)

********************************************************************** ***



[root@localhost gamer]# cd ..

[root@localhost ns-2.1b7a]# cd lbm

[root@localhost lbm]# ns box_study1.tcl 30 mob30-1

setting other default
settings...
removing unecessary packet headers...

num_nodes is set 30
creating channel...

invalid command name "Mac/NULL"

while executing
"Mac/NULL create _o19 "

invoked from within
"catch "$className create $o $args" msg"

(procedure "new" line 3)

invoked from within
"new $mactype"

  (procedure "_o14" line 10)

(Node/MobileNode add-interface line 10)


  invoked from within
"$node add-interface $chan $propInstance_ $llType_ $macType_   $ifqType_ $ifqlen_ $phyType_ $antType_"

(procedure "_o3" line 46)

(Simulator create-wireless-node line 46)


  invoked from within
"_o3 create-wireless-node"

("eval" body line 1)

invoked from within
"eval $self create-wireless-node $args"

(procedure "_o3" line 14)

(Simulator node line 14)

invoked from within
"$ns_ node"

("for" body line 2)

invoked from within
"for {set i 0} {$i <= $val(nn) } {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 0
     ;# disable random motion
}"

(file "box_study1.tcl" line 130)



********************************************************************** ************

[root@localhost lbm]# cd  ..

[root@localhost ns-2.1b7a]# cd geogride

bash: cd: geogride: No such file or directory
[
root@localhost ns-2.1b7a]# cd geogrid

[root@localhost geogrid]# ns run_study1.tcl 30 mob30-1

invalid command name "Agent/GeoGRID"

while executing
"Agent/GeoGRID instproc sendMulticastData
{minExtX minExtY maxExtX maxExtY size {forwardMethod ""}} {
   set ns [Simulator instance]    ;# Figure out ..."

(file "sendmulticastdata.tcl" line 38)

invoked from within
"source.orig sendmulticastdata.tcl"

   ("uplevel" body line 1)

invoked from within
"uplevel source.orig $fileName"

  (procedure "source" line 12)

invoked from within
"source sendmulticastdata.tcl"

(file "run_study1.tcl" line 25)

[root@localhost geogrid]#

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-2120436606-1176658433=:73301-- --===============1113773501== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1113773501==-- From manet-bounces@ietf.org Sun Apr 15 15:30:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdAQg-0005PC-62; Sun, 15 Apr 2007 15:30:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdAQe-0005Oz-9b for manet-confirm+ok@megatron.ietf.org; Sun, 15 Apr 2007 15:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdAQd-0005Or-WE for manet@ietf.org; Sun, 15 Apr 2007 15:30:28 -0400 Received: from ee.tamu.edu ([165.91.241.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdAQa-0005Xf-HE for manet@ietf.org; Sun, 15 Apr 2007 15:30:27 -0400 Received: from ECE149 (ece149.tamu.edu [165.91.208.72]) by ee.tamu.edu (8.13.6/8.13.6) with SMTP id l3FJUKi5029232; Sun, 15 Apr 2007 14:30:21 -0500 (CDT) Message-ID: <005701c77f9c$e505d960$48d05ba5@ECE149> From: "Dr. Xi Zhang" To: Date: Sun, 15 Apr 2007 14:30:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: ekpark@umkc.edu, hshwchen@comm.nsysu.edu.tw, mguizani@uaeu.ac.ae Subject: [manet] Submission deadline is today: ACM IWCMC 2007, Aug 12, 2007, Honolulu, Hawaii, USA. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org *Sorry for receiving multiple copies* Submissions: EDAS --> Deadline extened to April 15, 2007. Call For Papers for ACM IWCMC 2007: _____________________ ACM IWCMC 2007 (http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) August 12-16, 2007, Honolulu, Hawaii, USA Technical Sponsors: ACM (Approved) and IEEE (Pending) Submissions: EDAS --> Deadline extended to April 15, 2007. "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" The ACM International Wireless Communications and Mobile Computing Conference 2007 (ACM IWCMC 2007) will be held in Turtle Bay Resort Hotel, Honolulu, Hawaii, USA during August 12-16, 2007. Under our new theme of "The Future is Now -- The New Era of Wireless Communications and Mobile Computing/Networking" , IWCMC2007 is targeting at a wide spectrum of state-of-the-art as well as emerging topics pertaining to wireless networks, communications, and mobile computing. Continuing the great succeed of ACM IWCMC 2006 last year, IWCMC 2007 is anticipated to attract an even larger volume of high quality submissions and stimulate the cutting-edge research discussions amongst many academic pioneering researchers/scientists and industrial engineers/leaders attendees from all around the world as was evidenced during ACM IWCMC 2006. The ACM IWCMC 2007 program will feature a General Symposium, 8 Specific Technical Symposia, Workshop, and Tutorials Sessions. Prospective authors are invited to submit original technical papers to the corresponding IWCMC 2007 Symposia as listed below for oral presentation at IWCMC 2007 and publication in the IWCMC 2007 Conference Proceedings. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ We're pleased to announce the following: [1] Professor Gordon Stuber from Georgia Tech, USA, who is the world-class leader in mobile wireless communications/networking, communication signal processing, and many other areas, has agreed to be the Keynote Speaker for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [2] "NTT DoCoMo USA", which is one of most famous companies in the mobile communications industries, has officially become the Financial Sponsor for our ACM IWCMC 2007.(http://dropzone.tamu.edu/~xizhang/IWCMC07/IWCMC07.htm) [3] ACM has officially become the technical sponsor for IWCMC 2007 (this was notified earlier) and all the accepted IWCMC 2007 papers will be included into the ACM Database. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ IWCMC 2007 General Organizing Committee: General Co-Chairs: Mohsen Guizani, Western Michigan University, USA, Email: mguizani@ieee.org Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan, Email: hshwchen@comm.nsysu.edu.tw Technical Program Committee Chair: Xi Zhang, Texas A&M University, USA, Email: xizhang@ece.tamu.edu Financial Chair: Eun K. Park, University of Missouri at Kansas City, USA, Email: ekpark@umkc.edu IWCMC 2007 Technical Symposia: General Symposium: Chair: Xuemin (Sherman) Shen, University of Waterloo, Canada, xshen@bbcr.uwaterloo.ca Co-Chairs: Dongmei Zhao, McMaster University, Canada, dzhao@mail.ece.mcmaster.ca Hai Jiang, Princeton University, USA, haijiang@princeton.edu (1) Communication and Information Theory Symposium: Chair: Hamid Sadjadpour, University of California, Santa Cruz, USA, hamid@soe.ucsc.edu Ravi Narasimhan, University of California, Santa Cruz, USA ravi@soe.ucsc.edu (2) Computer and Network Security Symposium: Chair: Xiaojiang (James) Du, North Dakota State University, USA, xiaojiang.du@ndsu.edu Co-Chairs: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org, Yong Guan, Iowa State University, USA, guan@iastate.edu (3) Cross-Layer Optimized Wireless Networks Symposium: Chair: Xi Zhang, Texas A&M University, USA, xizhang@ece.tamu.edu Co-Chairs: Weihua Zhuang, University of Waterloo, Canada, wzhuang@ece.uwaterloo.ca Sunghyun Choi, Seoul National University, Korea, schoi@snu.ac.kr Kun Yang, University of Essex, UK, kunyang@essex.ac.uk (4) MIMO Systems Symposium: Chair: Zhengyuan Xu, University of California, Riverside, USA, dxu@ee.ucr.edu Co-Chairs (in alphabet order): Javier Garcia-Frias, University of Delaware, USA, jgarcia@ee.udel.edu Mounir Ghogho, Leeds University, UK, m.ghogho@leeds.ac.uk Weifeng Su, State University of New York (SUNY) at Buffalo, USA, weifeng@eng.buffalo.edu Liuqing Yang, University of Florida, USA, lqyang@ece.ufl.edu (5) Mobile Computing Symposium: Chair: Jie Li, University of Tsukuba, Japan, lijie@cs.tsukuba.ac.jp (6) Multimedia over Wireless Symposium: Chairs: Haohong Wang, Marvell Technology Group, USA, haohongwang@yahoo.com (7) Next Generation Mobile Networks Symposium (Website Link): Chair: Victor Leung, The University of British Columbia, Canada, vleung@ece.ubc.ca Co-Chairs: Ekram Hossain, University of Manitoba, Canada, ekram@ee.umanitoba.ca Javan Erfanian, Bell Mobility, Canada, javan.erfanian@bell.ca (8) Wireless Sensor Networks Symposium: Chair: Yang Yang, University College London, United Kingdom, y.yang@ee.ucl.ac.uk (9) Wireless LANs and Wireless PANs Symposium: Chair: Ehab Elmallah, University of Alberta, Canada, Canada, ehab@cs.ualberta.ca Co-Chair: Yang Xiao, University of Alabama, USA, yangxiao@ieee.org (10) Workshop Chair: Song Ci, University of Nebraska-Lincoln, USA sci@engr.unl.edu Co-Chair: Yi Cui, Vanderbilt University, USA yi.cui@vanderbilt.edu IMPORTANT DATES: Full Paper Submission: April 15, 2007 (extended) Notification of Acceptance: May 30, 2007 Camera-Ready Version/Copyright Form Submission: June 11, 2007 Registration Deadline for Authors: June 11, 2007 Hotel Reservation Deadline: July 10, 2007 _____________________ ========================================================================= Xi Zhang Assistant Professor Dept. of Elec. & Comput. Engin. Phone: 979-458-1416 Texas A&M University Fax: 979-845-2630 333N WERC Building Email: xizhang@ece.tamu.edu College Station, Texas 77843, USA URL http://dropzone.tamu.edu/~xizhang ========================================================================= _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 16 02:44:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdKxC-0006HJ-T4; Mon, 16 Apr 2007 02:44:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdKxA-0006H4-LD for manet-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 02:44:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdKx7-0006Gc-Bf for manet@ietf.org; Mon, 16 Apr 2007 02:44:41 -0400 Received: from ml.univ-avignon.fr ([195.83.163.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdKx5-0001jq-N5 for manet@ietf.org; Mon, 16 Apr 2007 02:44:41 -0400 Received: by ml.univ-avignon.fr (Postfix, from userid 33) id 818D6105657; Mon, 16 Apr 2007 08:44:38 +0200 (CEST) Received: from abo-209-71-69.avi.modulonet.fr (abo-209-71-69.avi.modulonet.fr [85.69.71.209]) by webmail.univ-avignon.fr (Horde MIME library) with HTTP for ; Mon, 16 Apr 2007 08:44:38 +0200 Message-ID: <20070416084438.6yid2iya5340kc8w@webmail.univ-avignon.fr> Date: Mon, 16 Apr 2007 08:44:38 +0200 From: rachedi To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_3a7pnpgp2qf4" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Subject: [manet] CFP of special session on security X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org This message is in MIME format. --=_3a7pnpgp2qf4 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable CFP for IEEE WiMOB=922007 special session on security in Mobile Ad hoc Netw= orks (MANET) and wireless sensor networks (WSN). The session is part of the 3rd IEEE International Conference on Wireless an= d Mobile Computing, Networking and Communications =93WiMob 2007=94 http://www.gel.usherbrooke.ca/WiMob2007/, which will take place in Crowne P= laza Hotel, White Plains, New York, USA, from October 8-10, 2007. Motivations: Mobile ad hoc networks are able to provide fast and efficient network deplo= yment capabilities in a wide variety of scenarios where a fixed networking infrastructure is not possible. Wireless Sensor Networks (WSNs) are relatively low cost to be deployed and = to be used in many promising applications, such as biomedical sensor monitoring (= e.g., cardiac patient monitoring), habitat monitoring (e.g., animal tracking), we= ather monitoring (temperature, humidity, etc.), low-performance seismic sensing, = and natural disaster detection/monitoring (e.g., flooding and fire). These types of networks offer new challenging security problems due primari= ly to their wireless network interface, allowing easy eavesdropping and injection= of messages, and to their distributed infrastructure-less topology. Unfortunat= ely, the security in mobile ad hoc networks has been analyzed individually at different layers of the communication protocols. Furthermore, many proposed security solutions contain strong assumptions or they didn=92t well adapt t= o the characteristics of MANETs or WSNs. That=92s way the future proposed solutio= n must take into account the resource constraints, (eventually) mobility and to ch= oose the cross-layer approach to design the security mechanism. Scope of Contributions for MANET and WSN (include but are not limited to th= e following): -=09Cross-Layer design of secure architecture -=09Novel Distributed architectures and security schemes -=09Key management and key distribution -=09Secure routing and communication protocols -=09Security and trust modeling -=09Monitoring mechanisms and Distributed Intrusion Detection Systems -=09Trust establishment and trust management -=09Secure localization -=09Secure time synchronization -=09Location privacy -=09etc. Authors are invited to submit a complete technical paper of their original = work. Maximum length for submissions is 8 double column pages in IEEE format. The preferred submission format is PDF. Session Chair: Abderrahim Benslimane, LIA Avignon University Session Co-chair: Chadi Assi, CIISE Concordia University Submissions should be sent attached by email to the session chair at: abderrahim.benslimane@univ-avignon.fr Important Dates : Manuscript Submission Due: May 5, 2007 Acceptance Notification: June 5, 2007 Final Manuscript Due: June 15, 2007 --=_3a7pnpgp2qf4 Content-Type: application/pdf; name="CFP for IEEE WiMOB special session on security.pdf" Content-Disposition: attachment; filename="CFP for IEEE WiMOB special session on security.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nM1dWXccxRV+n18xb8zkMO3eF97YQkiI2cTJyTF5GMsSNrItISQb52eQ/ODU Xl/Vvbd7RpJPgAM0Pbdrvct3lyr/si6Lql6X+m//cPpqVa6/UP/8tPplNRaN/sv8gM+nr9afnKwe fTes1Vcn56uymKaprcxv1Xooi3E99GXRrk9erTbr7cnPq6pR706+Wp386cnm0+2uKZqp6/rNn7dd 0Q9d022+2e5a1UOpXq7V73Wp/mfYnG/rYiy7zeV2Vxb11E5Du7l27zRZo8jaZvPltlbvKvXj59uy 6NuyrHv1uJuKpu/GEd9C4//Y7vqi68t62LzY7uqi6rtu3Px9u6uKrtaj+3qrnoa2rTefbPuir6pu 2Pxue++rTW3HpL7pNqXwPMAz9Pyr7qOup2nYXAHF2bYp1BxO7X/UmCo1qKFsNnv75qUdZdvANDrX WFPV/vv4Ij69iJ9eQo+vufGF5W4qNXWBhPTqRn0L5Han2mbC7m/itN5t/3Xy11U9DUXZdYp1Tp6t nmAf8JUwCrdZbdMm03oKz9AIrJ8bNDT1sdnsrm83z/i+nsNr7OyUNPU4NGW6adSjnrbv+635uamm ZJ3jYl3AW7fMZa2Holdr55drZ0VKL9mPGycSwLtuOmqVH4cnEIOT+Pjj1n5djXoOldIEnWJRx3K4 7tm6KMJ26KbGzUeLCYjRdZCTs4R59W8JnxopgEdsWb/W0+8m/w2OBz66JFyne/ZNDVPKxq6tmzii OAXaEmwJdOu2xK6XenR7oImdXqnaafO91WpVNQBTwIIXdoR9N1Ruf7WChM15Doov8mw9KUZT/AMr MLumsC8z0u9bBep0XzwB6izHJ3HRYVXhE+z2HPmtKRWBWj/47DndKmipYbc6l1nX6pfbShuGqksN A/eov6q0/PqPlMDgAt0Q5RHZ47Xhg6aswnoA9QGql9XvdsKjMpdGSw5t0Y6115JSS+dhTGSQUYL8 WJ3myteYZ5JqHJAEmBwmeL3dDUWt2s7FHpaNM0/Q8LLi8ZRU+RuV+RSeJeWvxl73TavXue5Kq1fd AoNeBaCCAOSVbqntNVS5gte38AzcDNL0Gih+2k7FoHis3nwIWgo11uOgk47TV1ocUF+lA/B7H/sn Sr+q60W9rwdIl8eQ2OXppil5vBUYFnbIseOdJChhpaBS/2Ob4nnVsU81TiJ2wLYc3Bv6JkN7RjrH SeNDL50I+/5rxlDWrVPwn5+svl1ZoPzdF+7h+p5gu58qC7afJAYDGAYekWc/iq8fsY9vA3jInzTz FcANkaGowUe6W7JrxrwwSj+y89PIt/HlZXzppbNRm3NBG8LuUyaDmc56A/0wikxyrB/waFsPY+CE av1i1U3lWi2odoXW1Vg26259fbY6v7cjVo+DmgZyx4cJ3thVXanRld9bhU2ez4rm81Q26Oe8vk3t mv8KBNztBrN1QI+o4yX5ltgy/5nsRHiKT41zVzYI+HCz4/QoiLRyHZr6JuI9OsR/W7OjwOyejPIv rE9AMEfdJhb1QyVzowLKDdqxqld2bEQ75ll7HBP18IJVD3EFg8yAbw5CvQ9uambfctE+2MBFxYJk /zzC1jFdGV7/IbQBiPzj8FIa4XnoJFE7manra8Uw2NvXgWFOiS2TtMhZYI7IhNjmCDBsFyiqqANL ugxezHMbxqgqY8T6saiqkTNiXoNqp8z7oY468BkN9IA7iviJB0dvgGJPAA/1YAyhwHHerPnBzgzm KS8Q1FulvvEz+BR+XY4TeMq7+6Q532d+mm5/6gHOEW+czgaZ8aWL0VQdQ39DtiIoVEdxRcabq9Q3 wM2goJ/RBQEXO/o2+9yTuEktjPtgH2QqhbOG2ZXiHcoRok7+K9dx7O2cC2OdJtoP3BvBZ4QO5G2P 0SGtPC5z1JNHIqBNZuWumA1V6A1afbetNGbrawTq8jSMOIUeT3NrRqMC2lote2NpbJB5G00fovxg 79xGgr0TXC7U7Htq5SLAhe9RxhnL+IbMGUTtBdEhen56G9RjXHtsDzbnnA1jgaCniIeGIOxA+rGR wj9M0C2ug9Y7LCY3Dn5ZT9lyTGXVZqtqTA4rPL/FwZ4lupR4XUuyshuLttGYPdWRRsI1oO5DXPmC Z0TswLgw5VgPyRAE4vMY6rg+SDFFKnSBKEJII+h5PEUYGe//4ngvqUA7vRTIrwTyhYRCZjkyfZiG OCmMcLvEw1UaUL5DOHkqNccmwdg7RpN9SweHZqL+DmJzAb4qP04fzld9glNKQsltm6gDH1WGkdap KrBBQKu1e99jpb8lQULqvPCq+Q0Vz5dOxynN9g5jTL4vaJp3stYOjA5FF8GoExOeK1N2tss4SKAb hsLh73Rhls0qdKGzPyWo9h6Um2WECtteDnTebyYTEtyC9stTd9qyPoPf4bNU98VJOA/AbhGILoRG 96ldUnwd10VjVLVa9ZBGo7yI02CrQSZ8XuKA8KbviwEqzG5m7kYIGPlVjWjogLSK7Ab7QQEFYxey iIv9qKd2Bn4Tkp9CiJaxv2JINstPuP5IJvi1S1hURRvkNxLxCTZoDwYnrSoPGfmW52x9yiC91ry5 vS0i4o2fOJumXKsx97V9UwQexxEJax05LHqKtrWQcTPiGbH1Elx+nYaSvAeAOQ+zR7wAM372TNiI q9BYTH2AzcqlozNLpPk/g7UMe2dDodEDaDDlLt+2H542yrPzyzCBEPxKmcv17JkLsLNnrnaizGUY KmeuXo2XMxyw/TBBXmzNcNoUmQauj8x16mOy1lsein4I2UfOLHR0XzWzszN4mxZIcDmf1PdgY2N+ JkcrDHCFj1EYqSZ2nUPen2aIYWSkzsdUhbArT32BrEAkSni6utEltrsFco1xX0xUgrwLXm8qDj4s 9G5bq82ua2LWbEC7Z4DxKU3GpPLvw0e6lVa3ghaZYsVWORG78P3VDL/o38+j8PGiTOUGdz8424Ct 3CBpEQbrl1EgAwbWt1ZPnDnlMK8kgpE2z/W49vdOoPti6oJAz4BQ/x1Tr7DstLIayLco2ME4xzlv GuMRCqqWg9TyWQ7c4GvqfB+Qan7E6lqGeoRcIg9VMrmmmscQWL2qQQWKuN0/rgosMy5KopxmVgKD 0reQ9ahGRv6MSsBnZhPnoHgegDukzuCcM7c0EAXKhKYrlsuqqBhrLa8ZapxSzWe9GOO6eNeGtgEf M7VP1kn3BEfkAWga/CK+dN2PQ7fcfXwi2XZxZF6QYgFjIB05h4VKPw0PsYwyr9x8JZLr+LBKVOuS qB/6ikExSVEqBGZ9H1f5yucJjfkYGOiJ1GVzzSPn37JLno5lHrVQS8aSvVyYs6CueIrnQBHhSVIZ FpFbdD/sfoASY4Pwdw/9eTTymsr7HTNt0KgA/mkunUUhubun03SOXoBUezL9eXyUFuTSQPdkZ6MQ ed1WGRJXy1irdWwz3vDlCinxGxLO94W7Q1qZycvOlUMkU6H0tRfOK2pXZl14P7Jlu7JQGPLzw6AE WFmqgJ0D40dCwzFcxN3N7CdqLCKNUN8TfQvEFVnMj6nLuWSRh90nEFpau4uCxgiyyVErur6XXA0Q 4xv6PRA+FVQnlULPBt58uAEIIsKVfuyJtqFjU2RyekfT0QMS0QjraqLo0hyh5/xkhGiYlNhJ49dg Z2mGOEvj2A67zQ8xA5euns/ATWXH1Sxfc16zVCNK3Y0s16DGFEeaRxzcSMXYQsB6jvBhTragQVWr WcuJROha8CeOOc7im4oin4m5J0CLjfb91H2YZOj0LoLAH2JOuxhgSYKCF/COz38xEJIn5LMejNsM 3zD2YZ8xUwuJK1ez1/ZEjWTtCmpEcI/e8K8lHMgC6chrNhTDJZdIZoxktYCfsOIlD4OTRLQ1JtZw t0oDeCHne0zyiX6jopBwAb4EKPt2RFPqCeakvFGACmmZnKJYu54FivOlu0/pOoxotnAqrwjlhDY9 CQGrHlczVeTRqptNBBmPRzNvGSmeN/meKs0meGeZFKPleNdFLdiIXJ5kTb6g65dXbIIjh0Xj1PnP QaMJ0w8MoWgdsoBFUvsDEmvH3gkZMthCBt3c5XAErd+SPksKtH3QsJs4/zlHvq6PhToYqWN6NqXu aDAwPt3yEnz1sAsmJi49wWL2gvJszVqIvBQSQfvvHHCC5mJshq0YTyKxGEzU+wrSz5S4ptnzvJJX D0HjnKqRsoI8Bb9SQMvGlWh8Pz0GAPE64oMvehk0+Z8FFdzIxLieJ0iO4xqcrI8gxYOg5vRhM41D jbHJ7HypaSuPTARjDBRLx06h3QzM+xZogNQttw+ejfEAInDf77zN9q1Ckd5eO8UaC4+ZLDjSRQkC 2mj+BcXI43W2reWC5eXSOMFuuB6Ids8NNGb6ZpWVP5SvG57yaNqYHmAE+4tGnGd74xvYwnGaTEfU js6GpV+OhPk1C843Vqh7MWMAmeQSLo5b8vEsIYEgQvUfk9bSsTt6cNa1y8yAtytz2XfJsMI3YsTH DiRJS585X7wqlLfgxZcp3BO6OsIP8RKd3ihghjSKafpl5/YAF7spDcEhh4fdaOSaOk/BGJ7LQ7UA 3xHlSW2dSZf6JY/+U/CjHxUH77ybbjcYxD85rJWDkJGmye1+5Sk6NPiQ8sqK9ZA/+Nq10K58gCSQ hIrJjhFQ0DYRKXIIND2swmsErrI+QfY6Ln8cuM8K+41o0hBvXKSswElwMdlKAproVP/5wGQ7v4+H 9lKt5DeS0ed4DiH87O/gwd+Fo9+ChmaX7IDA7cH1lR4sMSnj5ZtByKUpOnESS6z5S1Nwbw9LZRvS JYy2hv0EFc7nQ0+JNr4VhsCcHXjqQF1XqEl6qyAgKWaypGIcaRaOHdhzRIGa1/R8uQwNAXN+et3N qPfQ72JAmDnDIrjmszXtcKWKXNkBJvMjXHiH7OwuZUctleb/YPXou8md/W6Kqa+b1u6lpYgHw+um KLum9xsN8ssVXZM8gxGwXQRAX20rLQqmupWB9FxJwcPp9judljrLq2vn8jCZGaTBScbCSVyadXuA g+IzQWH3CzXDCXZ/Z/f2Lhv/mI3N49lbmmTHxfiMSy0vJcTula7LN50cs5P3wlvm0DDNuB+YmBPO Vx2h+REiLnIiTSzFIzUcuoiNM4sR+0tAiD8EO5Ei/bqfIu8Nirnah+G9vwXeO6NKY0xs33wxZpRI Jhl+2FHWjoW6h1SjXbBLy4ajheTPnLhkO78gLgeEM63D/fCKBOAlGwjHbAGvV/kA/TIUfIDSQr9B fAao0jGTKC7j0CzdXgShwrumgNhDmHwsSsA2zGTYBBDK2R+AM6T6ckaejpDSxcIMMQYWmhDiFRRX a1vNnx1jkhpD/V4WXbjd4uBzO7JrKyZmuIW6g2+baURSKknOp5NLypRLNrKMoDn8M+5uooW81HEK eMYRabrlywT5Y+HH3twa1Mdn+dGaG3ectipKz0tP7lvZFnpTsl5pYU8KcObq9WklLF5tOo4FFprc RyDAV/cezkEh8MBm1DehUXGm6jfTAMINZ+8bpBD1p6+BuIv6M3cbLUCw7N63w+8S+b/bHgaVCCW1 5Dgnv93kiq/Do1l/XKDGz4Fuc+Z5m/rhJCzAHKhCoeABoWAyuJX24OFwJUbOvjDP5mYTVHoLz+8N WMWgC5p4wpnHBVBxwnz5jFC2FmL9xJXr38vsFw8Uzi67DZj52Hi8HFu4tBVrmrgixqwgoFEENXMD ENxh5UgEYCXUAy5GRXyzckrFU/y6HYvBrJGfsq57QgPG37SQlXikM4U3YjGdsSDCpRn0Rp98xbgf GdVxUFleUvviTzV38RAkc601czt/WvpjBsmVgmQE88Fm4ZwM23wCU30ydOnoFH8O061wcuMY04+P eGgLlVeOuAHCVcyuq99ChQIJ6huOuA2h71dbtQtt0+UnmLv0eCOthmfuFBhqSYoNJFf/Vy7+oRKe TLiYY1lk7nwHe6ZV3DheqPUZW723/O9jJvDuNWoKKcAi4FcQQtfYfGxBqL9LkY1rq+fEjGDIrADP fijWGzLHh9yfCNLXc38iiC29gh74RE+UBBqWBLnORcO1KRRVYZifXRqSYcOr3WlGgpATf9R2wVdN UqY2Qsq6zHOuqVycRE8NzYkhvUdI8FJ4sUMKuJI3Ji9scXPLogeDEub/ZW5u/nb1PzifWI5lbmRz dHJlYW0KZW5kb2JqCjYgMCBvYmoKNDYwMgplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDEwIDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5k b2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIKXSAvQ291bnQgMQovUm90 YXRlIDA+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUgo+Pgpl bmRvYmoKMTAgMCBvYmoKPDwvUjgKOCAwIFIvUjcKNyAwIFIvUjkKOSAwIFI+PgplbmRvYmoKOCAw IG9iago8PC9CYXNlRm9udC9Db3VyaWVyL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMT4+CmVuZG9i ago3IDAgb2JqCjw8L0Jhc2VGb250L1RpbWVzLVJvbWFuL1R5cGUvRm9udAovRW5jb2RpbmcgMTEg MCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTEgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9EaWZm ZXJlbmNlc1sKMTQ2L3F1b3RlcmlnaHQvcXVvdGVkYmxsZWZ0L3F1b3RlZGJscmlnaHRdPj4KZW5k b2JqCjkgMCBvYmoKPDwvQmFzZUZvbnQvSGVsdmV0aWNhL1R5cGUvRm9udAovU3VidHlwZS9UeXBl MT4+CmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQTCBHaG9zdHNjcmlwdCA4LjUwKQovQ3Jl YXRpb25EYXRlKEQ6MjAwNzA0MTYwODM1MTcrMDInMDAnKQovTW9kRGF0ZShEOjIwMDcwNDE2MDgz NTE3KzAyJzAwJykKL1RpdGxlKFwzNzZcMzc3XDAwMENcMDAwRlwwMDBQXDAwMCBcMDAwZlwwMDBv XDAwMHJcMDAwIFwwMDBJXDAwMEVcMDAwRVwwMDBFXDAwMCBcMDAwV1wwMDBpXDAwME1cMDAwT1ww MDBCXDAwMCBcMDAwc1wwMDBwXDAwMGVcMDAwY1wwMDBpXDAwMGFcMDAwbFwwMDAgXDAwMHNcMDAw ZVwwMDBzXDAwMHNcMDAwaVwwMDBvXDAwMG5cMDAwIFwwMDBvXDAwMG5cMDAwIFwwMDBzXDAwMGVc MDAwY1wwMDB1XDAwMHJcMDAwaVwwMDB0XDAwMHkpCi9DcmVhdG9yKFwzNzZcMzc3XDAwMFBcMDAw RFwwMDBGXDAwMENcMDAwclwwMDBlXDAwMGFcMDAwdFwwMDBvXDAwMHJcMDAwIFwwMDBWXDAwMGVc MDAwclwwMDBzXDAwMGlcMDAwb1wwMDBuXDAwMCBcMDAwMFwwMDAuXDAwMDlcMDAwLlwwMDAxKQov QXV0aG9yKFwzNzZcMzc3XDAwMHpcMDAwYVwwMDBrKT4+ZW5kb2JqCnhyZWYKMCAxMgowMDAwMDAw MDAwIDY1NTM1IGYgCjAwMDAwMDQ5MTcgMDAwMDAgbiAKMDAwMDAwNTMxMiAwMDAwMCBuIAowMDAw MDA0ODQ5IDAwMDAwIG4gCjAwMDAwMDQ3MDcgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAow MDAwMDA0Njg3IDAwMDAwIG4gCjAwMDAwMDUwNzUgMDAwMDAgbiAKMDAwMDAwNTAxMyAwMDAwMCBu IAowMDAwMDA1MjQ4IDAwMDAwIG4gCjAwMDAwMDQ5NjUgMDAwMDAgbiAKMDAwMDAwNTE1NyAwMDAw MCBuIAp0cmFpbGVyCjw8IC9TaXplIDEyIC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCi9JRCBbPDc4 RUEzN0VDMUYyNEFCMUYxN0I3RDgxNDZFMzk1NkRBPjw3OEVBMzdFQzFGMjRBQjFGMTdCN0Q4MTQ2 RTM5NTZEQT5dCj4+CnN0YXJ0eHJlZgo1ODU0CiUlRU9GCg== --=_3a7pnpgp2qf4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --=_3a7pnpgp2qf4-- From manet-bounces@ietf.org Mon Apr 16 07:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdPWU-0006Bw-Uz; Mon, 16 Apr 2007 07:37:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdPWT-0006Br-FG for manet-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 07:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdPWT-0006Bj-5l for manet@ietf.org; Mon, 16 Apr 2007 07:37:29 -0400 Received: from lnx131.hrz.tu-darmstadt.de ([130.83.174.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdPWR-0007Ks-Ed for manet@ietf.org; Mon, 16 Apr 2007 07:37:29 -0400 Received: from deeds05.deeds.informatik.tu-darmstadt.de (deeds05.deeds.informatik.tu-darmstadt.de [130.83.162.134]) by lnx131.hrz.tu-darmstadt.de (8.13.4/8.12.10) with ESMTP id l3GBWF4C029974; Mon, 16 Apr 2007 13:32:15 +0200 Received: from DEEDS03 (deeds03.deeds.informatik.tu-darmstadt.de [130.83.162.133]) by deeds05.deeds.informatik.tu-darmstadt.de (8.13.1/8.13.1) with ESMTP id l3GBW6mD017919; Mon, 16 Apr 2007 13:32:06 +0200 From: "Abdelmajid Khelil" To: , Date: Mon, 16 Apr 2007 13:32:52 +0200 Message-ID: <006701c7801a$fd39ff10$85a25382@deeds.informatik.tudarmstadt.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceAGvfwrDff0Br/RtOa00iX7nrPiw== X-TUD-HRZ-MailScanner: Found to be clean X-TUD-HRZ-MailScanner-SpamCheck: X-MailScanner-From: khelil@informatik.tu-darmstadt.de X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: wgshi@cs.ualberta.ca, "'Obaidat, Mohammad'" , essia@cs.ucr.edu, zhuhua@hotmail.com, guopingtx@yahoo.com, pescape@unina.it Subject: [manet] CFP SPECTS'07: April 20th is Submission Deadline (Firm) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org "We apologize if you have received multiple copies of this CFP", = SPECTS07 Publicity Committee Submission of Papers (and tutorial proposals): April 20, 2007 (Firm Deadline)=20 Notification of Acceptance: June 1, 2007=20 Final Paper Submission: June 22, 2007=20 Please continue to submit your paper(s) to=20 http://www.softconf.com/scs/SPECTS07/ *************************************************************************= *** Call for Papers 2007 International Symposium on Performance Evaluation of Computer and Telecommunication Systems SPECTS 2007 10Th Anniversary of SPECTS http://eia.udg.es/SPECTS2007/ July 16-18, 2007 San Diego, California, USA This annual international conference is a forum for professionals = involved in performance evaluation of computer and telecommunication systems. Performance evaluation of computer systems and networks has progressed rapidly in the past decade and has begun to approach maturity. = Significant progress has been made in analytic modeling, simulation, and measurement approaches for performance evaluation of computer and telecommunication systems. Topics of interest include, but are not limited to: Networking and Telecommunication Systems =20 =A0Internet Technology Quality of Service (QoS) DiffServ/IntServ MPLS/GMPLS TCP World Wide Web (WWW) Technology =A0=A0Networking Techniques Unicast and Multicast Routing Congestion Admission and Control Switching Techniques Tele-traffic Network Protocols Network Management and Control Network Capacity Planning Network Architecture Evaluation Service and QoS Pricing Security and Authentication =A0=A0Broadband Networks High-Speed Networking Optical Networks =A0=A0Wireless Systems and Networks Satellite Systems UMTS Mobile Networks/Computing Ad-hoc Networks Sensor Networks =A0=A0Multimedia Communications and Applications =20 Computer Systems =A0=A0Distributed Architectures Client/Server Distributed Systems and Agents Parallel and Distributed Computing Massively Parallel Systems Cluster Computing Grid Computing Interconnection Networks =A0=A0Computer Architectures Microprocessors/Microcomputers Memory Systems High Performance I/O Real-time Systems Scheduling Schemes =A0=A0Software Software Performance, Evaluation, and Testing Parallel Algorithms and Languages =A0=A0Electronic Commerce =A0=A0Hardware and Software Monitors =A0=A0High-Performance Computing =A0=A0Information Assurance =A0=A0Reconfigurable Computing =A0=A0Scientific Computing Algorithms =A0=A0Workload and Traffic Characterization=20 Tools, Methodologies, and Applications =20 =A0=A0Parallel and Distributed Simulation =A0=A0Verification and Validation =A0=A0Neural Networks and Fuzzy Logic Applications =A0=A0Performance Optimization, Bounds, and Models =A0=A0Queuing Systems and Networks =A0=A0Scalability Studies =A0=A0Integrated Modeling and Measurement =A0=A0On-Line Performance Adaptation and Tuning =A0=A0Process Algebra-Based Models =A0=A0Mathematical Aspects and Integrated Design of Performance =A0=A0Case Studies=20 =20 General Chair Mohammad S. Obaidat Dept. of Computer Science, Monmouth University W. Long Branch, NJ 07764, = USA Tel +1-732-571-4482 Fax +1-732-263-5202 E-mail: obaidat@monmouth.edu Program Chairs =20 Jose L. Marzo University of Girona, Spain E-mail: joseluis.marzo@udg.es Ljiljana Trajkovic Simon Fraser University, Vancouver, Canada E-mail: ljilja@cs.sfu.ca Helena Szczerbicka University of Hannover, Germany E-mail: hsz@sim.uni-hannover.de Tutorials and Special Sessions Chair S. Dharmaraja Indian Institute of Technology, Delhi, India dharmar@maths.iitd.ernet.in Awards Chair Franco Davoli University of Genoa, Italy E-mail: franco@dist.unige.it Publication Chair Pawel Gburzynski University of Alberta, Canada E-mail: pawel@cs.ualberta.ca Publicity Committee Guoping Zeng, Nortel Networks, USA E-mail: zenggu@nortelnetworks.com=20 Weiguang Shi, University of Alberta, Canada E-mail: wgshi@cs.ualberta.ca Hua Zhu, San Diego Research Center, CA, USA E-mail: hua.zhu@sdrcinc.net Essia H. Elhafsi, University of California-Riverside, USA E-mail: essia@cs.ucr.edu Abdelmajid Khelil, Technical University of Darmstadt, Germany E-mail: khelil@informatik.tu-darmstadt.de Antonio Pescap=E8, University of Napoli "Federico II", Italy E-mail: pescape@unina.it Local Arrangement Chair Richard McDonald RMC, USA rmacd@ramlabs.com Web Masters Antonio Bueno University of Girona, Spain E-mail: jbueno@silver.udg.es Michel J. Chinni U. S. Army TACOM-ARDEC E-mail: mchinni@pica.army.mil Technical Program Committee Abdullah Abonamah, Zayed University, UAE Tricha Anjali, Illinois = Institute of Technology, USA Carlos Belo, Instituto de Telecomunica=E7=F5es-IST, = Portugal Noureddine Boudriga, University of Tunis, Tunisia Maria C. Calzarossa, University of Pavia, Italy Fernando Cerdan, Technical University of Cartagena, Spain Tomaso de Cola, University of Genoa, Italy S. = Dharmaraja, Indian Institute of Technology, Delhi, India Floriano De Rango, D.E.I.S. Dept., University of Calabria, Italy Rachid El Abdouni Khayari, = University of the Armed Forces Munich, Germany Geoffrey Fox, Indiana University, = USA John Fox, Foxband Consultancy, UK Laurent Franck, Telecom Paris, France Sebastia Galmes, Universitat de les Illes Balears, Spain Daniel Garcia, University of Oviedo, Spain Erol Gelenbe, Imperial College, UK Pawel Gburzynski, University of Alberta, Canada Sami Habib, Kuwait University, Kuwait Jarmo Harju, Tampere University of Technology, Finland Xavier Hesselbach-Serra, Universitat Polit=E8cnica de Catalunya, Spain Xiaoyan = Hong, University of California, Los Angeles, USA Carlos Juiz, Universitat de = les Illes Balears, Spain Krishna Kant, Intel, USA Helen Karatza, Aristotle University of Thessalonici, Greece Ulrich Killat, Tech. Univ. of = Hamburg, Germany Michalis E. Kounavis, Intel Research, USA Kevin Kwiat, Air Force Research Laboratory, USA Veronica Lagrange M. Reis, HP Corp., USA S. = Kami Makki, University of Toledo, USA Krzysztof Malinowski, Warsaw Technical University, Poland Marek Malowidzki, Military Communication Institute, Poland Petteri Mannersalo, University of Vaasa, Finland Mario Marchese, University of Genoa, Italy Pascale Minet, INRIA, France Jelena Misic, University of Manitoba, Canada Vojislav Misic, University of Manitoba, Canada Snezana Mitrovic-Minic, Simon Fraser University, Canada Hussein Mouftah, University of Ottawa, Canada Ibrahim Onyuksel, Northern Illinois University, USA Mohamed Ould-Khaoua, University of Glasgow, UK Elena Pagani, Universit=E0 di Milano, Italy = Georgios I. Papadimitriou, Aristotle University, Greece Achille Pattavina, Politecnico di Milano, Italy Krzysztof Pawlikowski, University of Canterbury, New Zealand Gregory D. Peterson, University of Tennessee, = USA Stephen Pink, Lancaster University, UK Michal Pioro, Warsaw University = of Technology, Poland Desa Polajnar, University of Northern British = Columbia, Canada Jernej Polajnar, University of Northern British Columbia, Canada Ramon Puigjaner, Universitat de les Illes Balears, Spain Vicente = Santonja, Technical University of Valencia, Spain Barbara Sorensen, Air Force = Research Laboratory, USA Tatsuya Suda, University of California, Irvine, USA = Phuoc Tran-Gia, University of Wuerzburg, Germany Pere Vila, University of = Girona, Spain Manuel Villen-Altamirano, Telefonica, Spain Bernd E. Wolfinger, Hamburg University, Germany Guoping Zeng, Nortel Networks, USA Michele Zorzi, Universit? di Ferrara, Italy Paper Submission Please submit your complete papers electronically to: http://www.softconf.com/scs/SPECTS07/ Instructions for authors will be posted on the paper submission web = site. Submissions should not exceed 8-10 double-spaced, 8.5x11 inch pages (including figures, tables, and references) in 10 point fonts. Please include 5-10 keywords, complete postal and e-mail address, and fax and = phone numbers of the corresponding author. If you have difficulties with electronic submission, please contact Technical Program Co-Chairs or the Local Arrangement Chair. Extended versions of selected accepted papers at SPECTS 2007 will be considered for possible publication in scholarly journals. Proposals for 1.5 hour tutorials should be sent to Tutorials and Special Sessions Chair. Tutorial abstracts along with keynote speeches=A0 = abstracts will be included in the proceedings of the conference. Proposals for = special sessions should also be submitted to the Tutorials and Special Sessions Chair.=20 Deadlines Submission of Papers (and tutorial proposals): April 20, 2007 (Firm Deadline)=20 Notification of Acceptance: June 1, 2007=20 Final Paper Submission: June 22, 2007 =20 Sponsored by The Society for Modeling and Simulation International Technically Co-Sponsored by the IEEE Systems, Man, and Cybernetics (SMC) Society. ------------------------------------------------------------- Abdelmajid Khelil khelil@informatik.tu-darmstadt.de DEEDS Group Department of Computer Science Hochschulstr. 10 S2:02 E219 D-64289 Darmstadt, GERMANY Tel. +49-6151-16-3414 Fax. +49-6151-16-4310 http://www.deeds.informatik.tu-darmstadt.de/khelil/index.html ------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 16 11:01:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSi5-0003Bu-6k; Mon, 16 Apr 2007 11:01:41 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdSi3-00039F-D0 for manet-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 11:01:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSi3-00038x-3I for manet@ietf.org; Mon, 16 Apr 2007 11:01:39 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdSi1-00021a-Mq for manet@ietf.org; Mon, 16 Apr 2007 11:01:39 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1176735696!10103856!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31714 invoked from network); 16 Apr 2007 15:01:36 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 16 Apr 2007 15:01:36 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3GF1aUg003732; Mon, 16 Apr 2007 08:01:36 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l3GF1ZWt015351; Mon, 16 Apr 2007 10:01:35 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l3GF1Wc5015322; Mon, 16 Apr 2007 10:01:33 -0500 (CDT) Message-ID: <46238FCC.9080203@gmail.com> Date: Mon, 16 Apr 2007 17:01:32 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] FW: Intended status of produced IDs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000733-2, 14/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Alexandru Petrescu , manet@ietf.org, Emmanuel Baccelli X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: > Charlie has pointed out some issues, and there's history. > But at this point, note that this (two protocols) is what > the WG is chartered to produce. Yes indeed, this is what the Charter says: > Using mature components from previous work on experimental reactive and > proactive protocols, the WG will develop two Standards track routing > protocol specifications: > > - Reactive MANET Protocol (RMP) > - Proactive MANET Protocol (PMP) > > If significant commonality between RMRP and PMRP protocol modules is > observed, the WG may decide to go with a converged approach. Remark the bottom phrase hinting eventually at one converged approach. > With regard to one protocol, my view is that such work > would currently be at the pre-experimental stage. Good > for research work (which I would be interested in) but > not for IETF standardisation. I am very surprised it's said so, because I think exactly the opposite: all work that is not able to converge and tends to generate two-or-more protocols for same task is clearly experimental type, visionary and exploratory work, but not 'standard'. This work is useful but is not necessary a standard. The very meaning (IMHO) of the word standard is that there's only one way of doing it. But again, I understand that some protocol can be used in some context only, and with good applicability statements that makes sense. Alex > > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: 06 April 2007 09:42 > To: Emmanuel Baccelli > Cc: manet@ietf.org > Subject: Re: [manet] FW: Intended status of produced IDs > > *** WARNING *** > > This mail has originated outside your organization, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > Emmanuel Baccelli wrote: >> Hi Teco, >> SMF is targeted as experimental. OLSRv2 and DYMO are targeted as >> standards track. > > Why two standards track documents? Why can't it be just one protocol? > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 16 11:08:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSoa-0006Wd-3j; Mon, 16 Apr 2007 11:08:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdSoY-0006WY-Vy for manet-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 11:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSoY-0006WQ-MQ for manet@ietf.org; Mon, 16 Apr 2007 11:08:22 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdSoX-000510-AN for manet@ietf.org; Mon, 16 Apr 2007 11:08:22 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1176736098!13654885!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3037 invoked from network); 16 Apr 2007 15:08:18 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 16 Apr 2007 15:08:18 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3GF8Ip0006371; Mon, 16 Apr 2007 08:08:18 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l3GF8Hx6009131; Mon, 16 Apr 2007 10:08:18 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3GF8G0c009092; Mon, 16 Apr 2007 10:08:16 -0500 (CDT) Message-ID: <46239160.6060402@gmail.com> Date: Mon, 16 Apr 2007 17:08:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [manet] FW: Intended status of produced IDs References: <461BB161.9000000@nokia.com> In-Reply-To: <461BB161.9000000@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000733-2, 14/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "ext Dearlove, Christopher \(UK\)" , manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Charles E. Perkins wrote: > > Hello Chris, > > ext Dearlove, Christopher (UK) wrote: >> With regard to one protocol, my view is that such work would >> currently be at the pre-experimental stage. > What is the difference between experimental and pre-experimental? >> Good for research work (which I would be interested in) but not for >> IETF standardisation. >> > If a good candidate were put forward, implemented by several people, > and shown to work, then I think it would be suitable for > standardization. This has not happened yet. > > However, there is little doubt that a single protocol would be better > for the user community. As it is, I think it will be crucial to > have detailed applicability statements in the protocols. For > instance, as I mentioned in my rushed-through presentation at the > last IETF, the user should be alerted to choose proactive vs. > reactive based on estimates of traffic density, which should be > quantified in the applicabililty statements. I mainly agree. I think further that each one of the two approaches (re-active and pro-active) should have its own applicability statement. The applicability statement should describe the mobility context into which that protocol was prototyped. It should also list one context for which that protocol was not intended. This is a useful perspective, better than the universal applicability perspective. Especially when not many people consider that a unique MANET protocol is possible or necessary. Alex > > Regards, Charlie P. > > > _______________________________________________ manet mailing list > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 16 11:24:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdT48-0004JR-Gg; Mon, 16 Apr 2007 11:24:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdT47-0004JJ-Di for manet-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 11:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdT47-0004JB-4B for manet@ietf.org; Mon, 16 Apr 2007 11:24:27 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdT45-0003wE-Oc for manet@ietf.org; Mon, 16 Apr 2007 11:24:27 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3GFOOZI027474 for ; Mon, 16 Apr 2007 16:24:24 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3GFOOw9013145 for ; Mon, 16 Apr 2007 16:24:24 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 16 Apr 2007 16:24:24 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 16 Apr 2007 16:21:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] FW: Intended status of produced IDs Date: Mon, 16 Apr 2007 16:16:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] FW: Intended status of produced IDs Thread-Index: AceAODPtQitbbJc7R8iJDl1x0F/zEQAAYT+Q From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 16 Apr 2007 15:21:00.0183 (UTC) FILETIME=[D6B28270:01C7803A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Emmanuel Baccelli , manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >Yes indeed, this is what the Charter says: >> Using mature components from previous work on experimental reactive and >> proactive protocols, the WG will develop two Standards track routing >> protocol specifications: >=20 >> - Reactive MANET Protocol (RMP) >> - Proactive MANET Protocol (PMP) >=20 >> If significant commonality between RMRP and PMRP protocol modules is > observed, the WG may decide to go with a converged approach. > Remark the bottom phrase hinting eventually at one converged approach. The bottom phrase hinting at POSSIBLE converged approach. The work over the last few years has not done so, and is in a position to go with two protocols. It is not in a position to go with one, and will not be in an acceptable timescale. > I am very surprised it's said so, because I think exactly the opposite:=20 > all work that is not able to converge and tends to generate two-or-more=20 > protocols for same task is clearly experimental type, visionary and=20 > exploratory work, but not 'standard'. This work is useful but is not=20 > necessary a standard. The very meaning (IMHO) of the word standard is > that there's only one way of doing it. Just to name one example, there is more than one standard IP routing protocol outside MANETs. There are many other things that have multiple competing standards. MAC/PHY layers, mobile phone systems, computer languages, the list is endless. I'm actually struggling to think of a major case where we don't - we even have IPv4 and IPv6. In short, I think that argument fails. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 16 11:40:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTJk-000144-L4; Mon, 16 Apr 2007 11:40:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdTJi-0000yv-Bz for manet-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 11:40:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTJi-0000yk-2L for manet@ietf.org; Mon, 16 Apr 2007 11:40:34 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdTJh-0002Xd-OG for manet@ietf.org; Mon, 16 Apr 2007 11:40:34 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1176738032!17614287!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 10215 invoked from network); 16 Apr 2007 15:40:32 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-128.messagelabs.com with SMTP; 16 Apr 2007 15:40:32 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3GFeVlT018975; Mon, 16 Apr 2007 08:40:32 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l3GFeVnU004473; Mon, 16 Apr 2007 10:40:31 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l3GFeScl004454; Mon, 16 Apr 2007 10:40:29 -0500 (CDT) Message-ID: <462398EC.8030703@gmail.com> Date: Mon, 16 Apr 2007 17:40:28 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] FW: Intended status of produced IDs References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000733-2, 14/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Alexandru Petrescu , manet@ietf.org, Emmanuel Baccelli X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: >> Yes indeed, this is what the Charter says: >>> Using mature components from previous work on experimental >>> reactive > and >>> proactive protocols, the WG will develop two Standards track >>> routing protocol specifications: - Reactive MANET Protocol (RMP) >>> - Proactive MANET Protocol (PMP) If significant commonality >>> between RMRP and PMRP protocol modules is >> observed, the WG may decide to go with a converged approach. > >> Remark the bottom phrase hinting eventually at one converged >> approach. > > The bottom phrase hinting at POSSIBLE converged approach. The work > over the last few years has not done so, and is in a position to go > with two protocols. It is not in a position to go with one, and will > not be in an acceptable timescale. Ok. >> I am very surprised it's said so, because I think exactly the > opposite: >> all work that is not able to converge and tends to generate > two-or-more >> protocols for same task is clearly experimental type, visionary and >> exploratory work, but not 'standard'. This work is useful but is >> not necessary a standard. The very meaning (IMHO) of the word >> standard is > >> that there's only one way of doing it. > > Just to name one example, there is more than one standard IP routing > protocol outside MANETs. I thought it would be said so, ok, but remark the 3 (RIP, OSPF, BGP, not any other StdsTrack) all have their companion applicability statement RFCs, so one doesn't deploy RIP on a inter-ISP network. > There are many other things that have multiple competing standards. > MAC/PHY layers, mobile phone systems, computer languages, the list is > endless. I'm actually struggling to think of a major case where we > don't - we even have IPv4 and IPv6. Laughing :-) that looks so true at first sight. Still there's only one MAC for LAN, only one PHY for a frequency and generally one computer language for a application type. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 16 15:51:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXDh-000886-Ns; Mon, 16 Apr 2007 15:50:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdXDd-00084e-Nf for manet-confirm+ok@megatron.ietf.org; Mon, 16 Apr 2007 15:50:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXDd-00084B-Bo; Mon, 16 Apr 2007 15:50:33 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HdXDd-0003vr-2I; Mon, 16 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B0702175BD; Mon, 16 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HdXD8-0000Ku-FZ; Mon, 16 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 16 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --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 : MANET IANA Needs Author(s) : I. Chakeres Filename : draft-ietf-manet-iana-01.txt Pages : 7 Date : 2007-4-16 This document enumerates IANA assignments for immediate use in MANET. Specifically, a UDP port, two link-local multicast group addresses (IPv4 & IPv6), and two site-local multicast group addresses (IPv4 & IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iana-01.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-iana-01.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: <2007-4-16144907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-iana-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-iana-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-16144907.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Tue Apr 17 02:53:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdhZO-00042w-Jv; Tue, 17 Apr 2007 02:53:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdhZM-00042o-Qd for manet-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 02:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdhZJ-00042X-2A for manet@ietf.org; Tue, 17 Apr 2007 02:53:37 -0400 Received: from web27605.mail.ukl.yahoo.com ([217.146.177.224]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdhZH-0007Sk-Le for manet@ietf.org; Tue, 17 Apr 2007 02:53:37 -0400 Received: (qmail 94482 invoked by uid 60001); 17 Apr 2007 06:53:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=azkL3HkhpKCAQ3XU+sv/h/vg+j0C5JkM1CjZVQoGi4jMPgRimv309iQJvTk/uf59+VqFLQVAV+5A3RzuH3HcCMQ3TdHOXFwwMVjXUyKFGqyKqzpb4QkpgyRjixH4S3qFUEWBmZ2Mdqg9WYDqaOBkbCxJ7viIzplcbUCjepRC0Oo= ; Message-ID: <20070417065335.94480.qmail@web27605.mail.ukl.yahoo.com> X-YMail-OSG: 5OG5dyEVM1lE_uzANCEA8Yjz_NdXvfHe4qfMFn1TAHDh.GwcQ1ExsJVqDhz95VSyiA-- Received: from [193.95.37.75] by web27605.mail.ukl.yahoo.com via HTTP; Tue, 17 Apr 2007 08:53:35 CEST Date: Tue, 17 Apr 2007 08:53:35 +0200 (CEST) From: nadia mansouri To: manet MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [manet] problem in implementation of AOMDV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1949365431==" Errors-To: manet-bounces@ietf.org --===============1949365431== Content-Type: multipart/alternative; boundary="0-268836115-1176792815=:94034" Content-Transfer-Encoding: 8bit --0-268836115-1176792815=:94034 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I implement AOMDV over glomosim, but the problem is that when I run ./glomosim config.in the result of the simulation of AOMDV is the same when I run AODV. I dont know what is the problem, is it in the implementation, or ... what can i do? it is urgent! Thanks in advance --------------------------------- Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-268836115-1176792815=:94034 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello,
I implement AOMDV over glomosim, but the problem is that when I run
  ./glomosim  config.in  the result of the simulation of AOMDV is the same when I run AODV.
I dont know what is the problem, is it in the implementation, or ...
what can i do? it is urgent!
Thanks in advance

Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-268836115-1176792815=:94034-- --===============1949365431== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1949365431==-- From manet-bounces@ietf.org Tue Apr 17 03:54:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdiVm-0007pP-Jc; Tue, 17 Apr 2007 03:54:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdiVk-0007pG-BD for manet-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 03:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdiVj-0007p7-IB for manet@ietf.org; Tue, 17 Apr 2007 03:53:59 -0400 Received: from web26309.mail.ukl.yahoo.com ([217.146.176.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdiVh-0000VU-Io for manet@ietf.org; Tue, 17 Apr 2007 03:53:59 -0400 Received: (qmail 42337 invoked by uid 60001); 17 Apr 2007 07:53:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.es; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=QUNksm6DSLwqQt9rsYDBGuMWnc1FzXC0mxriXM9EJF5qwRNKJXy1vZLXxS5LDb1/Wkm8rYYANFHIZ1405m4eBwH3dSQZA/pQyXV8dW3z+C4rHr7erqQIJ1bv4TFOcvzksJyHdNM/xirSw7rpHlqZZ7RDeZGWBL6h7oIw+qHT760=; X-YMail-OSG: f7LoKhcVM1nfTtiJrgO6U2aF80l5FLY2pTiESpAimLZGS.Tz6tvYbScI5uSjdRlu1JUPv6kmh.tJb9ObOXYPragzm1ugzn.TcW1TDbP8BrX1v8cIj1_uhr6Z628- Received: from [193.147.143.11] by web26309.mail.ukl.yahoo.com via HTTP; Tue, 17 Apr 2007 09:53:56 CEST Date: Tue, 17 Apr 2007 09:53:56 +0200 (CEST) From: Miguel Sepulcre Ribes To: manet@ietf.org In-Reply-To: <005701c77f9c$e505d960$48d05ba5@ECE149> MIME-Version: 1.0 Message-ID: <964641.42200.qm@web26309.mail.ukl.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [manet] Extension Deadline - IEEE International Symposium on Wireless Vehicular Communications (IEEE WiVeC) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0441651639==" Errors-To: manet-bounces@ietf.org --===============0441651639== Content-Type: multipart/alternative; boundary="0-1562202781-1176796436=:42200" Content-Transfer-Encoding: 8bit --0-1562202781-1176796436=:42200 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit [Apologies if you receive multiple copies of this CFP.] DEADLINE EXTENDED: 23rd April ---------------------------------------------------------------------------- 1st IEEE International Symposium on Wireless Vehicular Communications (IEEE WiVeC’07) 30th September - 1st October 2007, Baltimore, USA Renaissance Harborplace Hotel, 202 East Pratt Street, Baltimore, MD, USA, 21202 http://www.ieee-wivec.org Sponsored by the IEEE Vehicular Technology Society (VTS) ---------------------------------------------------------------------------- Wireless vehicular communications has been identified as a key technology for increasing road safety and transport efficiency, and providing Internet access on the move to ensure wireless ubiquitous connectivity. The potential of this technology has been acknowledged with the establishment of ambitious research programs worldwide, such as the European eSafety initiative, the US programs derived from the Intelligent Vehicle Initiative and the Japanese InternetITS and AHS programs. The IEEE Vehicular Technology Society (VTS) currently covers through its areas of interest (Mobile Radio, Transportation Systems and Automotive Electronics) all technical aspects needed to make wireless vehicular communications a reality. As a result, the IEEE VTS society has decided to establish a technical symposium on wireless vehicular communications, with the first issues planned to be co-located with the reputed IEEE VTC conferences. The IEEE International Symposium on Wireless Vehicular Communications (WiVeC) will cover all vehicular wireless communications aspects of Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I) and Vehicle-to-Person (V2P) communications, including implications on transport efficiency and safety, implications on automotive electronics, liability issues, standardizations efforts and spectrum assignment. The first IEEE WiVeC symposium will be collocated with the 66th IEEE Vehicular Technology Conference and will take place at the Renaissance Harborplace Hotel in Baltimore on the 30th September and 1st October 2007. Combined registrations packages will be offered to attendees to WiVeC and VTC conferences. Accepted papers will appear in the conference proceedings published by the IEEE and will be included in the IEEE Xplore digital library. A selection of the best five WiVeC papers will be published in a special issue of the IEEE Vehicular Technology Magazine www.ieeevtm.org. Authors are encouraged to submit full papers (a maximum of five pages) through the conference web site. Topics of interest ------------------ The WiVec Symposium seeks original papers - not published or currently under review for another workshop, conference, or journal - in the area of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-person (V2P) wireless communications. Areas of interest include, but are not limited to: * RF technologies, antenna design, physical layer and propagation models. * Radio resource management and interference management. * Spectrum assignment and EMC regulations. * Architecture, networking protocols (including ad-hoc, routing, data dissemination, etc) and their evalutation. * QoS and cross-layer optimization design. * Communications systems and technologies. * Testbeds and simulation platforms. * Interworking with sensor network technologies. * In-car electronics and embedded integration of wireless vehicular communications. * Roadside infrastructure. * Mobility management, mobility and vehicle traffic models. * Digital maps and location technologies. * Decision and control issues. * Human-Machine Interface. * Applications (Ecall, toll collection, traffic information, wireless diagnosis etc.). * Security, liability and privacy. * Standards development, business models, policies (e.g., Cooperative aspects of vehicular communication). * Assessment of impact on transport efficiency and safety. * Scalability issues in metropolitan-wide vehicular networks. Submissions ----------- Authors are encouraged to submit full length papers (maximum 5 pages) following the submission guidelines provided at www.ieee-wivec.org Accepted papers will appear in the conference proceedings published by the IEEE and will be included in the IEEE Xplore digital library. A selection of the best five WiVeC papers will be published in a special issue of the IEEE Vehicular Technology Magazine (www.ieeevtm.org). Organizing Committee -------------------- General Co-Chairs: - Mario Gerla, University of California (UCLA), USA - Javier Gozalvez, University Miguel Hernandez, Spain Technical Program Co-Chairs: - Fan Bai, General Motors, USA - Hannes Hartenstein, Karlsruhe University, Germany Speakers Chair - Timo Kosch, BMW, Germany Panel Chair - Jim Misener, PATH Berkeley, USA Finance Chair: - James Irvine, University of Strathclyde, UK Important Dates --------------- Paper Submission Deadline, 23 April 2007 Notification of acceptance, 22 May 2007 Camera-ready papers due, 8 June 2007 --------------------------------- LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com --0-1562202781-1176796436=:42200 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit [Apologies if you receive multiple copies of this CFP.]

DEADLINE EXTENDED: 23rd April

----------------------------------------------------------------------------
1st IEEE International Symposium on Wireless Vehicular Communications (IEEE WiVeC’07) 30th September - 1st October 2007, Baltimore, USA Renaissance Harborplace Hotel, 202 East Pratt Street, Baltimore, MD, USA, 21202

http://www.ieee-wivec.org

Sponsored by the IEEE Vehicular Technology Society (VTS)
----------------------------------------------------------------------------

Wireless vehicular communications has been identified as a key technology for increasing road safety and transport efficiency, and providing Internet access on the move to ensure wireless ubiquitous connectivity. The potential of this technology has been acknowledged with the establishment of ambitious research programs worldwide, such as the European eSafety initiative, the US programs derived from the Intelligent Vehicle Initiative and the Japanese InternetITS and AHS programs.

The IEEE Vehicular Technology Society (VTS) currently covers through its areas of interest (Mobile Radio, Transportation Systems and Automotive Electronics) all technical aspects needed to make wireless vehicular communications a reality. As a result, the IEEE VTS society has decided to establish a technical symposium on wireless vehicular communications, with the first issues planned to be co-located with the reputed IEEE VTC conferences.

The IEEE International Symposium on Wireless Vehicular Communications (WiVeC) will cover all vehicular wireless communications aspects of Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I) and Vehicle-to-Person (V2P) communications, including implications on transport efficiency and safety, implications on automotive electronics, liability issues, standardizations efforts and spectrum assignment.

The first IEEE WiVeC symposium will be collocated with the 66th IEEE Vehicular Technology Conference and will take place at the Renaissance Harborplace Hotel in Baltimore on the 30th September and 1st October 2007. Combined registrations packages will be offered to attendees to WiVeC and VTC conferences.

Accepted papers will appear in the conference proceedings published by the IEEE and will be included in the IEEE Xplore digital library. A selection of the best five WiVeC papers will be published in a special issue of the IEEE Vehicular Technology Magazine www.ieeevtm.org. Authors are encouraged to submit full papers (a maximum of five pages) through the conference web site.


Topics of interest
------------------
The WiVec Symposium seeks original papers - not published or currently under review for another workshop, conference, or journal - in the area of vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-person (V2P) wireless communications. Areas of interest include, but are not limited to:

* RF technologies, antenna design, physical layer and propagation models.
* Radio resource management and interference management.
* Spectrum assignment and EMC regulations.
* Architecture, networking protocols (including ad-hoc, routing, data dissemination, etc) and their evalutation.
* QoS and cross-layer optimization design.
* Communications systems and technologies.
* Testbeds and simulation platforms.
* Interworking with sensor network technologies.
* In-car electronics and embedded integration of wireless vehicular communications.
* Roadside infrastructure.
* Mobility management, mobility and vehicle traffic models.
* Digital maps and location technologies.
* Decision and control issues.
* Human-Machine Interface.
* Applications (Ecall, toll collection, traffic information, wireless diagnosis etc.).
* Security, liability and privacy.
* Standards development, business models, policies (e.g., Cooperative aspects of vehicular communication).
* Assessment of impact on transport efficiency and safety.
* Scalability issues in metropolitan-wide vehicular networks.


Submissions
-----------
Authors are encouraged to submit full length papers (maximum 5 pages) following the submission guidelines provided at www.ieee-wivec.org Accepted papers will appear in the conference proceedings published by the IEEE and will be included in the IEEE Xplore digital library.

A selection of the best five WiVeC papers will be published in a special issue of the IEEE Vehicular Technology Magazine (www.ieeevtm.org).


Organizing Committee
--------------------
General Co-Chairs:
- Mario Gerla, University of California (UCLA), USA
- Javier Gozalvez, University Miguel Hernandez, Spain

Technical Program Co-Chairs:
- Fan Bai, General Motors, USA
- Hannes Hartenstein, Karlsruhe University, Germany

Speakers Chair
- Timo Kosch, BMW, Germany

Panel Chair
- Jim Misener, PATH Berkeley, USA

Finance Chair:
- James Irvine, University of Strathclyde, UK

   
Important Dates
---------------
Paper Submission Deadline, 23 April 2007 Notification of acceptance, 22 May 2007 Camera-ready papers due, 8 June 2007



LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com --0-1562202781-1176796436=:42200-- --===============0441651639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0441651639==-- From manet-bounces@ietf.org Tue Apr 17 05:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdjfU-00010z-Uf; Tue, 17 Apr 2007 05:08:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdjfT-00010q-5K for manet-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 05:08:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdjfS-00010i-Qv for manet@ietf.org; Tue, 17 Apr 2007 05:08:06 -0400 Received: from web50510.mail.re2.yahoo.com ([206.190.38.247]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdjfQ-0004aK-9s for manet@ietf.org; Tue, 17 Apr 2007 05:08:06 -0400 Received: (qmail 75897 invoked by uid 60001); 17 Apr 2007 09:08:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=tayMqoSK+h7UShhTzJaaYaNxOrbiYwvorI2UdOJKP/QBOsbdyS1NgYpsPrLcESaegUwa0UnCkbHcK7TZpbZFxmuwGQzBRvd+FbXj8nF8rYN4gRyRIm2FgL3khCbtJ03tuS/pj1HQLoN1l0Q2z94cljixDIcSOUSQUMcOnnOgUIU=; X-YMail-OSG: UGpLVPgVM1mcRlojxGvEF9.NxSCZE2ScPcY0eJ9XguVkJRW.5Ir6xwdHKuTQv3hQNg2xrfZk9D79aXfPYbb4Ded07jYJVjd1vWi4 Received: from [59.92.33.152] by web50510.mail.re2.yahoo.com via HTTP; Tue, 17 Apr 2007 02:08:03 PDT Date: Tue, 17 Apr 2007 02:08:03 -0700 (PDT) From: Evelyn Stephen Subject: [manet] problem in implementation of ODMRP To: manet MIME-Version: 1.0 Message-ID: <734655.75764.qm@web50510.mail.re2.yahoo.com> X-Spam-Score: 1.6 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1877309487==" Errors-To: manet-bounces@ietf.org --===============1877309487== Content-Type: multipart/alternative; boundary="0-1037552712-1176800883=:75764" Content-Transfer-Encoding: 8bit --0-1037552712-1176800883=:75764 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, I implemented ODMRP in glomosim, but the problem is that when I run ./glomosim/bin/config.in .In the result of the simulation of ODMRP, only the source node has the data and it is not transfered to destination address. I dont know what is the problem, is it in the implementation, or ... what can i do? Thanks in advance --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. --0-1037552712-1176800883=:75764 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hello,
I implemented ODMRP in glomosim, but the problem is that when I run
  ./glomosim/bin/config.in .In  the result of the simulation of ODMRP, only the source node has the data and it is not transfered to destination address.
I dont know what is the problem, is it in the implementation, or ...
what can i do?

Thanks in advance

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-1037552712-1176800883=:75764-- --===============1877309487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1877309487==-- From manet-bounces@ietf.org Tue Apr 17 05:18:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdjpa-0008AW-LD; Tue, 17 Apr 2007 05:18:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdjpZ-0008AK-Pe for manet-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 05:18:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdjpZ-0008AB-De for manet@ietf.org; Tue, 17 Apr 2007 05:18:33 -0400 Received: from web27602.mail.ukl.yahoo.com ([217.146.177.221]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdjpY-0007el-1K for manet@ietf.org; Tue, 17 Apr 2007 05:18:33 -0400 Received: (qmail 11557 invoked by uid 60001); 17 Apr 2007 09:18:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=DTh3X1ahr4ab1Ylf1yfH1BaMZSfYD8N41UZt8soevEeao2kbgr3k4GwrkS5fbg0qsfINIChvds/lhZeEljW0xy2JltGp3dL92xERatl7ll0jzwKiArAfK/Z4YefScQgUHjhZ9EGMzBakBekk+vOjjV34yHSKpAgegoO5UO+kevw=; X-YMail-OSG: YAOuGOMVM1n0tRBrW0YZvyirQP6Z58dzeVXs5dymQcHqZXeOkYnqo_mKrty5wO7rLVqrh1mu7FrDo8x3ndSLglsptH3j1m6I15Slml7uVZnZOD0so5xaHrv5RNw- Received: from [193.95.37.75] by web27602.mail.ukl.yahoo.com via HTTP; Tue, 17 Apr 2007 11:18:31 CEST Date: Tue, 17 Apr 2007 11:18:31 +0200 (CEST) From: nadia mansouri To: manet MIME-Version: 1.0 Message-ID: <357159.9509.qm@web27602.mail.ukl.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [manet] aodvm code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0529560845==" Errors-To: manet-bounces@ietf.org --===============0529560845== Content-Type: multipart/alternative; boundary="0-1867217295-1176801511=:9509" Content-Transfer-Encoding: 8bit --0-1867217295-1176801511=:9509 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello, If anyone know where can i found the code of AODVM in Glomosim help me thanks in advance. --------------------------------- Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-1867217295-1176801511=:9509 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello,
If anyone know where can i found the code of AODVM in Glomosim help me
thanks in advance.

Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-1867217295-1176801511=:9509-- --===============0529560845== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0529560845==-- From manet-bounces@ietf.org Tue Apr 17 05:25:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdjvu-0004EW-7s; Tue, 17 Apr 2007 05:25:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hdjvs-0004DA-BW for manet-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 05:25:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdjvs-0004D2-0c for manet@ietf.org; Tue, 17 Apr 2007 05:25:04 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdjvp-0000p5-NV for manet@ietf.org; Tue, 17 Apr 2007 05:25:03 -0400 Received: by wx-out-0506.google.com with SMTP id h31so2075928wxd for ; Tue, 17 Apr 2007 02:25:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=TFyplVsHFIRTYCHGDtAC0SLcxjm2j5e+5aUuE0CWNooSkz6wSFkoPRYaILny1fDS4weVRPfwClSzx3Wuecd4IAxYLwQA0HJ10Z42jNnrYPdssb8vN3FpMkKpiSVxRM29Attj0GvbjqKUksOizZZmTgTks3H+PW1AxrGvmQBwJj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=D6wtjXwFpfiVsuJL63nigtq+Mt8B7ep7pFCADaGlEfbjMbFjQakdz7tuyCsX/qrvwKaGKYT84KuH735hWFwIymuaXwIh0njnc3aXcy8WlB2kDaFdM842qVT1rlEIfdl8GcIc4yUBo+dIDtLT/cQq1B0rreq60ly233uTDSvF3hs= Received: by 10.78.138.6 with SMTP id l6mr1260692hud.1176801900463; Tue, 17 Apr 2007 02:25:00 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Tue, 17 Apr 2007 02:25:00 -0700 (PDT) Message-ID: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> Date: Tue, 17 Apr 2007 14:55:00 +0530 From: "Ian Chakeres" To: manet Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The document includes suggestions by Bill Fenner regarding TBD numbering, but otherwise has not changed. I would like to issue a WG last call on this document. If you have any comments, please provide them before May 1st (two weeks). Thanks. Ian Chakeres On 4/17/07, 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 : MANET IANA Needs > Author(s) : I. Chakeres > Filename : draft-ietf-manet-iana-01.txt > Pages : 7 > Date : 2007-4-16 > > This document enumerates IANA assignments for immediate use in MANET. > Specifically, a UDP port, two link-local multicast group addresses > (IPv4 & IPv6), and two site-local multicast group addresses (IPv4 & > IPv6). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-iana-01.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-iana-01.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. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 17 14:34:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsVb-0005cc-SR; Tue, 17 Apr 2007 14:34:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdsVa-0005Zp-9B for manet-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 14:34:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdsVZ-0005Zg-Vj for manet@ietf.org; Tue, 17 Apr 2007 14:34:29 -0400 Received: from web32703.mail.mud.yahoo.com ([68.142.207.247]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdsVX-0000OV-6r for manet@ietf.org; Tue, 17 Apr 2007 14:34:29 -0400 Received: (qmail 21450 invoked by uid 60001); 17 Apr 2007 18:34:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=YhgggS7SlpW4DFy5dF62RVaKZUhx9qM6VFRMuXtkFOfKyGgbV5l5qyhdL8bluNwwi+ELkw6OUL63ok1PAiy+k5j3sMc60gCmIQ8S+2TosU3V4IYHrpt3WGre2PZsEY1s3RqcCXHOkSFcH4GcGxlEzjAT4kUNFy8BalYs8ycPvyU=; X-YMail-OSG: xMrUBi8VM1nFUgf74snDGFrKm.zV42Fp5k54s2e4YkUN4yql4lcCqPLQBonBe9pxyLxXL8ApJ0oK66ZLrYG9M2RFwlwiqaJkJMGA2XyeL3YkP6nmXtpfZ2Zpn7DEmA-- Received: from [80.191.197.111] by web32703.mail.mud.yahoo.com via HTTP; Tue, 17 Apr 2007 11:34:26 PDT Date: Tue, 17 Apr 2007 11:34:26 -0700 (PDT) From: hamid reza To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <589646.20657.qm@web32703.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [manet] CS and EIFS Triggering X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear all, I m sorry if I give your time. I have Two questions. Can you help me? 1- How Carrier Sensing(CS) works in below situation? Suppose node A sends a packet to Node B and Node B in transmission range of node A . Does Node B sense Node A after full reception of a packet or node B can sense activity of Node A During this transmission? 2- Suppose a packet trigger EIFS in SIFS duration of a Node. Does EIFS turn on related timer after Expiring SIFS or as soon as Recognizing error in FCS? I m appreciating that hear from you as soon as possible. Best Regards Hamid Reza __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 17 16:56:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdujJ-0003CU-UD; Tue, 17 Apr 2007 16:56:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HdujH-0003CO-W0 for manet-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 16:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdujH-0003CG-MT for manet@ietf.org; Tue, 17 Apr 2007 16:56:47 -0400 Received: from ml.univ-avignon.fr ([195.83.163.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdujG-0006QA-3o for manet@ietf.org; Tue, 17 Apr 2007 16:56:47 -0400 Received: by ml.univ-avignon.fr (Postfix, from userid 33) id CD0CC105436; Tue, 17 Apr 2007 22:56:44 +0200 (CEST) Received: from abo-209-71-69.avi.modulonet.fr (abo-209-71-69.avi.modulonet.fr [85.69.71.209]) by webmail.univ-avignon.fr (Horde MIME library) with HTTP for ; Tue, 17 Apr 2007 22:56:44 +0200 Message-ID: <20070417225644.dhnt4pq5og008ww0@webmail.univ-avignon.fr> Date: Tue, 17 Apr 2007 22:56:44 +0200 From: rachedi To: manet@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_5ikxh0yma1kw" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Subject: [manet] CFP of special session on security X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org This message is in MIME format. --=_5ikxh0yma1kw Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Apologies if you receive multiple postings for this =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CFP for IEEE WiMOB=922007 special session on security in Mobile Ad hoc Netw= orks (MANET) and wireless sensor networks (WSN). The session is part of the 3rd IEEE International Conference on Wireless an= d Mobile Computing, Networking and Communications =93WiMob 2007=94 http://www.gel.usherbrooke.ca/WiMob2007/, which will take place in Crowne P= laza Hotel, White Plains, New York, USA, from October 8-10, 2007. Motivations: Mobile ad hoc networks are able to provide fast and efficient network deplo= yment capabilities in a wide variety of scenarios where a fixed networking infrastructure is not possible. Wireless Sensor Networks (WSNs) are relatively low cost to be deployed and = to be used in many promising applications, such as biomedical sensor monitoring (= e.g., cardiac patient monitoring), habitat monitoring (e.g., animal tracking), we= ather monitoring (temperature, humidity, etc.), low-performance seismic sensing, = and natural disaster detection/monitoring (e.g., flooding and fire). These types of networks offer new challenging security problems due primari= ly to their wireless network interface, allowing easy eavesdropping and injection= of messages, and to their distributed infrastructure-less topology. Unfortunat= ely, the security in mobile ad hoc networks has been analyzed individually at different layers of the communication protocols. Furthermore, many proposed security solutions contain strong assumptions or they didn=92t well adapt t= o the characteristics of MANETs or WSNs. That=92s way the future proposed solutio= n must take into account the resource constraints, (eventually) mobility and to ch= oose the cross-layer approach to design the security mechanism. Scope of Contributions for MANET and WSN (include but are not limited to th= e following): - Cross-Layer design of secure architecture - Novel Distributed architectures and security schemes - Key management and key distribution - Secure routing and communication protocols - Security and trust modeling - Monitoring mechanisms and Distributed Intrusion Detection Systems - Trust establishment and trust management - Secure localization - Secure time synchronization - Location privacy - etc. Authors are invited to submit a complete technical paper of their original work. Maximum length for submissions is 8 double column pages in IEEE forma= t. The preferred submission format is PDF. Session Chair: Abderrahim Benslimane, LIA Avignon University Session Co-chair: Chadi Assi, CIISE Concordia University Submissions should be sent attached by email to the session chair at: abderrahim.benslimane@univ-avignon.fr Important Dates : Manuscript Submission Due: May 5, 2007 Acceptance Notification: June 5, 2007 Final Manuscript Due: June 15, 2007 --=_5ikxh0yma1kw Content-Type: application/pdf; name="CFP for IEEE WiMOB special session on security.pdf" Content-Disposition: attachment; filename="CFP for IEEE WiMOB special session on security.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nM1dWXccxRV+n18xb8zkMO3eF97YQkiI2cTJyTF5GMsSNrItISQb52eQ/ODU Xl/Vvbd7RpJPgAM0Pbdrvct3lyr/si6Lql6X+m//cPpqVa6/UP/8tPplNRaN/sv8gM+nr9afnKwe fTes1Vcn56uymKaprcxv1Xooi3E99GXRrk9erTbr7cnPq6pR706+Wp386cnm0+2uKZqp6/rNn7dd 0Q9d022+2e5a1UOpXq7V73Wp/mfYnG/rYiy7zeV2Vxb11E5Du7l27zRZo8jaZvPltlbvKvXj59uy 6NuyrHv1uJuKpu/GEd9C4//Y7vqi68t62LzY7uqi6rtu3Px9u6uKrtaj+3qrnoa2rTefbPuir6pu 2Pxue++rTW3HpL7pNqXwPMAz9Pyr7qOup2nYXAHF2bYp1BxO7X/UmCo1qKFsNnv75qUdZdvANDrX WFPV/vv4Ij69iJ9eQo+vufGF5W4qNXWBhPTqRn0L5Han2mbC7m/itN5t/3Xy11U9DUXZdYp1Tp6t nmAf8JUwCrdZbdMm03oKz9AIrJ8bNDT1sdnsrm83z/i+nsNr7OyUNPU4NGW6adSjnrbv+635uamm ZJ3jYl3AW7fMZa2Holdr55drZ0VKL9mPGycSwLtuOmqVH4cnEIOT+Pjj1n5djXoOldIEnWJRx3K4 7tm6KMJ26KbGzUeLCYjRdZCTs4R59W8JnxopgEdsWb/W0+8m/w2OBz66JFyne/ZNDVPKxq6tmzii OAXaEmwJdOu2xK6XenR7oImdXqnaafO91WpVNQBTwIIXdoR9N1Ruf7WChM15Doov8mw9KUZT/AMr MLumsC8z0u9bBep0XzwB6izHJ3HRYVXhE+z2HPmtKRWBWj/47DndKmipYbc6l1nX6pfbShuGqksN A/eov6q0/PqPlMDgAt0Q5RHZ47Xhg6aswnoA9QGql9XvdsKjMpdGSw5t0Y6115JSS+dhTGSQUYL8 WJ3myteYZ5JqHJAEmBwmeL3dDUWt2s7FHpaNM0/Q8LLi8ZRU+RuV+RSeJeWvxl73TavXue5Kq1fd AoNeBaCCAOSVbqntNVS5gte38AzcDNL0Gih+2k7FoHis3nwIWgo11uOgk47TV1ocUF+lA/B7H/sn Sr+q60W9rwdIl8eQ2OXppil5vBUYFnbIseOdJChhpaBS/2Ob4nnVsU81TiJ2wLYc3Bv6JkN7RjrH SeNDL50I+/5rxlDWrVPwn5+svl1ZoPzdF+7h+p5gu58qC7afJAYDGAYekWc/iq8fsY9vA3jInzTz FcANkaGowUe6W7JrxrwwSj+y89PIt/HlZXzppbNRm3NBG8LuUyaDmc56A/0wikxyrB/waFsPY+CE av1i1U3lWi2odoXW1Vg26259fbY6v7cjVo+DmgZyx4cJ3thVXanRld9bhU2ez4rm81Q26Oe8vk3t mv8KBNztBrN1QI+o4yX5ltgy/5nsRHiKT41zVzYI+HCz4/QoiLRyHZr6JuI9OsR/W7OjwOyejPIv rE9AMEfdJhb1QyVzowLKDdqxqld2bEQ75ll7HBP18IJVD3EFg8yAbw5CvQ9uambfctE+2MBFxYJk /zzC1jFdGV7/IbQBiPzj8FIa4XnoJFE7manra8Uw2NvXgWFOiS2TtMhZYI7IhNjmCDBsFyiqqANL ugxezHMbxqgqY8T6saiqkTNiXoNqp8z7oY468BkN9IA7iviJB0dvgGJPAA/1YAyhwHHerPnBzgzm KS8Q1FulvvEz+BR+XY4TeMq7+6Q532d+mm5/6gHOEW+czgaZ8aWL0VQdQ39DtiIoVEdxRcabq9Q3 wM2goJ/RBQEXO/o2+9yTuEktjPtgH2QqhbOG2ZXiHcoRok7+K9dx7O2cC2OdJtoP3BvBZ4QO5G2P 0SGtPC5z1JNHIqBNZuWumA1V6A1afbetNGbrawTq8jSMOIUeT3NrRqMC2lote2NpbJB5G00fovxg 79xGgr0TXC7U7Htq5SLAhe9RxhnL+IbMGUTtBdEhen56G9RjXHtsDzbnnA1jgaCniIeGIOxA+rGR wj9M0C2ug9Y7LCY3Dn5ZT9lyTGXVZqtqTA4rPL/FwZ4lupR4XUuyshuLttGYPdWRRsI1oO5DXPmC Z0TswLgw5VgPyRAE4vMY6rg+SDFFKnSBKEJII+h5PEUYGe//4ngvqUA7vRTIrwTyhYRCZjkyfZiG OCmMcLvEw1UaUL5DOHkqNccmwdg7RpN9SweHZqL+DmJzAb4qP04fzld9glNKQsltm6gDH1WGkdap KrBBQKu1e99jpb8lQULqvPCq+Q0Vz5dOxynN9g5jTL4vaJp3stYOjA5FF8GoExOeK1N2tss4SKAb hsLh73Rhls0qdKGzPyWo9h6Um2WECtteDnTebyYTEtyC9stTd9qyPoPf4bNU98VJOA/AbhGILoRG 96ldUnwd10VjVLVa9ZBGo7yI02CrQSZ8XuKA8KbviwEqzG5m7kYIGPlVjWjogLSK7Ab7QQEFYxey iIv9qKd2Bn4Tkp9CiJaxv2JINstPuP5IJvi1S1hURRvkNxLxCTZoDwYnrSoPGfmW52x9yiC91ry5 vS0i4o2fOJumXKsx97V9UwQexxEJax05LHqKtrWQcTPiGbH1Elx+nYaSvAeAOQ+zR7wAM372TNiI q9BYTH2AzcqlozNLpPk/g7UMe2dDodEDaDDlLt+2H542yrPzyzCBEPxKmcv17JkLsLNnrnaizGUY KmeuXo2XMxyw/TBBXmzNcNoUmQauj8x16mOy1lsein4I2UfOLHR0XzWzszN4mxZIcDmf1PdgY2N+ JkcrDHCFj1EYqSZ2nUPen2aIYWSkzsdUhbArT32BrEAkSni6utEltrsFco1xX0xUgrwLXm8qDj4s 9G5bq82ua2LWbEC7Z4DxKU3GpPLvw0e6lVa3ghaZYsVWORG78P3VDL/o38+j8PGiTOUGdz8424Ct 3CBpEQbrl1EgAwbWt1ZPnDnlMK8kgpE2z/W49vdOoPti6oJAz4BQ/x1Tr7DstLIayLco2ME4xzlv GuMRCqqWg9TyWQ7c4GvqfB+Qan7E6lqGeoRcIg9VMrmmmscQWL2qQQWKuN0/rgosMy5KopxmVgKD 0reQ9ahGRv6MSsBnZhPnoHgegDukzuCcM7c0EAXKhKYrlsuqqBhrLa8ZapxSzWe9GOO6eNeGtgEf M7VP1kn3BEfkAWga/CK+dN2PQ7fcfXwi2XZxZF6QYgFjIB05h4VKPw0PsYwyr9x8JZLr+LBKVOuS qB/6ikExSVEqBGZ9H1f5yucJjfkYGOiJ1GVzzSPn37JLno5lHrVQS8aSvVyYs6CueIrnQBHhSVIZ FpFbdD/sfoASY4Pwdw/9eTTymsr7HTNt0KgA/mkunUUhubun03SOXoBUezL9eXyUFuTSQPdkZ6MQ ed1WGRJXy1irdWwz3vDlCinxGxLO94W7Q1qZycvOlUMkU6H0tRfOK2pXZl14P7Jlu7JQGPLzw6AE WFmqgJ0D40dCwzFcxN3N7CdqLCKNUN8TfQvEFVnMj6nLuWSRh90nEFpau4uCxgiyyVErur6XXA0Q 4xv6PRA+FVQnlULPBt58uAEIIsKVfuyJtqFjU2RyekfT0QMS0QjraqLo0hyh5/xkhGiYlNhJ49dg Z2mGOEvj2A67zQ8xA5euns/ATWXH1Sxfc16zVCNK3Y0s16DGFEeaRxzcSMXYQsB6jvBhTragQVWr WcuJROha8CeOOc7im4oin4m5J0CLjfb91H2YZOj0LoLAH2JOuxhgSYKCF/COz38xEJIn5LMejNsM 3zD2YZ8xUwuJK1ez1/ZEjWTtCmpEcI/e8K8lHMgC6chrNhTDJZdIZoxktYCfsOIlD4OTRLQ1JtZw t0oDeCHne0zyiX6jopBwAb4EKPt2RFPqCeakvFGACmmZnKJYu54FivOlu0/pOoxotnAqrwjlhDY9 CQGrHlczVeTRqptNBBmPRzNvGSmeN/meKs0meGeZFKPleNdFLdiIXJ5kTb6g65dXbIIjh0Xj1PnP QaMJ0w8MoWgdsoBFUvsDEmvH3gkZMthCBt3c5XAErd+SPksKtH3QsJs4/zlHvq6PhToYqWN6NqXu aDAwPt3yEnz1sAsmJi49wWL2gvJszVqIvBQSQfvvHHCC5mJshq0YTyKxGEzU+wrSz5S4ptnzvJJX D0HjnKqRsoI8Bb9SQMvGlWh8Pz0GAPE64oMvehk0+Z8FFdzIxLieJ0iO4xqcrI8gxYOg5vRhM41D jbHJ7HypaSuPTARjDBRLx06h3QzM+xZogNQttw+ejfEAInDf77zN9q1Ckd5eO8UaC4+ZLDjSRQkC 2mj+BcXI43W2reWC5eXSOMFuuB6Ids8NNGb6ZpWVP5SvG57yaNqYHmAE+4tGnGd74xvYwnGaTEfU js6GpV+OhPk1C843Vqh7MWMAmeQSLo5b8vEsIYEgQvUfk9bSsTt6cNa1y8yAtytz2XfJsMI3YsTH DiRJS585X7wqlLfgxZcp3BO6OsIP8RKd3ihghjSKafpl5/YAF7spDcEhh4fdaOSaOk/BGJ7LQ7UA 3xHlSW2dSZf6JY/+U/CjHxUH77ybbjcYxD85rJWDkJGmye1+5Sk6NPiQ8sqK9ZA/+Nq10K58gCSQ hIrJjhFQ0DYRKXIIND2swmsErrI+QfY6Ln8cuM8K+41o0hBvXKSswElwMdlKAproVP/5wGQ7v4+H 9lKt5DeS0ed4DiH87O/gwd+Fo9+ChmaX7IDA7cH1lR4sMSnj5ZtByKUpOnESS6z5S1Nwbw9LZRvS JYy2hv0EFc7nQ0+JNr4VhsCcHXjqQF1XqEl6qyAgKWaypGIcaRaOHdhzRIGa1/R8uQwNAXN+et3N qPfQ72JAmDnDIrjmszXtcKWKXNkBJvMjXHiH7OwuZUctleb/YPXou8md/W6Kqa+b1u6lpYgHw+um KLum9xsN8ssVXZM8gxGwXQRAX20rLQqmupWB9FxJwcPp9judljrLq2vn8jCZGaTBScbCSVyadXuA g+IzQWH3CzXDCXZ/Z/f2Lhv/mI3N49lbmmTHxfiMSy0vJcTula7LN50cs5P3wlvm0DDNuB+YmBPO Vx2h+REiLnIiTSzFIzUcuoiNM4sR+0tAiD8EO5Ei/bqfIu8Nirnah+G9vwXeO6NKY0xs33wxZpRI Jhl+2FHWjoW6h1SjXbBLy4ajheTPnLhkO78gLgeEM63D/fCKBOAlGwjHbAGvV/kA/TIUfIDSQr9B fAao0jGTKC7j0CzdXgShwrumgNhDmHwsSsA2zGTYBBDK2R+AM6T6ckaejpDSxcIMMQYWmhDiFRRX a1vNnx1jkhpD/V4WXbjd4uBzO7JrKyZmuIW6g2+baURSKknOp5NLypRLNrKMoDn8M+5uooW81HEK eMYRabrlywT5Y+HH3twa1Mdn+dGaG3ectipKz0tP7lvZFnpTsl5pYU8KcObq9WklLF5tOo4FFprc RyDAV/cezkEh8MBm1DehUXGm6jfTAMINZ+8bpBD1p6+BuIv6M3cbLUCw7N63w+8S+b/bHgaVCCW1 5Dgnv93kiq/Do1l/XKDGz4Fuc+Z5m/rhJCzAHKhCoeABoWAyuJX24OFwJUbOvjDP5mYTVHoLz+8N WMWgC5p4wpnHBVBxwnz5jFC2FmL9xJXr38vsFw8Uzi67DZj52Hi8HFu4tBVrmrgixqwgoFEENXMD ENxh5UgEYCXUAy5GRXyzckrFU/y6HYvBrJGfsq57QgPG37SQlXikM4U3YjGdsSDCpRn0Rp98xbgf GdVxUFleUvviTzV38RAkc601czt/WvpjBsmVgmQE88Fm4ZwM23wCU30ydOnoFH8O061wcuMY04+P eGgLlVeOuAHCVcyuq99ChQIJ6huOuA2h71dbtQtt0+UnmLv0eCOthmfuFBhqSYoNJFf/Vy7+oRKe TLiYY1lk7nwHe6ZV3DheqPUZW723/O9jJvDuNWoKKcAi4FcQQtfYfGxBqL9LkY1rq+fEjGDIrADP fijWGzLHh9yfCNLXc38iiC29gh74RE+UBBqWBLnORcO1KRRVYZifXRqSYcOr3WlGgpATf9R2wVdN UqY2Qsq6zHOuqVycRE8NzYkhvUdI8FJ4sUMKuJI3Ji9scXPLogeDEub/ZW5u/nb1PzifWI5lbmRz dHJlYW0KZW5kb2JqCjYgMCBvYmoKNDYwMgplbmRvYmoKMTIgMCBvYmoKPDwvTGVuZ3RoIDEzIDAg Ui9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicvVbbTtwwEH3PV+StdkVc3x3z1NJSVEQr QcMT6gPscmnFctkuSP37jhMnGW+yLGXbghAjx3PxnOPjuc85EzLn4bc1JrOM53vwd5ndZyVT4af+ gO3JLN+psjdHLgev6iLjzHuvRf1N5I6zMneWM51Xs4zktPqRCQVr1UFWvT4hX2mhIRg3lpxTxZwm P2khmJTeO2x+p4VkwhpTkltacCa99rD5Btl5sIV2zkvynhaKKW8g7FWzBTwNOW1SoGBzKlkJ2QXZ josKAn2r9uvq3lHBjDNckTOUaIrsWHQMA/8LxyTnvk11hfaitLNgauO9ScreoZZZwZVp496g4lE3 rvtI40FPh+4x4hZEgXxGuZC5NqUhBxQsC77kExVwFCEMHL4omVZC+6TGpidaS/KIokMZ4Ccc+F1S zxwcQibpb5GN12Noa5wgx027bVp4PKFWNsmYdF4rH/ujhMQeCzBDXVaSX01dTkaA4d+r/8TB9vCi dKToGDdJKPIigg55XpcRw0zHyTdEMzB87Zm3kNvSOeFGaw7Q9+TprdhdIRzZpYFknEu7rlHLLJnQ wjJpgZ9t55VVqDfTIV9CybEPONlxR98RjgWfDTkmAsmsfYJjDwgVLCvN9bVhCyrnJVRclgt8frR8 teJ6PnQXGOnMdHhn63hnw3atSNd8FTLt/GKclzVyynOBNywGyI5cofOE+wONgXolZ4rDlhYsiZUw ug+1FAF+3Zs49KJfvl2RHW1Jaw5kkQb28RLezWqanXTtMF4h3iUKFRZGKTl2j4L44FrWyk8I1FMf 9ShuQ4dZ1qbdKjvMmgngaC8a8w2nCGt4mCFO2vT/7klmT/P7rz7Kra69BW3UpuRKtwIxEMGhSIGY luhBiQkex33+7F1mPdwXHQfmFPDq8DWe5wbknFlAzRqZm3x+nl1sPDNK6xnXLd7NzFgIDwGMy4tm epwuzZKd0MaHB+BGenqHIMd62XJk0U8vKUj1rhUS9aF7SdL7EPalt5TLVDO3ccDkmfgcHKDnUPNI IfjlQMSbpIRHkN+tPwV6njHvMO0RhV/wMI1MfJ6VBmaD2MEw7z0Mb9n2eL3YTrpVCLhJTpSprIe9 ZQm4GpRhC6kgVkSJ9vAVtkvUNAGvn6UmyesUD7QExhOES/3yfmL/0lEON3cxKjwXnSygxRh5SNhn 4DYEBDewbvI+lBoID3q2SsSaQ3GZjgkj6AzQ3hCdj9SAUBmVkBh3PTblepx3z7qZy09CP7bOx9C4 Wz8H9SLzvCsShgXsv98X8zQiiZdAn/8xNPVLcpj9BibHYK5lbmRzdHJlYW0KZW5kb2JqCjEzIDAg b2JqCjk3MwplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQy XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9Gb250IDEwIDAgUgo+PgovQ29udGVudHMgNSAwIFIKPj4KZW5kb2JqCjExIDAgb2JqCjw8L1R5 cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMTQgMCBSCj4+Ci9Db250ZW50cyAx MiAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAwIFIKMTEg MCBSCl0gL0NvdW50IDIKL1JvdGF0ZSAwPj4KZW5kb2JqCjEgMCBvYmoKPDwvVHlwZSAvQ2F0YWxv ZyAvUGFnZXMgMyAwIFIKPj4KZW5kb2JqCjEwIDAgb2JqCjw8L1I4CjggMCBSL1I3CjcgMCBSL1I5 CjkgMCBSPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjggMCBvYmoKPDwv QmFzZUZvbnQvQ291cmllci9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNyAwIG9i ago8PC9CYXNlRm9udC9UaW1lcy1Sb21hbi9UeXBlL0ZvbnQKL0VuY29kaW5nIDE1IDAgUi9TdWJ0 eXBlL1R5cGUxPj4KZW5kb2JqCjE1IDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNb CjE0Ni9xdW90ZXJpZ2h0L3F1b3RlZGJsbGVmdC9xdW90ZWRibHJpZ2h0XT4+CmVuZG9iago5IDAg b2JqCjw8L0Jhc2VGb250L0hlbHZldGljYS9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRv YmoKMiAwIG9iago8PC9Qcm9kdWNlcihHUEwgR2hvc3RzY3JpcHQgOC41MCkKL0NyZWF0aW9uRGF0 ZShEOjIwMDcwNTE3MjIyNTQ3KzAyJzAwJykKL01vZERhdGUoRDoyMDA3MDUxNzIyMjU0NyswMicw MCcpCi9UaXRsZShcMzc2XDM3N1wwMDBDXDAwMEZcMDAwUFwwMDAgXDAwMGZcMDAwb1wwMDByXDAw MCBcMDAwSVwwMDBFXDAwMEVcMDAwRVwwMDAgXDAwMFdcMDAwaVwwMDBNXDAwME9cMDAwQlwwMDAg XDAwMHNcMDAwcFwwMDBlXDAwMGNcMDAwaVwwMDBhXDAwMGxcMDAwIFwwMDBzXDAwMGVcMDAwc1ww MDBzXDAwMGlcMDAwb1wwMDBuXDAwMCBcMDAwb1wwMDBuXDAwMCBcMDAwc1wwMDBlXDAwMGNcMDAw dVwwMDByXDAwMGlcMDAwdFwwMDB5KQovQ3JlYXRvcihcMzc2XDM3N1wwMDBQXDAwMERcMDAwRlww MDBDXDAwMHJcMDAwZVwwMDBhXDAwMHRcMDAwb1wwMDByXDAwMCBcMDAwVlwwMDBlXDAwMHJcMDAw c1wwMDBpXDAwMG9cMDAwblwwMDAgXDAwMDBcMDAwLlwwMDA5XDAwMC5cMDAwMSkKL0F1dGhvcihc Mzc2XDM3N1wwMDB6XDAwMGFcMDAwayk+PmVuZG9iagp4cmVmCjAgMTYKMDAwMDAwMDAwMCA2NTUz NSBmIAowMDAwMDA2MTMzIDAwMDAwIG4gCjAwMDAwMDY1NTggMDAwMDAgbiAKMDAwMDAwNjA1OCAw MDAwMCBuIAowMDAwMDA1NzcyIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwNDY4 NyAwMDAwMCBuIAowMDAwMDA2MzIxIDAwMDAwIG4gCjAwMDAwMDYyNTkgMDAwMDAgbiAKMDAwMDAw NjQ5NCAwMDAwMCBuIAowMDAwMDA2MTgxIDAwMDAwIG4gCjAwMDAwMDU5MTQgMDAwMDAgbiAKMDAw MDAwNDcwNyAwMDAwMCBuIAowMDAwMDA1NzUyIDAwMDAwIG4gCjAwMDAwMDYyMjkgMDAwMDAgbiAK MDAwMDAwNjQwMyAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDE2IC9Sb290IDEgMCBSIC9JbmZv IDIgMCBSCi9JRCBbPDUyRTA0NjYyMDU4M0Q5NDcwQjJFNUExQkE2N0YxRUEzPjw1MkUwNDY2MjA1 ODNEOTQ3MEIyRTVBMUJBNjdGMUVBMz5dCj4+CnN0YXJ0eHJlZgo3MTAwCiUlRU9GCg== --=_5ikxh0yma1kw Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --=_5ikxh0yma1kw-- From manet-bounces@ietf.org Tue Apr 17 18:09:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdvrm-0002GJ-Ug; Tue, 17 Apr 2007 18:09:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hdvrl-0002GE-3d for manet-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 18:09:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdvrk-0002G5-QN for manet@ietf.org; Tue, 17 Apr 2007 18:09:36 -0400 Received: from insomnia.liquidweb.com ([64.91.225.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdvrj-0006EB-Dz for manet@ietf.org; Tue, 17 Apr 2007 18:09:36 -0400 Received: from confprom by insomnia.liquidweb.com with local (Exim 4.63) (envelope-from ) id 1Hdvrh-0001Oq-K0; Tue, 17 Apr 2007 18:09:33 -0400 Received: from 213.47.231.184 ([213.47.231.184]) (SquirrelMail authenticated user andy@confpromo.com) by www.confpromo.com with HTTP; Tue, 17 Apr 2007 18:09:33 -0400 (EDT) Message-ID: <19582.213.47.231.184.1176847773.squirrel@www.confpromo.com> Date: Tue, 17 Apr 2007 18:09:33 -0400 (EDT) From: andy@confpromo.com To: manet@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - insomnia.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32132 32133] / [47 12] X-AntiAbuse: Sender Address Domain - confpromo.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.2 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: pdini@cisco.com Subject: [manet] UBICOMM 2007 || Call for Papers || November 4-9, 2007 - Papeete, French Polynesia (Tahiti) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org ====================== CALL FOR PAPERS, TUTORIALS, PANELS International Conference on Mobile Ubiquitous Computing, Systems, Services, and Technologies UBICOMM 2007 November 4-9, 2007 - Papeete, French Polynesia (Tahiti) Site: http://www.iaria.org/conferences2007/UBICOMM07.html Call: http://www.iaria.org/conferences2007/CfPUBICOMM07.html Important deadlines: Submission deadline May 15, 2007 Notification of acceptance June 16, 2007 Registration/camera ready July 1, 2007 The rapid advances in ubiquitous technologies make fruition of more than 35 years of research in distributed computing systems, and more than two decades of mobile computing. The ubiquity vision is becoming a reality. Hardware and software components evolved to deliver functionality under failure-prone environments with limited resources. The advent of web services and the progress on wearable devices, ambient components, user-generated content, mobile communications, and new business models generated new applications and services. The conference makes a bridge between issues with software and hardware challenges through mobile communications. The goal of the International Conference on Mobile Ubiquitous Computing, Systems, Services, and Technologies, UBICOMM 2007, is to bring together researchers from the academia and practitioners from the industry in order to address fundamentals of ubiquitous systems and the new applications related to them. The conference will provide a forum where researchers shall be able to present recent research results and new research problems and directions related to them. The conference seeks contributions presenting novel research in all aspects of ubiquitous techniques and technologies applied to advanced mobile applications. Topics of interest (but not limited to): Fundamentals * Semantics of ubiquity * Ubiquitous knowledge * Control of ubiquitous data * Profiling ubiquitous environments Mobility * Ubiquitous computing * Ubiquitous networks * Mobile computing * Mobile services * Mobile commerce * Embedded systems Web Services * Web 2.0 * Semantic web * Web services * Ontology Ubiquitous devices and networks * Networks and technology convergence * Mobile service and service convergence * RFID * Mobile devices * Wearable devices Ubiquitous mobile services * Frameworks, architectures, and languages for ubiquitous services * SLA/QoS in ubiquitous services * Ontology based services * Protocols and interaction mechanisms for ubiquitous services * Mobile services and service convergence * Measurement, control, and management of ubiquitous services * Design and development of ubiquitous services Ubiquitous software * Ambient components * Software for spontaneous interoperation * Dependability guarantees * Security * Fault-tolerance User and applications * Ubiquitous user-generated content (weblogs, wikis, etc.) * Evaluation of user models for ubiquitous environments * On-line analytical techniques * Ubiquitous e-Development (business, science, health, etc.) INSTRUCTION FOR THE AUTHORS The UBICOMM 2007 Proceedings will be published by IEEE Computer Society Press and on-line via IEEE XPlore Digital Library. IEEE will index the papers with major indexes. Only .pdf or .doc files will be accepted for paper submission. All received papers will be acknowledged via the EDAS system. Final author manuscripts will be 8.5" x 11" (two columns IEEE format), not exceeding 6 pages; max 4 extra pages allowed at additional cost. The formatting instructions can be found on the Instructions page . Once you receive the notification of paper acceptance, you will be provided by the IEEE CS Press an online author kit with all the steps an author needs to follow to submit the final version. The author kits URL will be included in the letter of acceptance. Technical marketing/business/positioning presentations The conference initiates a series of business, technical marketing, and positioning presentations on the same topics. Speakers must submit a 10-12 slide deck presentations with substantial notes accompanying the slides, in the .ppt format (.pdf-ed). The slide deck will be published in the conference's CD collection, together with the regular papers. Please send your presentations to petre@iaria.org . Tutorials Tutorials provide overviews of current high interest topics. Proposals can be for half or full day tutorials. Please send your proposals to petre@iaria.org Panel proposals: The organizers encourage scientists and industry leaders to organize dedicated panels dealing with controversial and challenging topics and paradigms. Panel moderators are asked to identify their guests and manage that their appropriate talk supports timely reach our deadlines. Moderators must specifically submit an official proposal, indicating their background, panelist names, their affiliation, the topic of the panel, as well as short biographies. For more information, petre@iaria.org Workshop proposals We welcome workshop proposals on issues complementary to the topics of this conference. Your requests should be forwarded to petre@iaria.org . _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 17 18:14:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdvw9-00058W-0X; Tue, 17 Apr 2007 18:14:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hdvw7-00058R-Ub for manet-confirm+ok@megatron.ietf.org; Tue, 17 Apr 2007 18:14:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdvw7-00058J-L2 for manet@ietf.org; Tue, 17 Apr 2007 18:14:07 -0400 Received: from insomnia.liquidweb.com ([64.91.225.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdvw7-0008As-9I for manet@ietf.org; Tue, 17 Apr 2007 18:14:07 -0400 Received: from confprom by insomnia.liquidweb.com with local (Exim 4.63) (envelope-from ) id 1Hdvw5-0001mi-RS; Tue, 17 Apr 2007 18:14:05 -0400 Received: from 213.47.231.184 ([213.47.231.184]) (SquirrelMail authenticated user andy@confpromo.com) by www.confpromo.com with HTTP; Tue, 17 Apr 2007 18:14:05 -0400 (EDT) Message-ID: <1200.213.47.231.184.1176848045.squirrel@www.confpromo.com> Date: Tue, 17 Apr 2007 18:14:05 -0400 (EDT) From: andy@confpromo.com To: manet@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - insomnia.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32132 32133] / [47 12] X-AntiAbuse: Sender Address Domain - confpromo.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: pdini@cisco.com Subject: [manet] SEMAPRO 2007 || Call for Papers || November 4-9, 2007 - Papeete, French Polynesia (Tahiti) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Invitation: Please consider to contribute and distribute to the appropriate groups the following ======== ======== CALL FOR PAPERS, TUTORIALS, PANELS International Conference on Advances in Semantic Processing SEMAPRO 2007 November 4-9, 2007 - Papeete, French Polynesia (Tahiti) Site: http://www.iaria.org/conferences2007/SEMAPRO07.html Call: http://www.iaria.org/conferences2007/CfPSEMAPRO07.html Important deadlines: Submission deadline May 15, 2007 Notification of acceptance June 16, 2007 Registration/camera ready July 1, 2007 This inaugural International Conference on Advances in Semantic Processing, SEMAPRO 2007, deal with the complexity of understanding and processing information. Semantic processing considers contextual dependencies and adds to the individually acquired knowledge emergent properties and understanding. Hardware and software support and platforms were developed for semantically enhanced information retrieval and interpretation. The goal of the conference is to bring together researchers from the academia and practitioners from the industry in order to address fundamentals of semantic processing. The conference will provide a forum where researchers shall be able to present recent research results and new research problems and directions related to them. The conference seeks contributions presenting novel research in all aspects of techniques and technologies for semantic processing, as well as exploring special applications and services using these mechanisms. Topics of special interest (but not limited to): * Fundamental of semantic processing (storing, computing, representation, communications, etc.) * Semantic-driven system design * Syntactic and semantic processing models * Semantic networking and routing * Hardware and software support for semantic processing * Microprocessors for semantic processing * Multi-model semantic systems * Semantic annotation of multimedia supports * Semantic multimedia information retrieval * Natural language semantic processing * Context-based semantic processing * Content-based semantic processing * Performance in semantic processing * Information security in semantic processing * Applications, services and systems based on semantic processing * Speech, text and picture recognition * Semantic email workflow and content * Semantic blogs and wikis * Semantic email addressing * Semantic web and digital libraries * Semantic processing for biomedical knowledge * Semantic processing in e-Health * Semantic-driven tutoring systems * Semantic processing platforms * Lessons learnt INSTRUCTION FOR THE AUTHORS The SEMAPRO 2007 Proceedings will be published by IEEE Computer Society Press and on-line via IEEE XPlore Digital Library. IEEE will index the papers with major indexes. Only .pdf or .doc files will be accepted for paper submission. All received papers will be acknowledged via the EDAS system. Final author manuscripts will be 8.5" x 11" (two columns IEEE format), not exceeding 6 pages; max 4 extra pages allowed at additional cost. The formatting instructions can be found on the Instructions page . Once you receive the notification of paper acceptance, you will be provided by the IEEE CS Press an online author kit with all the steps an author needs to follow to submit the final version. The author kits URL will be included in the letter of acceptance. Technical marketing/business/positioning presentations The conference initiates a series of business, technical marketing, and positioning presentations on the same topics. Speakers must submit a 10-12 slide deck presentations with substantial notes accompanying the slides, in the .ppt format (.pdf-ed). The slide deck will be published in the conference's CD collection, together with the regular papers. Please send your presentations to petre@iaria.org . Tutorials Tutorials provide overviews of current high interest topics. Proposals can be for half or full day tutorials. Please send your proposals to petre@iaria.org Panel proposals: The organizers encourage scientists and industry leaders to organize dedicated panels dealing with controversial and challenging topics and paradigms. Panel moderators are asked to identify their guests and manage that their appropriate talk supports timely reach our deadlines. Moderators must specifically submit an official proposal, indicating their background, panelist names, their affiliation, the topic of the panel, as well as short biographies. For more information, petre@iaria.org Workshop proposals We welcome workshop proposals on issues complementary to the topics of this conference. Your requests should be forwarded to petre@iaria.org . ================================== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 02:55:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He44W-0000gq-64; Wed, 18 Apr 2007 02:55:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1He44U-0000gi-9X for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 02:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He44R-0000dx-5k for manet@ietf.org; Wed, 18 Apr 2007 02:55:15 -0400 Received: from web27605.mail.ukl.yahoo.com ([217.146.177.224]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He44P-0005n9-My for manet@ietf.org; Wed, 18 Apr 2007 02:55:15 -0400 Received: (qmail 49007 invoked by uid 60001); 18 Apr 2007 06:55:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BKsQk/BvwILM8V1EFzzdYvF+lYMmCn+6COeNCmxu3fpwVKicLp6L84LQU+Py30pPPkTrDp/KmhO2fz1QfwC5GdTb35Iwg8rUq2kKKA0tWUpM5gf67YqOeDG8/sIb/yYR1AbrdR9cdrf9dGZNExDgbOoUaFqejRldCjVD6G5kMsI= ; Message-ID: <20070418065513.49005.qmail@web27605.mail.ukl.yahoo.com> X-YMail-OSG: rjVxfjoVM1nZUSd7B25vpjtqURj5MVXb4FXCX2eHaq2hDPnaXJoj9zQ5Xp4WLGYwuw.Kp5OWFta2NhaAKw_NMJ_GZfBusfpqfzSTJ74k0MYKRuB7ZaiNIMiTAes- Received: from [193.95.37.75] by web27605.mail.ukl.yahoo.com via HTTP; Wed, 18 Apr 2007 08:55:13 CEST Date: Wed, 18 Apr 2007 08:55:13 +0200 (CEST) From: nadia mansouri To: manet MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [manet] how can i implement new protocol in glomosim X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0325707996==" Errors-To: manet-bounces@ietf.org --===============0325707996== Content-Type: multipart/alternative; boundary="0-1302075093-1176879313=:47090" Content-Transfer-Encoding: 8bit --0-1302075093-1176879313=:47090 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, Ihow can i implement in glomosim new protocol : MSR this protocol call DSR and I have only 2 file of MSR: MSR.pc and MSR.h. thanks in advance --------------------------------- Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-1302075093-1176879313=:47090 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello,
Ihow can i implement in glomosim new protocol : MSR this protocol call DSR and I have only 2 file of MSR:
MSR.pc and MSR.h.
thanks in advance

Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-1302075093-1176879313=:47090-- --===============0325707996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0325707996==-- From manet-bounces@ietf.org Wed Apr 18 02:55:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He44Y-0000hN-Uf; Wed, 18 Apr 2007 02:55:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1He44Y-0000hE-FP for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 02:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He44Y-0000h5-5n for manet@ietf.org; Wed, 18 Apr 2007 02:55:22 -0400 Received: from web27603.mail.ukl.yahoo.com ([217.146.177.222]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He44W-0005se-Po for manet@ietf.org; Wed, 18 Apr 2007 02:55:22 -0400 Received: (qmail 9605 invoked by uid 60001); 18 Apr 2007 06:55:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kqA7/vUP869o3biCJjDYnmaf84bBn5UTqsgUo4L2k60/02hdK4V3AlpN7H82Zbde8NXWhlHcx7Xxe85MFyZNGfbS4Gqx9Xh7tGv4uydiQdVs0V4qH8w4P8jc9iebK6i96zEfKW7VNTvmBqhOLCkeL+ILfLTiVv9B1R/PIK8uC0g= ; Message-ID: <20070418065520.9603.qmail@web27603.mail.ukl.yahoo.com> X-YMail-OSG: _5wJNHoVM1kIvW7gOdeLHvuAiRC7lsxll_csqxBTLQ4IM.NHdV35fDCICWTZqlffO68ruV6N6FkimOHQXrimeg5viSTT4wnlyMChL6zMsaPyV17vtYyNApZ2l54- Received: from [193.95.37.75] by web27603.mail.ukl.yahoo.com via HTTP; Wed, 18 Apr 2007 08:55:20 CEST Date: Wed, 18 Apr 2007 08:55:20 +0200 (CEST) From: nadia mansouri To: manet MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [manet] how can i implement new protocol in glomosim X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0294335842==" Errors-To: manet-bounces@ietf.org --===============0294335842== Content-Type: multipart/alternative; boundary="0-1337151352-1176879320=:5266" Content-Transfer-Encoding: 8bit --0-1337151352-1176879320=:5266 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, Ihow can i implement in glomosim new protocol : MSR this protocol call DSR and I have only 2 file of MSR: MSR.pc and MSR.h. thanks in advance --------------------------------- Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-1337151352-1176879320=:5266 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello,
Ihow can i implement in glomosim new protocol : MSR this protocol call DSR and I have only 2 file of MSR:
MSR.pc and MSR.h.
thanks in advance

Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-1337151352-1176879320=:5266-- --===============0294335842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0294335842==-- From manet-bounces@ietf.org Wed Apr 18 06:34:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7US-0003k5-I0; Wed, 18 Apr 2007 06:34:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1He7UP-0003hl-ER for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 06:34:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7UO-0003hC-RL for manet@ietf.org; Wed, 18 Apr 2007 06:34:16 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He7Q7-00036X-E6 for manet@ietf.org; Wed, 18 Apr 2007 06:29:52 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1176892190!7896519!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20057 invoked from network); 18 Apr 2007 10:29:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 18 Apr 2007 10:29:50 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3IAToR7013369; Wed, 18 Apr 2007 03:29:50 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3IATnFs002282; Wed, 18 Apr 2007 05:29:49 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3IATlkq002272; Wed, 18 Apr 2007 05:29:48 -0500 (CDT) Message-ID: <4625F31B.2090807@gmail.com> Date: Wed, 18 Apr 2007 12:29:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> In-Reply-To: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > The document includes suggestions by Bill Fenner regarding TBD > numbering, but otherwise has not changed. > > I would like to issue a WG last call on this document. I think there's more work with this document, more than just two weeks Last Call. > If you have any comments, please provide them before May 1st (two > weeks). Thanks for asking for comments, here are some: draft: > MANET routers subscribe to this LL scoped multicast address and use > it for LL transmissions of routing protocol packets. ... > For IPv6, a statically assigned, link-local scope multicast address > is used. I think there's a big difference between a router subscribing to a multicast address, and statically assigning a multicast address to an interface. In the above paragraphs you're actually saying the two should happen, for the same multicast address. I personally think the link-scoped multicast address should not be 'statically assigned', but the router should send a MLD message for it, and subsequently be subscribed to that group. For interface-scoped multicast addresses (ff01::smthing) From manet-bounces@ietf.org Wed Apr 18 06:34:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7US-0003k5-I0; Wed, 18 Apr 2007 06:34:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1He7UP-0003hl-ER for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 06:34:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7UO-0003hC-RL for manet@ietf.org; Wed, 18 Apr 2007 06:34:16 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He7Q7-00036X-E6 for manet@ietf.org; Wed, 18 Apr 2007 06:29:52 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1176892190!7896519!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20057 invoked from network); 18 Apr 2007 10:29:50 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-153.messagelabs.com with SMTP; 18 Apr 2007 10:29:50 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3IAToR7013369; Wed, 18 Apr 2007 03:29:50 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3IATnFs002282; Wed, 18 Apr 2007 05:29:49 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3IATlkq002272; Wed, 18 Apr 2007 05:29:48 -0500 (CDT) Message-ID: <4625F31B.2090807@gmail.com> Date: Wed, 18 Apr 2007 12:29:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> In-Reply-To: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > The document includes suggestions by Bill Fenner regarding TBD > numbering, but otherwise has not changed. > > I would like to issue a WG last call on this document. I think there's more work with this document, more than just two weeks Last Call. > If you have any comments, please provide them before May 1st (two > weeks). Thanks for asking for comments, here are some: draft: > MANET routers subscribe to this LL scoped multicast address and use > it for LL transmissions of routing protocol packets. ... > For IPv6, a statically assigned, link-local scope multicast address > is used. I think there's a big difference between a router subscribing to a multicast address, and statically assigning a multicast address to an interface. In the above paragraphs you're actually saying the two should happen, for the same multicast address. I personally think the link-scoped multicast address should not be 'statically assigned', but the router should send a MLD message for it, and subsequently be subscribed to that group. For interface-scoped multicast addresses (ff01::smthing) - I think yes, they can be statically assigned to an interface. Another issue is that AUTOCONF WG seems to be looking at address auto-configuration means for MANET networks. Discovery phase of address auto-configuration often uses multicast addresses. _Maybe_ (I say maybe because without this then DHCP multicast groups can be used) new MANET-AUTOCONF IANA-reserved multicast groups could be reserved by IANA, for MANET autoconfiguration purposes. What do you think? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 06:34:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7UU-0003n2-CB; Wed, 18 Apr 2007 06:34:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1He7US-0003kL-1c for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 06:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7UR-0003hC-BS; Wed, 18 Apr 2007 06:34:19 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He7PL-0002sC-7y; Wed, 18 Apr 2007 06:29:07 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 46BF41FBD0D; Wed, 18 Apr 2007 12:29:00 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19247-01-25; Wed, 18 Apr 2007 12:28:59 +0200 (CEST) Received: from [155.54.205.200] (inf-205-200.um.es [155.54.205.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 7BC8F1FBF43; Wed, 18 Apr 2007 12:28:46 +0200 (CEST) Message-ID: <4625F2C5.7080804@dif.um.es> Date: Wed, 18 Apr 2007 12:28:21 +0200 From: "Pedro M. Ruiz" User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: 'IETF Manet' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [manet] CFP, Track on Intelligent Sensors and Sensor Networks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org We apologize in advance for possible cross-postings. _______________________________________________________ ** CALL FOR PAPERS ** IEEE ETFA 2007 11th IEEE International Conference on Emerging Technologies and Factory Automation ** Track on Intelligent Sensors and Sensor Networks ** September 25-28, 2006; Prague, Czech Republic http://www.etfa2007.org ________________________________________________________ ================================================ Track on Intelligent Sensors and Sensor Networks ================================================ ----------- BACKGROUND: ----------- The track on Intelligent Sensors and Sensor Networks of ETFA 2007 addresses concepts, implementations and applications of sensor network systems from bot- I think yes, they can be statically assigned to an interface. Another issue is that AUTOCONF WG seems to be looking at address auto-configuration means for MANET networks. Discovery phase of address auto-configuration often uses multicast addresses. _Maybe_ (I say maybe because without this then DHCP multicast groups can be used) new MANET-AUTOCONF IANA-reserved multicast groups could be reserved by IANA, for MANET autoconfiguration purposes. What do you think? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 06:34:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7UU-0003n2-CB; Wed, 18 Apr 2007 06:34:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1He7US-0003kL-1c for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 06:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7UR-0003hC-BS; Wed, 18 Apr 2007 06:34:19 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He7PL-0002sC-7y; Wed, 18 Apr 2007 06:29:07 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 46BF41FBD0D; Wed, 18 Apr 2007 12:29:00 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19247-01-25; Wed, 18 Apr 2007 12:28:59 +0200 (CEST) Received: from [155.54.205.200] (inf-205-200.um.es [155.54.205.200]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 7BC8F1FBF43; Wed, 18 Apr 2007 12:28:46 +0200 (CEST) Message-ID: <4625F2C5.7080804@dif.um.es> Date: Wed, 18 Apr 2007 12:28:21 +0200 From: "Pedro M. Ruiz" User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: 'IETF Manet' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [manet] CFP, Track on Intelligent Sensors and Sensor Networks X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org We apologize in advance for possible cross-postings. _______________________________________________________ ** CALL FOR PAPERS ** IEEE ETFA 2007 11th IEEE International Conference on Emerging Technologies and Factory Automation ** Track on Intelligent Sensors and Sensor Networks ** September 25-28, 2006; Prague, Czech Republic http://www.etfa2007.org ________________________________________________________ ================================================ Track on Intelligent Sensors and Sensor Networks ================================================ ----------- BACKGROUND: ----------- The track on Intelligent Sensors and Sensor Networks of ETFA 2007 addresses concepts, implementations and applications of sensor network systems from both hardware and software domain, and their application to industrial and factory automation. Papers on any of the following and related topics will be considered for the track: - Wireless integrated networked sensors - Localized algorithms and protocols - Energy efficiency; hardware/software - Data integration and fusion algorithms - Topology control and area coverage algorithms - Wideband networked sensors - MEMS sensors - System architecture - Sensing, processing, and communicating on a chip - Power supplies - Positioning systems and algorithms - Communication protocols and algorithms - Communication-computation trade-offs - Design and implementation - Development environments and tools --------------------- SUBMISSION OF PAPERS: --------------------- Papers should be submitted following the "Instructions for authors" under the Call for Papers on the ETFA 2007 web site (www.etfa2007.org) ---------------- IMPORTANT DATES: ---------------- Long paper submission deadline: April 27, 2007 Notification of acceptance for long papers: June 15, 2007 Work in progress and Industry practice papers: June 1, 2007 Notification of acceptance for WiP papers: July 1, 2007 Submission of final manuscripts: July 16, 2007 -------------------- FURTHER INFORMATION: -------------------- ETFA-07 Conference Secretariat: Tel: +30-2610-996427, 996440, 910308, 997284 Fax: +30-2610-996818 Email: etfa2007@isi.gr Paper Acceptance: Each accepted paper must be presented at the conference by one of the authors. The final manuscript must be accompanied by a registration form and a registration fee payment proof. All conference attendees, including authors and session chairpersons, must pay the conference registration fee, and their travel expenses. ----------- TRACK CHAIRS ------------ Pedro M. Ruiz University of Murcia, Spain pedrom@dif.um.es Paul M. Havinga University of Twente, Netherlands havinga@cs.utwente.nl -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet h hardware and software domain, and their application to industrial and factory automation. Papers on any of the following and related topics will be considered for the track: - Wireless integrated networked sensors - Localized algorithms and protocols - Energy efficiency; hardware/software - Data integration and fusion algorithms - Topology control and area coverage algorithms - Wideband networked sensors - MEMS sensors - System architecture - Sensing, processing, and communicating on a chip - Power supplies - Positioning systems and algorithms - Communication protocols and algorithms - Communication-computation trade-offs - Design and implementation - Development environments and tools --------------------- SUBMISSION OF PAPERS: --------------------- Papers should be submitted following the "Instructions for authors" under the Call for Papers on the ETFA 2007 web site (www.etfa2007.org) ---------------- IMPORTANT DATES: ---------------- Long paper submission deadline: April 27, 2007 Notification of acceptance for long papers: June 15, 2007 Work in progress and Industry practice papers: June 1, 2007 Notification of acceptance for WiP papers: July 1, 2007 Submission of final manuscripts: July 16, 2007 -------------------- FURTHER INFORMATION: -------------------- ETFA-07 Conference Secretariat: Tel: +30-2610-996427, 996440, 910308, 997284 Fax: +30-2610-996818 Email: etfa2007@isi.gr Paper Acceptance: Each accepted paper must be presented at the conference by one of the authors. The final manuscript must be accompanied by a registration form and a registration fee payment proof. All conference attendees, including authors and session chairpersons, must pay the conference registration fee, and their travel expenses. ----------- TRACK CHAIRS ------------ Pedro M. Ruiz University of Murcia, Spain pedrom@dif.um.es Paul M. Havinga University of Twente, Netherlands havinga@cs.utwente.nl -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 08:00:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8pw-0005Sa-44; Wed, 18 Apr 2007 08:00:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1He8pg-0005MW-RY for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 08:00:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8pe-0005DX-Mo for manet@ietf.org; Wed, 18 Apr 2007 08:00:18 -0400 Received: from ik-out-1112.google.com ([66.249.90.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He8gy-0002IE-Dg for manet@ietf.org; Wed, 18 Apr 2007 07:51:21 -0400 Received: by ik-out-1112.google.com with SMTP id c21so132044ika for ; Wed, 18 Apr 2007 04:51:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gcO6rnj8MqdKfry4vPkwwhMwqjipBetixmpRnRJPr8d/iuPjPr/QTbTcBQ26UDMfrmE4Lbhxz+saxmWNqVRHtw8NF8HErm0fk9VIrZJ6KFuje/gyaJwfHoYMbA31mPia2Ci1JUAauIbTFUSn7lNJa6fd4CrT4fz2FNXLUlLOxPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FqQ//SWgrKjtgb9Mt9IKSxrtasj8jZJMeexaCAQicuO24RFvqR9uzf2K7kGByFSma6StYO+Asmt5f6ufhZX68UM2qC80sNt7IOmh95iyz6mydW69Ycjyj3XQDCAg8ybRxLqk8M9ueS2w4YTQRY7kqrwtd6PUJ5w1doolMLlgxM8= Received: by 10.78.183.15 with SMTP id g15mr64447huf.1176897079603; Wed, 18 Apr 2007 04:51:19 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Wed, 18 Apr 2007 04:51:19 -0700 (PDT) Message-ID: <374005f30704180451x4ac51e77x379b0bb4378c90ca@mail.gmail.com> Date: Wed, 18 Apr 2007 17:21:19 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call In-Reply-To: <4625F31B.2090807@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> <4625F31B.2090807@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org If you look at other routing protocols, they specify a particular static multicast address for communication. We are simply allocating the same type of addresses for MANET protocols. See the IANA lists at http://www.iana.org/assignments/multicast-addresses http://www.iana.org/assignments/ipv6-multicast-addresses Other comments inline. On 4/18/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > The document includes suggestions by Bill Fenner regarding TBD > > numbering, but otherwise has not changed. > > > > I would like to issue a WG last call on this document. > > I think there's more work with this document, more than just two weeks > Last Call. There has been little to no change on this document for some time. I see no reason to delay its publication. > > If you have any comments, please provide them before May 1st (two > > weeks). > > Thanks for asking for comments, here are some: > > draft: > > MANET routers subscribe to this LL scoped multicast address and use > > it for LL transmissions of routing protocol packets. > ... > > For IPv6, a statically assigned, link-local scope multicast address > > is used. The purpose of the multicast group is for MANET router communication. MANET routers MUST subscribe to receive messages protocol messages on a particular address and MUST also transmit to the same address to insure interoperability. > I think there's a big difference between a router subscribing to a > multicast address, and statically assigning a multicast address to an > interface. In the above paragraphs you're actually saying the two > should happen, for the same multicast address. > > I personally think the link-scoped multicast address should not be > 'statically assigned', but the router should send a MLD message for it, > and subsequently be subscribed to that group. I think that this proposition could significantly delay routing convergence and cause many problems in MANET style networks. > For interface-scoped multicast addresses (ff01::smthing) - I think yes, > they can be statically assigned to an interface. > > Another issue is that AUTOCONF WG seems to be looking at address > auto-configuration means for MANET networks. Discovery phase of address > auto-configuration often uses multicast addresses. _Maybe_ (I say maybe > because without this then DHCP multicast groups can be used) new > MANET-AUTOCONF IANA-reserved multicast groups could be reserved by IANA, > for MANET autoconfiguration purposes. >From looking at the AUTOCONF charter (http://www.ietf.org/html.charters/autoconf-charter.html) and problem statement, they are working on unicast address auto-configuration for MANET routers. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 10:03:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAl1-0000v7-31; Wed, 18 Apr 2007 10:03:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeAky-0000uy-6I for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 10:03:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAkx-0000uq-Sx for manet@ietf.org; Wed, 18 Apr 2007 10:03:35 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeAkw-0004i9-EE for manet@ietf.org; Wed, 18 Apr 2007 10:03:35 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1176905013!15279073!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26919 invoked from network); 18 Apr 2007 14:03:33 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with SMTP; 18 Apr 2007 14:03:33 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3IE3XI1023390; Wed, 18 Apr 2007 07:03:33 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l3IE3WhJ010445; Wed, 18 Apr 2007 09:03:33 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l3IE3VmR010419; Wed, 18 Apr 2007 09:03:31 -0500 (CDT) Message-ID: <46262531.5010002@gmail.com> Date: Wed, 18 Apr 2007 16:03:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> <4625F31B.2090807@gmail.com> <374005f30704180451x4ac51e77x379b0bb4378c90ca@mail.gmail.com> In-Reply-To: <374005f30704180451x4ac51e77x379b0bb4378c90ca@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > If you look at other routing protocols, they specify a particular > static multicast address for communication. We are simply allocating > the same type of addresses for MANET protocols. Yes, I agree, but these addresses (eg OSPF's AllSPFRouters ff02::5) aren't statically assigned, IMHO. A router must join that group. Or maybe we have misunderstanding of 'statically assigning'? > See the IANA lists at > > http://www.iana.org/assignments/multicast-addresses > http://www.iana.org/assignments/ipv6-multicast-addresses > > Other comments inline. > > On 4/18/07, Alexandru Petrescu wrote: >> Ian Chakeres wrote: >>> The document includes suggestions by Bill Fenner regarding TBD >>> numbering, but otherwise has not changed. >>> >>> I would like to issue a WG last call on this document. >> >> I think there's more work with this document, more than just two >> weeks Last Call. > > There has been little to no change on this document for some time. I > see no reason to delay its publication. Wait for more review? >>> If you have any comments, please provide them before May 1st (two >>> weeks). >> >> Thanks for asking for comments, here are some: >> >> draft: >>> MANET routers subscribe to this LL scoped multicast address and >>> use it for LL transmissions of routing protocol packets. >> ... >>> For IPv6, a statically assigned, link-local scope multicast >>> address is used. > > The purpose of the multicast group is for MANET router communication. > MANET routers MUST subscribe to receive messages protocol messages > on a particular address Right, that's what I mean, so they're not 'statically assigned'. > and MUST also transmit to the same address to insure > interoperability. Yes, when a router sends a packet to a multicast address it doesn't necessarily have to statically assign that address to a interface, neither does it have to join that group. >> I think there's a big difference between a router subscribing to a >> multicast address, and statically assigning a multicast address to >> an interface. In the above paragraphs you're actually saying the >> two should happen, for the same multicast address. >> >> I personally think the link-scoped multicast address should not be >> 'statically assigned', but the router should send a MLD message for >> it, and subsequently be subscribed to that group. > > I think that this proposition could significantly delay routing > convergence and cause many problems in MANET style networks. I think there may be an understood multicast way of working for IPv6, and doing anything different than that ('assign' multicast addresses without subscribing to the respective group) can cause many delays in standardizing a novel multicast method for MANET and IPv6. Underlying linklayers for which MANET protocols have been demonstrated (WiFi) have explicit means to subscribe to link-layer multicast groups, which work hand in hand with the capability of receiving network-layer multicast datagrams. I don't see any way for a router to receive packets addressed to a group other than subscribing, or joining, to that group. Do you see another? >> For interface-scoped multicast addresses (ff01::smthing) - I think >> yes, they can be statically assigned to an interface. >> >> Another issue is that AUTOCONF WG seems to be looking at address >> auto-configuration means for MANET networks. Discovery phase of >> address auto-configuration often uses multicast addresses. _Maybe_ >> (I say maybe because without this then DHCP multicast groups can be >> used) new MANET-AUTOCONF IANA-reserved multicast groups could be >> reserved by IANA, for MANET autoconfiguration purposes. > >> From looking at the AUTOCONF charter > (http://www.ietf.org/html.charters/autoconf-charter.html) and problem > statement, they are working on unicast address auto-configuration > for MANET routers. Does the AUTOCONF Charter forbid the use of known multicast mechanisms to auto-configure unicast addresses? If it doesn't, then AUTOCONF may need new well-known multicast addresses, with link or site scope, exclusively for the purpose of unicast address auto-configuration. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 10:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBZU-0001QD-Ve; Wed, 18 Apr 2007 10:55:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeBZS-0001Py-OI for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 10:55:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBZS-0001Pq-Eo for manet@ietf.org; Wed, 18 Apr 2007 10:55:46 -0400 Received: from balu3.urz.unibas.ch ([131.152.1.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBZP-0004oN-S6 for manet@ietf.org; Wed, 18 Apr 2007 10:55:46 -0400 Received: from [131.152.55.200] (baobab.cs.unibas.ch [131.152.55.200]) by balu3.urz.unibas.ch (8.13.1/8.13.1) with ESMTP id l3IEtg1E003836 for ; Wed, 18 Apr 2007 16:55:42 +0200 Message-ID: <46263198.5040003@unibas.ch> Date: Wed, 18 Apr 2007 16:56:24 +0200 From: Christophe Jelger Organization: University of Basel User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: manet Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> In-Reply-To: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SMTP-Vilter-Version: 1.3.2 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian/all, I'm sorry to play the devil's advocate again ;-) but ... looking back at the debate that took place in mid-March 2005 (2 years ago!) on this mailing list I am still not convinved that the WG was in favor of having a unique mcast address and port for all MANET protocols. This is against the current best practice for assigning mcast addresses to routing protocols and as we all know, having a unique address and port is mostly driven by the packetbb proposal which was also highly debated in July 2006 on the AUTOCONF list. Note I don't want to trigger yet another debate on this, but I wonder if the IESG is ready to validate a proposal that advocates the use of a single tuple for multiple (different) protocols while current best practice is to _not_ do this. Maybe you have had promising pre-discussions with IESG people to convince them this is a good idea, otherwise the document could have a better motivation section. More details: - in section 2 you say "all interoperable MANET routing protocol traffic ...". I think "interoperable traffic" is very vague and sounds even very odd to me: we have interoperable systems, but can (network) traffic be interoperable ... I mean does the wording makes sense? Better say that all traffic with common format (i.e. packetbb) must be sent to the same UDP port? - reference to packetbb: I'm not sure here, but can you refer to a draft in an RFC about to go to IESG? sorry for raising negative points, Christophe Ian Chakeres wrote: > The document includes suggestions by Bill Fenner regarding TBD > numbering, but otherwise has not changed. > > I would like to issue a WG last call on this document. > > If you have any comments, please provide them before May 1st (two weeks). > > Thanks. > Ian Chakeres > > On 4/17/07, 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 : MANET IANA Needs >> Author(s) : I. Chakeres >> Filename : draft-ietf-manet-iana-01.txt >> Pages : 7 >> Date : 2007-4-16 >> >> This document enumerates IANA assignments for immediate use in MANET. >> Specifically, a UDP port, two link-local multicast group addresses >> (IPv4 & IPv6), and two site-local multicast group addresses (IPv4 & >> IPv6). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-01.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of >> the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> 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-iana-01.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-iana-01.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. >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- -------------------------------------------------- Dr. Christophe Jelger, University of Basel Computer Networks Group, http://cn.cs.unibas.ch/ Bernoullistrasse 16, CH-4056 Basel, Switzerland _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 11:49:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCPK-00071h-5T; Wed, 18 Apr 2007 11:49:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeCPJ-00071c-4s for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 11:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCPI-00071T-RN for manet@ietf.org; Wed, 18 Apr 2007 11:49:20 -0400 Received: from insomnia.liquidweb.com ([64.91.225.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCOx-0000cf-OM for manet@ietf.org; Wed, 18 Apr 2007 11:49:20 -0400 Received: from confprom by insomnia.liquidweb.com with local (Exim 4.63) (envelope-from ) id 1HeCOq-0004yp-Tf; Wed, 18 Apr 2007 11:48:53 -0400 Received: from 138.232.65.129 ([138.232.65.129]) (SquirrelMail authenticated user vicky@confpromo.com) by www.confpromo.com with HTTP; Wed, 18 Apr 2007 11:48:52 -0400 (EDT) Message-ID: <13875.138.232.65.129.1176911332.squirrel@www.confpromo.com> Date: Wed, 18 Apr 2007 11:48:52 -0400 (EDT) From: "Vicky Star" To: manet@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - insomnia.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32132 32133] / [47 12] X-AntiAbuse: Sender Address Domain - confpromo.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: pdini@cisco.com Subject: [manet] cfp: ADVCOMP 2007 || November 4-9, 2007 - Papeete, French Polynesia (Tahiti) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Invitation: Please consider to contribute and distribute to the appropriate groups the following ================ CALL FOR PAPERS, TUTORIALS, PANELS The International Conference on Advanced Engineering Computing and Applications in Sciences ADVCOMP 2007 November 4-9, 2007 - Papeete, French Polynesia (Tahiti) Site: http://www.iaria.org/conferences2007/ADVCOMP07.html Call: http://www.iaria.org/conferences2007/CfPADVCOMP07.html Important deadlines: Submission deadline May 15, 2007 Notification of acceptance June 16, 2007 Registration/camera ready July 1, 2007 With the advent of high performance computing environments, virtualization, distributed and parallel computing, as well as the increasing memory, storage and computational power, processing particularly complex scientific applications and voluminous data is more affordable. With the current computing software, hardware and distributed platforms effective use of advanced computing techniques is more achievable. The goal of the International Conference on Advanced Engineering Computing and Applications in Sciences, ADVCOMP 2007, is to bring together researchers from the academia and practitioners from the industry in order to address fundamentals of advanced scientific computing and specific mechanisms and algorithms for particular sciences. The conference will provide a forum where researchers shall be able to present recent research results and new research problems and directions related to them. The conference seeks contributions presenting novel research in all aspects of new scientific methods for computing and hybrid methods for computing optimization, as well as advanced algorithms and computational procedures, software and hardware solutions dealing with specific domains of science. Topics of special interest (but not limited to): Computing techniques: * Hybrid computational methods * Advanced numerical algorithms * Parallel and grid computing * Autonomic computing * Computational logics * Neuronal networks * Genetic algorithms * Fractals & Superfractal algorithms * Random graph dynamics * Clustering large and high dimensional data * Computation Genomic * Biological Sequence analysis Computing support: * Support for scientific problem-solving * Support for decisions * Agent-assisted workflow support * Middleware computation support * High performance computing * Problem solving environments * Computational science and education Application domains: * Advanced scientific computing * Development of numerical and scientific software-based systems * Management of scientific data and knowledge * Advanced computing in bioinformatics and biophysics * Advanced computing in molecular systems and biological systems * Application of engineering methods to genetics * Medical computation and graphics * Advanced computing in simulation systems * Advanced computing in mathematics * Advanced computing for statistics and optimization * Advanced computing in operation research * Advanced computing in mechanics and quantum mechanics * Advanced computing in civil engineering * Advanced computing in physics science * Advanced computing in chemistry science * Advanced computing for geosciences and meteorology * Maps and geo-images building * Curve and surface reconstruction * Financial computing and forecasting * Advanced computing in economics * Advanced computing in robotics and manufacturing * Advanced computing on Earth science, geosciences and meteorology * Advanced computing in electronics and electrical science * Advanced computing in power systems * Environmental advanced computing INSTRUCTION FOR THE AUTHORS The ADVCOMP 2007 Proceedings will be published by IEEE Computer Society Press and on-line via IEEE XPlore Digital Library. IEEE will index the papers with major indexes. Only .pdf or .doc files will be accepted for paper submission. All received papers will be acknowledged via the EDAS system. Final author manuscripts will be 8.5" x 11" (two columns IEEE format), not exceeding 6 pages; max 4 extra pages allowed at additional cost. The formatting instructions can be found on the Instructions page . Once you receive the notification of paper acceptance, you will be provided by the IEEE CS Press an online author kit with all the steps an author needs to follow to submit the final version. The author kits URL will be included in the letter of acceptance. Technical marketing/business/positioning presentations The conference initiates a series of business, technical marketing, and positioning presentations on the same topics. Speakers must submit a 10-12 slide deck presentations with substantial notes accompanying the slides, in the .ppt format (.pdf-ed). The slide deck will be published in the conference's CD collection, together with the regular papers. Please send your presentations to petre@iaria.org . Tutorials Tutorials provide overviews of current high interest topics. Proposals can be for half or full day tutorials. Please send your proposals to petre@iaria.org Panel proposals: The organizers encourage scientists and industry leaders to organize dedicated panels dealing with controversial and challenging topics and paradigms. Panel moderators are asked to identify their guests and manage that their appropriate talk supports timely reach our deadlines. Moderators must specifically submit an official proposal, indicating their background, panelist names, their affiliation, the topic of the panel, as well as short biographies. For more information, petre@iaria.org Workshop proposals We welcome workshop proposals on issues complementary to the topics of this conference. Your requests should be forwarded to petre@iaria.org . ================================== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 13:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeELc-0003Xn-JD; Wed, 18 Apr 2007 13:53:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeELa-0003Xb-M1 for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 13:53:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeELa-0003XG-BR; Wed, 18 Apr 2007 13:53:38 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeELa-00089M-1P; Wed, 18 Apr 2007 13:53:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1176918816!21620778!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 4422 invoked from network); 18 Apr 2007 17:53:37 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-9.tower-119.messagelabs.com with SMTP; 18 Apr 2007 17:53:37 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l3IHrZ0n000986; Wed, 18 Apr 2007 12:53:36 -0500 (CDT) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l3IHrZkU014558; Wed, 18 Apr 2007 12:53:35 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l3IHrXH0014534; Wed, 18 Apr 2007 12:53:33 -0500 (CDT) Message-ID: <46265B1E.2040101@gmail.com> Date: Wed, 18 Apr 2007 19:53:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: internet-drafts@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: manet@ietf.org, i-d-announce@ietf.org Subject: [manet] Re: multicast addresses in the MANET solution drafts (was: I-D ACTION:draft-ietf-manet-iana-01.txt) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org In the MANET WG the following multicast addresses are described by respective solution drafts: NHDP, OLSRv2: ALL-MANET-NEIGHBORS SMF: ALL_IPv6_MANET_ROUTERS DYMO: LL_ALL_MANET_ROUTER The "MANET IANA Needs" draft requests the following: "LL MANET Routers" "MANET Routers" There are of course differences at least between the ASCII names for these addresses, if not between the semantics too. Are there plans to modify NHDP, OLSR, SMF and DYMO to textually just use the two addresses of this "MANET IANA Needs" draft? For example, is the OLSRv2 "ALL-MANET-NEIGHBORS" multicast address semantically completely equivalent to "LL MANET Routers"? If yes then it's a significant step forward in accepting a common subnet model. Alex 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 : MANET IANA Needs > Author(s) : I. Chakeres > Filename : draft-ietf-manet-iana-01.txt > Pages : 7 > Date : 2007-4-16 > > This document enumerates IANA assignments for immediate use in MANET. > Specifically, a UDP port, two link-local multicast group addresses > (IPv4 & IPv6), and two site-local multicast group addresses (IPv4 & > IPv6). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > 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-iana-01.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-iana-01.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 14:08:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEZW-0006NA-Qz; Wed, 18 Apr 2007 14:08:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeEZV-0006Mx-8G for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 14:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEZU-0006Ml-1n for manet@ietf.org; Wed, 18 Apr 2007 14:08:00 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEZS-0002np-Kb for manet@ietf.org; Wed, 18 Apr 2007 14:08:00 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3II7v3e025550; Wed, 18 Apr 2007 14:07:57 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007041814075624855 ; Wed, 18 Apr 2007 14:07:56 -0400 From: "Joe Macker" To: "'Alexandru Petrescu'" , "'Ian Chakeres'" References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com><4625F31B.2090807@gmail.com><374005f30704180451x4ac51e77x379b0bb4378c90ca@mail.gmail.com> <46262531.5010002@gmail.com> Subject: RE: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call Date: Wed, 18 Apr 2007 14:07:54 -0400 Message-ID: <043101c781e4$7c6a5b20$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceBwpGdqlkVZfCWR2K11RRDid4FVAAGA5tQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46262531.5010002@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I agree "statically assigned" is confusing and I think Ian meant a well-known address is perhaps better. I think some in the MANET community may be unclear that MLD joins are specified to actually occur for these link-local well known ranges, except FF02::1 all nodes. Actually I think this has been a broader problem in some general IPv6 implementations. Snooping switches,etc being an example of issues. So it's a really a well-known, link-scoped multicast address that is Ian is referencing a request for. And I agree with Alexandru, I was assuming a join would be occur (RFC2710) although MLD,etc may seem less useful in the MANET case. Connecting MANET across filtering L2 technologies is an example. I think the efficiency/robustness issues should be looked at more. -Joe >-----Original Message----- >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >Sent: Wednesday, April 18, 2007 10:03 AM >To: Ian Chakeres >Cc: manet >Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = >WG Last Call > >Ian Chakeres wrote: >> If you look at other routing protocols, they specify a particular >> static multicast address for communication. We are simply allocating >> the same type of addresses for MANET protocols. > >Yes, I agree, but these addresses (eg OSPF's AllSPFRouters >ff02::5) aren't statically assigned, IMHO. A router must join >that group. > >Or maybe we have misunderstanding of 'statically assigning'? > >> See the IANA lists at >> >> http://www.iana.org/assignments/multicast-addresses >> http://www.iana.org/assignments/ipv6-multicast-addresses >> >> Other comments inline. >> >> On 4/18/07, Alexandru Petrescu wrote: >>> Ian Chakeres wrote: >>>> The document includes suggestions by Bill Fenner regarding TBD >>>> numbering, but otherwise has not changed. >>>> >>>> I would like to issue a WG last call on this document. >>> >>> I think there's more work with this document, more than just two >>> weeks Last Call. >> >> There has been little to no change on this document for some time. I >> see no reason to delay its publication. > >Wait for more review? > >>>> If you have any comments, please provide them before May 1st (two >>>> weeks). >>> >>> Thanks for asking for comments, here are some: >>> >>> draft: >>>> MANET routers subscribe to this LL scoped multicast >address and use >>>> it for LL transmissions of routing protocol packets. >>> ... >>>> For IPv6, a statically assigned, link-local scope >multicast address >>>> is used. >> >> The purpose of the multicast group is for MANET router communication. >> MANET routers MUST subscribe to receive messages protocol messages >> on a particular address > >Right, that's what I mean, so they're not 'statically assigned'. > >> and MUST also transmit to the same address to insure >interoperability. > >Yes, when a router sends a packet to a multicast address it >doesn't necessarily have to statically assign that address to >a interface, neither does it have to join that group. > >>> I think there's a big difference between a router subscribing to a >>> multicast address, and statically assigning a multicast >address to an >>> interface. In the above paragraphs you're actually saying the two >>> should happen, for the same multicast address. >>> >>> I personally think the link-scoped multicast address should not be >>> 'statically assigned', but the router should send a MLD message for >>> it, and subsequently be subscribed to that group. >> >> I think that this proposition could significantly delay routing >> convergence and cause many problems in MANET style networks. > >I think there may be an understood multicast way of working >for IPv6, and doing anything different than that ('assign' >multicast addresses without subscribing to the respective >group) can cause many delays in standardizing a novel >multicast method for MANET and IPv6. > >Underlying linklayers for which MANET protocols have been demonstrated >(WiFi) have explicit means to subscribe to link-layer >multicast groups, which work hand in hand with the capability >of receiving network-layer multicast datagrams. > >I don't see any way for a router to receive packets addressed >to a group other than subscribing, or joining, to that group. >Do you see another? > >>> For interface-scoped multicast addresses (ff01::smthing) - I think >>> yes, they can be statically assigned to an interface. >>> >>> Another issue is that AUTOCONF WG seems to be looking at address >>> auto-configuration means for MANET networks. Discovery phase of >>> address auto-configuration often uses multicast addresses. _Maybe_ >>> (I say maybe because without this then DHCP multicast groups can be >>> used) new MANET-AUTOCONF IANA-reserved multicast groups could be >>> reserved by IANA, for MANET autoconfiguration purposes. >> >>> From looking at the AUTOCONF charter >> (http://www.ietf.org/html.charters/autoconf-charter.html) >and problem >> statement, they are working on unicast address >auto-configuration for >> MANET routers. > >Does the AUTOCONF Charter forbid the use of known multicast >mechanisms to auto-configure unicast addresses? If it >doesn't, then AUTOCONF may need new well-known multicast >addresses, with link or site scope, exclusively for the >purpose of unicast address auto-configuration. > >Alex > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit >http://www.messagelabs.com/email >______________________________________________________________________ > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 14:21:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEm9-0000Ru-RF; Wed, 18 Apr 2007 14:21:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeEm7-0000Il-G5 for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 14:21:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEm7-0000Gd-5Y for manet@ietf.org; Wed, 18 Apr 2007 14:21:03 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEm5-0005n2-Tr for manet@ietf.org; Wed, 18 Apr 2007 14:21:03 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3IIL0DD026353; Wed, 18 Apr 2007 14:21:00 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007041814210024941 ; Wed, 18 Apr 2007 14:21:00 -0400 From: "Joe Macker" To: "'Joe Macker'" , "'Alexandru Petrescu'" , "'Ian Chakeres'" References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com><4625F31B.2090807@gmail.com><374005f30704180451x4ac51e77x379b0bb4378c90ca@mail.gmail.com><46262531.5010002@gmail.com> <043101c781e4$7c6a5b20$165cfa84@SEXTANT> Subject: RE: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call Date: Wed, 18 Apr 2007 14:20:57 -0400 Message-ID: <043201c781e6$4f3d3120$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceBwpGdqlkVZfCWR2K11RRDid4FVAAGA5tQAALd7WA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <043101c781e4$7c6a5b20$165cfa84@SEXTANT> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >-----Original Message----- >From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] >Sent: Wednesday, April 18, 2007 2:08 PM >To: 'Alexandru Petrescu'; 'Ian Chakeres' >Cc: 'manet' >Subject: RE: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = >WG Last Call > >I agree "statically assigned" is confusing and I think Ian >meant a well-known address is perhaps better. I think some in >the MANET community may be unclear that MLD joins are >specified to actually occur for these link-local well known >ranges, except FF02::1 all nodes. Actually I think this has >been a broader problem in some general IPv6 implementations. >Snooping switches,etc being an example of issues. > >So it's a really a well-known, link-scoped multicast address >that is Ian is referencing a request for. And I agree with >Alexandru, I was assuming a join would be occur (RFC2710) >although MLD,etc may seem less useful in the MANET case. >Connecting MANET across filtering L2 technologies is an >example. I think the efficiency/robustness issues should be Before I see comments on my logic, I meant to say filtering L2 technologies is an example when it IS useful. >looked at more. >-Joe > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 14:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEpA-0001u0-Pe; Wed, 18 Apr 2007 14:24:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeEp8-0001tr-6P for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 14:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEp7-0001tW-S7; Wed, 18 Apr 2007 14:24:09 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEp7-0006GP-Ha; Wed, 18 Apr 2007 14:24:09 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3IIO8pW026549; Wed, 18 Apr 2007 14:24:08 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007041814240824966 ; Wed, 18 Apr 2007 14:24:08 -0400 From: "Joe Macker" To: "'Alexandru Petrescu'" , References: <46265B1E.2040101@gmail.com> Subject: RE: [manet] Re: multicast addresses in the MANET solution drafts (was:I-D ACTION:draft-ietf-manet-iana-01.txt) Date: Wed, 18 Apr 2007 14:24:05 -0400 Message-ID: <043301c781e6$bf683fd0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceB4qQno+t04jbLR2WQ7tjFQY/IWgAAe5tA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46265B1E.2040101@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: manet@ietf.org, i-d-announce@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Yes, Ian's intention with the IANA ID was to promote convergence to this naming,etc. Most other revisions have occurred in parallel to this date. In the SMF case of ALL_IPv6_MANET_ROUTERS (it was marked TBD with the anticipation of some common approach) it is consistent with the site-scope multicast request in the IANA draft. In the next revision it will reflect that. SMF is EXP targeted but should be consistent. I assume other authors will follow suit with related common link-local references unless there is further debate over this issue. -Joe >-----Original Message----- >From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >Sent: Wednesday, April 18, 2007 1:54 PM >To: internet-drafts@ietf.org >Cc: manet@ietf.org; i-d-announce@ietf.org >Subject: [manet] Re: multicast addresses in the MANET solution >drafts (was:I-D ACTION:draft-ietf-manet-iana-01.txt) > >In the MANET WG the following multicast addresses are >described by respective solution drafts: > >NHDP, OLSRv2: ALL-MANET-NEIGHBORS >SMF: ALL_IPv6_MANET_ROUTERS >DYMO: LL_ALL_MANET_ROUTER > >The "MANET IANA Needs" draft requests the following: > "LL MANET Routers" > "MANET Routers" > >There are of course differences at least between the ASCII >names for these addresses, if not between the semantics too. >Are there plans to modify NHDP, OLSR, SMF and DYMO to >textually just use the two addresses of this "MANET IANA Needs" draft? > >For example, is the OLSRv2 "ALL-MANET-NEIGHBORS" multicast >address semantically completely equivalent to "LL MANET >Routers"? If yes then it's a significant step forward in >accepting a common subnet model. > >Alex > > > >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 : MANET IANA Needs >> Author(s) : I. Chakeres >> Filename : draft-ietf-manet-iana-01.txt >> Pages : 7 >> Date : 2007-4-16 >> >> This document enumerates IANA assignments for immediate use in MANET. >> Specifically, a UDP port, two link-local multicast group addresses >> (IPv4 & IPv6), and two site-local multicast group >addresses (IPv4 & >> IPv6). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-01.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in >the body of >> the message. >> You can also visit >https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> 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-iana-01.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-iana-01.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. >> >> >> >---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce > > >______________________________________________________________________ >This email has been scanned by the MessageLabs Email Security System. >For more information please visit >http://www.messagelabs.com/email >______________________________________________________________________ > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 18 22:48:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeMhH-00081X-9I; Wed, 18 Apr 2007 22:48:35 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeMhF-0007wv-MX for manet-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 22:48:33 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeMhF-0007uk-Br for manet@ietf.org; Wed, 18 Apr 2007 22:48:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeMfi-0006qm-32 for manet@ietf.org; Wed, 18 Apr 2007 22:46:58 -0400 Received: from web35411.mail.mud.yahoo.com ([66.163.179.120]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeMfg-0003vu-5d for manet@ietf.org; Wed, 18 Apr 2007 22:46:58 -0400 Received: (qmail 52780 invoked by uid 60001); 19 Apr 2007 02:46:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=dI3HxEiUOP6UgpPtsuKb/3FCDVadryh3glLepexiKZhj5Wl4ESFlSc/aVJ/W74AqmwRy6dz+LQrDfzfSPR/hbGp7olwhXMwT1FElfnFym90Lcn+8r+vEyUWE4upKyc6e2nzKV/8EK5u35QqQKJqT891Q5/wAP2WIGOLYQVawAY8=; X-YMail-OSG: Ux87XL8VM1kA8cNgGxdMk1e90WeNZSAVYRNWWoZcJKkFqhFxyHSULV_MZtdg.KFoQu9fkB_e.WjPTRpViygaWn.qorjJJAW6QPQTccNi.co2jL76crsm4BiCjOf_ew-- Received: from [202.184.37.1] by web35411.mail.mud.yahoo.com via HTTP; Wed, 18 Apr 2007 19:46:55 PDT Date: Wed, 18 Apr 2007 19:46:55 -0700 (PDT) From: Farzaneh Razavi Armaghani To: manet@ietf.org MIME-Version: 1.0 Message-ID: <587481.50221.qm@web35411.mail.mud.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-TMDA-Confirmed: Wed, 18 Apr 2007 22:48:33 -0400 Subject: [manet] TCP-New Reno in GloMoSim X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0824952773==" Errors-To: manet-bounces@ietf.org --===============0824952773== Content-Type: multipart/alternative; boundary="0-379142683-1176950815=:50221" Content-Transfer-Encoding: 8bit --0-379142683-1176950815=:50221 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear all, What is the current TCP flavor implemented in GloMoSim2.03? For my study, I need the Tcp-New Reno flavor source code in GloMoSim. Can you please help me where can I get the source codes or introducing a good resource or telling me the necessary changings over the current one in Glomosim? Thanks in advanced, Farzaneh. --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. --0-379142683-1176950815=:50221 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dear all,
 
What is the current TCP flavor implemented in GloMoSim2.03? For my study, I need the Tcp-New Reno flavor source code in GloMoSim. 
Can you please help me where can I get the source codes or introducing a good resource or telling me the necessary changings over the current one in Glomosim?
 
Thanks in advanced,
Farzaneh.  

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-379142683-1176950815=:50221-- --===============0824952773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0824952773==-- From manet-bounces@ietf.org Thu Apr 19 03:25:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeR0u-0000NI-S3; Thu, 19 Apr 2007 03:25:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeR0t-0000ND-2N for manet-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 03:25:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeR0s-0000N5-OA for manet@ietf.org; Thu, 19 Apr 2007 03:25:06 -0400 Received: from mail4.myhsphere.biz ([204.14.104.85]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeR0r-0008Nm-IF for manet@ietf.org; Thu, 19 Apr 2007 03:25:06 -0400 Received: (qmail 10994 invoked by uid 399); 19 Apr 2007 07:25:02 -0000 Received: from host06.osdp.cs.tsukuba.ac.jp (HELO khoriba) (130.158.83.86) by mail4.myhsphere.biz with SMTP; 19 Apr 2007 07:25:02 -0000 Message-ID: <007b01c78253$dcbf75e0$56539e82@khoriba> From: "ghada" To: References: <46265B1E.2040101@gmail.com> Date: Thu, 19 Apr 2007 16:25:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [manet] [about Wireless Sensor Network Simulation] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear all, Can any one advice me, about the best simulator I can use for wireless sensor network protocols and security. Thanks in advance. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 19 04:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeRr6-0003O3-2k; Thu, 19 Apr 2007 04:19:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeRr3-0003NT-OD for manet-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 04:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeRnI-0008Pf-PX; Thu, 19 Apr 2007 04:15:08 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeRZd-0000HN-2M; Thu, 19 Apr 2007 04:01:02 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3J80xES012618; Thu, 19 Apr 2007 09:00:59 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3J80xxe006998; Thu, 19 Apr 2007 09:00:59 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 19 Apr 2007 09:00:59 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Apr 2007 09:00:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Re: multicast addresses in the MANET solution drafts(was:I-D ACTION:draft-ietf-manet-iana-01.txt) Date: Thu, 19 Apr 2007 08:59:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: multicast addresses in the MANET solution drafts(was:I-D ACTION:draft-ietf-manet-iana-01.txt) Thread-Index: AceB4qQno+t04jbLR2WQ7tjFQY/IWgAAe5tAABzrA+A= From: "Dearlove, Christopher \(UK\)" To: "Joe Macker" , "Alexandru Petrescu" , X-OriginalArrivalTime: 19 Apr 2007 08:00:06.0967 (UTC) FILETIME=[BE975470:01C78258] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: manet@ietf.org, i-d-announce@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org From: Joe Macker [mailto:joseph.macker@nrl.navy.mil]=20 > I assume other authors will > follow suit with related common link-local references unless there is > further debate over this issue. The next issues of NHDP and OLSRv2 will reference draft-ietf-manet-iana and its LL address (and UDP port number). ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 19 07:57:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeVG0-0001d2-T9; Thu, 19 Apr 2007 07:57:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeVFz-0001cv-0W for manet-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 07:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeVFy-0001cn-Mf for manet@ietf.org; Thu, 19 Apr 2007 07:56:58 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeVFx-0000CX-8y for manet@ietf.org; Thu, 19 Apr 2007 07:56:58 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1176983816!13068498!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2744 invoked from network); 19 Apr 2007 11:56:56 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-7.tower-119.messagelabs.com with SMTP; 19 Apr 2007 11:56:56 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3JBuuR2029158; Thu, 19 Apr 2007 04:56:56 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3JButLM002322; Thu, 19 Apr 2007 06:56:55 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3JBur0Q002246; Thu, 19 Apr 2007 06:56:54 -0500 (CDT) Message-ID: <46275902.8030106@gmail.com> Date: Thu, 19 Apr 2007 13:56:50 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Joe Macker Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com><4625F31B.2090807@gmail.com><374005f30704180451x4ac51e77x379b0bb4378c90ca@mail.gmail.com> <46262531.5010002@gmail.com> <043101c781e4$7c6a5b20$165cfa84@SEXTANT> In-Reply-To: <043101c781e4$7c6a5b20$165cfa84@SEXTANT> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: 'manet' , 'Alexandru Petrescu' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Joe Macker wrote: > I agree "statically assigned" is confusing and I think Ian meant a > well-known address is perhaps better. I agree 'well-known address' is better than 'statically assigned'. > I think some in the MANET community may be unclear that MLD joins are > specified to actually occur for these link-local well known ranges, > except FF02::1 all nodes. Actually I think this has been a broader > problem in some general IPv6 implementations. Snooping switches,etc > being an example of issues. I think indeed a broader set of issues. But even for all-nodes link-local scope ff02::1 the node must join the group. I think the only addresses for which it is sufficient to statically assign (no need to join, no need to set local filters) are the multicast addresses with interface-local scope (not site-local, not link-local, not global). Like all-nodes ff01::1 (not ff02::1) . Alex > So it's a really a well-known, link-scoped multicast address that is > Ian is referencing a request for. And I agree with Alexandru, I was > assuming a join would be occur (RFC2710) although MLD,etc may seem > less useful in the MANET case. Connecting MANET across filtering L2 > technologies is an example. I think the efficiency/robustness issues > should be looked at more. -Joe > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, April 18, >> 2007 10:03 AM To: Ian Chakeres Cc: manet Subject: Re: [manet] I-D >> ACTION:draft-ietf-manet-iana-01.txt = WG Last Call >> >> Ian Chakeres wrote: >>> If you look at other routing protocols, they specify a particular >>> static multicast address for communication. We are simply >>> allocating the same type of addresses for MANET protocols. >> Yes, I agree, but these addresses (eg OSPF's AllSPFRouters ff02::5) >> aren't statically assigned, IMHO. A router must join that group. >> >> Or maybe we have misunderstanding of 'statically assigning'? >> >>> See the IANA lists at >>> >>> http://www.iana.org/assignments/multicast-addresses >>> http://www.iana.org/assignments/ipv6-multicast-addresses >>> >>> Other comments inline. >>> >>> On 4/18/07, Alexandru Petrescu >>> wrote: >>>> Ian Chakeres wrote: >>>>> The document includes suggestions by Bill Fenner regarding >>>>> TBD numbering, but otherwise has not changed. >>>>> >>>>> I would like to issue a WG last call on this document. >>>> I think there's more work with this document, more than just >>>> two weeks Last Call. >>> There has been little to no change on this document for some >>> time. I see no reason to delay its publication. >> Wait for more review? >> >>>>> If you have any comments, please provide them before May 1st >>>>> (two weeks). >>>> Thanks for asking for comments, here are some: >>>> >>>> draft: >>>>> MANET routers subscribe to this LL scoped multicast >> address and use >>>>> it for LL transmissions of routing protocol packets. >>>> ... >>>>> For IPv6, a statically assigned, link-local scope >> multicast address >>>>> is used. >>> The purpose of the multicast group is for MANET router >>> communication. MANET routers MUST subscribe to receive messages >>> protocol messages on a particular address >> Right, that's what I mean, so they're not 'statically assigned'. >> >>> and MUST also transmit to the same address to insure >> interoperability. >> >> Yes, when a router sends a packet to a multicast address it doesn't >> necessarily have to statically assign that address to a interface, >> neither does it have to join that group. >> >>>> I think there's a big difference between a router subscribing >>>> to a multicast address, and statically assigning a multicast >> address to an >>>> interface. In the above paragraphs you're actually saying the >>>> two should happen, for the same multicast address. >>>> >>>> I personally think the link-scoped multicast address should not >>>> be 'statically assigned', but the router should send a MLD >>>> message for it, and subsequently be subscribed to that group. >>> I think that this proposition could significantly delay routing >>> convergence and cause many problems in MANET style networks. >> I think there may be an understood multicast way of working for >> IPv6, and doing anything different than that ('assign' multicast >> addresses without subscribing to the respective group) can cause >> many delays in standardizing a novel multicast method for MANET and >> IPv6. >> >> Underlying linklayers for which MANET protocols have been >> demonstrated (WiFi) have explicit means to subscribe to link-layer >> multicast groups, which work hand in hand with the capability of >> receiving network-layer multicast datagrams. >> >> I don't see any way for a router to receive packets addressed to a >> group other than subscribing, or joining, to that group. Do you see >> another? >> >>>> For interface-scoped multicast addresses (ff01::smthing) - I >>>> think yes, they can be statically assigned to an interface. >>>> >>>> Another issue is that AUTOCONF WG seems to be looking at >>>> address auto-configuration means for MANET networks. Discovery >>>> phase of address auto-configuration often uses multicast >>>> addresses. _Maybe_ (I say maybe because without this then DHCP >>>> multicast groups can be used) new MANET-AUTOCONF IANA-reserved >>>> multicast groups could be reserved by IANA, for MANET >>>> autoconfiguration purposes. From looking at the AUTOCONF >>>> charter >>> (http://www.ietf.org/html.charters/autoconf-charter.html) >> and problem >>> statement, they are working on unicast address >> auto-configuration for >>> MANET routers. >> Does the AUTOCONF Charter forbid the use of known multicast >> mechanisms to auto-configure unicast addresses? If it doesn't, >> then AUTOCONF may need new well-known multicast addresses, with >> link or site scope, exclusively for the purpose of unicast address >> auto-configuration. >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> >> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet >> > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 19 09:40:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWri-0007mB-LL; Thu, 19 Apr 2007 09:40:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeWrg-0007lo-1Q for manet-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 09:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWrf-0007lg-Nl for manet@ietf.org; Thu, 19 Apr 2007 09:39:59 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeWre-00028Y-Fd for manet@ietf.org; Thu, 19 Apr 2007 09:39:59 -0400 Received: by nz-out-0506.google.com with SMTP id z6so501593nzd for ; Thu, 19 Apr 2007 06:39:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Su9FQtzBZbMxAcHs1Sm5XzR4TgLZOit8HniaPBBsMk+cCG1xkBt1evVkS8IW23k47lo8x1f65cyxpffFjEGblP6QFc2BzXihyENLk6yFoKPMUN2PT9zpmOrWJ+a6pu7yHxUVf2iI9+CdPuQJI6SC5k+HAB+7azSRhUG+JQY7I6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PJ/53dUE9jS+uL9r9A5qqgMODgnFu1YRHPhuXbEypf4iyyZD1av5NJ0ssQ4KDLKWvunK0RQz2hzxu8mQ5UUMfVs66yNDbg8xCMYgY/DstGNG5hoA8pbpZm4FZpqgYbIPE30HunjaTcn4bC15DOm+yV8mC9Md2OE/ace4h7nJ3Co= Received: by 10.115.110.6 with SMTP id n6mr748104wam.1176989997621; Thu, 19 Apr 2007 06:39:57 -0700 (PDT) Received: by 10.114.72.7 with HTTP; Thu, 19 Apr 2007 06:39:52 -0700 (PDT) Message-ID: Date: Thu, 19 Apr 2007 23:39:52 +1000 From: "Kalvinder Singh" To: ghada Subject: Re: [manet] [about Wireless Sensor Network Simulation] In-Reply-To: <007b01c78253$dcbf75e0$56539e82@khoriba> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46265B1E.2040101@gmail.com> <007b01c78253$dcbf75e0$56539e82@khoriba> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org There are a few. Depends on the OS, you are using, the platforms, the number of nodes, etc. If you are using TinyOS, I would suggest you start with TOSSIM. I have also used ATEMU, and did some work with NS-2. However, it depends on what you are trying to measure. But the best one to use first would still have to be TOSSIM. Cheers, Kal. On 4/19/07, ghada wrote: > Dear all, > Can any one advice me, about the best simulator I can use for wireless > sensor network protocols and security. > > Thanks in advance. > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 19 19:30:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heg4u-0006EG-Op; Thu, 19 Apr 2007 19:30:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Heg4j-0006Dc-T8 for manet-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 19:30:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heg4i-0006DT-Vt for manet@ietf.org; Thu, 19 Apr 2007 19:30:05 -0400 Received: from smtp.humber.ca ([192.75.71.6] helo=artax.humber.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heg4f-0002Th-CR for manet@ietf.org; Thu, 19 Apr 2007 19:30:04 -0400 Received: from artax.humber.ca (127.0.0.1) by artax.humber.ca (MlfMTA v3.2r1b3) id h4vtoo0171sc for ; Thu, 19 Apr 2007 19:30:19 -0400 (envelope-from ) Received: from Denkomobility ([142.214.30.16]) by artax.humber.ca (MAILSCANNER) with ESMTP; Thu, 19 Apr 2007 19:30:19 -0400 Message-ID: <018a01c782da$aea3f2d0$2e02a8c0@Denkomobility> From: "Mieso Denko" To: Date: Thu, 19 Apr 2007 19:30:14 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mlf-Version: 5.0.3.8711 X-Mlf-UniqueId: o200704192330190096002 X-Spam-Score: 0.3 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Subject: [manet] CFP: IST-AWST 2007 --- ONE DAY LEFT (Deadline 20 April 2007) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1270889172==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1270889172== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0187_01C782B9.2751EE70" This is a multi-part message in MIME format. ------=_NextPart_000_0187_01C782B9.2751EE70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** LAST CALL for PAPERS ****=20 The 2nd International Workshop on Intelligent Systems Techniques for Ad = hoc and Wireless Sensor Networks (IST-AWSN'07) 28 August - 1 September, 2007 http://cs.acadiau.ca/~eshakshu/IST-WSN-2007.htm in conjunction with The Fifth International Symposium on Parallel and Distributed Processing and Applications 28 August - 1 September, 2007 http://www.cs.umanitoba.ca/~ispa07/ Important Workshop Dates: Paper Submission: 10 April 2007 Author Notification: 10 May 2007 Camera-ready Due: 10 June 2007 Location: Niagara Falls, Ontario, Canada. Description: Recent developments of low-cost, low-power, multifunctional wireless sensors have enabled the fast growth of Wireless Sensor Network (WSN) applications, which include security, military, agriculture, automation, environmental and habitat monitoring. WSNs consist of numerous small inexpensive battery powered sensors; each sensor has the capability to process and store the sensor data. A combination of the dense deployment of numerous smart sensors, AI techniques, and intelligent agents can provide continuous real-time monitoring that is precise, accurate, reliable, and inexpensive. This workshop aims to bring together researchers and practitioners working on different aspects of ad-hoc and wireless sensor networks and software agent technology in an effort to highlight the state-of-the-art and discuss the challenges and opportunities to explore new research directions. We strongly welcome submissions that include results which advance the state of the art relating to the theme of the workshop. The main topics to be addressed include (but not limited to): - Adaptive agents in AWSN - Agent security and trust in AWSNs - Agent-based architectures for AWSNs - Agents design issues dealing with reliability, efficiency, and fault tolerance - Database management systems for AWSNs - Distributed management systems for AWSNs - Intelligent data fusion and aggregation - Intelligent query and data dissemination - Intelligent systems for AWSNs - Learning agents in AWSN - Mobile agents in AWSNs - Monitoring agents in AWSN - Peer-to-Peer systems for AWSNs - Power management and energy-efficient protocols - Routing protocols for AWSNs - Safe transmissions of data in AWSNs - Self-organization of AWSNs - Smart energy-efficient routing protocols Publication Only original papers will be considered that have neither been published nor submitted for publication elsewhere, including web publication. All submissions will be handled electronically. The length of the paper is limited to 15 pages. All papers will be reviewed by at least two independent reviewers. Accepted papers will be published in Springer's Lecture Notes in Computer Science workshops proceedings. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Authors of high quality papers presented in the workshop will be invited to submit extended version of their papers for publication in an international journal. Last year, selected papers were extended and accepted for publication in a special issue in the Journal of Information Fusion, Elsevier Science. Workshop Organizers: Elhadi Shakshuki, Acadia University Darcy Benoit, Acadia University Mieso Denko, University of Guelph, Canada ------=_NextPart_000_0187_01C782B9.2751EE70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
*****  LAST  CALL for PAPERS **** 
 
 
The 2nd International Workshop on Intelligent Systems Techniques = for Ad hoc=20 and Wireless Sensor Networks (IST-AWSN'07)
28 August - 1 September,=20 2007
http://cs.acadiau.ca/~eshakshu/IST-WSN-2007.htm


= in=20 conjunction with The Fifth International Symposium on Parallel=20 and
Distributed Processing and Applications
28 August - 1 = September,=20 2007
http://www.cs.umanitoba.ca/~ispa07/

Important=20 Workshop Dates:
Paper Submission: 10 April 2007
Author = Notification: 10=20 May 2007
Camera-ready Due: 10 June 2007

Location: Niagara = Falls,=20 Ontario, Canada.

Description:

Recent developments of = low-cost,=20 low-power, multifunctional wireless
sensors have enabled the fast = growth of=20 Wireless Sensor Network (WSN)
applications, which include security, = military,=20 agriculture, automation,
environmental and habitat monitoring. WSNs = consist=20 of numerous small
inexpensive battery powered sensors; each sensor = has the=20 capability to
process and store the sensor data. A combination of the = dense=20 deployment
of numerous smart sensors, AI techniques, and intelligent = agents=20 can
provide continuous real-time monitoring that is precise,=20 accurate,
reliable, and inexpensive.

This workshop aims to = bring=20 together researchers and practitioners
working on different aspects = of ad-hoc=20 and wireless sensor networks and
software agent technology in an = effort to=20 highlight the state-of-the-art
and discuss the challenges and = opportunities=20 to explore new research
directions. We strongly welcome submissions = that=20 include results which
advance the state of the art relating to the = theme of=20 the workshop.

The main topics to be addressed include (but not = limited=20 to):

- Adaptive agents in AWSN
- Agent security and trust in=20 AWSNs
- Agent-based architectures for AWSNs
- Agents design issues = dealing=20 with reliability, efficiency, and fault
tolerance
- Database = management=20 systems for AWSNs
- Distributed management systems for AWSNs
- = Intelligent=20 data fusion and aggregation
- Intelligent query and data = dissemination
-=20 Intelligent systems for AWSNs
- Learning agents in AWSN
- Mobile = agents in=20 AWSNs
- Monitoring agents in AWSN
- Peer-to-Peer systems for = AWSNs
-=20 Power management and energy-efficient protocols
- Routing protocols = for=20 AWSNs
- Safe transmissions of data in AWSNs
- Self-organization of = AWSNs
- Smart energy-efficient routing=20 protocols

Publication

Only original papers will be = considered that=20 have neither been published
nor submitted for publication elsewhere,=20 including web publication. All
submissions will be handled = electronically.=20 The length of the paper is
limited to 15 pages. All papers will be = reviewed=20 by at least two
independent reviewers.

Accepted papers will be = published in Springer's Lecture Notes in
Computer Science workshops=20 proceedings. Submission of a paper should be
regarded as a commitment = that,=20 should the paper be accepted, at least
one of the authors will = register and=20 attend the conference to present
the work.

Authors of high = quality=20 papers presented in the workshop will be invited
to submit extended = version=20 of their papers for publication in an
international journal. Last = year,=20 selected papers were extended and
accepted for publication in a = special issue=20 in the Journal of
Information Fusion, Elsevier = Science.


Workshop=20 Organizers:
Elhadi Shakshuki, Acadia University
Darcy Benoit, = Acadia=20 University
Mieso Denko, University of Guelph,=20 Canada
------=_NextPart_000_0187_01C782B9.2751EE70-- --===============1270889172== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1270889172==-- From manet-bounces@ietf.org Thu Apr 19 22:44:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hej6P-0003bL-J6; Thu, 19 Apr 2007 22:44:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hej6N-0003RT-O6 for manet-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 22:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hej6N-0003Ml-7Y for manet@ietf.org; Thu, 19 Apr 2007 22:43:59 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hej6L-0001yv-Mx for manet@ietf.org; Thu, 19 Apr 2007 22:43:59 -0400 Received: by wx-out-0506.google.com with SMTP id h31so867342wxd for ; Thu, 19 Apr 2007 19:43:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=kcxpCaWaiYp4PRsR5g8MzzkCmjsm7HB09RF9LhXD4Twh1fuRldT6UlrW3P9eQJdVCagroBt9rsNT216yIfXfuHhvFGB3ji9UFn3VsHNczxSibdlnqd5mqHJ5jsM8IBrvB3WozuraAuFlCCQe3JEKKhlVdN8bEvB69dLbV8kgfzk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=d3Ax8KysWwKOQHbnGUhvKzHJgu1yT2UcsYJnljvJhhlYFyRd0qJkrDhFMQGDLTfSFoXRo6gBnpt2CJsuH3Zu22GWVEzwqvN/1Fjyo8CYzu4/TchDi07ewlbANPQjdSbV9p5MbxJAmqjl+KIoa+g8uKhf16khbOppUZRmIQoOVn0= Received: by 10.90.27.13 with SMTP id a13mr2651113aga.1177037037274; Thu, 19 Apr 2007 19:43:57 -0700 (PDT) Received: by 10.90.117.11 with HTTP; Thu, 19 Apr 2007 19:43:57 -0700 (PDT) Message-ID: Date: Thu, 19 Apr 2007 22:43:57 -0400 From: "Jinhua Guo" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [manet] 2nd CFP: IEEE MHWMN'07 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1695738033==" Errors-To: manet-bounces@ietf.org --===============1695738033== Content-Type: multipart/alternative; boundary="----=_Part_30273_12273549.1177037037236" ------=_Part_30273_12273549.1177037037236 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We apologize if you receive multiple copies of this message. --- STARTS--- ***** Second Call for Papers ***** --------------------------------------------------------------------------- Third IEEE International Workshop on Heterogeneous Multi-Hop Wireless and Mobile Networks 2007 (IEEE MHWMN'07) Website: http://www.cis.uoguelph.ca/~denko/mhwmn07.html Held with The Fourth IEEE International Conference on Mobile Ad-hoc and Sensor Systems - MASS 2007 (http://cnd.iit.cnr.it/mass2007/) , Pisa, Italy, 8 - 11 October 2007 --------------------------------------------------------------------------- AIM and SCOPE ------------- The traditional centralized wireless and mobile networks are based on single-hop architecture and rely on the existing fixed infrastructure such as base stations or access points. The proliferation and deployment of radio access networks such as Wireless WANs, Wireless LANs, and Wireless PANs with distinguishing characteristics of data rate, coverage range, power, mobility, and prices will clearly lead to a need for seamless and ubiquitous access across these various networks. Such an integrated heterogeneous environment enables a user to access a particular network depending upon the application needs and the types of radio access networks (RANs) available (e.g., cellular network, ad hoc, WLAN, WPAN etc). The heterogeneous multi-hop wireless and mobile networks, on the other hand, provide unlimited mobility and greater flexibility but introduce a number of challenges due to dynamic network topology. The design of efficient and scalable protocols for existing multi-hop wireless and mobile networks such as wireless and mobile ad hoc networks continue to pose challenges at all the layers of networking stack. Therefore, it is necessary to investigate a global heterogeneous architecture and services that together provide seamless integration of single-hop networks ( e.g., cellular, WLAN, WWAN) and multi-hop mobile ad hoc networks. The aim of this workshop is to bring together practitioners and researchers from both academia and industry in order to have a forum for discussion and technical presentations on the latest research and future research directions in heterogeneous multi-hop wireless and mobile networks. We are seeking original and previously unpublished research papers addressing theoretical and application issues in heterogeneous multi-hop wireless mobile networks. TOPICS ------ Topics of interest include, but are not limited to, the following areas: Multi-hop architectures and protocols for resource management Quality of services (QoS) delivery in MHWMN Seamless Mobility, Vertical Handoff Robust and scalable routing protocols for MHWMN MAC protocols for MHWMN Self-configuration and synchronization for MHWMN Security issues in MHWMN Topology control and management for MHWMN Mobility models and location management in MHWMN Wireless Mesh networks Cross-layer design and interactions for MHWMN Modeling and performance evaluation for MHWMN Algorithms for localization and signal processing in MHWMN Implementation testbeds for MHWMN Operating systems and middleware for MHWMN SUBMISSIONS ---------- See (http://www.cis.uoguelph.ca/~denko/mhwmn07.html) IMPORTANT DATES: --------------- Submission deadline: May 15, 2007 Author Notification: July 16, 2007 Camera Ready papers: August 10, 2007 Workshop date: October 8, 2007 Organizing Committee ------------------- General Co-Chair Anup Kumar Computer Engineering and Computer Science Dept. University of Louisville, USA Email: ak@louisville.edu Program Co-Chairs Qing-An Zeng Department of Computer Science, University of Cincinnati, USA Email: qzeng@ececs.uc.edu Mieso Denko Dept. of Computing and Info. Science University of Guelph, Ontario, Canada Email: denko@cis.uoguelph.ca Publicity Chair Jinhua Guo Computer and Info. Science Dept. The Univer sity of Michigan-Deaborn, USA Email: jinhua@umich.edu Contacts For any enquiries related to the workshop please contact the program Co-Chairs at the addresses given above. PROGRAM COMMITTEE: See (http://www.cis.uoguelph.ca/~denko/mhwmn07.html ) --- ENDS --- ------=_Part_30273_12273549.1177037037236 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We apologize if you receive multiple copies of this message.


---  STARTS---

***** Second Call for Papers *****

---------------------------------------------------------------------------
 Third IEEE International Workshop on Heterogeneous Multi-Hop Wireless
 and Mobile Networks 2007 (IEEE MHWMN'07)

 Website: http://www.cis.uoguelph.ca/~denko/mhwmn07.html

  Held with The Fourth IEEE International Conference on Mobile Ad-hoc and
  Sensor Systems - MASS 2007 ( http://cnd.iit.cnr.it/mass2007/) , Pisa,
  Italy, 8 - 11 October 2007
---------------------------------------------------------------------------

AIM and SCOPE
-------------

The traditional centralized wireless and mobile networks
are based on single-hop architecture and rely on the existing fixed
infrastructure such as base stations or access points. The proliferation
and deployment of radio access networks such as Wireless WANs, Wireless
LANs, and Wireless PANs with distinguishing characteristics of data rate,
coverage range, power, mobility, and prices will clearly lead to a need
for seamless and ubiquitous access across these various networks. Such an
integrated heterogeneous environment enables a user to access a particular
network depending upon the application needs and the types of radio access
networks (RANs) available (e.g., cellular network, ad hoc, WLAN, WPAN
etc). The heterogeneous multi-hop wireless and mobile networks, on the
other hand, provide unlimited mobility and greater flexibility but
introduce a number of challenges due to dynamic network topology. The
design of efficient and scalable protocols for existing multi-hop wireless
and mobile networks such as wireless and mobile ad hoc networks continue
to pose challenges at all the layers of networking stack. Therefore, it is
necessary to investigate a global heterogeneous architecture and services
that together provide seamless integration of single-hop networks ( e.g.,
cellular, WLAN, WWAN) and multi-hop mobile ad hoc networks.

The aim of this workshop is to bring together practitioners and
researchers from both academia and industry in order to have a forum for
discussion and technical presentations on the latest research and future
research directions in heterogeneous multi-hop wireless and mobile
networks. We are seeking original and previously unpublished research
papers addressing theoretical and application issues in heterogeneous
multi-hop wireless mobile networks.

TOPICS
------

Topics of interest include, but are not limited to, the following areas:

Multi-hop architectures and protocols for resource management
Quality of services (QoS) delivery in MHWMN
Seamless Mobility, Vertical Handoff
Robust and scalable routing protocols for MHWMN
MAC protocols for MHWMN
Self-configuration and synchronization for MHWMN
Security issues in MHWMN
Topology control and management for MHWMN
Mobility models and location management in MHWMN
Wireless Mesh networks
Cross-layer design and interactions for MHWMN
Modeling and performance evaluation for MHWMN
Algorithms for localization and signal processing in MHWMN
Implementation testbeds for MHWMN
Operating systems and middleware for MHWMN


SUBMISSIONS
----------
See ( http://www.cis.uoguelph.ca/~denko/mhwmn07.html)


IMPORTANT DATES:
---------------

Submission deadline:      May 15, 2007
Author Notification:      July 16, 2007
Camera Ready papers:      August 10, 2007
Workshop date:            October 8, 2007


Organizing Committee
-------------------

General Co-Chair

Anup Kumar
Computer Engineering and Computer Science Dept.
University of Louisville, USA
Email: ak@louisville.edu

Program Co-Chairs

Qing-An Zeng
Department of Computer Science,
University of Cincinnati, USA
Email: qzeng@ececs.uc.edu

Mieso Denko
Dept. of Computing and Info. Science
University of Guelph, Ontario, Canada
Email: denko@cis.uoguelph.ca

Publicity Chair

Jinhua Guo
Computer and Info. Science Dept.
The Univer sity of Michigan-Deaborn, USA
Email: jinhua@umich.edu

Contacts

For any enquiries related to the workshop please contact the
program Co-Chairs at the addresses given above.



PROGRAM COMMITTEE:

See ( http://www.cis.uoguelph.ca/~denko/mhwmn07.html )

---  ENDS ---
------=_Part_30273_12273549.1177037037236-- --===============1695738033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1695738033==-- From manet-bounces@ietf.org Thu Apr 19 23:57:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HekFA-0007sc-0G; Thu, 19 Apr 2007 23:57:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HekF7-0007sX-Ud for manet-confirm+ok@megatron.ietf.org; Thu, 19 Apr 2007 23:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HekF7-0007sP-Ko for manet@ietf.org; Thu, 19 Apr 2007 23:57:05 -0400 Received: from ik-out-1112.google.com ([66.249.90.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HekF6-0002kO-0X for manet@ietf.org; Thu, 19 Apr 2007 23:57:05 -0400 Received: by ik-out-1112.google.com with SMTP id c21so889102ika for ; Thu, 19 Apr 2007 20:57:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Cb8yTIx7r2xx3dUDU7oFCQ2ZO9nvFiN97ztyRh00Dt5zbhzSY6AQMzvugCs649YyaF2WtarlKeQkUJ5e6F7lf8JHAgW27KqSDfi1RscBXHNwyJ30Z2LvBBG4sl7uLmXBVptvGBGREoXXzwhYMOKXxbBSiuxPVlejdi9FejxGj+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=raqcBrohH4p733eDK1xgZ2l4D1G+vkysXMBLgiJkx9ZbrZXZf1r3ZD9/AWOV3/05U4Kp5aWGNdwafV8uh72caNhDvpJmsKgDZvuxjpVHHXZ9uITARlA+D6USfPfDPQdNGRC+nkOnDrhJTbRFJo7d5yNbwjiMi9c4PBSS5fcZoBM= Received: by 10.78.181.13 with SMTP id d13mr431595huf.1177041422719; Thu, 19 Apr 2007 20:57:02 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Thu, 19 Apr 2007 20:57:02 -0700 (PDT) Message-ID: <374005f30704192057v4bd16d37oed98ad9ec9c7dff4@mail.gmail.com> Date: Fri, 20 Apr 2007 09:27:02 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call In-Reply-To: <46275902.8030106@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> <4625F31B.2090807@gmail.com> <374005f30704180451x4ac51e77x379b0bb4378c90ca@mail.gmail.com> <46262531.5010002@gmail.com> <043101c781e4$7c6a5b20$165cfa84@SEXTANT> <46275902.8030106@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I will updated the draft to as per the discussion below. If anyone has any other technical, grammatical, or other comments, please let me know and I will incorporate them into the revision. Ian Chakeres On 4/19/07, Alexandru Petrescu wrote: > Joe Macker wrote: > > I agree "statically assigned" is confusing and I think Ian meant a > > well-known address is perhaps better. > > I agree 'well-known address' is better than 'statically assigned'. > > > I think some in the MANET community may be unclear that MLD joins are > > specified to actually occur for these link-local well known ranges, > > except FF02::1 all nodes. Actually I think this has been a broader > > problem in some general IPv6 implementations. Snooping switches,etc > > being an example of issues. > > I think indeed a broader set of issues. > > But even for all-nodes link-local scope ff02::1 the node must join the > group. I think the only addresses for which it is sufficient to > statically assign (no need to join, no need to set local filters) are > the multicast addresses with interface-local scope (not site-local, not > link-local, not global). Like all-nodes ff01::1 (not ff02::1) . > > Alex > > > So it's a really a well-known, link-scoped multicast address that is > > Ian is referencing a request for. And I agree with Alexandru, I was > > assuming a join would be occur (RFC2710) although MLD,etc may seem > > less useful in the MANET case. Connecting MANET across filtering L2 > > technologies is an example. I think the efficiency/robustness issues > > should be looked at more. -Joe > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@gmail.com] Sent: Wednesday, April 18, > >> 2007 10:03 AM To: Ian Chakeres Cc: manet Subject: Re: [manet] I-D > >> ACTION:draft-ietf-manet-iana-01.txt = WG Last Call > >> > >> Ian Chakeres wrote: > >>> If you look at other routing protocols, they specify a particular > >>> static multicast address for communication. We are simply > >>> allocating the same type of addresses for MANET protocols. > >> Yes, I agree, but these addresses (eg OSPF's AllSPFRouters ff02::5) > >> aren't statically assigned, IMHO. A router must join that group. > >> > >> Or maybe we have misunderstanding of 'statically assigning'? > >> > >>> See the IANA lists at > >>> > >>> http://www.iana.org/assignments/multicast-addresses > >>> http://www.iana.org/assignments/ipv6-multicast-addresses > >>> > >>> Other comments inline. > >>> > >>> On 4/18/07, Alexandru Petrescu > >>> wrote: > >>>> Ian Chakeres wrote: > >>>>> The document includes suggestions by Bill Fenner regarding > >>>>> TBD numbering, but otherwise has not changed. > >>>>> > >>>>> I would like to issue a WG last call on this document. > >>>> I think there's more work with this document, more than just > >>>> two weeks Last Call. > >>> There has been little to no change on this document for some > >>> time. I see no reason to delay its publication. > >> Wait for more review? > >> > >>>>> If you have any comments, please provide them before May 1st > >>>>> (two weeks). > >>>> Thanks for asking for comments, here are some: > >>>> > >>>> draft: > >>>>> MANET routers subscribe to this LL scoped multicast > >> address and use > >>>>> it for LL transmissions of routing protocol packets. > >>>> ... > >>>>> For IPv6, a statically assigned, link-local scope > >> multicast address > >>>>> is used. > >>> The purpose of the multicast group is for MANET router > >>> communication. MANET routers MUST subscribe to receive messages > >>> protocol messages on a particular address > >> Right, that's what I mean, so they're not 'statically assigned'. > >> > >>> and MUST also transmit to the same address to insure > >> interoperability. > >> > >> Yes, when a router sends a packet to a multicast address it doesn't > >> necessarily have to statically assign that address to a interface, > >> neither does it have to join that group. > >> > >>>> I think there's a big difference between a router subscribing > >>>> to a multicast address, and statically assigning a multicast > >> address to an > >>>> interface. In the above paragraphs you're actually saying the > >>>> two should happen, for the same multicast address. > >>>> > >>>> I personally think the link-scoped multicast address should not > >>>> be 'statically assigned', but the router should send a MLD > >>>> message for it, and subsequently be subscribed to that group. > >>> I think that this proposition could significantly delay routing > >>> convergence and cause many problems in MANET style networks. > >> I think there may be an understood multicast way of working for > >> IPv6, and doing anything different than that ('assign' multicast > >> addresses without subscribing to the respective group) can cause > >> many delays in standardizing a novel multicast method for MANET and > >> IPv6. > >> > >> Underlying linklayers for which MANET protocols have been > >> demonstrated (WiFi) have explicit means to subscribe to link-layer > >> multicast groups, which work hand in hand with the capability of > >> receiving network-layer multicast datagrams. > >> > >> I don't see any way for a router to receive packets addressed to a > >> group other than subscribing, or joining, to that group. Do you see > >> another? > >> > >>>> For interface-scoped multicast addresses (ff01::smthing) - I > >>>> think yes, they can be statically assigned to an interface. > >>>> > >>>> Another issue is that AUTOCONF WG seems to be looking at > >>>> address auto-configuration means for MANET networks. Discovery > >>>> phase of address auto-configuration often uses multicast > >>>> addresses. _Maybe_ (I say maybe because without this then DHCP > >>>> multicast groups can be used) new MANET-AUTOCONF IANA-reserved > >>>> multicast groups could be reserved by IANA, for MANET > >>>> autoconfiguration purposes. From looking at the AUTOCONF > >>>> charter > >>> (http://www.ietf.org/html.charters/autoconf-charter.html) > >> and problem > >>> statement, they are working on unicast address > >> auto-configuration for > >>> MANET routers. > >> Does the AUTOCONF Charter forbid the use of known multicast > >> mechanisms to auto-configure unicast addresses? If it doesn't, > >> then AUTOCONF may need new well-known multicast addresses, with > >> link or site scope, exclusively for the purpose of unicast address > >> auto-configuration. > >> > >> Alex > >> > >> > >> ______________________________________________________________________ > >> This email has been scanned by the MessageLabs Email Security > >> System. For more information please visit > >> http://www.messagelabs.com/email > >> ______________________________________________________________________ > >> > >> > >> > >> _______________________________________________ manet mailing list > >> manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > >> > > > > > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 03:11:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HenHC-0004ia-Cj; Fri, 20 Apr 2007 03:11:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HenHA-0004iS-EQ for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 03:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HenHA-0004iK-3b for manet@ietf.org; Fri, 20 Apr 2007 03:11:24 -0400 Received: from ajax.nicta.com.au ([203.143.174.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HenH7-0003lv-12 for manet@ietf.org; Fri, 20 Apr 2007 03:11:24 -0400 Received: from nicta-atp-mail.in.nicta.com.au ([129.94.151.12]) by ajax.nicta.com.au with esmtp (Exim 4.50) id 1HenGv-0006AB-UL for manet@ietf.org; Fri, 20 Apr 2007 17:11:16 +1000 Received: NICTA-ATP-MAIL.in.nicta.com.au 129.94.151.12 from 203.143.164.187 203.143.164.187 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 20 Apr 2007 17:06:16 +1000 From: Ricky Robinson To: Message-ID: Thread-Topic: DAIS 2007 - Call for Participation Thread-Index: AceDGmMyogforO8NEduUSAAX8swtvg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SA-Exim-Connect-IP: 129.94.151.12 X-SA-Exim-Mail-From: Ricky.Robinson@nicta.com.au X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on ajax.nicta.com.au X-Spam-Level: X-Spam-Status: No, score=-1.0 required=16.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on ajax.nicta.com.au) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Subject: [manet] DAIS 2007 - Call for Participation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --------------------------------------------------------------------- Call for Participation DAIS 2007 7th IFIP International Conference on Distributed Applications and Interoperable Systems "Towards Sustainability" Paphos, Cyprus 6 - 8 June 2007 --------------------------------------------------------------------- Early Registration Deadline: May 5, 2007 --------------------------------------------------------------------- http://www.discotec07.cs.ucy.ac.cy/ --------------------------------------------------------------------- The 7th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS) is part of the federated conferences DisCoTec (Distributed Computing Techniques), together with the 9th International Conference on Coordination Models and Languages (COORDINATION) and the 9th IFIP International Conference on Formal Methods for Open Object-based Distributed Systems (FMOODS). It will be organised by the Department of Computer Science of the University of Cyprus. --------------------------------------------------------------------- ABOUT THE CONFERENCE --------------------------------------------------------------------- Distributed applications and interoperable systems have become an integral part of everyday living, part of the socio-economic ecosystem of our human environment. With such interdependence between society and software, distributed software applications must be sustainable and adaptable in the long term, despite the changes in our environment. * What do we understand by sustainability in distributed applications and interoperable systems? * How do we ensure our distributed applications can make local adaptation to specific circumstances of their deployment? * How do we make our interoperable systems evolvable in the face of widespread change in their environment? * How do we integrate distributed software within the wider fabric of computing within our modern world? * How can distributed applications and interoperable systems capitalise and exploit future trends and the changing user demographic? The DAIS conference series addresses all aspects of distributed applications and interoperable systems: design, implementation, operation and maintenance. DAIS'07 is the 7th event in this successful international conference series, commencing in 1997. It will be a forum for researchers, vendors and users to come together to review, discuss and learn about the future of distributed applications and interoperable systems. DAIS is now an annual event. --------------------------------------------------------------------- ADVANCE PROGRAM --------------------------------------------------------------------- WEDNESDAY June 6th ------------------ 9:30 - 10:30 INVITED SPEAKER FMOODS Mariangiola Dezani-Ciancaglini Asynchronous Session Types and Progress for Object Oriented Languages Break 11:00 - 12:30 SESSION 1: CONTEXT-AWARENESS I The Context-Dependent Role Model Jorge Vallejos, Peter Ebraert, Brecht Desmet, Tom Van Cutsem, Stijn Mostinckx, Pascal Costanza Integrating Facts and Beliefs to Model and Reason about Context Waltenegus Dargie, Thomas Springer Situation Specification and Realization in Rule-Based Context-Aware Applications Patricia Dockhorn Costa, Joao Paulo A. Almeida, Luis Ferreira Pires, Marten van Sinderen Lunch 14:30 - 15:30 SESSION 2: DISTRIBUTED APPLICATIONS I Observability and Controllability of Wireless Software Components Fabien Romeo, Franck Barbier, and Jean-Michel Bruel Service level agreement management in federated virtual organizations Tuomas Nurmela, Lea Kutvonen Break 16:00 - 17:30 SESSION 3: ADAPTATION I Construction and Execution of Adaptable Applications using an Aspect-Oriented and Model Driven Approach Sten A. Lundesgaard, Arnor Solberg, Jon Oldevik, Robert France, Jan Oyvind Aagedal, Frank Eliassen Component Adaptation in Contemporary Execution Environments Susan Eisenbach, Chris Sadler, Dominic Wong Managing Distributed Adaptation of Mobile Applications Mourad Alia, Svein Hallsteinsen, Nearchos Paspallis, Frank Eliassen THURSDAY June 7th ----------------- 9:30 - 10:30 SESSION 4: PEER-TO-PEER DOLCLAN Middleware Support for Peer-to-Peer Distributed Shared Objects Jakob E. Bardram, Martin Mogensen Peer-to-Peer based QoS Registry Architecture for Web Services Fei Li, Fangchun Yang, Kai Shuang, Sen Su Break 11:00 - 12:30 SESSION 5: MOBILITY I Migration in CORBA Component Model Jacek Cala A Serialisation Based Approach for Processes Strong Mobility Soumaya Marzouk, Maher Ben Jemaa, Mohamed Jmaiel Parallel State Transfer in Object Replication Systems Rudiger Kapitza, Thomas Zeman, Franz J. Hauck, Hans P. Reiser Lunch 14:30 - 15:30 SESSION 6: DISTRIBUTED APPLICATIONS II MARS: An Agent-based Recommender System for the Semantic Web Salvatore Garruzzo, Domenico Rosaci, Giuseppe M.L. Sarne An HTML Fragments Based Approach for Portlet Interoperability Jingyu Song, Jun Wei, Shuchao Wan Break 16:00 - 17:30 SESSION 7: CONTEXT-AWARENESS II Scalable Processing of Context Information with COSMOS Denis Conan, Romain Rouvoy, Lionel Seinturier Experiences from Developing a Distributed Context Management System for Enabling Adaptivity Nearchos Paspallis, Avraam Chimaris, George A. Papadopoulos Towards Context-Aware Web Applications Po-Hao Chang, Gul Agha FRIDAY June 8th -------------- 9:30 - 10:30 INVITED SPEAKER COORDINATION Rachid Guerraoui Sommersby: The Return of the Transaction Break 11:00 - 12:30 SESSION 8: ADAPTATION II A Flexible Architecture for Enforcing and Composing Policies in a Service-Oriented Environment Tom Goovaerts, Bart De Win, Wouter Joosen Managing concern interactions in middleware Frans Sanen, Eddy Truyen, Wouter Joosen An Improved Genetic Algorithm for Web Services Selection Sen Su, Chengwen Zhang, Junliang Chen Lunch 14:30 - 16:00 SESSION 9 : MOBILITY II A UML Profile for Modeling Mobile Information Systems Vegard Dehlen, Jan Oyvind Aagedal A Planning Method for Component Placement in Smart Item Environments using Heuristic Search Jurgen Anke, Bernhard Wolf, Gregor Hackenbroich, Klaus Kabitzsch A Generic Infrastructure for Decentralised Dynamic Loading of Platform-Specific Code Rudiger Kapitza, Holger Schmidt, Udo Bartlang, Franz J. Hauck --------------------------------------------------------------------- VENUE AND LOCATION INFORMATION --------------------------------------------------------------------- The DisCoTec 2007 conference will be held at the Paphos Amathus Hotel, in Paphos, Cyprus. More information about the venue, including travel information, can be found at the following web page: http://www.discotec07.cs.ucy.ac.cy/location.htm --------------------------------------------------------------------- REGISTRATION FEES --------------------------------------------------------------------- The early registration deadline is May 5, 2007. All prices quoted are in Euro. Early Delegate's Registration Fees: 480 Early Student Registration Fees: 350 Early Paper Presenters Fees: 480 Workshop Registration Fees: 150 Late Delegate's Registration Fees: 550 Late Student Registration Fees: 400 Late Paper Presenters Fees: 550 Workshop Registration Fees: 170 --------------------------------------------------------------------- REGISTRATION PROCEDURES --------------------------------------------------------------------- Please visit http://www.cyprusconferences.org/discotec/registration.html, then download and complete the registration form. Registrations will be accepted by fax, mail or e-mail. -- Ricky Robinson, Ph.D. Researcher Queensland Laboratory NICTA PO Box 10161 Brisbane QLD 4000 Australia Tel. +61 7 3000 0514 Fax. +61 7 3000 0480 The imagination driving Australia's ICT future. To receive the latest NICTA information register at http://nicta.com.au/registration.cfm _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 03:17:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HenNW-00032u-DR; Fri, 20 Apr 2007 03:17:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HenNU-0002uK-EB for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 03:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HenNU-0002t4-26 for manet@ietf.org; Fri, 20 Apr 2007 03:17:56 -0400 Received: from psmtp04.wxs.nl ([195.121.247.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HenNS-0000YR-Pd for manet@ietf.org; Fri, 20 Apr 2007 03:17:56 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by psmtp04.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JGS00DMCC9MFG@psmtp04.wxs.nl> for manet@ietf.org; Fri, 20 Apr 2007 09:17:54 +0200 (MEST) Date: Fri, 20 Apr 2007 09:18:49 +0200 From: Teco Boot In-reply-to: <374005f30704192057v4bd16d37oed98ad9ec9c7dff4@mail.gmail.com> To: 'Ian Chakeres' Message-id: <001d01c7831c$2827d310$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceDADoFtRNSU06PSGC7zv4koZnjPQAGPhQg X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'manet' Subject: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Ian, I still think the status of MANET drafts is confusing, and the IANA request confused me again. First of all, I want to know what will happen with current MANET RFCs. Do they become obsolete? This is the second time I asked this question, it should not be that hard to answer. Name: Rfc: Protocol: Port: AODV 3561 654 OLSR 3626 698 TBRPF 3684 712 DSR 4728 48 The manet-iana I-D is about PacketBB and not for __all__ MANET protocols. I am sure there will be successors on PacketBB, as the current proposals has still their problems. And think about other work-in-progress on MANET, like OSPF-MANET, ideas in 6lowpan/sensornetworks and MANEMO. Renaming the requested port & addresses to PacketBB solves the __all__ MANET remark. And please anser my question what to do with existing MANET protocol RFCs. Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 04:02:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heo4D-00065P-BH; Fri, 20 Apr 2007 04:02:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Heo4A-00065F-TS for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 04:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heo4A-00064O-HJ; Fri, 20 Apr 2007 04:02:02 -0400 Received: from smtp15.wxs.nl ([195.121.247.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heo48-0005BR-TO; Fri, 20 Apr 2007 04:02:02 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by smtp15.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JGS00ET1EB2IZ@smtp15.wxs.nl>; Fri, 20 Apr 2007 10:02:00 +0200 (CEST) Date: Fri, 20 Apr 2007 10:02:52 +0200 From: Teco Boot In-reply-to: To: manet-dt@ietf.org Message-id: <001e01c78322$4d8a8980$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acd9rydWRR4SwktmRAOnEMcJZwZMYwFb4v0g X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 'manet' Subject: [manet] RE: SMF: Usage of IPv4 Identification field X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I have a remark on using IPv4 DPD and support for fragmentation. I think it is not that difficult to support fragmentation, we only have to extent the DPD filter for Fragment Offset (and Protocol, to be compliant with RFC791). Incorporating the Flags field (e.g. more fragments) is not needed but not harmful either. The DPD filter should check on Source Address, Destination Address, Protocol, Identification and Fragment Offset. Out of RFC791; header fields not used by DPD are blanked: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | | Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Protocol | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Example Internet Datagram Header Figure 4. IMHO updating DPD to RFC791 is important. Also for using it as remedy for unicast routing loops as I suggested before. Cheers, Teco > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: vrijdag 13 april 2007 11:36 > To: 'manet-dt@ietf.org' > Subject: SMF: Usage of IPv4 Identification field > > The SMF ID deviates from RFC791 for the Identification field. > > 791: "The originating protocol module of an internet datagram sets the > identification field to a value that must be unique for that source- > destination pair and protocol" > > SMF: "In the case that resequencing is deemed necessary, it is RECOMMENDED > that sequence numbering be applied such that a different sequence number > space per duple be used" > > The difference is the protocol field. I see two options, modify SMF or add > text clarifying the deviation and analyze for consequences. Or are the > rules for Identification changed since 791? > > Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 05:38:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepZf-0002sD-Eq; Fri, 20 Apr 2007 05:38:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HepZd-0002rp-Cn for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 05:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HepZd-0002rZ-2N for manet@ietf.org; Fri, 20 Apr 2007 05:38:37 -0400 Received: from wx-out-0506.google.com ([66.249.82.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HepZb-000734-Ss for manet@ietf.org; Fri, 20 Apr 2007 05:38:37 -0400 Received: by wx-out-0506.google.com with SMTP id h31so959005wxd for ; Fri, 20 Apr 2007 02:38:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Sg7KHB5+3BS/CIPwR+lTknFTSexhWWXUO2GvgKVSI1Ty3peMUlNm/F7OOBk/HJeNQgO9A3vxv7sjooa7STi/nUb7y4Bsmzg9jPBa6bWQORvI3snb+pMyp3lW6/GmVrz5XGClNUHu+BMzeag9rtMwFntCQI1BYxCxD5iZ0dS+Bn4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=cqD30qaLThaAQajvHU1IedS/mYlbNJvmBTaa21SMC29QrR8UKEBksVSObN9XsXdjF0c6t/mcsoUeMMB/laGHs8rdCfZGTDKsUdu07A5ic3qgCd4BItmwGfBPBEvv2EG5U4mmrZyVIQNukjhuVKleJYX9SxY9JeO1SDRiZqv/YVA= Received: by 10.90.32.14 with SMTP id f14mr2734845agf.1177061915717; Fri, 20 Apr 2007 02:38:35 -0700 (PDT) Received: by 10.90.118.10 with HTTP; Fri, 20 Apr 2007 02:38:35 -0700 (PDT) Message-ID: Date: Fri, 20 Apr 2007 11:38:35 +0200 From: "Romain Thouvenin" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [manet] Dymo route discovery X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello, I just wanted to be sure about a point of the DYMO specs. Section 5.4 says that a RREQ is created when it does not have a forwarding route. Section 5.5 says also that a RRER must be issued when a data packet for which no next hop is known is received. So in that case, a RRER AND a RREQ are issued, is that right ? Thanks, Romain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 06:16:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqAT-0007RD-Fg; Fri, 20 Apr 2007 06:16:41 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeqAR-0007R0-RE for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 06:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqAR-0007Qk-F4 for manet@ietf.org; Fri, 20 Apr 2007 06:16:39 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeqAN-0001Bg-3z for manet@ietf.org; Fri, 20 Apr 2007 06:16:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-153.messagelabs.com!1177064193!8020344!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 4578 invoked from network); 20 Apr 2007 10:16:33 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-14.tower-153.messagelabs.com with SMTP; 20 Apr 2007 10:16:33 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l3KAGX3W006067; Fri, 20 Apr 2007 05:16:33 -0500 (CDT) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l3KAGWf2006223; Fri, 20 Apr 2007 05:16:32 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l3KAGUh8006190; Fri, 20 Apr 2007 05:16:31 -0500 (CDT) Message-ID: <462892FD.3060701@gmail.com> Date: Fri, 20 Apr 2007 12:16:29 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Romain Thouvenin Subject: Re: [manet] Dymo route discovery References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Romain Thouvenin wrote: > Hello, > > I just wanted to be sure about a point of the DYMO specs. Section 5.4 > says that a RREQ is created when it does not have a forwarding > route. Section 5.5 says also that a RRER must be issued when a data > packet for which no next hop is known is received. So in that case, a > RRER AND a RREQ are issued, is that right ? It sounds very odd to happen so, IMHO. I always thought RRER and RREQ are to be used alternatively, not simultaneously. Probably the text should describe a situation whereby a router: -check whether there's route for the dst of the received packet. -if no then queue the packet and send RREQ and wait 10min else forward the packet. -if after 10min there's route in routing table then forward the packet there's no route in routing table then issue RRER to src and drop the packet Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 06:40:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqXV-0001Ns-OL; Fri, 20 Apr 2007 06:40:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeqXR-0001Me-C3 for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 06:40:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqXQ-0001Kt-DV for manet@ietf.org; Fri, 20 Apr 2007 06:40:24 -0400 Received: from wx-out-0506.google.com ([66.249.82.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeqXP-0007g8-5r for manet@ietf.org; Fri, 20 Apr 2007 06:40:24 -0400 Received: by wx-out-0506.google.com with SMTP id h31so974468wxd for ; Fri, 20 Apr 2007 03:40:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=snZdjwuIi279XXb8fBcQrkQXL5iHJHxqbzH6KOvSKY3feGErcowM5AlfmNCSYZyXpc99kVXMAr0LfGm7CmcXh56bMyo4DTssBIUL34HIsE7EQlNgDzQaNUItu55sQOIFN5sev78oEwZqeuCwDaFcQ1IfTWu7sf+1LXiQqNCtg6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=GlbgyA91T5mz49P93Sk/CBd3+OgqyG4ooQ/SMjFSqz7T2/5amEtRAH7YbSjg8GwIzPNQBrtnjeNwMry+gcugqRIZcHJcK/Sdr4ZppOFKj4VrY9tdjAQU2Nz4u6cg5Y++YaXRlYy6G5dk7OR6XkYHNutcTM53mVVayXyMV6uQQWg= Received: by 10.90.119.15 with SMTP id r15mr2769631agc.1177065622915; Fri, 20 Apr 2007 03:40:22 -0700 (PDT) Received: by 10.90.118.10 with HTTP; Fri, 20 Apr 2007 03:40:22 -0700 (PDT) Message-ID: Date: Fri, 20 Apr 2007 12:40:22 +0200 From: "Romain Thouvenin" To: "Alexandru Petrescu" Subject: Re: [manet] Dymo route discovery In-Reply-To: <462892FD.3060701@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462892FD.3060701@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 4/20/07, Alexandru Petrescu wrote: > Romain Thouvenin wrote: > > Hello, > > > > I just wanted to be sure about a point of the DYMO specs. Section 5.4 > > says that a RREQ is created when it does not have a forwarding > > route. Section 5.5 says also that a RRER must be issued when a data > > packet for which no next hop is known is received. So in that case, a > > RRER AND a RREQ are issued, is that right ? > > It sounds very odd to happen so, IMHO. > > I always thought RRER and RREQ are to be used alternatively, not > simultaneously. > > Probably the text should describe a situation whereby a router: > -check whether there's route for the dst of the received packet. > -if no then queue the packet > and send RREQ > and wait 10min > else forward the packet. > -if after 10min > there's route in routing table > then forward the packet > there's no route in routing table > then issue RRER to src > and drop the packet > > Alex Sounds interesting, but I'm not sure it is a good idea to make routers queue packets in memory constrained contexts. Maybe that should be administratively configurable. Anyway, that's not how I understood the specs. 5.5 does not say whether the RERR is sent immediately or after RREQ failure, and 5.4 does say that an error message should be sent after the failure, but an ICMP message, not a RERR. That implies that the transport protocol is IP, which is not the case for me. Romain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 07:46:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerZi-0005Yw-RB; Fri, 20 Apr 2007 07:46:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HerZg-0005NA-F8 for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 07:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerZg-0005LE-4L for manet@ietf.org; Fri, 20 Apr 2007 07:46:48 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HerZe-0000a1-Rv for manet@ietf.org; Fri, 20 Apr 2007 07:46:48 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1177069606!16938919!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23593 invoked from network); 20 Apr 2007 11:46:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-119.messagelabs.com with SMTP; 20 Apr 2007 11:46:46 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3KBkjQK022873; Fri, 20 Apr 2007 04:46:45 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l3KBkjEG002353; Fri, 20 Apr 2007 06:46:45 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3KBkidZ002301; Fri, 20 Apr 2007 06:46:44 -0500 (CDT) Message-ID: <4628A81F.90401@gmail.com> Date: Fri, 20 Apr 2007 13:46:39 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Romain Thouvenin Subject: Re: [manet] Dymo route discovery References: <462892FD.3060701@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Romain Thouvenin wrote: > On 4/20/07, Alexandru Petrescu wrote: >> Romain Thouvenin wrote: >>> Hello, >>> >>> I just wanted to be sure about a point of the DYMO specs. Section >>> 5.4 says that a RREQ is created when it does not have a >>> forwarding route. Section 5.5 says also that a RRER must be >>> issued when a data packet for which no next hop is known is >>> received. So in that case, a RRER AND a RREQ are issued, is that >>> right ? >> >> It sounds very odd to happen so, IMHO. >> >> I always thought RRER and RREQ are to be used alternatively, not >> simultaneously. >> >> Probably the text should describe a situation whereby a router: >> -check whether there's route for the dst of the received packet. >> -if no then queue the packet and send RREQ and wait 10min else >> forward the packet. -if after 10min there's route in routing table >> then forward the packet there's no route in routing table then >> issue RRER to src and drop the packet >> >> Alex > > Sounds interesting, but I'm not sure it is a good idea to make > routers queue packets in memory constrained contexts. Ah, right, I agree. Doesn't make sense to queue packets especially if it's about streaming data. > Maybe that should be administratively configurable. > > Anyway, that's not how I understood the specs. 5.5 does not say > whether the RERR is sent immediately or after RREQ failure, and 5.4 > does say that an error message should be sent after the failure, but > an ICMP message, not a RERR. I much prefer if DYMO sends ICMP Destination Unreachable instead of RERR. Because, if one wants DYMO to send RERR instead of ICMP then one must modify the IP stack code to disallow sending ICMP Destination Unreachable. And that _only_ when DYMO runs on the machine. This is too complex IMHO. > That implies that the transport protocol is IP, which is not the case > for me. What is the transport protocol for you? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 08:17:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hes3N-0005Ba-Ax; Fri, 20 Apr 2007 08:17:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hes3H-0004yl-Vp for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 08:17:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hes3H-0004xV-Iq for manet@ietf.org; Fri, 20 Apr 2007 08:17:23 -0400 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hes1e-0001Wx-Ev for manet@ietf.org; Fri, 20 Apr 2007 08:15:44 -0400 Received: by wx-out-0506.google.com with SMTP id h31so999154wxd for ; Fri, 20 Apr 2007 05:15:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PKu2VVeN/yAa/i4nOCuR+/Ads2FiAPQZaWwKh5434TEyfGIhsaMz2z+2kbWhG+5XMXHmLyKvcW7UEFV7QXcLMiwrbOAK7iMmtVKjzKdifYwj3AVBVKUAfeR1Jy4E8CAi/53ziqKnb0M0Cf5N0B2SLpxQvE7x0LK9Tj7jqTcxDGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Eqz1iKIhKGspQV01YWYV6UKFovZJQJOHF06zJ+ZAtD7TetxynNzPks2n+KKc1FS8pFt2kjuoQ4cNspOcOY7v92XgU8KKzPt+HQ+v14d665jALijhzo0WJd+4Ep5GeaN75R0XjuXDqAJorCfomfqn5WUIIuvVAED3wDdnWpHeA/k= Received: by 10.90.100.2 with SMTP id x2mr2835283agb.1177071342176; Fri, 20 Apr 2007 05:15:42 -0700 (PDT) Received: by 10.90.118.10 with HTTP; Fri, 20 Apr 2007 05:15:37 -0700 (PDT) Message-ID: Date: Fri, 20 Apr 2007 14:15:37 +0200 From: "Romain Thouvenin" To: "Alexandru Petrescu" Subject: Re: [manet] Dymo route discovery In-Reply-To: <4628A81F.90401@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 4/20/07, Alexandru Petrescu wrote: > Romain Thouvenin wrote: > > On 4/20/07, Alexandru Petrescu wrote: > >> Romain Thouvenin wrote: > >>> Hello, > >>> > >>> I just wanted to be sure about a point of the DYMO specs. Section > >>> 5.4 says that a RREQ is created when it does not have a > >>> forwarding route. Section 5.5 says also that a RRER must be > >>> issued when a data packet for which no next hop is known is > >>> received. So in that case, a RRER AND a RREQ are issued, is that > >>> right ? > >> [...] > >> > >> Probably the text should describe a situation whereby a router: > >> -check whether there's route for the dst of the received packet. > >> -if no then queue the packet and send RREQ and wait 10min else > >> forward the packet. -if after 10min there's route in routing table > >> then forward the packet there's no route in routing table then > >> issue RRER to src and drop the packet > >> > >> Alex > > [...] > > > > Anyway, that's not how I understood the specs. 5.5 does not say > > whether the RERR is sent immediately or after RREQ failure, and 5.4 > > does say that an error message should be sent after the failure, but > > an ICMP message, not a RERR. > > I much prefer if DYMO sends ICMP Destination Unreachable instead of RERR. > > Because, if one wants DYMO to send RERR instead of ICMP then one must > modify the IP stack code to disallow sending ICMP Destination > Unreachable. And that _only_ when DYMO runs on the machine. This is > too complex IMHO. > Yes you're absolutely right. We are talking about a data packet, so the transport protocol or its associated control protocol handles the error. > > That implies that the transport protocol is IP, which is not the case > > for me. > > What is the transport protocol for you? I'm implementing DYMO on TinyOS at the link-layer (no existing net-layer). So DYMO messages are carried in AM packets, and I use my implementation to provide a net-layer with AM as the transport packet format. No control protocol for now. Romain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 08:49:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HesYJ-00027B-OZ; Fri, 20 Apr 2007 08:49:27 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HesYH-000273-Pn for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 08:49:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HesYH-00026v-GI for manet@ietf.org; Fri, 20 Apr 2007 08:49:25 -0400 Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HesYF-0006SC-1P for manet@ietf.org; Fri, 20 Apr 2007 08:49:25 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1009374wxd for ; Fri, 20 Apr 2007 05:49:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qmGi+LXhuYD2ov2TlIssEnMAFRfnQBoH/B7h8sTYSyn4qVGsTrnzsvezGww2XBSjZsu6kCNXflgWatXUOFc4mKeELfeRqp+GG7BxWMFoppDVZgd7GzKjdAjrDBR0+1qQJHFjtNTeVhmi59ZqUo4ps8kSc7a7ZgrG4VqREpc+EZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=T/FMLIPIb5lq4o5RtXzfSGsMtXsqcbyUedMz4DE/io45RoB9vQtQSUe6NrXugChfaiwGYL7YWdOvBmqyR+928a/dH/D5qi1G6RgeFilcRO3Pi60Vd9jcpnedC/7VoYn0GsCGRSuIzlV/kZNAm9RKkrHu8TNEZ2bdOyVu1mO8+hY= Received: by 10.78.130.6 with SMTP id c6mr476332hud.1177073359996; Fri, 20 Apr 2007 05:49:19 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Fri, 20 Apr 2007 05:49:19 -0700 (PDT) Message-ID: <374005f30704200549n57bb48f1r9b032655a39ae3ee@mail.gmail.com> Date: Fri, 20 Apr 2007 18:19:19 +0530 From: "Ian Chakeres" To: "Teco Boot" In-Reply-To: <001d01c7831c$2827d310$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704192057v4bd16d37oed98ad9ec9c7dff4@mail.gmail.com> <001d01c7831c$2827d310$0202a8c0@Teco> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: manet Subject: [manet] Re: I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org For interoperability between the routing protocol implementations, it is important that well known port and multicast addresses be assigned. It was debated long ago that we assign common IANA assignments for all the current MANET specifications. Renaming the port to PacketBB sounds like a possible solution to port naming, but it does not portray the correct intent for the multicast addresses. Ian Chakeres Regarding the status of the existing MANET experimental RFC's, I have not given any thought to changing their status nor do I see any urgency to do so. On 4/20/07, Teco Boot wrote: > Hi Ian, > > I still think the status of MANET drafts is confusing, and the IANA request > confused me again. First of all, I want to know what will happen with > current MANET RFCs. Do they become obsolete? This is the second time I asked > this question, it should not be that hard to answer. > > Name: Rfc: Protocol: Port: > AODV 3561 654 > OLSR 3626 698 > TBRPF 3684 712 > DSR 4728 48 o > > The manet-iana I-D is about PacketBB and not for __all__ MANET protocols. I > am sure there will be successors on PacketBB, as the current proposals has > still their problems. And think about other work-in-progress on MANET, like > OSPF-MANET, ideas in 6lowpan/sensornetworks and MANEMO. > > Renaming the requested port & addresses to PacketBB solves the __all__ MANET > remark. > And please anser my question what to do with existing MANET protocol RFCs. > > Teco > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 08:53:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HescW-0006mE-8a; Fri, 20 Apr 2007 08:53:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HescU-0006m9-QA for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 08:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HescU-0006m1-Gl for manet@ietf.org; Fri, 20 Apr 2007 08:53:46 -0400 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HescT-0007nd-9T for manet@ietf.org; Fri, 20 Apr 2007 08:53:46 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1010763wxd for ; Fri, 20 Apr 2007 05:53:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mxwWPvGZNGcDb7gNY33tuDqw46n9AjhxusRnos1UQEYkLQ7ToXtnj5qMZvjneEvnYv/x9I5rJ1jOCcvvyfT/LscqsbTVDzm4kmklr8qvJXRpZ1oAPTR6fsGukmuREYF6fvAGRWK+yxD7lSeuctVrESzruIvqZ1UCH7CganFMS28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FVCYQAcr+p6Z5RTAMbcnSYrJO/phygQk1cDaaocUBWyHWVtwtL+pQY/S/vtjB4TQX4ZsWZvbhG9zfdDyyUvZnJcXVXV1v9f2j5nAQHVrnxb49SRvgoKeF4RT7EF1VMulbxrogQdxceOoGr6nTUg7yfj+9WEPEFehV0iquuMzcio= Received: by 10.78.193.5 with SMTP id q5mr483705huf.1177073624310; Fri, 20 Apr 2007 05:53:44 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Fri, 20 Apr 2007 05:53:44 -0700 (PDT) Message-ID: <374005f30704200553v1d45ef56n622e8cfb3a18f2db@mail.gmail.com> Date: Fri, 20 Apr 2007 18:23:44 +0530 From: "Ian Chakeres" To: "Teco Boot" , manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [manet] MANET Port Name X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I'd like to ask people whether they would like the port in the IANA document named "MANET" or "PacketBB". If you have a preference, please reply. Ian Chakeres On 4/20/07, Ian Chakeres wrote: > For interoperability between the routing protocol implementations, it > is important that well known port and multicast addresses be assigned. > > It was debated long ago that we assign common IANA assignments for all > the current MANET specifications. > > Renaming the port to PacketBB sounds like a possible solution to port > naming, but it does not portray the correct intent for the multicast > addresses. > > Ian Chakeres > > Regarding the status of the existing MANET experimental RFC's, I have > not given any thought to changing their status nor do I see any > urgency to do so. > > > On 4/20/07, Teco Boot wrote: > > Hi Ian, > > > > I still think the status of MANET drafts is confusing, and the IANA request > > confused me again. First of all, I want to know what will happen with > > current MANET RFCs. Do they become obsolete? This is the second time I asked > > this question, it should not be that hard to answer. > > > > Name: Rfc: Protocol: Port: > > AODV 3561 654 > > OLSR 3626 698 > > TBRPF 3684 712 > > DSR 4728 48 o > > > > The manet-iana I-D is about PacketBB and not for __all__ MANET protocols. I > > am sure there will be successors on PacketBB, as the current proposals has > > still their problems. And think about other work-in-progress on MANET, like > > OSPF-MANET, ideas in 6lowpan/sensornetworks and MANEMO. > > > > Renaming the requested port & addresses to PacketBB solves the __all__ MANET > > remark. > > And please anser my question what to do with existing MANET protocol RFCs. > > > > Teco > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 09:23:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Het5W-0007Kc-VX; Fri, 20 Apr 2007 09:23:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Het5U-0007KL-Qy for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 09:23:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Het5U-0007KC-HB for manet@ietf.org; Fri, 20 Apr 2007 09:23:44 -0400 Received: from ik-out-1112.google.com ([66.249.90.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Het5T-0007sL-6n for manet@ietf.org; Fri, 20 Apr 2007 09:23:44 -0400 Received: by ik-out-1112.google.com with SMTP id c21so1021701ika for ; Fri, 20 Apr 2007 06:23:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LCGhPrY4WWC/OHzm73gEEVvbHznq1ROjpdPs/sFrlLE7IFI/s1tHq/zSiaPczBkg4T05vK7YPX2QygPx5ZCO0Z5YkVuh0KTL1ohC7jAeAFVQXChDIwv8Vb61rYhIr2EkDsoLberTcg0jypX1anxdHMbBmX4aHjy8V6QXnI+nR+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=j/XwXu5qf3QXXJZ885GSlgs5eTx7tYVMtBbFKtrCsDpuqBwNxSzawDXEOQSIbiEWGJvpjlQ4TXf4ys0Kf2548ONwNuWBA64zrPhElNuzzTHJr1JStxdm608IxMmpjGU9m8iGfKfj4UdC5YgELo7MRHTl+BZZM8XwLB9wZxZz6wk= Received: by 10.78.180.16 with SMTP id c16mr490077huf.1177075421114; Fri, 20 Apr 2007 06:23:41 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Fri, 20 Apr 2007 06:23:40 -0700 (PDT) Message-ID: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> Date: Fri, 20 Apr 2007 18:53:40 +0530 From: "Ian Chakeres" To: "Romain Thouvenin" Subject: Re: [manet] Dymo route discovery In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I guess I need to add an additional condition, as it is not clear in the current document. Here is the updated text in Section 5.4. When a node originates a data packet and does not have a forwarding route to the IP.DestinationAddress, it sends a RREQ (described in Seciton 5.3.1) to discover a route to the particular destination (TargetNode). Is that more clear? I've also updated Section 5.5 to say """ A RERR MUST be issued if a data packet is to be forwarded and it cannot be delivered to the next hop because no forwarding route exists """ If you have any other issues, please keep them coming. These are good suggestions. Thanks. Ian Chakeres On 4/20/07, Romain Thouvenin wrote: > Hello, > > I just wanted to be sure about a point of the DYMO specs. Section 5.4 > says that a RREQ is created when it does not have a forwarding route. > Section 5.5 says also that a RRER must be issued when a data packet > for which no next hop is known is received. So in that case, a RRER > AND a RREQ are issued, is that right ? > > Thanks, > Romain > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 09:33:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HetF4-0000xa-Ro; Fri, 20 Apr 2007 09:33:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HetF4-0000xT-0X for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 09:33:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HetF3-0000xL-Mz for manet@ietf.org; Fri, 20 Apr 2007 09:33:37 -0400 Received: from ik-out-1112.google.com ([66.249.90.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HetF2-0003XG-EF for manet@ietf.org; Fri, 20 Apr 2007 09:33:37 -0400 Received: by ik-out-1112.google.com with SMTP id c21so1024823ika for ; Fri, 20 Apr 2007 06:33:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ILQ4s5xDFaAaRXLC1owKxK/9CsXamWpzliWXWn1cFR1uh8pj1ChhwrbQMgFLlMfOtCXc44HyDIJRjH73dnGbNIum4DZ5mlg/1v2vprorg5ZmEc/1EvHpeUzXBW6JYQ2Y+32JH6PjEHMArPu4DUgBPj1/8P0TDxxGZg5q0pF6ay0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JZuByJkCmgNEZoxlabtXNktIEFANd+j8whkf6bVd2oMZTy/f0xUzuwle5wZqWGG3vcecvUOQ1h9Iylpev0IbnyEj//3fqJcg+ut5xAQlnDQ95O1G0NxUdOJ1a3vo7gSpAL8zGRr0blnEy4i+/w16bcawaVpjeIWD8wZwab0TFLk= Received: by 10.78.106.3 with SMTP id e3mr500180huc.1177076015229; Fri, 20 Apr 2007 06:33:35 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Fri, 20 Apr 2007 06:33:35 -0700 (PDT) Message-ID: <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> Date: Fri, 20 Apr 2007 19:03:35 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Dymo route discovery In-Reply-To: <4628A81F.90401@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > > I much prefer if DYMO sends ICMP Destination Unreachable instead of RERR. > > Because, if one wants DYMO to send RERR instead of ICMP then one must > modify the IP stack code to disallow sending ICMP Destination > Unreachable. And that _only_ when DYMO runs on the machine. This is > too complex IMHO. RERR messages are disseminated in a controlled manner to remove routes that are no longer available/accurate. An generic ICMP Destination Unreachable message would not be capable of performing this operation. Can you please talk more as to why you think RERR messaging or processing is too complex? Or how we might improve RERR operation? Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 10:11:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hetpv-0003Rl-7E; Fri, 20 Apr 2007 10:11:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hetpt-0003RT-ST for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 10:11:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hetpt-0003RL-Ho for manet@ietf.org; Fri, 20 Apr 2007 10:11:41 -0400 Received: from wx-out-0506.google.com ([66.249.82.239]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hetps-0006Kc-8x for manet@ietf.org; Fri, 20 Apr 2007 10:11:41 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1037940wxd for ; Fri, 20 Apr 2007 07:11:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mJrC4Cm4vAWcxEyUnDNQP2LkzN2P9B/q34q3PBCaotUe0fB6I0YejfHAsolfS2N/i70njAmcFFv6bTO7ELuYhHk5Z4c3JebDyvVxfq0I4eYoXoDYHWDuw0FwaI60PosZfdYqN5WjFi4RtN08KAAxIw/Fp/IFUTkzHGQXpLiw/Cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sMNIak9CfSvdT0uV9RvuFUL4cHdbBuMAXE5DSHDQKGME9z50h7Vpz1zOu/gWN58Fe8fJ75+bpgZmttF7YESZZC0H7UCqJ89M/gl3JXJLYUXYiNyBdGumUhWL6Vg0+IwO2Qo/jk9ZC+G2k7OcEU0GVJAeJfBh5Ow839+KUwDu7l8= Received: by 10.90.94.2 with SMTP id r2mr2983349agb.1177078299487; Fri, 20 Apr 2007 07:11:39 -0700 (PDT) Received: by 10.90.118.10 with HTTP; Fri, 20 Apr 2007 07:11:39 -0700 (PDT) Message-ID: Date: Fri, 20 Apr 2007 16:11:39 +0200 From: "Romain Thouvenin" To: "Ian Chakeres" Subject: Re: [manet] Dymo route discovery In-Reply-To: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 4/20/07, Ian Chakeres wrote: > I guess I need to add an additional condition, as it is not clear in > the current document. > > Here is the updated text in Section 5.4. > > When a node originates a data packet and does not have a forwarding > route to the IP.DestinationAddress, it sends a RREQ (described in > Seciton 5.3.1) to discover a route to the particular destination > (TargetNode). > > Is that more clear? > > I've also updated Section 5.5 to say > """ > A RERR MUST be issued if a data packet is to be forwarded and it > cannot be delivered to the next hop because no forwarding route exists > """ > > > If you have any other issues, please keep them coming. These are good > suggestions. > > Thanks. > Ian Chakeres > So no RREQ during packet forwarding, and (of course) no RERR during packet originating. Yes I agree. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 10:16:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hetu4-0007vg-RR; Fri, 20 Apr 2007 10:16:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hetu1-0007va-Oh for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 10:15:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hetu1-0007vS-FA for manet@ietf.org; Fri, 20 Apr 2007 10:15:57 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hetu0-0004t2-8g for manet@ietf.org; Fri, 20 Apr 2007 10:15:57 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1039483wxd for ; Fri, 20 Apr 2007 07:15:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ablsHMsYvU87gfjKhSOHe8buOUbOX6Z3jwiLekf/caOHilnmFKnYVm0MySmXiuOz2AM8iAa0IsxDzLUgZDPFaSb4fsxkotDA5cudU2DoEISq91kMt4i5fYkEyPWu/6LQiekxdn2FSKwRTIuwHiD6la+JY9c/YGVjTd2MdYfsD+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dleEReamxz/J5BtSEx8iH9+bQSzfyMNT7zp1fNxjUsZZ2Drcml+T+aY5hptI2WDROv+2Tbbuua0W9fAwvVkIW5UzpVRaGI/QCYquTrvl1a4Xpr63ddB1s9oCXbzckPvuviIMjrLXUmMLpM0dLbyspyTkpNymeBDsnzAp7x7jjng= Received: by 10.90.49.1 with SMTP id w1mr2981122agw.1177078555609; Fri, 20 Apr 2007 07:15:55 -0700 (PDT) Received: by 10.90.118.10 with HTTP; Fri, 20 Apr 2007 07:15:55 -0700 (PDT) Message-ID: Date: Fri, 20 Apr 2007 16:15:55 +0200 From: "Romain Thouvenin" To: "Ian Chakeres" Subject: Re: [manet] Dymo route discovery In-Reply-To: <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 4/20/07, Ian Chakeres wrote: > > > > > > I much prefer if DYMO sends ICMP Destination Unreachable instead of RERR. > > > > Because, if one wants DYMO to send RERR instead of ICMP then one must > > modify the IP stack code to disallow sending ICMP Destination > > Unreachable. And that _only_ when DYMO runs on the machine. This is > > too complex IMHO. > > RERR messages are disseminated in a controlled manner to remove routes > that are no longer available/accurate. An generic ICMP Destination > Unreachable message would not be capable of performing this operation. > > Can you please talk more as to why you think RERR messaging or > processing is too complex? Or how we might improve RERR operation? > > Ian Chakeres > I think the point was not RERR processing, but using RERR instead of ICMP, that is interfering with IP implementation. With your clarifications, no problem anymore. Nodes always generate RERR to update surrounding routing tables, and can also use ICMP to let know the originating application that a problem occured. Romain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 10:20:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HetyI-0001cn-58; Fri, 20 Apr 2007 10:20:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HetyG-0001cW-JA for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 10:20:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HetyG-0001cO-9X for manet@ietf.org; Fri, 20 Apr 2007 10:20:20 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HetyE-0007LZ-V5 for manet@ietf.org; Fri, 20 Apr 2007 10:20:20 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1177078817!13013470!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 3896 invoked from network); 20 Apr 2007 14:20:17 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 20 Apr 2007 14:20:17 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3KEKHjv004315; Fri, 20 Apr 2007 07:20:17 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr02.mot.com (8.13.1/Vontu) with SMTP id l3KEKHc0009581; Fri, 20 Apr 2007 09:20:17 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l3KEKF3l009547; Fri, 20 Apr 2007 09:20:15 -0500 (CDT) Message-ID: <4628CC1F.1060106@gmail.com> Date: Fri, 20 Apr 2007 16:20:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Dymo route discovery References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> In-Reply-To: <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > > >> >> I much prefer if DYMO sends ICMP Destination Unreachable instead of >> RERR. >> >> Because, if one wants DYMO to send RERR instead of ICMP then one >> must modify the IP stack code to disallow sending ICMP Destination >> Unreachable. And that _only_ when DYMO runs on the machine. This >> is too complex IMHO. > > RERR messages are disseminated in a controlled manner to remove > routes that are no longer available/accurate. An generic ICMP > Destination Unreachable message would not be capable of performing > this operation. Would a generic ICMP Redirect achieve the same effect you look for? (add a route that overcomes an existing route that is no longer accurate). > Can you please talk more as to why you think RERR messaging or > processing is too complex? Or how we might improve RERR operation? I meant it is complex to implement the logic whereby one forbids the generation of ICMP Destination Unreachable. Presumably, that's what you want to do on a router: if it runs DYMO and sends RERR then it must not send ICMP Destination Unreachable, right? You find easy to forbid the generation of Dest Unreachable? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 10:27:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heu4q-0000yM-FN; Fri, 20 Apr 2007 10:27:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Heu4o-0000y7-VI for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 10:27:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heu4o-0000xx-Ld; Fri, 20 Apr 2007 10:27:06 -0400 Received: from psmtp13.wxs.nl ([195.121.247.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heu4o-00017a-4d; Fri, 20 Apr 2007 10:27:06 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by psmtp13.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JGS0017LW4YFW@psmtp13.wxs.nl>; Fri, 20 Apr 2007 16:27:04 +0200 (MEST) Date: Fri, 20 Apr 2007 16:27:59 +0200 From: Teco Boot In-reply-to: To: 'Brian Adamson' , manet-dt@ietf.org Message-id: <003501c78358$1cd12de0$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceDSqfWn2b1+/XPRbWgeiWO2/QUIAACNBNQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: 'manet' Subject: [manet] RE: [Manet-dt] RE: SMF: Usage of IPv4 Identification field X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Brian, I leave implementation details up to you. The only hint I can provide is the number of fragments for a full IP datagram is typically low, as the maximum IPv4 packet is 64KB and the minimum supported MTU is often mentioned as 576. 576 is the minimum size of IP datagram to be supported, so is not exactly MTU (see RFC791). Fragment order is an issue, a replay table is required. I think a bit table with packets received with offsets to a sequence number base (as often used in IPsec replay detection code) is not usable. Teco > -----Original Message----- > From: Brian Adamson [mailto:adamson@itd.nrl.navy.mil] > Sent: vrijdag 20 april 2007 14:51 > To: Teco Boot; manet-dt@ietf.org > Cc: 'manet' > Subject: [Manet-dt] RE: SMF: Usage of IPv4 Identification field > > Teco, > > > This is a good comment. I had also thought of this during the past > couple of weeks. The DPD filter I have implemented in the "nrlsmf" > code now already supports variable length "packet identifier content" > (on a per-flow basis) in order to handle the mix of possible use of > IPv4 ID, the IPv6 SMF_DPD option header, IPSec, and the gateway > "taggerID" option. > > So, it should be possible to extend the code to concatenate the > fragment offset (when applicable) with the IPv4 ID field as an > extended packet identifier ... making a sort of effective 29-bit > sequence number. > > _BUT_ the challenge is that the 13 least signficant bits (the > "Fragment Offset") do not incrementally increase in the manner of the > other sequence numbers used (i.e, by one with each packet - the > "fragment offset" increases as a function of the length of the > fragments). > > However, if one could assume that packets for a flow are fragmented > to equal (i.e. MTU) size except for the last fragment, one could > translate the "fragment offset" into a few bits of sequence space > (i.e. fragmentSequence = (fragmentOffset*8) / fragmentationSize) > and the relatively low complexity/not-too-stateful approach of using > a bit mask for sequence-based DPD could still be applied without > requiring a very large window size ... For the last fragment where > the fragmentation size could not be inferred, since the MF flag is > not set for this fragment, the implementation could assume that its > "fragmentSequence" would be FRAGMENT_SEQ_MAX ... If different > fragmentation occurred in different parts of the network path as > route changes occur, etc there might be some issue here, but that is > not likely a frequent or sustained condition? > > So, the question is ... what would a reasonable number of bits for > the "fragmentSequence" space for an implementation to assume? I > would wager that it would not have to be very many, perhaps just 4? > Thus extending the 16-bit IPv4 ID field to 20 bits for flows that are > fragmented somewhere in the system. > > Again, for various reasons, I don't think it is often a good policy > to forward multicast fragments, particularly in a wireless network > ... but this provision could be described in the SMF document if > there is agreement among the working group ... > > > > At 10:02 AM +0200 4/20/07, Teco Boot wrote: > >I have a remark on using IPv4 DPD and support for fragmentation. I think > it > >is not that difficult to support fragmentation, we only have to extent > the > >DPD filter for Fragment Offset (and Protocol, to be compliant with > RFC791). > >Incorporating the Flags field (e.g. more fragments) is not needed but not > >harmful either. > > > >The DPD filter should check on Source Address, Destination Address, > >Protocol, Identification and Fragment Offset. Out of RFC791; header > fields > >not used by DPD are blanked: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | | | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Identification | | Fragment Offset | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | Protocol | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Source Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Destination Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Example Internet Datagram Header > > > > Figure 4. > > > >IMHO updating DPD to RFC791 is important. Also for using it as remedy for > >unicast routing loops as I suggested before. > > > >Cheers, Teco > > > >> -----Original Message----- > >> From: Teco Boot [mailto:teco@inf-net.nl] > >> Sent: vrijdag 13 april 2007 11:36 > >> To: 'manet-dt@ietf.org' > >> Subject: SMF: Usage of IPv4 Identification field > >> > >> The SMF ID deviates from RFC791 for the Identification field. > >> > >> 791: "The originating protocol module of an internet datagram sets the > >> identification field to a value that must be unique for that source- > >> destination pair and protocol" > >> > >> SMF: "In the case that resequencing is deemed necessary, it is > RECOMMENDED > >> that sequence numbering be applied such that a different sequence > number > >> space per duple be used" > >> > >> The difference is the protocol field. I see two options, modify SMF or > add > >> text clarifying the deviation and analyze for consequences. Or are the > >> rules for Identification changed since 791? > >> > >> Teco > > > > > > > >_______________________________________________ > >Manet-dt mailing list > >Manet-dt@ietf.org > >https://www1.ietf.org/mailman/listinfo/manet-dt > > > -- > Brian > __________________________________ > Brian Adamson > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 10:58:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuZI-00074H-Gj; Fri, 20 Apr 2007 10:58:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeuZG-000746-KX for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 10:58:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuZG-00073y-Aw for manet@ietf.org; Fri, 20 Apr 2007 10:58:34 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeuZF-0000om-W5 for manet@ietf.org; Fri, 20 Apr 2007 10:58:34 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1177081112!13016407!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6175 invoked from network); 20 Apr 2007 14:58:32 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 20 Apr 2007 14:58:32 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3KEwWWd016501; Fri, 20 Apr 2007 07:58:32 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3KEwWCn013493; Fri, 20 Apr 2007 09:58:32 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3KEwUR3013393; Fri, 20 Apr 2007 09:58:30 -0500 (CDT) Message-ID: <4628D511.4030906@gmail.com> Date: Fri, 20 Apr 2007 16:58:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Romain Thouvenin Subject: Re: [manet] Dymo route discovery References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Romain Thouvenin wrote: > On 4/20/07, Alexandru Petrescu wrote: >> Romain Thouvenin wrote: >>> On 4/20/07, Alexandru Petrescu >>> wrote: >>>> Romain Thouvenin wrote: >>>>> Hello, >>>>> >>>>> I just wanted to be sure about a point of the DYMO specs. >>>>> Section 5.4 says that a RREQ is created when it does not have >>>>> a forwarding route. Section 5.5 says also that a RRER must be >>>>> issued when a data packet for which no next hop is known is >>>>> received. So in that case, a RRER AND a RREQ are issued, is >>>>> that right ? >>>> > [...] >>>> >>>> Probably the text should describe a situation whereby a router: >>>> -check whether there's route for the dst of the received >>>> packet. -if no then queue the packet and send RREQ and wait >>>> 10min else forward the packet. -if after 10min there's route in >>>> routing table then forward the packet there's no route in >>>> routing table then issue RRER to src and drop the packet >>>> >>>> Alex >>> > [...] >>> >>> Anyway, that's not how I understood the specs. 5.5 does not say >>> whether the RERR is sent immediately or after RREQ failure, and >>> 5.4 does say that an error message should be sent after the >>> failure, but an ICMP message, not a RERR. >> >> I much prefer if DYMO sends ICMP Destination Unreachable instead of >> RERR. >> >> Because, if one wants DYMO to send RERR instead of ICMP then one >> must modify the IP stack code to disallow sending ICMP Destination >> Unreachable. And that _only_ when DYMO runs on the machine. This >> is too complex IMHO. >> > Yes you're absolutely right. We are talking about a data packet, so > the transport protocol or its associated control protocol handles the > error. > >>> That implies that the transport protocol is IP, which is not the >>> case for me. >> >> What is the transport protocol for you? > > I'm implementing DYMO on TinyOS at the link-layer (no existing > net-layer). So DYMO messages are carried in AM packets, and I use my > implementation to provide a net-layer with AM as the transport packet > format. No control protocol for now. Sorry, 'AM' stands for what? Which link-layer is that? Just for my clarification, thanks. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 11:07:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuiJ-0004cd-S3; Fri, 20 Apr 2007 11:07:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HeuiH-0004Nd-SB for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 11:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuiH-0004Jd-Dp for manet@ietf.org; Fri, 20 Apr 2007 11:07:53 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeuiH-0003zD-17 for manet@ietf.org; Fri, 20 Apr 2007 11:07:53 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1177081670!18018638!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.9] Received: (qmail 24976 invoked from network); 20 Apr 2007 15:07:50 -0000 Received: from ftpbox.mot.com (HELO ftpbox.mot.com) (129.188.136.9) by server-6.tower-128.messagelabs.com with SMTP; 20 Apr 2007 15:07:50 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by ftpbox.mot.com (8.12.11/Motorola) with ESMTP id l3KF7jPn020470; Fri, 20 Apr 2007 10:07:45 -0500 (CDT) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l3KF7iew003037; Fri, 20 Apr 2007 10:07:44 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3KF7gtq002944; Fri, 20 Apr 2007 10:07:43 -0500 (CDT) Message-ID: <4628D738.3050002@gmail.com> Date: Fri, 20 Apr 2007 17:07:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] MANET Port Name References: <374005f30704200553v1d45ef56n622e8cfb3a18f2db@mail.gmail.com> In-Reply-To: <374005f30704200553v1d45ef56n622e8cfb3a18f2db@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > I'd like to ask people whether they would like the port in the IANA > document named "MANET" or "PacketBB". > > If you have a preference, please reply. Yes, I have some thoughts on this, thanks for asking. _If_ PacketBB is something used by most (all?) MANET protocols, then indeed the port should be named PacketBB. _If_ PacketBB is something that works only over UDP and/or TCP then again I prefer PacketBB for port name. If some existing MANET protocols have already ports assigned then a new one can't be so called MANET. But let me say something else. _If_ (only a big _if_) this WG defined only one protocol that they called "GRABNET" for example then it could have been easier to just have one port called "GRABNET" instead of PacketBB which seems to be only a TLV, not a protocol per se. Because, for example DYMO doesn't necessarily run at network layer (it may run at link-layer) so at that point DYMO using PacketBB and PacketBB port number wouldn't make much sense; it should have been "DYMO port number". Alex > > Ian Chakeres > > On 4/20/07, Ian Chakeres wrote: >> For interoperability between the routing protocol implementations, >> it is important that well known port and multicast addresses be >> assigned. >> >> It was debated long ago that we assign common IANA assignments for >> all the current MANET specifications. >> >> Renaming the port to PacketBB sounds like a possible solution to >> port naming, but it does not portray the correct intent for the >> multicast addresses. >> >> Ian Chakeres >> >> Regarding the status of the existing MANET experimental RFC's, I >> have not given any thought to changing their status nor do I see >> any urgency to do so. >> >> >> On 4/20/07, Teco Boot wrote: >>> Hi Ian, >>> >>> I still think the status of MANET drafts is confusing, and the >>> IANA >> request >>> confused me again. First of all, I want to know what will happen >>> with current MANET RFCs. Do they become obsolete? This is the >>> second time >> I asked >>> this question, it should not be that hard to answer. >>> >>> Name: Rfc: Protocol: Port: AODV 3561 654 OLSR >>> 3626 698 TBRPF 3684 712 DSR 4728 48 >>> o >>> >>> The manet-iana I-D is about PacketBB and not for __all__ MANET >> protocols. I >>> am sure there will be successors on PacketBB, as the current >> proposals has >>> still their problems. And think about other work-in-progress on >> MANET, like >>> OSPF-MANET, ideas in 6lowpan/sensornetworks and MANEMO. >>> >>> Renaming the requested port & addresses to PacketBB solves the >> __all__ MANET >>> remark. And please anser my question what to do with existing >>> MANET protocol >> RFCs. >>> >>> Teco >>> >>> >> > > > _______________________________________________ manet mailing list > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 11:11:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heum1-0006v1-4n; Fri, 20 Apr 2007 11:11:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Heum0-0006ut-9j for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 11:11:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heum0-0006ul-0D for manet@ietf.org; Fri, 20 Apr 2007 11:11:44 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Heulz-0004WG-K0 for manet@ietf.org; Fri, 20 Apr 2007 11:11:43 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-153.messagelabs.com!1177081902!8080391!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 23178 invoked from network); 20 Apr 2007 15:11:42 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-13.tower-153.messagelabs.com with SMTP; 20 Apr 2007 15:11:42 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l3KFBfEN014556; Fri, 20 Apr 2007 08:11:42 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l3KFBekB005950; Fri, 20 Apr 2007 10:11:41 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3KFBcMM005933; Fri, 20 Apr 2007 10:11:39 -0500 (CDT) Message-ID: <4628D829.80900@gmail.com> Date: Fri, 20 Apr 2007 17:11:37 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Dymo route discovery References: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> In-Reply-To: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000734-0, 16/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > I guess I need to add an additional condition, as it is not clear in > the current document. > > Here is the updated text in Section 5.4. > > When a node originates a data packet and does not have a forwarding > route to the IP.DestinationAddress, it sends a RREQ (described in > Seciton 5.3.1) to discover a route to the particular destination > (TargetNode). > > Is that more clear? YEs to me. Can it say what it does about the packet to be forwarded until a RREP is received? Drop, queue, buffer? And for how long to wait? > I've also updated Section 5.5 to say """ A RERR MUST be issued if a > data packet is to be forwarded and it cannot be delivered to the next > hop because no forwarding route exists """ Can you say something about whether ICMP Destination Unreachable is issued or not in this case? Thanks, Alex > > > If you have any other issues, please keep them coming. These are good > suggestions. > > Thanks. Ian Chakeres > > > On 4/20/07, Romain Thouvenin wrote: >> Hello, >> >> I just wanted to be sure about a point of the DYMO specs. Section >> 5.4 says that a RREQ is created when it does not have a forwarding >> route. Section 5.5 says also that a RRER must be issued when a data >> packet for which no next hop is known is received. So in that case, >> a RRER AND a RREQ are issued, is that right ? >> >> Thanks, Romain >> >> >> _______________________________________________ manet mailing list >> manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ manet mailing list > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 11:33:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hev72-0005IZ-5T; Fri, 20 Apr 2007 11:33:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hev6z-0005Cl-MY for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 11:33:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hev6y-00058e-W9; Fri, 20 Apr 2007 11:33:25 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hev6x-0000pF-ME; Fri, 20 Apr 2007 11:33:24 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3KFXHPG013434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Apr 2007 08:33:22 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3KFXGbe004221; Fri, 20 Apr 2007 08:33:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3KFXD3E004058; Fri, 20 Apr 2007 08:33:16 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 08:33:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Apr 2007 08:32:49 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED730@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <003501c78358$1cd12de0$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Manet-dt] RE: SMF: Usage of IPv4 Identification field Thread-Index: AceDSqfWn2b1+/XPRbWgeiWO2/QUIAACNBNQAAL5O/A= References: <003501c78358$1cd12de0$0202a8c0@Teco> From: "Templin, Fred L" To: "Teco Boot" , "Brian Adamson" , X-OriginalArrivalTime: 20 Apr 2007 15:33:14.0381 (UTC) FILETIME=[35F73BD0:01C78361] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: manet Subject: [manet] RE: [Manet-dt] RE: SMF: Usage of IPv4 Identification field X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I leave implementation details up to you. The only hint I can=20 > provide is the > number of fragments for a full IP datagram is typically low,=20 > as the maximum > IPv4 packet is 64KB and the minimum supported MTU is often=20 > mentioned as 576. > 576 is the minimum size of IP datagram to be supported, so is=20 > not exactly > MTU (see RFC791). (RFC791, Section 3.2) says: "Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets." This means that the minimum MTU all links must support is only 68 bytes; not 576. (RFC791, Section 3.2) also says: "Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled." This means that all end systems must have a Maximum Receive Unit (MRU) of at least 576 bytes. This is sustained by (RFC1122, Section 3.2.2), which calls it the "Effective MTU to Receive" (EMTU_R). Main point - it is possible for both source hosts and middleboxes to fragment datagrams into "tinygrams" as small as 68 bytes - so this has to be accounted for by any in-the-network function that might draw conclusions about fragment offset.=20 Fred fred.l.templin@boeing.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 20 15:50:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hez7s-0006W3-BG; Fri, 20 Apr 2007 15:50:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hez7N-0005Wb-AC for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hez7M-0005Vu-Cj; Fri, 20 Apr 2007 15:50:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hez7K-0007Fo-GD; Fri, 20 Apr 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5C51126F2E; Fri, 20 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hez7K-0001xW-6m; Fri, 20 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 20 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-jitter-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --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 : Jitter considerations in MANETs Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-jitter-00.txt Pages : 16 Date : 2007-4-20 This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in MANET routing protocols to reduce the probability of packet collisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-jitter-00.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-jitter-00.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: <2007-4-20104711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-jitter-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-jitter-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-20104711.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Fri Apr 20 15:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hez8P-0007pE-4I; Fri, 20 Apr 2007 15:51:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hez7q-0006V6-Nd for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 15:50:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hez7p-0006Sm-9T; Fri, 20 Apr 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hez7o-00012X-HM; Fri, 20 Apr 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 73CE02ADB2; Fri, 20 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hez7K-0001xZ-7S; Fri, 20 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 20 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-timetlv-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --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 : Representing multi-value time in MANETs Author(s) : T. Clausen, C. Dearlove Filename : draft-ietf-manet-timetlv-00.txt Pages : 16 Date : 2007-4-20 This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message TLVs for representing validity and interval times for MANET routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-timetlv-00.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-timetlv-00.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: <2007-4-20105004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-timetlv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-timetlv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-20105004.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Fri Apr 20 22:26:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf5Id-0003Qt-5t; Fri, 20 Apr 2007 22:26:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hf5Ib-0003HT-4Q for manet-confirm+ok@megatron.ietf.org; Fri, 20 Apr 2007 22:26:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf5Ia-0003FF-OZ for manet@ietf.org; Fri, 20 Apr 2007 22:26:04 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf5Ia-00054L-Cd for manet@ietf.org; Fri, 20 Apr 2007 22:26:04 -0400 Received: by ug-out-1314.google.com with SMTP id 72so851417ugd for ; Fri, 20 Apr 2007 19:26:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tgqtnLnDuqrP3r6+5XF3kD/br9EHHCYlB6bjUw7SqqSgRzVw9hOjXB0e4j4B0zzodgW2Mgdar7LhfkJz5eGyHi1GTtaR8h3KOQQCe8JJ8vrfFV8M/cw1CVpDSW4Pq33NFZ+JdSU9VaI6XXXXdeLPriWJ0rVgY+oGIcF9smWw+fY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XG04bUgSyoV+db18qXT6dWjVnZM8aO5XlcS6qNCxbhIoODpjLVEWsk4UHUK2szZdd3jUzhnRx6WwsaiBhYM88MDf84HY0xADNY6w6tsiwP51aFgYu9IxIR/zx15g2Bq3mvl5SQbIZNjlUlteGvh59j5hXm+HbTLcrTYct+mrm6A= Received: by 10.78.142.14 with SMTP id p14mr634167hud.1177122363549; Fri, 20 Apr 2007 19:26:03 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Fri, 20 Apr 2007 19:26:03 -0700 (PDT) Message-ID: <374005f30704201926h7c485e36x45f5e36df04d9774@mail.gmail.com> Date: Sat, 21 Apr 2007 07:56:03 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] MANET Port Name In-Reply-To: <4628D738.3050002@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704200553v1d45ef56n622e8cfb3a18f2db@mail.gmail.com> <4628D738.3050002@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org All the MANET protocols that generate control messages (NHDP, DYMO, OLSRv2) use PacketBB (Packet Building Block) for their packets & messages. Ian On 4/20/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > I'd like to ask people whether they would like the port in the IANA > > document named "MANET" or "PacketBB". > > > > If you have a preference, please reply. > > Yes, I have some thoughts on this, thanks for asking. > > _If_ PacketBB is something used by most (all?) MANET protocols, then > indeed the port should be named PacketBB. > > _If_ PacketBB is something that works only over UDP and/or TCP then > again I prefer PacketBB for port name. > > If some existing MANET protocols have already ports assigned then a new > one can't be so called MANET. > > But let me say something else. _If_ (only a big _if_) this WG defined > only one protocol that they called "GRABNET" for example then it could > have been easier to just have one port called "GRABNET" instead of > PacketBB which seems to be only a TLV, not a protocol per se. > > Because, for example DYMO doesn't necessarily run at network layer (it > may run at link-layer) so at that point DYMO using PacketBB and PacketBB > port number wouldn't make much sense; it should have been "DYMO port > number". > > Alex > > > > > Ian Chakeres > > > > On 4/20/07, Ian Chakeres wrote: > >> For interoperability between the routing protocol implementations, > >> it is important that well known port and multicast addresses be > >> assigned. > >> > >> It was debated long ago that we assign common IANA assignments for > >> all the current MANET specifications. > >> > >> Renaming the port to PacketBB sounds like a possible solution to > >> port naming, but it does not portray the correct intent for the > >> multicast addresses. > >> > >> Ian Chakeres > >> > >> Regarding the status of the existing MANET experimental RFC's, I > >> have not given any thought to changing their status nor do I see > >> any urgency to do so. > >> > >> > >> On 4/20/07, Teco Boot wrote: > >>> Hi Ian, > >>> > >>> I still think the status of MANET drafts is confusing, and the > >>> IANA > >> request > >>> confused me again. First of all, I want to know what will happen > >>> with current MANET RFCs. Do they become obsolete? This is the > >>> second time > >> I asked > >>> this question, it should not be that hard to answer. > >>> > >>> Name: Rfc: Protocol: Port: AODV 3561 654 OLSR > >>> 3626 698 TBRPF 3684 712 DSR 4728 48 > >>> o > >>> > >>> The manet-iana I-D is about PacketBB and not for __all__ MANET > >> protocols. I > >>> am sure there will be successors on PacketBB, as the current > >> proposals has > >>> still their problems. And think about other work-in-progress on > >> MANET, like > >>> OSPF-MANET, ideas in 6lowpan/sensornetworks and MANEMO. > >>> > >>> Renaming the requested port & addresses to PacketBB solves the > >> __all__ MANET > >>> remark. And please anser my question what to do with existing > >>> MANET protocol > >> RFCs. > >>> > >>> Teco > >>> > >>> > >> > > > > > > _______________________________________________ manet mailing list > > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Apr 21 01:05:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf7mN-0002SU-Mw; Sat, 21 Apr 2007 01:04:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hf7mM-0002SM-8z for manet-confirm+ok@megatron.ietf.org; Sat, 21 Apr 2007 01:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf7mL-0002SD-VI for manet@ietf.org; Sat, 21 Apr 2007 01:04:57 -0400 Received: from web56209.mail.re3.yahoo.com ([216.252.110.218]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hf7mK-0002Ol-Kt for manet@ietf.org; Sat, 21 Apr 2007 01:04:57 -0400 Received: (qmail 87660 invoked by uid 60001); 21 Apr 2007 05:04:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Vv1wRRImUaIQhgv7YnyUWUjAjJTzTksZSEuMTVKlsCcejrHl2IvutgFjCawaMpwZdsXknBawPtfaWneeo1JhxJfPGaJaj+++XIdeK0Zrs0EF2ceKlxNX8YyNwxQPdFCds8YG49WNoyMDjDousDhxhkJKgKlYnYCtkyW/I50MPyw=; X-YMail-OSG: Kv4uqskVM1nVeXuVT8EReukBh76CLaa_Ym4sv.4zJVnIPEps8i70lDpTrF1UB7E9_cBV0KB4RxnpbVuPv0k1eoPh6sLNt6qm85ncejPi8ez09VV3.T7jSSUydTJnSMbrK6_bh62nvJ87ER7n010.2Z3_Uw-- Received: from [71.208.152.57] by web56209.mail.re3.yahoo.com via HTTP; Fri, 20 Apr 2007 22:04:55 PDT Date: Fri, 20 Apr 2007 22:04:55 -0700 (PDT) From: Qi Han To: manet@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <700944.87332.qm@web56209.mail.re3.yahoo.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [manet] [MASS 2007] Call for Workshops' Papers X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- ***** CALL FOR WORKSHOPS PAPERS **** IEEE MASS 2007 WORKSHOPS http://cnd.iit.cnr.it/mass2007/workshops.html Pisa, October 8 & 12, 2007 Sponsored by IEEE, IEEE Computer Society, IEEE Technical Committee on Distributed Processing, and IEEE Technical Committee on Simulation in-cooperation with ACM SIGMOBILE ---------------------------------------------------------------------- The Fourth IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2007) will host 10 workshops on technical subjects related to mobile and wireless ad hoc networking and its applications (see the list below). For more information about the workshops and the paper submission procedures, see http://cnd.iit.cnr.it/mass2007/workshops.html ********* MASS 2007 Workshops *********** ----------------------- Monday, October 8, 2007 ----------------------- PARIS: 1st International Workshop on Protocols and Algorithms for Reliable and Data Intensive Sensor Networks Papers due: April 30, 2007 WSNS: 3rd IEEE International Workshop on Wireless and Sensor Networks Security Papers due: April 30, 2007 MeshTech: 1st IEEE International Workshop on Enabling Technologies and Standards for Wireless Mesh Networking Papers due: May 15, 2007 MHWMN 2007: 3rd IEEE International Workshop on Heterogeneous Multi-Hop Wireless and Mobile Networks Papers due: May 15, 2007 BIONETWORKS 2007: A Workshop on Socially and Biologically Inspired Wired and Wireless Networks Papers due: April 30, 2007 MPPS: 1st International Workshop on Multilateral/Multiuser Privacy in Pervasive Systems Papers due: May 15, 2007 ------------------------ Friday, October 12, 2007 ------------------------ MASS-GHS: 1st International Workshop on Mobile Ad hoc and Sensor Systems for Global and Homeland Security Papers due: May 15, 2007 SensorFusion'07: Second International Workshop on Information Fusion and Dissemination in Wireless Sensor Networks Papers due: May 15, 2007 LOCAN 2007: The Third International Workshop on Localized Communication and Topology Protocols for Ad hoc Networks Papers due: April 30, 2007 MoVeNet 2007: The First International Workshop on Mobile Vehicular Networks Papers due: May 7, 2007 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Apr 21 12:53:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfIps-0002sR-1U; Sat, 21 Apr 2007 12:53:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfIpq-0002sF-KD for manet-confirm+ok@megatron.ietf.org; Sat, 21 Apr 2007 12:53:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfIpq-0002s7-Am for manet@ietf.org; Sat, 21 Apr 2007 12:53:18 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfIpp-0004P0-3W for manet@ietf.org; Sat, 21 Apr 2007 12:53:18 -0400 Received: by an-out-0708.google.com with SMTP id d30so1376565and for ; Sat, 21 Apr 2007 09:53:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NRTCDWSJRxjQ16IfpGD6tJE2Ac814XhGFu2e4ElHfFTvXvogrzWDPVSRwFz55KDnafFOQJ0k00eB9bzh+oV9qLl/uPKDEELc9z//5mqP1Y46i4hPtRIDkMHBW3EAiUseeHPWrznOx5oeXs11bRQ9Ej8ry7cEMpz/w6ffSNaA1KU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=CNYuGq+7hXhdHO4QpN2oJ7AaAogQGUg0Fy8hBAlF7KBlXKi/h2sO7W+yoCj4mCeCrQpBwZdGxPDxfCmRuN2ciu5mQZAAksWee86i0v75hWODHAhReTCvlKccHq2PgHltJVx++Z7aogwvirbvgid/iR1mvfQ0nDXsNLil9kJsiss= Received: by 10.100.128.8 with SMTP id a8mr2489913and.1177174396613; Sat, 21 Apr 2007 09:53:16 -0700 (PDT) Received: by 10.100.211.13 with HTTP; Sat, 21 Apr 2007 09:53:16 -0700 (PDT) Message-ID: Date: Sat, 21 Apr 2007 12:53:16 -0400 From: Roger To: manet Subject: Re: [manet] MANET Port Name MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org There are, and will continue to be, other MANET protocols outside the standards, so we should at least specify that we are talking about standard MANET protocols. As you have said, the experimental RFCs will remain experimental for now. What we should be asking is whether all future MANET standards can be expected to use PacketBB. Given the recent discussions on this list, I do not believe that we can safely say that 10-20 years out. On 4/20/07, Ian Chakeres wrote: >All the MANET protocols that generate control messages (NHDP, DYMO, >OLSRv2) use PacketBB (Packet Building Block) for their packets & >messages. > >Ian > >On 4/20/07, Alexandru Petrescu wrote: >> Ian Chakeres wrote: >> > I'd like to ask people whether they would like the port in the IANA >> > document named "MANET" or "PacketBB". >> > >> > If you have a preference, please reply. >> >> Yes, I have some thoughts on this, thanks for asking. >> >> _If_ PacketBB is something used by most (all?) MANET protocols, then >> indeed the port should be named PacketBB. >> >> _If_ PacketBB is something that works only over UDP and/or TCP then >> again I prefer PacketBB for port name. >> >> If some existing MANET protocols have already ports assigned then a new >> one can't be so called MANET. >> >> But let me say something else. _If_ (only a big _if_) this WG defined >> only one protocol that they called "GRABNET" for example then it could >> have been easier to just have one port called "GRABNET" instead of >> PacketBB which seems to be only a TLV, not a protocol per se. >> >> Because, for example DYMO doesn't necessarily run at network layer (it >> may run at link-layer) so at that point DYMO using PacketBB and PacketBB >> port number wouldn't make much sense; it should have been "DYMO port >> number". >> >> Alex -- Roger _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 22 06:46:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfZaV-0006QR-Gg; Sun, 22 Apr 2007 06:46:35 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfZaU-0006QM-9t for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 06:46:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfZaT-0006QE-Rd for manet@ietf.org; Sun, 22 Apr 2007 06:46:33 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfZaS-0006IC-Ke for manet@ietf.org; Sun, 22 Apr 2007 06:46:33 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1525937wxd for ; Sun, 22 Apr 2007 03:46:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ATczstKnvmYLAERqCIJJ9CmGSZVgNLvaXGt50JMtXGHAX4J0/BEjZH4N6Lk707rQftMckeEnX5eK+3v/ulUhJc6l74seAtF45sxwyBD0xU/tPBwmAzxctjWUBUAF0QBVHqL9yJ1bRymQwaJSdNYehvYNrCuG92nfZt9gm8ilE7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kwYzayamaLUF/4N5KHEvw31mgvLJr5okidjdPuCW08upabF6uXYdm/7IVjKQdF1Ukow0CxI+PZgT3biogXOFDY1Jv/2BABahlOvVJAc7ZygrioO9m1D2EcNhxFP9z/eicFRzFofi26oBI4KRKHl+pe4yEyok7fuCCWr3tAoIA8U= Received: by 10.78.151.3 with SMTP id y3mr833504hud.1177238791772; Sun, 22 Apr 2007 03:46:31 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Sun, 22 Apr 2007 03:46:31 -0700 (PDT) Message-ID: <374005f30704220346o7ea375c8k270ee87c51844431@mail.gmail.com> Date: Sun, 22 Apr 2007 16:16:31 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Dymo route discovery In-Reply-To: <4628CC1F.1060106@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> <4628CC1F.1060106@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 4/20/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > > > > >> > >> I much prefer if DYMO sends ICMP Destination Unreachable instead of > >> RERR. > >> > >> Because, if one wants DYMO to send RERR instead of ICMP then one > >> must modify the IP stack code to disallow sending ICMP Destination > >> Unreachable. And that _only_ when DYMO runs on the machine. This > >> is too complex IMHO. > > > > RERR messages are disseminated in a controlled manner to remove > > routes that are no longer available/accurate. An generic ICMP > > Destination Unreachable message would not be capable of performing > > this operation. > > Would a generic ICMP Redirect achieve the same effect you look for? (add > a route that overcomes an existing route that is no longer accurate). ICMP redirect would not convey the same information as a RERR, nor would it be distributed appropriately. > > Can you please talk more as to why you think RERR messaging or > > processing is too complex? Or how we might improve RERR operation? > > I meant it is complex to implement the logic whereby one forbids the > generation of ICMP Destination Unreachable. Presumably, that's what you > want to do on a router: if it runs DYMO and sends RERR then it must not > send ICMP Destination Unreachable, right? ICMP Destination Unreachable messages are for the sources of packets, not the routers in between. In the AODV/DYMO implementations I've seen, ICMP Destination Unreachable messages are issued by the source if it cannot find a route. I believe this is the chosen proceedure to discourage a sources application from believing that no route is available, since it is likely that the route is only temporarily broken or unavailable and will soon be repaired. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 22 06:49:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfZdM-0007hP-Kl; Sun, 22 Apr 2007 06:49:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfZdK-0007hC-SM for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 06:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfZdK-0007gw-Hw for manet@ietf.org; Sun, 22 Apr 2007 06:49:30 -0400 Received: from ik-out-1112.google.com ([66.249.90.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfZdI-0006hp-KU for manet@ietf.org; Sun, 22 Apr 2007 06:49:30 -0400 Received: by ik-out-1112.google.com with SMTP id c30so308804ika for ; Sun, 22 Apr 2007 03:49:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RKI+19sKc+0TGoBnQ6lSx2rlYBSMWtoKPREY/i6n1Eeg4QVZNmSKOSnlbCIG7kqTPl0lASE/LdA2sHdculX4RRpm2uKiPYNwn+FNGz1lznvp71VKjItRTW5JxGaBJ5PiOt4aaTt2Yw7CHfHefVFGOMlGyvnWQ0wq9XCPA6qk9+E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FPrXd/0RpkbP3CRbDO+NxIE5+Qj2KGqfSmDQZrwb0TzGpYL4qKimKZVnw1j6BAwcM9flbvM9Eh3AI/agcY//0SquttPJ3chsOIywrsquRPn3G3wGdtTUgvJsFulrxsY9HixhPvs9NINO/iKbCrxtn9RSQXVu9L3sr3HFXh/ei+I= Received: by 10.78.171.13 with SMTP id t13mr161400hue.1177238967793; Sun, 22 Apr 2007 03:49:27 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Sun, 22 Apr 2007 03:49:27 -0700 (PDT) Message-ID: <374005f30704220349q394413c4l9794205d95a1e0b2@mail.gmail.com> Date: Sun, 22 Apr 2007 16:19:27 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Dymo route discovery In-Reply-To: <4628D829.80900@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> <4628D829.80900@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 4/20/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > I guess I need to add an additional condition, as it is not clear in > > the current document. > > > > Here is the updated text in Section 5.4. > > > > When a node originates a data packet and does not have a forwarding > > route to the IP.DestinationAddress, it sends a RREQ (described in > > Seciton 5.3.1) to discover a route to the particular destination > > (TargetNode). > > > > Is that more clear? > > YEs to me. > > Can it say what it does about the packet to be forwarded until a RREP is > received? Drop, queue, buffer? And for how long to wait? We recommend queue, but there are parameters regarding the queue and how long to wait. Please see the ID. > > I've also updated Section 5.5 to say """ A RERR MUST be issued if a > > data packet is to be forwarded and it cannot be delivered to the next > > hop because no forwarding route exists """ > > Can you say something about whether ICMP Destination Unreachable is > issued or not in this case? I would recommend that an ICMP destination unreachable not issued, but I would not require it. Please see my other email on this subject. Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 22 07:31:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfaHy-0003Jh-77; Sun, 22 Apr 2007 07:31:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfaHx-0003Jb-AI for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 07:31:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfaHx-0003JS-0t for manet@ietf.org; Sun, 22 Apr 2007 07:31:29 -0400 Received: from web52502.mail.re2.yahoo.com ([206.190.48.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfaHv-0007CF-FM for manet@ietf.org; Sun, 22 Apr 2007 07:31:29 -0400 Received: (qmail 17938 invoked by uid 60001); 22 Apr 2007 11:31:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=a8vbJWwqA5O/MtSVx2XtT/lrHjchFnIIjx/qHvove1+yu+HgdQWiDdJRy9Pu7ue31o3nZy7GBf07xSLd8QEE5TSxS0RAI6blYg6Yic+4HmIV3kTlQw1/gqdax+S9MnjtMTAFUQNEXZhicjBU3AEEAh3hjpu2OnTygM6GiIeIzbY=; X-YMail-OSG: KONXEdoVM1lGFArg2gOoQdkSK7EKffQPj8k0DJh8nSLUbNIUGy2NMZOQ7qkonA01KpEODe8mEpAoGwxwt6iyBSYlikYDDcRaUSRUlLTRCK5ctZbmAkokUXyaY.dxxgS4uOZwH5Yk3Rp5uMi0oLbUEqg7Vw-- Received: from [202.141.145.18] by web52502.mail.re2.yahoo.com via HTTP; Sun, 22 Apr 2007 04:31:27 PDT Date: Sun, 22 Apr 2007 04:31:27 -0700 (PDT) From: sam karazon To: manet@ietf.org MIME-Version: 1.0 Message-ID: <335007.17096.qm@web52502.mail.re2.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [manet] Please..is this code in Glomosim wrong.... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1773748416==" Errors-To: manet-bounces@ietf.org --===============1773748416== Content-Type: multipart/alternative; boundary="0-907253912-1177241487=:17096" Content-Transfer-Encoding: 8bit --0-907253912-1177241487=:17096 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I think the propagation background noise functions defined in file include/propagation.h is wrong...I want to be confirm.... the code is written as #define GLOMO_PropBackgroundNoise_mW(node, channelBandwidth) \ ((node)->propData->backgroundNoise_mW * channelBandwidth) #define GLOMO_PropBackgroundNoise_dBm(node, channelBandwidth) \ ((node)->propData->backgroundNoise_dBm * channelBandwidth) the code for the function GLOMO_PropBackgroundNoise_dBm is too wrong it should be #define GLOMO_PropBackgroundNoise_dBm(node, channelBandwidth) \ ((node)->propData->backgroundNoise_dBm + 10*log10(channelBandwidth)) --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. --0-907253912-1177241487=:17096 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I think the propagation background noise functions defined in file include/propagation.h  is wrong...I want to be confirm....
 
the code is written as
 
#define GLOMO_PropBackgroundNoise_mW(node, channelBandwidth) \
            ((node)->propData->backgroundNoise_mW * channelBandwidth)
 
#define GLOMO_PropBackgroundNoise_dBm(node, channelBandwidth) \
            ((node)->propData->backgroundNoise_dBm * channelBandwidth)
 
the code for the function  GLOMO_PropBackgroundNoise_dBm is too wrong
 
it should be
 
#define GLOMO_PropBackgroundNoise_dBm(node, channelBandwidth) \
            ((node)->propData->backgroundNoise_dBm + 10*log10(channelBandwidth))
 

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-907253912-1177241487=:17096-- --===============1773748416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1773748416==-- From manet-bounces@ietf.org Sun Apr 22 10:07:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfcjC-0006DH-UC; Sun, 22 Apr 2007 10:07:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfcjB-00065L-8d for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 10:07:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfcjA-00065D-VD for manet@ietf.org; Sun, 22 Apr 2007 10:07:44 -0400 Received: from neptune.azu.com ([67.15.54.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfcj6-0000YO-Lw for manet@ietf.org; Sun, 22 Apr 2007 10:07:44 -0400 Received: (qmail 21524 invoked by uid 89); 22 Apr 2007 23:07:32 +0900 Received: from unknown (HELO IBM-T42) (218.225.198.74) by 0 with SMTP; 22 Apr 2007 23:07:32 +0900 Date: Sun, 22 Apr 2007 23:07:36 +0900 From: "Jia Hu" To: "manet" Organization: WICI X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e140a89d08e89747ee196e282ac2228 Message-Id: Subject: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wiiat@kis-lab.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org [Apologies if you receive this more than once] ##################################################################### IEEE/WIC/ACM WEB INTELLIGENCE 2007 CALL FOR PAPERS ##################################################################### 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07) Silicon Valley, USA, November 2-5, 2007 Official: http://www.cs.sjsu.edu/wi07/wi/ Mirror: http://www.maebashi-it.org/wi07/wi/ (to be collocated with IAT'07, BIBM'07 and GrC'07) Sponsored By IEEE Computer Society Web Intelligence Consortium (WIC) Association for Computing Machinery (ACM) ###################################################################### # Conference Chair # Andrei Broder, VP, Yahoo Fellow, Yahoo! Research # # Program Chair and Co-Chairs # T.Y. Lin, Professor, SJSU, BISC Fellow, UC-Berkeley # Laura Haas, Director, IBM Almaden Research Center # Janusz Kacprzyk, Professor, Polish Academy of Science # Rajeev Motwani, Professor, Stanford University # # Organizing Chair # Howard Ho, Manager, IBM Almaden Research Center # # WI-IAT Joint Keynote Speakers (Tentative) # # Vinton G. Cerf, Turing Award Winner, # VP and Chief Internet Evangelist, Google # Anant Jhingran, VP and CTO, IBM Silicon Valley Laboratory # # (More WI Invited Speakers will be announced) # # (Papers Due: ** June 1 **, 2007) # Accepted papers will be published in the conference proceedings # by the IEEE Computer Society Press, which are indexed by EI. ###################################################################### Web Intelligence (WI) has been recognized as a new direction for scientific research and development to explore the fundamental roles as well as practical impacts of Artificial Intelligence (AI) (e.g., knowledge representation, planning, knowledge discovery and data mining, intelligent agents, and social network intelligence) and advanced Information Technology (IT) (e.g., wireless networks, ubiquitous devices, social networks, and data/knowledge grids) on the next generation of Web-empowered products, systems, services, and activities. It is one of the most important as well as promising IT research fields in the era of Web and agent intelligence. The 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07) will be jointly held with the 2007 IEEE/WIC/ACM International Conference on Intelligent Agent Technology (IAT'07), the 2007 IEEE International Conference on Bioinformatics and Biomedicine (BIBM'07), and the 2007 IEEE International Conference on Granular Computing (GrC'07) for providing synergism among the four research areas. It will provide opportunities for technical collaboration beyond that of previous conferences. The four conferences will have a joint opening, keynote, reception, and banquet. Attendees only need to register for one conference and can attend workshops, sessions and tutorials across the four conferences. We are also planning a joint panel and joint paper sessions that discuss common problems in the four areas. +++++++++++ Highlights +++++++++++ The conference will be held in Silicon Valley, California. Many high-tech companies and three distinguished universities (Stanford, UC Berkely and UCSC) are just around the corner. The highlight of the conference is that a unique forum consisting of a half-day industry/ demo track and free discussion will be organized to link industries and academics. Leading IT companies like IBM, Google, and Yahoo etc will present at the conference. The area now known as Silicon Valley has been a center of technological development since the 1950's. The name Silicon Valley stems from the early 1970's, when the area had become the center for many semiconductor companies. While still hosting semiconductor and microprocessor companies, the region now hosts the headquarters of high tech companies of every kind, including many of the best known and most prestigious names in personal computers, Web search, Internet auctions, networking, storage, databases, etc. +++++++++++++++++++ Topics of Interest +++++++++++++++++++ The topics and areas include, but not limited to: * WI Foundations - Brain Informatics for WI - Human level WI - New cognitive models and computational models for WI - Granular Computing (GrC) for WI - Autonomy-Oriented Computing (AOC) for WI * World Wide Wisdom Web (W4) - Meta-Knowledge Discovery and Representation - Problem Solver Markup Language (PSML) - Search of Best Means and Ends - Goal-Directed Services Support - Distributed Resources Optimization - Service Self-Aggregation - Web Inference Engine - Information and Knowledge Markets - New Social Interaction Paradigms - Social and Psychological Contexts - Regularities and Laws of W4 * Social Networks and Social Intelligence - Social Network Mining - Web Site Clustering - Link Topology and Site Hierarchy - Theories of Small-World Web - Virtual and Web Communities - Web-Based Cooperative Work - Knowledge Community Formation and Support - Ubiquitous Computing - Intelligent Wireless Web - Ubiquitous Learning Systems - Entertainment * Knowledge Grids and Grid Intelligence - Semantic Grids - Knowledge Resources and Services Discovery - On-Demand Planning and Routing - Brokering and Scheduling - Middleware Architectures and Tools * Web Mining and Farming - Text Mining - Data Stream Mining - Multimedia Data Mining - Web Content Mining - Web Log and Usage Mining - Learning User Profiles - Context Sensitive Web Mining - Web Information Clustering - Web Page Clustering and Mining - E-Mail Classification - Web Site Classification - Web Information Indexing - Data Warehousing - Web Farming and Warehousing * Semantics and Ontology Engineering - Ontology-Based Information Extraction and Retrieval - Ontology-Based Web Mining - Web-Based Ontology Learning - Semantic Web * Web Agents - Global Information Foraging - Distributed Problem Solving - Coordination - Resource Intermediary and Coordination Mechanisms - Self-Organization and Reproduction - Agent Networks and Topologies - Mobile Agents - Macroscopic Behavior Modeling - Trust Models for Web Agents * Web Services - Service-Oriented Computing - Matchmaking - Web Service Reconfiguration - Web Service Workflow Composition - Middleware-Based Ubiquitous Services - Grid Services * Web Information Filtering and Retrieval - Automatic Cataloging and Indexing - Clustering-Based Recommender Systems - Collaborative Filtering and Recommendation - Hybrid Recommendation - Information Retrieval Criteria and Evaluations - Web Information Categorization and Ranking - Proxy and Cache Techniques - Web Prediction and Prefetching - Distributed Web Search - Specifications for Web Information Extraction Process - Web Crawling Systems - Search Engines and Meta-search Engines * Intelligent Human-Web Interaction - Adaptive Web Interfaces - Context-Aware Computing - Learning User Profiles - Personalized Interfaces - Personalized Web Sites - Remembrance Agents - Multimedia Representation - Visualization of Information and Knowledge - Social and Psychological Issues * Web Support Systems - Information Retrieval Support Systems - Web Site Navigation Support Systems - Recommender Support Systems - Web-Based Decision Support Systems - Soft Computing (including neural networks, fuzzy logic, evolutionary computation, rough sets, and granular computing) and Uncertainty Management for WI * Intelligent e-Technology - Business Intelligence - Digital Library - Decentralized Community Communication Techniques - e-Community - e-Business and e-Commerce - e-Finance - e-Government - e-Learning - e-Publishing - e-Science - Intelligent Enterprise Portals - Web-Based Direct Marketing and CRM - Web-Based EDI - Web Security, Integrity, Privacy and Trust ++++++++++++++++++++++++++++++++++++ On-Line Submissions and Publication ++++++++++++++++++++++++++++++++++++ High-quality papers in all WI related areas are solicited. Paper submissions should be limited to a maximum of 7 pages in the IEEE 2-column format, the same as the camera-ready format (see the Author Guidelines of last year at http://www.computer.org/portal/pages/cscps/cps/final/wi06.xml). All submitted papers will be reviewed by the Program Committee on the basis of technical quality, relevance, significance, and clarity. Note that WI'07 will accept ONLY on-line submissions, containing PDF versions. Please use the Submission Form on the WI'07 website to submit your paper. Accepted papers will be published in the conference proceedings by the IEEE Computer Society Press that are indexed by EI. Submissions accepted as regular papers will be allocated 7 pages in the proceedings and accorded oral presentation times in the main conference. Submissions accepted as short papers will be allocated 4 pages in the proceedings and will have a shorter presentation time at the conference than regular papers. All co-authors will be notified at all time, for the submission, notification, and confirmation on the attendance. Submitting a paper to the conference and workshops means that, if the paper is accepted, at least one author should attend the conference to present the paper. The acceptance list and no-show list will be openly published on-line. For no-show authors, their affiliations will receive a notification. A selected number of WI'07 accepted papers will be expanded and revised for inclusion in Web Intelligence and Agent Systems: An International Journal (http://wi-consortium.org/journal.html) and in Annual Review of Intelligent Informatics (http://www.wi-consortium.org/annual.html). More detailed instructions and the On-Line Submission Form can be found from the WI'07 homepage: http://www.cs.sjsu.edu/wi07/wi/. ++++++++++++++++++++++++ WI'07 Best Paper Awards ++++++++++++++++++++++++ The best paper awards will be conferred at the conference on the authors of (1) the best research paper and (2) the best application paper. Application-oriented submissions will be considered for the best application paper award. The full author list and paper title will be announced on the Web Intelligence Consortium homepage: http://wi-consortium.org/html/wicawards.html ++++++++++++++++++++ Industry/Demo-Track ++++++++++++++++++++ We solicit Industry/Demo-Track papers by the following methods. (1) Industry papers of 4 pages can be submitted on the same schedule as the research track. (2) Separate 2 page demo proposals can submitted at a later schedule. (3) Full regular paper submissions can include a demo option. That is, a full paper submissions will be asked to specify if they would like to give a demonstration; choice of demonstrations (while utilizing information from the regular reviewing process) will be selected based on value as a demonstration. For options (1) and (2), please find more detailed instructions at the homepage: http://www.cs.sjsu.edu/wi07/wi/ We are planning to arrange the Industry/Demo track in the afternoon of November 3 (before and during the conference reception), jointly with the IAT'07 Demo sessions. Leading IT companies in Silicon Valley will be invited to attend this track. ++++++++++ Workshops ++++++++++ As an important part of the conference, the workshop program will focus on new research challenges and initiatives. All papers accepted for workshops will be included in the Workshop Proceedings published by the IEEE Computer Society Press that are indexed by EI, and will be available at the workshops. Detailed information is available at the conference homepage. Note: we will not have a separate workshop registration fee (i.e., conference registration covers everything). ------------------ WI 2007 Workshops: ------------------ Title: Educating the Web-Generation Organisers: Elisabeth Heinemann Email: elisabeth.heinemann@googlemail.com Web page: http://www.effactory.com/Edu4WebGen/ Title: Collective Intelligence on Semantic Web Organisers: Geun Sik Jo; Jason J. Jung; Ngoc Thanh Nguyen Email: gsjo@inha.ac.kr; j2jung@intelligent.pe.kr; thanh@pwr.wroc.pl Web page: http://intelligent.pe.kr/CISW07/ Title: New Computing Paradigms for Web Intelligence and Brain Informatics Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter Fensel Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: Title: Web Personalization and Recommender Systems Organisers: Yue Xu Email: yue.xu@qut.edu.au Web page: http://www.wprs07.fit.qut.edu.au/ Title: Service Composition Organisers: M. Brian Blake; Dumitru Roman; Charles Petrie Email: blakeb@cs.georgetown.edu; dumitru.roman@deri.org Web site: http://events.deri.at/sercomp2007/ Title: Biomedicine applications of Web technologies Organisers: Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu Email: chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw; whlu@mail.ncku.edu.tw Web page: http://chunnan.iis.sinica.edu.tw/BMWT2007.html Title: Intelligent Web Interaction Workshop 2007 1st Organiser: Prof. Seiji YAMADA Email: seiji@nii.ac.jp Web site: http://ymd.ex.nii.ac.jp/ws/iwi/07/ Title: Cyberinfrastucture for e-Science Organisers: Prof. Vasant Honavar; A/prof. Kei Cheung Email: honavar@cs.iastate.edu; kei.cheung@yale.edu Web page: http://www.cild.iastate.edu/events/CyIneS2007/ Title: 2007 International Workshop on Social Media Analysis Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu Email: sma@comp.hkbu.edu.hk Web page: http://www.comp.hkbu.edu.hk/~sma/ Title: Web Security, Integrity, Privacy and Trust Organisers: Dr. Yiuming Cheung, Prof. Michael Chau, and Prof. Yong Zhang Email: ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk; zhangyong076@gmail.com Web page: ------------------- IAT 2007 Workshops: ------------------- Title: Second International Workshop on Communication between Human and Artificial Agents (CHAA-07) Organisers: Christel Kemke Email: ckemke@cs.umanitoba.ca Web page: http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ Title: Rational, Robust, and Secure Negotiations in Multi-Agent Systems (RRS2007) Organisers: Takayuki Ito Email: ito.takayuki@nitech.ac.jp Web page: http://www-itolab.mta.nitech.ac.jp/RRS2007/ Title: P2P Computing and Autonomous Agents Organisers: Tarek Helmy, Khaled Ragab Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa Web Page: http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html Title: Multiagent systems in E-business: concepts, technologies and applications Organisers: Costin Badica; Maria Ganzha; Marcin Paprzycki Email: badica_costin@software.ucv.ro; ganzha@euh-e.edu.pl; marcin.parzycki@swps.edu.pl Web page: http://software.ucv.ro/~badica_costin/maseb2007/ Title: Agent & Data Mining Interaction Organisers: Pericles A. Mitkas, Longbing Cao, Vladimir Gorodetsky, Justin Zhan Email: mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page: http://issel.ee.auth.gr/ADMI For more information, please visit the conference website at http://www.cs.sjsu.edu/wi07/wi/?index=workshop. ++++++++++ Tutorials ++++++++++ WI'07 also welcomes Tutorial proposals. WI'07 will include tutorials providing in-depth background on subjects that are of broad interest to the Web intelligence community. Both short (2 hours) and long (half day) tutorials will be considered. The tutorials will be part of the main conference technical program. Detailed information is available at the conference homepage. Note: we will not have a separate tutorials registration fee (i.e., only one conference registration covers everything). ++++++++++++++++ Important Dates ++++++++++++++++ Workshop proposal submission: March 20, 2007 Electronic submission of full papers: ** June 1, 2007 ** Tutorial proposal submission: June 15, 2007 Notification of paper acceptance: July 22, 2007 Camera-ready copies of accepted papers: August 17, 2007 Conference: November 2-5, 2007 ++++++++++++++++++++++++ Conference Organization ++++++++++++++++++++++++ Conference Chair: * Andrei Broder, Yahoo! Research, USA Program Chair: * Tsau Young (T.Y.) Lin, San Jose State University/UC Berkeley, USA WI Program Co-Chairs: * Laura Haas, IBM Almaden Research Center, USA * Janusz Kacprzyk, Polish Academy of Science, Poland * Rajeev Motwani, Stanford University, USA IAT Program Co-Chairs: * Jeffrey M. Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Matthias Klusch, German Research Center for AI, Germany * Chengqi Zhang, University of Technology, Sydney, Australia Organizing Chair: * Howard Ho, IBM Almaden Research Center, USA Workshop Co-Chairs: * Vijay Raghavan, University of Louisiana, USA * Yuefeng Li, Queensland University of Technology, Australia Tutorial Chair: * Pawan Lingras, Saint Mary's University, Canada Industry/Demo-Track Chair: * Jianchang Mao, Yahoo! Inc., USA Local Accommodations Co-Chairs: * David Scot Taylor, San Jose State University, USA * Tom Qi Zhang, Google, USA Publicity Chair: * James Wang, Clemson University, USA (chair) Publicity Co-Chairs: * Martine De Cock, Ghent University, Belgium * Jia Hu, International WIC Institute, China * Debajyoti Mukhopadhyay, West Bengal University of Technology, India IEEE-CS-TCII Chair: * Ning Zhong, Maebashi Institute of Technology, Japan ACM-SIGART Chair * Maria Gini, University of Minnesota, USA WIC Co-Chairs/Directors: * Ning Zhong, Maebashi Institute of Technology, Japan * Jiming Liu, University of Windsor, Canada WIC Advisory Board: * Edward A. Feigenbaum, Stanford University, USA * Setsuo Ohsuga, Waseda University, Japan * Benjamin Wah, University of Illinois, Urbana-Champaign, USA * Philip Yu, IBM Thomas J. Watson Research Center, USA * L.A. Zadeh, University of California Berkeley, USA WIC Tech. Committee & WI/IAT Steering Committee: * Jeffrey Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Nick Cercone, Dalhousie University, Canada * Dieter Fensel, National University of Ireland, Ireland * Georg Gottlob, Oxford University, UK * Lakhmi Jain, University of South Australia, Australia * Jianchang Mao, Yahoo! Inc., USA * Pierre Morizet-Mahoudeaux, Compiegne University of Technology, France * Hiroshi Motoda, Osaka University, Japan * Toyoaki Nishida, Kyoto University, Japan * Andrzej Skowron, Warsaw University, Poland * Jinglong Wu, Kagawa University, Japan * Xindong Wu, University of Vermont, USA * Yiyu Yao, University of Regina, Canada Webmaster: * Albert Sutojo, San Jose State University, USA Abbreviation: WI 2007, WI2007, WI'2007, WI'07, WI07, WI 07, WI-07, WI-2007, WI-IAT 2007, WI-IAT2007, WI-IAT'2007, WI-IAT'07, WI-IAT07, WI-IAT 07, WI-IAT-2007, WI-IAT-07, WI/IAT 2007, WI/IAT2007, WI/IAT'2007, WI/IAT'07, WI/IAT07, WI/IAT 07, WI/IAT-2007, WI/IAT-07 *** Contact Information *** Jia Hu International WIC Institute, China E-mail: hujia@kis-lab.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 22 10:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfcyr-00050D-OA; Sun, 22 Apr 2007 10:23:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfcyp-000507-J8 for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 10:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfcyp-0004zz-9R for manet@ietf.org; Sun, 22 Apr 2007 10:23:55 -0400 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfcyj-0005LB-Un for manet@ietf.org; Sun, 22 Apr 2007 10:23:55 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 426FE34015; Sun, 22 Apr 2007 10:23:52 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 10:23:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Date: Sun, 22 Apr 2007 10:23:47 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC01C8BD85@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Thread-Index: AceE569RpTLCeYn6QQ+gW0W8lFwUIwAAgfpg References: From: "Bound, Jim" To: , "manet" X-OriginalArrivalTime: 22 Apr 2007 14:23:49.0227 (UTC) FILETIME=[D82AABB0:01C784E9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Folks, is it appropriate to post call for paper on an IETF WG list. I don't think so this is a working group. thanks /jim=20 > -----Original Message----- > From: Jia Hu [mailto:wiiat@kis-lab.com]=20 > Sent: Sunday, April 22, 2007 10:08 AM > To: manet > Subject: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon=20 > Valley,USA) Deadline: June 1 >=20 > [Apologies if you receive this more than once] >=20 > ##################################################################### > IEEE/WIC/ACM WEB INTELLIGENCE 2007 > CALL FOR PAPERS > ##################################################################### >=20 > 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07) >=20 > Silicon Valley, USA, November 2-5, 2007 > Official: http://www.cs.sjsu.edu/wi07/wi/ > Mirror: http://www.maebashi-it.org/wi07/wi/ > (to be collocated with IAT'07, BIBM'07 and GrC'07) >=20 > Sponsored By > IEEE Computer Society > Web Intelligence Consortium (WIC) > Association for Computing Machinery (ACM) >=20 > ###################################################################### > # Conference Chair > # Andrei Broder, VP, Yahoo Fellow, Yahoo! Research > # > # Program Chair and Co-Chairs=09 > # T.Y. Lin, Professor, SJSU, BISC Fellow, UC-Berkeley > # Laura Haas, Director, IBM Almaden Research Center > # Janusz Kacprzyk, Professor, Polish Academy of Science > # Rajeev Motwani, Professor, Stanford University > # > # Organizing Chair=09 > # Howard Ho, Manager, IBM Almaden Research Center=20 > # > # WI-IAT Joint Keynote Speakers (Tentative) # # Vinton G.=20 > Cerf, Turing Award Winner,=20 > # VP and Chief Internet Evangelist, Google=20 > # Anant Jhingran, VP and CTO, IBM Silicon Valley Laboratory #=20 > # (More WI Invited Speakers will be announced) # # (Papers=20 > Due: ** June 1 **, 2007) # Accepted papers will be published=20 > in the conference proceedings # by the IEEE Computer Society=20 > Press, which are indexed by EI. > ###################################################################### >=20 > Web Intelligence (WI) has been recognized as a new direction=20 > for scientific research and development to explore the=20 > fundamental roles as well as practical impacts of Artificial=20 > Intelligence (AI) (e.g., knowledge representation, planning,=20 > knowledge discovery and data mining, intelligent agents, and=20 > social network intelligence) and advanced Information=20 > Technology (IT) (e.g., wireless networks, ubiquitous devices,=20 > social networks, and data/knowledge grids) on the next=20 > generation of Web-empowered products, systems, services, and=20 > activities. It is one of the most important as well as=20 > promising IT research fields in the era of Web and agent intelligence. >=20 > The 2007 IEEE/WIC/ACM International Conference on Web Intelligence > (WI'07) will be jointly held with the 2007 IEEE/WIC/ACM=20 > International Conference on Intelligent Agent Technology=20 > (IAT'07), the 2007 IEEE International Conference on=20 > Bioinformatics and Biomedicine (BIBM'07), and the 2007 IEEE=20 > International Conference on Granular Computing > (GrC'07) for providing synergism among the four research=20 > areas. It will provide opportunities for technical=20 > collaboration beyond that of previous conferences. The four=20 > conferences will have a joint opening, keynote, reception,=20 > and banquet. Attendees only need to register for one=20 > conference and can attend workshops, sessions and tutorials=20 > across the four conferences. We are also planning a joint=20 > panel and joint paper sessions that discuss common problems=20 > in the four areas. >=20 > +++++++++++ > Highlights > +++++++++++ >=20 > The conference will be held in Silicon Valley, California.=20 > Many high-tech companies and three distinguished universities=20 > (Stanford, UC Berkely and UCSC) are just around the corner.=20 > The highlight of the conference is that a unique forum=20 > consisting of a half-day industry/ demo track and free=20 > discussion will be organized to link industries and=20 > academics. Leading IT companies like IBM, Google, and Yahoo=20 > etc will present at the conference. >=20 > The area now known as Silicon Valley has been a center of=20 > technological development since the 1950's. The name Silicon=20 > Valley stems from the early 1970's, when the area had become=20 > the center for many semiconductor companies. While still=20 > hosting semiconductor and microprocessor companies, the=20 > region now hosts the headquarters of high tech companies of=20 > every kind, including many of the best known and most=20 > prestigious names in personal computers, Web search, Internet=20 > auctions, networking, storage, databases, etc. >=20 > +++++++++++++++++++ > Topics of Interest > +++++++++++++++++++ >=20 > The topics and areas include, but not limited to: >=20 > * WI Foundations > - Brain Informatics for WI > - Human level WI > - New cognitive models and computational models for WI > - Granular Computing (GrC) for WI > - Autonomy-Oriented Computing (AOC) for WI >=20 > * World Wide Wisdom Web (W4) > - Meta-Knowledge Discovery and Representation > - Problem Solver Markup Language (PSML) > - Search of Best Means and Ends > - Goal-Directed Services Support > - Distributed Resources Optimization > - Service Self-Aggregation > - Web Inference Engine > - Information and Knowledge Markets > - New Social Interaction Paradigms > - Social and Psychological Contexts > - Regularities and Laws of W4 >=20 > * Social Networks and Social Intelligence > - Social Network Mining > - Web Site Clustering > - Link Topology and Site Hierarchy > - Theories of Small-World Web > - Virtual and Web Communities > - Web-Based Cooperative Work > - Knowledge Community Formation and Support > - Ubiquitous Computing > - Intelligent Wireless Web > - Ubiquitous Learning Systems > - Entertainment >=20 > * Knowledge Grids and Grid Intelligence > - Semantic Grids > - Knowledge Resources and Services Discovery > - On-Demand Planning and Routing > - Brokering and Scheduling > - Middleware Architectures and Tools >=20 > * Web Mining and Farming > - Text Mining > - Data Stream Mining > - Multimedia Data Mining > - Web Content Mining > - Web Log and Usage Mining > - Learning User Profiles > - Context Sensitive Web Mining > - Web Information Clustering > - Web Page Clustering and Mining > - E-Mail Classification > - Web Site Classification > - Web Information Indexing > - Data Warehousing > - Web Farming and Warehousing >=20 > * Semantics and Ontology Engineering > - Ontology-Based Information Extraction and Retrieval > - Ontology-Based Web Mining > - Web-Based Ontology Learning > - Semantic Web >=20 > * Web Agents > - Global Information Foraging > - Distributed Problem Solving > - Coordination > - Resource Intermediary and Coordination Mechanisms > - Self-Organization and Reproduction > - Agent Networks and Topologies > - Mobile Agents > - Macroscopic Behavior Modeling > - Trust Models for Web Agents >=20 > * Web Services > - Service-Oriented Computing > - Matchmaking > - Web Service Reconfiguration > - Web Service Workflow Composition > - Middleware-Based Ubiquitous Services > - Grid Services >=20 > * Web Information Filtering and Retrieval > - Automatic Cataloging and Indexing > - Clustering-Based Recommender Systems > - Collaborative Filtering and Recommendation > - Hybrid Recommendation > - Information Retrieval Criteria and Evaluations > - Web Information Categorization and Ranking > - Proxy and Cache Techniques > - Web Prediction and Prefetching > - Distributed Web Search > - Specifications for Web Information Extraction Process > - Web Crawling Systems > - Search Engines and Meta-search Engines >=20 > * Intelligent Human-Web Interaction > - Adaptive Web Interfaces > - Context-Aware Computing > - Learning User Profiles > - Personalized Interfaces > - Personalized Web Sites > - Remembrance Agents > - Multimedia Representation > - Visualization of Information and Knowledge > - Social and Psychological Issues >=20 > * Web Support Systems > - Information Retrieval Support Systems > - Web Site Navigation Support Systems > - Recommender Support Systems > - Web-Based Decision Support Systems > - Soft Computing (including neural networks, fuzzy logic, > evolutionary computation, rough sets, and granular computing) > and Uncertainty Management for WI >=20 > * Intelligent e-Technology > - Business Intelligence > - Digital Library > - Decentralized Community Communication Techniques > - e-Community > - e-Business and e-Commerce > - e-Finance > - e-Government > - e-Learning > - e-Publishing > - e-Science > - Intelligent Enterprise Portals > - Web-Based Direct Marketing and CRM > - Web-Based EDI > - Web Security, Integrity, Privacy and Trust >=20 > ++++++++++++++++++++++++++++++++++++ > On-Line Submissions and Publication > ++++++++++++++++++++++++++++++++++++ >=20 > High-quality papers in all WI related areas are solicited.=20 > Paper submissions should be limited to a maximum of 7 pages=20 > in the IEEE 2-column format, the same as the camera-ready=20 > format (see the Author Guidelines of last year at=20 > http://www.computer.org/portal/pages/cscps/cps/final/wi06.xml). =20 > All submitted papers will be reviewed by the Program=20 > Committee on the basis of technical quality, relevance,=20 > significance, and clarity.=20 >=20 > Note that WI'07 will accept ONLY on-line submissions,=20 > containing PDF versions. Please use the Submission Form on=20 > the WI'07 website to submit your paper. Accepted papers will=20 > be published in the conference proceedings by the IEEE=20 > Computer Society Press that are indexed by EI. >=20 > Submissions accepted as regular papers will be allocated 7=20 > pages in the proceedings and accorded oral presentation times=20 > in the main conference.=20 > Submissions accepted as short papers will be allocated 4=20 > pages in the proceedings and will have a shorter presentation=20 > time at the conference than regular papers. >=20 > All co-authors will be notified at all time, for the=20 > submission, notification, and confirmation on the attendance.=20 > Submitting a paper to the conference and workshops means=20 > that, if the paper is accepted, at least one author should=20 > attend the conference to present the paper. The acceptance=20 > list and no-show list will be openly published on-line. For=20 > no-show authors, their affiliations will receive a notification.=20 >=20 > A selected number of WI'07 accepted papers will be expanded=20 > and revised for inclusion in Web Intelligence and Agent=20 > Systems: An International Journal=20 > (http://wi-consortium.org/journal.html) and in Annual Review=20 > of Intelligent Informatics (http://www.wi-consortium.org/annual.html). >=20 > More detailed instructions and the On-Line Submission Form=20 > can be found from the WI'07 homepage: http://www.cs.sjsu.edu/wi07/wi/. >=20 > ++++++++++++++++++++++++ > WI'07 Best Paper Awards=20 > ++++++++++++++++++++++++ >=20 > The best paper awards will be conferred at the conference on=20 > the authors of (1) the best research paper and (2) the best=20 > application paper. Application-oriented submissions will be=20 > considered for the best application paper award.=20 >=20 > The full author list and paper title will be announced on the=20 > Web Intelligence Consortium homepage: > http://wi-consortium.org/html/wicawards.html >=20 > ++++++++++++++++++++ > Industry/Demo-Track > ++++++++++++++++++++ >=20 > We solicit Industry/Demo-Track papers by the following methods. >=20 > (1) Industry papers of 4 pages can be submitted on the same=20 > schedule as > the research track. > (2) Separate 2 page demo proposals can submitted at a later schedule. > (3) Full regular paper submissions can include a demo option. > That is, a full paper submissions will be asked to > specify if they would like to give a demonstration; choice of > demonstrations (while utilizing information from the=20 > regular reviewing > process) will be selected based on value as a demonstration. >=20 > For options (1) and (2), please find more detailed=20 > instructions at the homepage: http://www.cs.sjsu.edu/wi07/wi/ >=20 > We are planning to arrange the Industry/Demo track in the=20 > afternoon of November 3 (before and during the conference=20 > reception), jointly with the IAT'07 Demo sessions. Leading IT=20 > companies in Silicon Valley will be invited to attend this track. >=20 > ++++++++++ > Workshops > ++++++++++ >=20 > As an important part of the conference, the workshop program=20 > will focus on new research challenges and initiatives. All=20 > papers accepted for workshops will be included in the=20 > Workshop Proceedings published by the IEEE Computer Society=20 > Press that are indexed by EI, and will be available at the=20 > workshops. Detailed information is available at the=20 > conference homepage. >=20 > Note: we will not have a separate workshop registration fee=20 > (i.e., conference registration covers everything). >=20 > ------------------ > WI 2007 Workshops: > ------------------ > Title: Educating the Web-Generation > Organisers: Elisabeth Heinemann > Email: elisabeth.heinemann@googlemail.com > Web page: http://www.effactory.com/Edu4WebGen/ >=20 > Title: Collective Intelligence on Semantic Web > Organisers: Geun Sik Jo; Jason J. Jung; Ngoc Thanh Nguyen > Email: gsjo@inha.ac.kr; j2jung@intelligent.pe.kr;=20 > thanh@pwr.wroc.pl Web page: > http://intelligent.pe.kr/CISW07/ >=20 > Title: New Computing Paradigms for Web Intelligence and Brain=20 > Informatics > Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter Fensel > Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: >=20 > Title: Web Personalization and Recommender Systems > Organisers: Yue Xu > Email: yue.xu@qut.edu.au > Web page: http://www.wprs07.fit.qut.edu.au/ >=20 > Title: Service Composition > Organisers: M. Brian Blake; Dumitru Roman; Charles Petrie > Email: blakeb@cs.georgetown.edu; dumitru.roman@deri.org Web=20 > site: http://events.deri.at/sercomp2007/ >=20 > Title: Biomedicine applications of Web technologies > Organisers: Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu > Email: chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw;=20 > whlu@mail.ncku.edu.tw Web page:=20 > http://chunnan.iis.sinica.edu.tw/BMWT2007.html >=20 > Title: Intelligent Web Interaction Workshop 2007 1st=20 > Organiser: Prof. Seiji YAMADA > Email: seiji@nii.ac.jp > Web site: http://ymd.ex.nii.ac.jp/ws/iwi/07/ >=20 > Title: Cyberinfrastucture for e-Science > Organisers: Prof. Vasant Honavar; A/prof. Kei Cheung > Email: honavar@cs.iastate.edu; kei.cheung@yale.edu Web page:=20 > http://www.cild.iastate.edu/events/CyIneS2007/ >=20 > Title: 2007 International Workshop on Social Media Analysis > Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu > Email: sma@comp.hkbu.edu.hk > Web page: http://www.comp.hkbu.edu.hk/~sma/ >=20 > Title: Web Security, Integrity, Privacy and Trust > Organisers: Dr. Yiuming Cheung, Prof. Michael Chau, and Prof.=20 > Yong Zhang > Email: ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk;=20 > zhangyong076@gmail.com Web page: >=20 > ------------------- > IAT 2007 Workshops: > ------------------- > Title: Second International Workshop on Communication between=20 > Human and Artificial Agents (CHAA-07) > Organisers: Christel Kemke > Email: ckemke@cs.umanitoba.ca > Web page: http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ >=20 > Title: Rational, Robust, and Secure Negotiations in=20 > Multi-Agent Systems (RRS2007) > Organisers: Takayuki Ito > Email: ito.takayuki@nitech.ac.jp > Web page: http://www-itolab.mta.nitech.ac.jp/RRS2007/ >=20 > Title: P2P Computing and Autonomous Agents > Organisers: Tarek Helmy, Khaled Ragab > Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa Web Page:=20 > http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html >=20 > Title: Multiagent systems in E-business: concepts,=20 > technologies and applications > Organisers: Costin Badica; Maria Ganzha; Marcin Paprzycki > Email: badica_costin@software.ucv.ro; ganzha@euh-e.edu.pl;=20 > marcin.parzycki@swps.edu.pl Web page:=20 > http://software.ucv.ro/~badica_costin/maseb2007/ >=20 > Title: Agent & Data Mining Interaction > Organisers: Pericles A. Mitkas, Longbing Cao, Vladimir=20 > Gorodetsky, Justin Zhan > Email: mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page:=20 > http://issel.ee.auth.gr/ADMI=20 >=20 > For more information, please visit the conference website at=20 > http://www.cs.sjsu.edu/wi07/wi/?index=3Dworkshop. >=20 > ++++++++++ > Tutorials > ++++++++++ >=20 > WI'07 also welcomes Tutorial proposals. WI'07 will include=20 > tutorials providing in-depth background on subjects that are=20 > of broad interest to the Web intelligence community. Both=20 > short (2 hours) and long (half > day) tutorials will be considered. The tutorials will be part=20 > of the main conference technical program. Detailed=20 > information is available at the conference homepage. >=20 > Note: we will not have a separate tutorials registration fee=20 > (i.e., only one conference registration covers everything). >=20 > ++++++++++++++++ > Important Dates > ++++++++++++++++ >=20 > Workshop proposal submission: March 20, 2007 > Electronic submission of full papers: ** June 1, 2007 ** > Tutorial proposal submission: June 15, 2007 > Notification of paper acceptance: July 22, 2007 > Camera-ready copies of accepted papers: August 17, 2007 > Conference: November 2-5, 2007 >=20 > ++++++++++++++++++++++++ > Conference Organization > ++++++++++++++++++++++++ >=20 > Conference Chair: > * Andrei Broder, Yahoo! Research, USA >=20 > Program Chair: > * Tsau Young (T.Y.) Lin, San Jose State University/UC Berkeley, USA >=20 > WI Program Co-Chairs: > * Laura Haas, IBM Almaden Research Center, USA > * Janusz Kacprzyk, Polish Academy of Science, Poland > * Rajeev Motwani, Stanford University, USA >=20 > IAT Program Co-Chairs: > * Jeffrey M. Bradshaw, UWF/Institute for Human and Machine=20 > Cognition, USA > * Matthias Klusch, German Research Center for AI, Germany > * Chengqi Zhang, University of Technology, Sydney, Australia >=20 > Organizing Chair: > * Howard Ho, IBM Almaden Research Center, USA >=20 > Workshop Co-Chairs: > * Vijay Raghavan, University of Louisiana, USA > * Yuefeng Li, Queensland University of Technology, Australia >=20 > Tutorial Chair: > * Pawan Lingras, Saint Mary's University, Canada >=20 > Industry/Demo-Track Chair: > * Jianchang Mao, Yahoo! Inc., USA >=20 > Local Accommodations Co-Chairs: > * David Scot Taylor, San Jose State University, USA > * Tom Qi Zhang, Google, USA >=20 > Publicity Chair:=20 > * James Wang, Clemson University, USA (chair) Publicity Co-Chairs:=20 > * Martine De Cock, Ghent University, Belgium > * Jia Hu, International WIC Institute, China > * Debajyoti Mukhopadhyay, West Bengal University of=20 > Technology, India >=20 > IEEE-CS-TCII Chair: > * Ning Zhong, Maebashi Institute of Technology, Japan >=20 > ACM-SIGART Chair > * Maria Gini, University of Minnesota, USA >=20 > WIC Co-Chairs/Directors: > * Ning Zhong, Maebashi Institute of Technology, Japan > * Jiming Liu, University of Windsor, Canada >=20 > WIC Advisory Board:=20 > * Edward A. Feigenbaum, Stanford University, USA > * Setsuo Ohsuga, Waseda University, Japan > * Benjamin Wah, University of Illinois, Urbana-Champaign, USA > * Philip Yu, IBM Thomas J. Watson Research Center, USA > * L.A. Zadeh, University of California Berkeley, USA >=20 > WIC Tech. Committee & WI/IAT Steering Committee: > * Jeffrey Bradshaw, UWF/Institute for Human and Machine=20 > Cognition, USA > * Nick Cercone, Dalhousie University, Canada > * Dieter Fensel, National University of Ireland, Ireland > * Georg Gottlob, Oxford University, UK > * Lakhmi Jain, University of South Australia, Australia > * Jianchang Mao, Yahoo! Inc., USA > * Pierre Morizet-Mahoudeaux, Compiegne University of=20 > Technology, France > * Hiroshi Motoda, Osaka University, Japan > * Toyoaki Nishida, Kyoto University, Japan > * Andrzej Skowron, Warsaw University, Poland > * Jinglong Wu, Kagawa University, Japan > * Xindong Wu, University of Vermont, USA > * Yiyu Yao, University of Regina, Canada >=20 > Webmaster: > * Albert Sutojo, San Jose State University, USA >=20 > Abbreviation:=20 > WI 2007, WI2007, WI'2007, WI'07, WI07, WI 07, WI-07, WI-2007,=20 > WI-IAT 2007, WI-IAT2007, WI-IAT'2007, WI-IAT'07, WI-IAT07,=20 > WI-IAT 07, WI-IAT-2007, WI-IAT-07, WI/IAT 2007, WI/IAT2007,=20 > WI/IAT'2007, WI/IAT'07, WI/IAT07, WI/IAT 07, WI/IAT-2007, WI/IAT-07 >=20 > *** Contact Information *** >=20 > Jia Hu > International WIC Institute, China > E-mail: hujia@kis-lab.com >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 22 16:01:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfiFT-0000yh-W1; Sun, 22 Apr 2007 16:01:27 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfiFS-0000yb-Pt for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 16:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfiFS-0000yT-GG for manet@ietf.org; Sun, 22 Apr 2007 16:01:26 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfiFO-0006wr-GE for manet@ietf.org; Sun, 22 Apr 2007 16:01:26 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1177272081!13267164!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 15996 invoked from network); 22 Apr 2007 20:01:21 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-7.tower-119.messagelabs.com with SMTP; 22 Apr 2007 20:01:21 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l3MK1KmU011197; Sun, 22 Apr 2007 13:01:21 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l3MK1Ke8013037; Sun, 22 Apr 2007 15:01:20 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.64]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l3MK1GLm013007; Sun, 22 Apr 2007 15:01:17 -0500 (CDT) Message-ID: <462BBF0C.4010800@gmail.com> Date: Sun, 22 Apr 2007 22:01:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Bound, Jim" Subject: Re: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 References: <816DD9299957E547B5D758D7F977D6DC01C8BD85@tayexc14.americas.cpqcorp.net> In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01C8BD85@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a4195ffb11c7b0baf82f77b2a730aa9 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Bound, Jim wrote: > Folks, is it appropriate to post call for paper on an IETF WG list. > I don't think so this is a working group. I think it is not appropriate to post Call for Papers on the MANET WG mailing list. I am reacting to this because there are too many CfPs on the MANET mailing list, largely more than WG work traffic. Alex > > thanks /jim > >> -----Original Message----- From: Jia Hu [mailto:wiiat@kis-lab.com] >> Sent: Sunday, April 22, 2007 10:08 AM To: manet Subject: [manet] >> CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley,USA) Deadline: June 1 >> >> [Apologies if you receive this more than once] >> >> ##################################################################### >> IEEE/WIC/ACM WEB INTELLIGENCE 2007 CALL FOR PAPERS >> ##################################################################### >> >> >> 2007 IEEE/WIC/ACM International Conference on Web Intelligence >> (WI'07) >> >> Silicon Valley, USA, November 2-5, 2007 Official: >> http://www.cs.sjsu.edu/wi07/wi/ Mirror: >> http://www.maebashi-it.org/wi07/wi/ (to be collocated with IAT'07, >> BIBM'07 and GrC'07) >> >> Sponsored By IEEE Computer Society Web Intelligence Consortium >> (WIC) Association for Computing Machinery (ACM) >> >> ###################################################################### >> # Conference Chair # Andrei Broder, VP, Yahoo Fellow, Yahoo! >> Research # # Program Chair and Co-Chairs # T.Y. Lin, >> Professor, SJSU, BISC Fellow, UC-Berkeley # Laura Haas, >> Director, IBM Almaden Research Center # Janusz Kacprzyk, >> Professor, Polish Academy of Science # Rajeev Motwani, >> Professor, Stanford University # # Organizing Chair # Howard Ho, >> Manager, IBM Almaden Research Center # # WI-IAT Joint Keynote >> Speakers (Tentative) # # Vinton G. Cerf, Turing Award Winner, # >> VP and Chief Internet Evangelist, Google # Anant Jhingran, VP and >> CTO, IBM Silicon Valley Laboratory # # (More WI Invited Speakers >> will be announced) # # (Papers Due: ** June 1 **, 2007) # Accepted >> papers will be published in the conference proceedings # by the >> IEEE Computer Society Press, which are indexed by EI. >> ###################################################################### >> >> >> Web Intelligence (WI) has been recognized as a new direction for >> scientific research and development to explore the fundamental >> roles as well as practical impacts of Artificial Intelligence (AI) >> (e.g., knowledge representation, planning, knowledge discovery and >> data mining, intelligent agents, and social network intelligence) >> and advanced Information Technology (IT) (e.g., wireless networks, >> ubiquitous devices, social networks, and data/knowledge grids) on >> the next generation of Web-empowered products, systems, services, >> and activities. It is one of the most important as well as >> promising IT research fields in the era of Web and agent >> intelligence. >> >> The 2007 IEEE/WIC/ACM International Conference on Web Intelligence >> (WI'07) will be jointly held with the 2007 IEEE/WIC/ACM >> International Conference on Intelligent Agent Technology (IAT'07), >> the 2007 IEEE International Conference on Bioinformatics and >> Biomedicine (BIBM'07), and the 2007 IEEE International Conference >> on Granular Computing (GrC'07) for providing synergism among the >> four research areas. It will provide opportunities for technical >> collaboration beyond that of previous conferences. The four >> conferences will have a joint opening, keynote, reception, and >> banquet. Attendees only need to register for one conference and can >> attend workshops, sessions and tutorials across the four >> conferences. We are also planning a joint panel and joint paper >> sessions that discuss common problems in the four areas. >> >> +++++++++++ Highlights +++++++++++ >> >> The conference will be held in Silicon Valley, California. Many >> high-tech companies and three distinguished universities (Stanford, >> UC Berkely and UCSC) are just around the corner. The highlight of >> the conference is that a unique forum consisting of a half-day >> industry/ demo track and free discussion will be organized to link >> industries and academics. Leading IT companies like IBM, Google, >> and Yahoo etc will present at the conference. >> >> The area now known as Silicon Valley has been a center of >> technological development since the 1950's. The name Silicon Valley >> stems from the early 1970's, when the area had become the center >> for many semiconductor companies. While still hosting semiconductor >> and microprocessor companies, the region now hosts the headquarters >> of high tech companies of every kind, including many of the best >> known and most prestigious names in personal computers, Web search, >> Internet auctions, networking, storage, databases, etc. >> >> +++++++++++++++++++ Topics of Interest +++++++++++++++++++ >> >> The topics and areas include, but not limited to: >> >> * WI Foundations - Brain Informatics for WI - Human level WI - New >> cognitive models and computational models for WI - Granular >> Computing (GrC) for WI - Autonomy-Oriented Computing (AOC) for WI >> >> * World Wide Wisdom Web (W4) - Meta-Knowledge Discovery and >> Representation - Problem Solver Markup Language (PSML) - Search of >> Best Means and Ends - Goal-Directed Services Support - Distributed >> Resources Optimization - Service Self-Aggregation - Web Inference >> Engine - Information and Knowledge Markets - New Social Interaction >> Paradigms - Social and Psychological Contexts - Regularities and >> Laws of W4 >> >> * Social Networks and Social Intelligence - Social Network Mining - >> Web Site Clustering - Link Topology and Site Hierarchy - Theories >> of Small-World Web - Virtual and Web Communities - Web-Based >> Cooperative Work - Knowledge Community Formation and Support - >> Ubiquitous Computing - Intelligent Wireless Web - Ubiquitous >> Learning Systems - Entertainment >> >> * Knowledge Grids and Grid Intelligence - Semantic Grids - >> Knowledge Resources and Services Discovery - On-Demand Planning and >> Routing - Brokering and Scheduling - Middleware Architectures and >> Tools >> >> * Web Mining and Farming - Text Mining - Data Stream Mining - >> Multimedia Data Mining - Web Content Mining - Web Log and Usage >> Mining - Learning User Profiles - Context Sensitive Web Mining - >> Web Information Clustering - Web Page Clustering and Mining - >> E-Mail Classification - Web Site Classification - Web Information >> Indexing - Data Warehousing - Web Farming and Warehousing >> >> * Semantics and Ontology Engineering - Ontology-Based Information >> Extraction and Retrieval - Ontology-Based Web Mining - Web-Based >> Ontology Learning - Semantic Web >> >> * Web Agents - Global Information Foraging - Distributed Problem >> Solving - Coordination - Resource Intermediary and Coordination >> Mechanisms - Self-Organization and Reproduction - Agent Networks >> and Topologies - Mobile Agents - Macroscopic Behavior Modeling - >> Trust Models for Web Agents >> >> * Web Services - Service-Oriented Computing - Matchmaking - Web >> Service Reconfiguration - Web Service Workflow Composition - >> Middleware-Based Ubiquitous Services - Grid Services >> >> * Web Information Filtering and Retrieval - Automatic Cataloging >> and Indexing - Clustering-Based Recommender Systems - Collaborative >> Filtering and Recommendation - Hybrid Recommendation - Information >> Retrieval Criteria and Evaluations - Web Information Categorization >> and Ranking - Proxy and Cache Techniques - Web Prediction and >> Prefetching - Distributed Web Search - Specifications for Web >> Information Extraction Process - Web Crawling Systems - Search >> Engines and Meta-search Engines >> >> * Intelligent Human-Web Interaction - Adaptive Web Interfaces - >> Context-Aware Computing - Learning User Profiles - Personalized >> Interfaces - Personalized Web Sites - Remembrance Agents - >> Multimedia Representation - Visualization of Information and >> Knowledge - Social and Psychological Issues >> >> * Web Support Systems - Information Retrieval Support Systems - Web >> Site Navigation Support Systems - Recommender Support Systems - >> Web-Based Decision Support Systems - Soft Computing (including >> neural networks, fuzzy logic, evolutionary computation, rough sets, >> and granular computing) and Uncertainty Management for WI >> >> * Intelligent e-Technology - Business Intelligence - Digital >> Library - Decentralized Community Communication Techniques - >> e-Community - e-Business and e-Commerce - e-Finance - e-Government >> - e-Learning - e-Publishing - e-Science - Intelligent Enterprise >> Portals - Web-Based Direct Marketing and CRM - Web-Based EDI - Web >> Security, Integrity, Privacy and Trust >> >> ++++++++++++++++++++++++++++++++++++ On-Line Submissions and >> Publication ++++++++++++++++++++++++++++++++++++ >> >> High-quality papers in all WI related areas are solicited. Paper >> submissions should be limited to a maximum of 7 pages in the IEEE >> 2-column format, the same as the camera-ready format (see the >> Author Guidelines of last year at >> http://www.computer.org/portal/pages/cscps/cps/final/wi06.xml). All >> submitted papers will be reviewed by the Program Committee on the >> basis of technical quality, relevance, significance, and clarity. >> >> Note that WI'07 will accept ONLY on-line submissions, containing >> PDF versions. Please use the Submission Form on the WI'07 website >> to submit your paper. Accepted papers will be published in the >> conference proceedings by the IEEE Computer Society Press that are >> indexed by EI. >> >> Submissions accepted as regular papers will be allocated 7 pages in >> the proceedings and accorded oral presentation times in the main >> conference. Submissions accepted as short papers will be allocated >> 4 pages in the proceedings and will have a shorter presentation >> time at the conference than regular papers. >> >> All co-authors will be notified at all time, for the submission, >> notification, and confirmation on the attendance. Submitting a >> paper to the conference and workshops means that, if the paper is >> accepted, at least one author should attend the conference to >> present the paper. The acceptance list and no-show list will be >> openly published on-line. For no-show authors, their affiliations >> will receive a notification. >> >> A selected number of WI'07 accepted papers will be expanded and >> revised for inclusion in Web Intelligence and Agent Systems: An >> International Journal (http://wi-consortium.org/journal.html) and >> in Annual Review of Intelligent Informatics >> (http://www.wi-consortium.org/annual.html). >> >> More detailed instructions and the On-Line Submission Form can be >> found from the WI'07 homepage: http://www.cs.sjsu.edu/wi07/wi/. >> >> ++++++++++++++++++++++++ WI'07 Best Paper Awards >> ++++++++++++++++++++++++ >> >> The best paper awards will be conferred at the conference on the >> authors of (1) the best research paper and (2) the best application >> paper. Application-oriented submissions will be considered for the >> best application paper award. >> >> The full author list and paper title will be announced on the Web >> Intelligence Consortium homepage: >> http://wi-consortium.org/html/wicawards.html >> >> ++++++++++++++++++++ Industry/Demo-Track ++++++++++++++++++++ >> >> We solicit Industry/Demo-Track papers by the following methods. >> >> (1) Industry papers of 4 pages can be submitted on the same >> schedule as the research track. (2) Separate 2 page demo proposals >> can submitted at a later schedule. (3) Full regular paper >> submissions can include a demo option. That is, a full paper >> submissions will be asked to specify if they would like to give a >> demonstration; choice of demonstrations (while utilizing >> information from the regular reviewing process) will be selected >> based on value as a demonstration. >> >> For options (1) and (2), please find more detailed instructions at >> the homepage: http://www.cs.sjsu.edu/wi07/wi/ >> >> We are planning to arrange the Industry/Demo track in the afternoon >> of November 3 (before and during the conference reception), jointly >> with the IAT'07 Demo sessions. Leading IT companies in Silicon >> Valley will be invited to attend this track. >> >> ++++++++++ Workshops ++++++++++ >> >> As an important part of the conference, the workshop program will >> focus on new research challenges and initiatives. All papers >> accepted for workshops will be included in the Workshop Proceedings >> published by the IEEE Computer Society Press that are indexed by >> EI, and will be available at the workshops. Detailed information is >> available at the conference homepage. >> >> Note: we will not have a separate workshop registration fee (i.e., >> conference registration covers everything). >> >> ------------------ WI 2007 Workshops: ------------------ Title: >> Educating the Web-Generation Organisers: Elisabeth Heinemann Email: >> elisabeth.heinemann@googlemail.com Web page: >> http://www.effactory.com/Edu4WebGen/ >> >> Title: Collective Intelligence on Semantic Web Organisers: Geun Sik >> Jo; Jason J. Jung; Ngoc Thanh Nguyen Email: gsjo@inha.ac.kr; >> j2jung@intelligent.pe.kr; thanh@pwr.wroc.pl Web page: >> http://intelligent.pe.kr/CISW07/ >> >> Title: New Computing Paradigms for Web Intelligence and Brain >> Informatics Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter >> Fensel Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: >> >> Title: Web Personalization and Recommender Systems Organisers: Yue >> Xu Email: yue.xu@qut.edu.au Web page: >> http://www.wprs07.fit.qut.edu.au/ >> >> Title: Service Composition Organisers: M. Brian Blake; Dumitru >> Roman; Charles Petrie Email: blakeb@cs.georgetown.edu; >> dumitru.roman@deri.org Web site: http://events.deri.at/sercomp2007/ >> >> >> Title: Biomedicine applications of Web technologies Organisers: >> Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu Email: >> chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw; >> whlu@mail.ncku.edu.tw Web page: >> http://chunnan.iis.sinica.edu.tw/BMWT2007.html >> >> Title: Intelligent Web Interaction Workshop 2007 1st Organiser: >> Prof. Seiji YAMADA Email: seiji@nii.ac.jp Web site: >> http://ymd.ex.nii.ac.jp/ws/iwi/07/ >> >> Title: Cyberinfrastucture for e-Science Organisers: Prof. Vasant >> Honavar; A/prof. Kei Cheung Email: honavar@cs.iastate.edu; >> kei.cheung@yale.edu Web page: >> http://www.cild.iastate.edu/events/CyIneS2007/ >> >> Title: 2007 International Workshop on Social Media Analysis >> Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu Email: >> sma@comp.hkbu.edu.hk Web page: http://www.comp.hkbu.edu.hk/~sma/ >> >> Title: Web Security, Integrity, Privacy and Trust Organisers: Dr. >> Yiuming Cheung, Prof. Michael Chau, and Prof. Yong Zhang Email: >> ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk; zhangyong076@gmail.com >> Web page: >> >> ------------------- IAT 2007 Workshops: ------------------- Title: >> Second International Workshop on Communication between Human and >> Artificial Agents (CHAA-07) Organisers: Christel Kemke Email: >> ckemke@cs.umanitoba.ca Web page: >> http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ >> >> Title: Rational, Robust, and Secure Negotiations in Multi-Agent >> Systems (RRS2007) Organisers: Takayuki Ito Email: >> ito.takayuki@nitech.ac.jp Web page: >> http://www-itolab.mta.nitech.ac.jp/RRS2007/ >> >> Title: P2P Computing and Autonomous Agents Organisers: Tarek Helmy, >> Khaled Ragab Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa Web >> Page: http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html >> >> Title: Multiagent systems in E-business: concepts, technologies and >> applications Organisers: Costin Badica; Maria Ganzha; Marcin >> Paprzycki Email: badica_costin@software.ucv.ro; >> ganzha@euh-e.edu.pl; marcin.parzycki@swps.edu.pl Web page: >> http://software.ucv.ro/~badica_costin/maseb2007/ >> >> Title: Agent & Data Mining Interaction Organisers: Pericles A. >> Mitkas, Longbing Cao, Vladimir Gorodetsky, Justin Zhan Email: >> mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page: >> http://issel.ee.auth.gr/ADMI >> >> For more information, please visit the conference website at >> http://www.cs.sjsu.edu/wi07/wi/?index=workshop. >> >> ++++++++++ Tutorials ++++++++++ >> >> WI'07 also welcomes Tutorial proposals. WI'07 will include >> tutorials providing in-depth background on subjects that are of >> broad interest to the Web intelligence community. Both short (2 >> hours) and long (half day) tutorials will be considered. The >> tutorials will be part of the main conference technical program. >> Detailed information is available at the conference homepage. >> >> Note: we will not have a separate tutorials registration fee (i.e., >> only one conference registration covers everything). >> >> ++++++++++++++++ Important Dates ++++++++++++++++ >> >> Workshop proposal submission: March 20, 2007 Electronic >> submission of full papers: ** June 1, 2007 ** Tutorial proposal >> submission: June 15, 2007 Notification of paper >> acceptance: July 22, 2007 Camera-ready copies of accepted >> papers: August 17, 2007 Conference: >> November 2-5, 2007 >> >> ++++++++++++++++++++++++ Conference Organization >> ++++++++++++++++++++++++ >> >> Conference Chair: * Andrei Broder, Yahoo! Research, USA >> >> Program Chair: * Tsau Young (T.Y.) Lin, San Jose State >> University/UC Berkeley, USA >> >> WI Program Co-Chairs: * Laura Haas, IBM Almaden Research Center, >> USA * Janusz Kacprzyk, Polish Academy of Science, Poland * Rajeev >> Motwani, Stanford University, USA >> >> IAT Program Co-Chairs: * Jeffrey M. Bradshaw, UWF/Institute for >> Human and Machine Cognition, USA * Matthias Klusch, German Research >> Center for AI, Germany * Chengqi Zhang, University of Technology, >> Sydney, Australia >> >> Organizing Chair: * Howard Ho, IBM Almaden Research Center, USA >> >> Workshop Co-Chairs: * Vijay Raghavan, University of Louisiana, USA >> * Yuefeng Li, Queensland University of Technology, Australia >> >> Tutorial Chair: * Pawan Lingras, Saint Mary's University, Canada >> >> Industry/Demo-Track Chair: * Jianchang Mao, Yahoo! Inc., USA >> >> Local Accommodations Co-Chairs: * David Scot Taylor, San Jose State >> University, USA * Tom Qi Zhang, Google, USA >> >> Publicity Chair: * James Wang, Clemson University, USA (chair) >> Publicity Co-Chairs: * Martine De Cock, Ghent University, Belgium * >> Jia Hu, International WIC Institute, China * Debajyoti >> Mukhopadhyay, West Bengal University of Technology, India >> >> IEEE-CS-TCII Chair: * Ning Zhong, Maebashi Institute of Technology, >> Japan >> >> ACM-SIGART Chair * Maria Gini, University of Minnesota, USA >> >> WIC Co-Chairs/Directors: * Ning Zhong, Maebashi Institute of >> Technology, Japan * Jiming Liu, University of Windsor, Canada >> >> WIC Advisory Board: * Edward A. Feigenbaum, Stanford University, >> USA * Setsuo Ohsuga, Waseda University, Japan * Benjamin Wah, >> University of Illinois, Urbana-Champaign, USA * Philip Yu, IBM >> Thomas J. Watson Research Center, USA * L.A. Zadeh, University of >> California Berkeley, USA >> >> WIC Tech. Committee & WI/IAT Steering Committee: * Jeffrey >> Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Nick >> Cercone, Dalhousie University, Canada * Dieter Fensel, National >> University of Ireland, Ireland * Georg Gottlob, Oxford University, >> UK * Lakhmi Jain, University of South Australia, Australia * >> Jianchang Mao, Yahoo! Inc., USA * Pierre Morizet-Mahoudeaux, >> Compiegne University of Technology, France * Hiroshi Motoda, Osaka >> University, Japan * Toyoaki Nishida, Kyoto University, Japan * >> Andrzej Skowron, Warsaw University, Poland * Jinglong Wu, Kagawa >> University, Japan * Xindong Wu, University of Vermont, USA * Yiyu >> Yao, University of Regina, Canada >> >> Webmaster: * Albert Sutojo, San Jose State University, USA >> >> Abbreviation: WI 2007, WI2007, WI'2007, WI'07, WI07, WI 07, WI-07, >> WI-2007, WI-IAT 2007, WI-IAT2007, WI-IAT'2007, WI-IAT'07, WI-IAT07, >> WI-IAT 07, WI-IAT-2007, WI-IAT-07, WI/IAT 2007, WI/IAT2007, >> WI/IAT'2007, WI/IAT'07, WI/IAT07, WI/IAT 07, WI/IAT-2007, WI/IAT-07 >> >> >> *** Contact Information *** >> >> Jia Hu International WIC Institute, China E-mail: hujia@kis-lab.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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 22 17:12:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfjMD-0006F0-Ck; Sun, 22 Apr 2007 17:12:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfjMC-0006Ev-0p for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 17:12:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfjMB-0006ET-Mn for manet@ietf.org; Sun, 22 Apr 2007 17:12:27 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfjMB-00021Z-Br for manet@ietf.org; Sun, 22 Apr 2007 17:12:27 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1177276346!18185812!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 31527 invoked from network); 22 Apr 2007 21:12:26 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-6.tower-128.messagelabs.com with SMTP; 22 Apr 2007 21:12:26 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l3MLCPH4019162; Sun, 22 Apr 2007 14:12:25 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l3MLCO7r001623; Sun, 22 Apr 2007 16:12:25 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.81]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l3MLCMSj001600; Sun, 22 Apr 2007 16:12:22 -0500 (CDT) Message-ID: <462BCFB5.7070305@gmail.com> Date: Sun, 22 Apr 2007 23:12:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Dymo route discovery References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> <4628CC1F.1060106@gmail.com> <374005f30704220346o7ea375c8k270ee87c51844431@mail.gmail.com> In-Reply-To: <374005f30704220346o7ea375c8k270ee87c51844431@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > Comments inline. > > On 4/20/07, Alexandru Petrescu wrote: >> Ian Chakeres wrote: >>> >>> >>>> >>>> I much prefer if DYMO sends ICMP Destination Unreachable >>>> instead of RERR. >>>> >>>> Because, if one wants DYMO to send RERR instead of ICMP then >>>> one must modify the IP stack code to disallow sending ICMP >>>> Destination Unreachable. And that _only_ when DYMO runs on the >>>> machine. This is too complex IMHO. >>> >>> RERR messages are disseminated in a controlled manner to remove >>> routes that are no longer available/accurate. An generic ICMP >>> Destination Unreachable message would not be capable of >>> performing this operation. >> >> Would a generic ICMP Redirect achieve the same effect you look for? >> (add a route that overcomes an existing route that is no longer >> accurate). > > ICMP redirect would not convey the same information as a RERR, nor > would it be distributed appropriately. We somehow turn and turn. Indeed RERR conveys information more similar to ICMP Dst Unreachable (it contains the address that is unreachable). >>> Can you please talk more as to why you think RERR messaging or >>> processing is too complex? Or how we might improve RERR >>> operation? >> >> I meant it is complex to implement the logic whereby one forbids >> the generation of ICMP Destination Unreachable. Presumably, that's >> what you want to do on a router: if it runs DYMO and sends RERR >> then it must not send ICMP Destination Unreachable, right? > > ICMP Destination Unreachable messages are for the sources of packets, > not the routers in between. Yes. ICMP Redirect is for routers in between. But, do you mean that RERR and ICMP Destination Unreachable can work simultaneously ok? > In the AODV/DYMO implementations I've seen, ICMP Destination > Unreachable messages are issued by the source if it cannot find a > route. Well, I think that is wrong. The Dst Unreachable is usually generated by the last router in the path to the destination that has no route to that destination (and not by the source). The local source host will not generate a Dst Unreachable because it is supposed to have at least a default route. > I believe this is the chosen proceedure to discourage a sources > application from believing that no route is available, since it is > likely that the route is only temporarily broken or unavailable and > will soon be repaired. I think better than that can be achieved by always offering a default route to the host. But here again we assume different models for the networks. You assume that the application is run on the router that does the route discovery as well. I assume the application is run on a host that has no routing capabilities, and always has at least a default route. I will send a separate message about this, later. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 22 17:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfjQT-0008FS-Hh; Sun, 22 Apr 2007 17:16:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfjQR-00085b-Ki for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 17:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfjQR-00084n-B0 for manet@ietf.org; Sun, 22 Apr 2007 17:16:51 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfjQQ-0002co-02 for manet@ietf.org; Sun, 22 Apr 2007 17:16:51 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-128.messagelabs.com!1177276608!18186009!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 696 invoked from network); 22 Apr 2007 21:16:49 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-6.tower-128.messagelabs.com with SMTP; 22 Apr 2007 21:16:49 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l3MLGmhN016055; Sun, 22 Apr 2007 14:16:48 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l3MLGmP8027323; Sun, 22 Apr 2007 16:16:48 -0500 (CDT) Received: from [127.0.0.1] ([10.129.40.81]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3MLGiH9027310; Sun, 22 Apr 2007 16:16:45 -0500 (CDT) Message-ID: <462BD0BC.7040100@gmail.com> Date: Sun, 22 Apr 2007 23:16:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Dymo route discovery References: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> <4628D829.80900@gmail.com> <374005f30704220349q394413c4l9794205d95a1e0b2@mail.gmail.com> In-Reply-To: <374005f30704220349q394413c4l9794205d95a1e0b2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > Comments inline. > > On 4/20/07, Alexandru Petrescu wrote: >> Ian Chakeres wrote: >>> I guess I need to add an additional condition, as it is not clear >>> in the current document. >>> >>> Here is the updated text in Section 5.4. >>> >>> When a node originates a data packet and does not have a >>> forwarding route to the IP.DestinationAddress, it sends a RREQ >>> (described in Seciton 5.3.1) to discover a route to the >>> particular destination (TargetNode). >>> >>> Is that more clear? >> >> YEs to me. >> >> Can it say what it does about the packet to be forwarded until a >> RREP is received? Drop, queue, buffer? And for how long to wait? > > We recommend queue, but there are parameters regarding the queue and > how long to wait. Please see the ID. > >>> I've also updated Section 5.5 to say """ A RERR MUST be issued if >>> a data packet is to be forwarded and it cannot be delivered to >>> the next hop because no forwarding route exists """ >> >> Can you say something about whether ICMP Destination Unreachable is >> issued or not in this case? > > I would recommend that an ICMP destination unreachable not issued, > but I would not require it. Please see my other email on this > subject. I think this sounds like a recommendation on the use of ICMP Destination Unreachable. This recommendation should be discussed in my oppinion. Currently the draft only talks about a local Dst Unreachable delivered to the application. I think what you want is to make sure that no router in a network running DYMO sends a ICMP Dst Unreachable, because its information may be contradicting the information in RERR. I think I understand you correctly. Sorry if I misunderstand you. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 22 23:27:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfpCZ-0008Jk-OE; Sun, 22 Apr 2007 23:26:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfpCX-0008GJ-RH for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 23:26:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfpCX-0008GB-Gg for manet@ietf.org; Sun, 22 Apr 2007 23:26:53 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfpCW-0005FV-A9 for manet@ietf.org; Sun, 22 Apr 2007 23:26:53 -0400 Received: by an-out-0708.google.com with SMTP id d30so1748522and for ; Sun, 22 Apr 2007 20:26:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:subject:reply-to:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding:from; b=fvgp5X+6zVM0xCVkDuEb+y9W6bXfgXQI80QYQtX/dQM1H4kxl3WgxPV1u4i4Ie/AxIEQXVkC8PqBeayrAvng3dqEFnUMlIXwEP3p9FKbG9C3ocmxgrkxEZ6lvKHHMX1yhhVTH6hT6OVHM2JtFWL5+P0OtPwh0tFOoTXNPcmjeaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:reply-to:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding:from; b=hvHgldluQLau427wyk02KI0PldsmscVa3U/am/E5LW1kORNEdN/ri/V0n1nqwZsBDLQBYAnyDbWR28b62ffiyzyHX9vtElkEeU3LXmHdCIgHxSPgkNRpzplNkkcJn/40NSdxA62MqaJ2NdLFkEJlWlnk1wgWEo8UfDu0Z7MSemo= Received: by 10.100.35.17 with SMTP id i17mr3316897ani.1177298811983; Sun, 22 Apr 2007 20:26:51 -0700 (PDT) Received: from ?192.168.0.103? ( [68.48.64.78]) by mx.google.com with ESMTP id c40sm7025227anc.2007.04.22.20.26.50; Sun, 22 Apr 2007 20:26:51 -0700 (PDT) To: manet In-Reply-To: <462BD0BC.7040100@gmail.com> References: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> <4628D829.80900@gmail.com> <374005f30704220349q394413c4l9794205d95a1e0b2@mail.gmail.com> <462BD0BC.7040100@gmail.com> Content-Type: text/plain Date: Sun, 22 Apr 2007 23:26:52 -0400 Message-Id: <1177298812.4671.2.camel@Clunker> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit From: "Thomas M. DuBuisson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [manet] PacketBB Libraries? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thomas.dubuisson.please.no.spam@gmail.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Is there a library for PacketBB out there? Thomas -- "The philosophy behind your actions should never change, on the other hand, the practicality of them is never constant." - Thomas Main DuBuisson _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Apr 22 23:53:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfpc0-0005Eu-Qc; Sun, 22 Apr 2007 23:53:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfpbz-0005E5-CJ for manet-confirm+ok@megatron.ietf.org; Sun, 22 Apr 2007 23:53:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfpbz-0005Dk-2E for manet@ietf.org; Sun, 22 Apr 2007 23:53:11 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfpbx-0003PL-KM for manet@ietf.org; Sun, 22 Apr 2007 23:53:11 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3N3qxwx006261; Mon, 23 Apr 2007 06:53:06 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 06:53:04 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 22:53:02 -0500 Received: from [10.162.89.30] ([10.162.89.30]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 22:53:01 -0500 Message-ID: <462C2D98.1070107@nokia.com> Date: Sun, 22 Apr 2007 20:52:56 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Alexandru Petrescu Subject: Re: [manet] Dymo route discovery References: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> <4628D829.80900@gmail.com> <374005f30704220349q394413c4l9794205d95a1e0b2@mail.gmail.com> <462BD0BC.7040100@gmail.com> In-Reply-To: <462BD0BC.7040100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Apr 2007 03:53:02.0040 (UTC) FILETIME=[E3E5FD80:01C7855A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Alex, I am pretty sure RERR is better, because it can invalidate many broken routes. An ICMP message would pretty much be restricted to invalidating only one. The ICMP message would have to be unicast to the source (and, actually, to the particular application on the source). The RERR message is a hop-by-hop broadcast and can do a lot better. Does this make sense? ext Alexandru Petrescu wrote: >> >> I would recommend that an ICMP destination unreachable not issued, >> but I would not require it. Please see my other email on this >> subject. > > I think this sounds like a recommendation on the use of ICMP Destination > Unreachable. This recommendation should be discussed in my oppinion. > Currently the draft only talks about a local Dst Unreachable delivered > to the application. I think what you want is to make sure that no > router in a network running DYMO sends a ICMP Dst Unreachable, because > its information may be contradicting the information in RERR. I am not sure when the ICMP data would contradict the RERR message data -- except unless the RERR triggered a route repair without disturbing the application. Is that what you meant? Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 00:05:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfpo3-0006yC-Bp; Mon, 23 Apr 2007 00:05:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfpo1-0006xN-1D for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 00:05:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfpo0-0006xF-NY for manet@ietf.org; Mon, 23 Apr 2007 00:05:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfpo0-0006Ee-9r for manet@ietf.org; Mon, 23 Apr 2007 00:05:36 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1101368ugd for ; Sun, 22 Apr 2007 21:05:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BwiZGrUGHV3g0xb2qv6I7XYLQWUx4FnxAIICzDP3GqNatCUwl4Q/ULyHp5eRS955qJVBor2j3h91v/5tu8Cre84ZGrJe2ZmRkXB8TDFWUUlSAVYs0bX5qVdjywJjSttKbHBr1csy43YSdD6WstEgIQcdxpna+dgUwmHZYKlAtbo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ERILTahm3YfkuepN+sPXZW+StwL6s800KIShY5T7Lu/47H9MtEvtNtJ69IuzsafAZnn9wjqptGo1ZKU3e6x1EZeDeWYIkKEZ/4dxv9jWOo2QPbIq7DJgeqUHxpuHDC4B+AlmFVMfGMxdNAHoPQegv1bgfK3w2KoESn0ImlPj+II= Received: by 10.78.175.14 with SMTP id x14mr283453hue.1177301135386; Sun, 22 Apr 2007 21:05:35 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Sun, 22 Apr 2007 21:05:35 -0700 (PDT) Message-ID: <374005f30704222105q7c65f4dch49b4628105958adf@mail.gmail.com> Date: Mon, 23 Apr 2007 09:35:35 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Dymo route discovery In-Reply-To: <462BCFB5.7070305@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> <4628CC1F.1060106@gmail.com> <374005f30704220346o7ea375c8k270ee87c51844431@mail.gmail.com> <462BCFB5.7070305@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 4/23/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > Comments inline. > > > > On 4/20/07, Alexandru Petrescu wrote: > >> Ian Chakeres wrote: > >>> > >>> > >>>> > >>>> I much prefer if DYMO sends ICMP Destination Unreachable > >>>> instead of RERR. > >>>> > >>>> Because, if one wants DYMO to send RERR instead of ICMP then > >>>> one must modify the IP stack code to disallow sending ICMP > >>>> Destination Unreachable. And that _only_ when DYMO runs on the > >>>> machine. This is too complex IMHO. > >>> > >>> RERR messages are disseminated in a controlled manner to remove > >>> routes that are no longer available/accurate. An generic ICMP > >>> Destination Unreachable message would not be capable of > >>> performing this operation. > >> > >> Would a generic ICMP Redirect achieve the same effect you look for? > >> (add a route that overcomes an existing route that is no longer > >> accurate). > > > > ICMP redirect would not convey the same information as a RERR, nor > > would it be distributed appropriately. > > We somehow turn and turn. > > Indeed RERR conveys information more similar to ICMP Dst Unreachable (it > contains the address that is unreachable). Here is a short list of some of RERRs features. The RERR is disseminated in a limited flood. RERR may contain the addresses of many now unreachable devices. RERR can be generated on-demand, instead of waiting for data traffic to flow. RERR contain the sequence number related to the addresses for which a route is not available. > >>> Can you please talk more as to why you think RERR messaging or > >>> processing is too complex? Or how we might improve RERR > >>> operation? > >> > >> I meant it is complex to implement the logic whereby one forbids > >> the generation of ICMP Destination Unreachable. Presumably, that's > >> what you want to do on a router: if it runs DYMO and sends RERR > >> then it must not send ICMP Destination Unreachable, right? > > > > ICMP Destination Unreachable messages are for the sources of packets, > > not the routers in between. > > Yes. ICMP Redirect is for routers in between. > > But, do you mean that RERR and ICMP Destination Unreachable can work > simultaneously ok? I don't see any reason why they couldn't work together, but as I mention I wouldn't suggest it. > > In the AODV/DYMO implementations I've seen, ICMP Destination > > Unreachable messages are issued by the source if it cannot find a > > route. > > Well, I think that is wrong. The Dst Unreachable is usually generated > by the last router in the path to the destination that has no route to > that destination (and not by the source). The local source host will > not generate a Dst Unreachable because it is supposed to have at least a > default route. The question here is about "having no route". In reactive protocols, just be cause you don't have a route at this moment, does not mean you can't find a route. > > I believe this is the chosen proceedure to discourage a sources > > application from believing that no route is available, since it is > > likely that the route is only temporarily broken or unavailable and > > will soon be repaired. > > I think better than that can be achieved by always offering a default > route to the host. > > But here again we assume different models for the networks. You assume > that the application is run on the router that does the route discovery > as well. I assume the application is run on a host that has no routing > capabilities, and always has at least a default route. I will send a > separate message about this, later. We do not assume that the application is run on the router. A MANET router can/will perform route discovery on behalf of its attached hosts. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 03:14:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfskw-0004a9-V0; Mon, 23 Apr 2007 03:14:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfskv-0004a4-EZ for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 03:14:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfsks-0004Zi-CO for manet@ietf.org; Mon, 23 Apr 2007 03:14:34 -0400 Received: from reserv5.univ-lille1.fr ([193.49.225.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfskq-0007Ts-TI for manet@ietf.org; Mon, 23 Apr 2007 03:14:34 -0400 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by reserv5.univ-lille1.fr (8.14.0/8.14.0) with ESMTP id l3N7ENh8020656 for ; Mon, 23 Apr 2007 09:14:23 +0200 Received: from [127.0.0.1] (romy.lifl.fr [134.206.11.216]) by malonne.lifl.fr with ESMTP id l3N7EN721832 for ; Mon, 23 Apr 2007 09:14:23 +0200 (MEST) Message-ID: <462C5CEB.5090404@inria.fr> Date: Mon, 23 Apr 2007 09:14:51 +0200 From: Nathalie MITTON User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.7.13) Gecko/20060414 X-Accept-Language: fr, en MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (reserv5.univ-lille1.fr [193.49.225.19]); Mon, 23 Apr 2007 09:14:23 +0200 (CEST) X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: nathalie.mitton@inria.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [manet] CALL FOR PAPERS - ACM SANET 2007 - Deadline : 14 May X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org ====================================================================== CALL FOR PAPERS SANET 2007 First ACM Workshop on Sensor Actor Networks http://www.lifl.fr/POPS/SANET2007 Montreal, Canada, Sept. 10, 2007 Organized and run in conjunction with ACM MobiCom 2007 http://www.sigmobile.org/mobicom/2007/ ====================================================================== Purpose The advent of nano-technology and advances in communications has made it technologically feasible and economically viable to develop low-power devices that integrate general-purpose computing with multi-purpose sensing and wireless communications capabilities. It is expected that sensor networks will have a significant impact on a wide array of applications ranging from military, to scientific, to industrial, to health-care, to domestic, to environmental, establishing ubiquitous wireless sensor networks that will pervade society redefining the way in which we live and work. Recently, in an attempt to integrate sensor networks in the fabric of human activities it has been recognized that it would be beneficial to augment sensor networks by either actuators or actors. Actuators are simple devices programmed to take immediate, one-shot, action in response to sensory input. Actors are more sophisticated entities that, in addition to actuating can provide a meaningful, long-term, interaction with the environment. This long-term interaction presupposes intelligent coordination with both the sensory data but also with anticipated changes in the environment. The resulting augmented version of sensor networks is commonly referred to as Sensor Actor Networks (SANET). SANET 2007 has for stated goal to be a high-profile workshop that brings together state-of-the-art contributions on the design, specification, and implementation of architectures and protocols for current and future applications of SANETs. Topics of Interest Topics of interest include, but are not limited to: * Autonomous sensor networks * Emergent behavior in SANET * Modeling and simulation of SANET * Autonomic and self-organizing coordination and communication * Sensor-actor and actor-actor coordination * Energy-efficient and real-time communication protocols * Distributed control in sensor-actor networks * Communication protocols for swarms of mobile actors * Biologically inspired communication * Ecological systems * Architectures and topology control * Localization in SANET * Probabilistic integration in SANET * SANET control and management * SANET security and robustness * SANET architectural and operational models * Applications and prototypes Paper Submission Submit a full paper of about 8 pages (ACM single-space, double-column format), including figures and references, using 10 font size, and number each page. Accepted papers will be published by published by ACM Press and distributed at the workshop; copies of the Proceedings will also be available for sale from ACM after the workshop. Papers must be submitted electronically through the EDAS system Important Dates Manuscript Submission: May 14, 2007, 11:59 GMT Acceptance Notification: June 18, 2007 Final Manuscript Due: July 13, 2007 Program Co-Chairs Silvia Giordano, SUPSI, Swittzerland Stephan Olariu, Old Dominion University, USA David Simplot-Ryl, University of Lille, INRIA, France Program Committee see web site. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 03:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfslz-0005Y7-0d; Mon, 23 Apr 2007 03:15:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfslx-0005Xx-4R for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 03:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfslw-0005Xp-Qy for manet@ietf.org; Mon, 23 Apr 2007 03:15:40 -0400 Received: from web27605.mail.ukl.yahoo.com ([217.146.177.224]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfslv-0007vP-ER for manet@ietf.org; Mon, 23 Apr 2007 03:15:40 -0400 Received: (qmail 1712 invoked by uid 60001); 23 Apr 2007 07:15:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=N5X2fGuFtB2lVFLxyje5w99qttJDTTSx1HsUOweGtpRZNjFH7gERHZDjo7vSwH9O2/8nZ2KTcVLW4S1gh5koQDEISB0bKVAxdVatBQjSICWRdtqzJdJv1Pt+CRwh1tmjyZmBs20HHS2wNt4bTztuqlOJgIi4V737vVEwgcJN8Oo= ; Message-ID: <20070423071538.1710.qmail@web27605.mail.ukl.yahoo.com> X-YMail-OSG: lnQOFigVM1mG08lmqdy87Bsa1BBe2TJLPqWFZ0M8sasX3dov4LVqp6HI2qBvLc6BBiNXD8K8gNbk2RcFu_fqKIsT5SlqbAh4fIms1fH3tSYdT0HNmNwWkflg7is- Received: from [193.95.37.75] by web27605.mail.ukl.yahoo.com via HTTP; Mon, 23 Apr 2007 09:15:38 CEST Date: Mon, 23 Apr 2007 09:15:38 +0200 (CEST) From: nadia mansouri To: manet In-Reply-To: <767468.16563.qm@web53109.mail.re2.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [manet] mesure the load of the network X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2074621987==" Errors-To: manet-bounces@ietf.org --===============2074621987== Content-Type: multipart/alternative; boundary="0-328387786-1177312538=:1706" Content-Transfer-Encoding: 8bit --0-328387786-1177312538=:1706 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, how can I mesure the load of the network to improve the load balancing with multipath routing protocol such AOMDV. --------------------------------- Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-328387786-1177312538=:1706 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi,
how can I mesure the  load of the network to improve the load balancing with multipath routing protocol such AOMDV.

Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses. --0-328387786-1177312538=:1706-- --===============2074621987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============2074621987==-- From manet-bounces@ietf.org Mon Apr 23 03:20:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfsqr-0002OT-RG; Mon, 23 Apr 2007 03:20:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfsqq-0002OC-6f for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 03:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfsqp-0002O1-T7 for manet@ietf.org; Mon, 23 Apr 2007 03:20:43 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfsqo-0008ND-74 for manet@ietf.org; Mon, 23 Apr 2007 03:20:43 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1310160nzd for ; Mon, 23 Apr 2007 00:20:41 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=jJ1FyZmBjxb8IdbOf/dhDbV3uvuGVffgPAojnOvX9n4hP9vhDGTfqANyN1ZXMHgypZJN0WQ4/B+lXcnTx73bGhFKq45nDpSxgisTYOMILpSizJsUmAjK9BZ3G5wyPG/v/OKBuXheyb3sHNzXfymxHa57bNHAE9xI/3jMvF2paGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Y8PVTS4yaM4ZtgQz5MIzmMsnifk1x/uiztwjrVDzigCsrW8ozXnAkY1FHcp0WVfUChBYxPWKNAEIa3Oud4Pa1DJtU5mkWvjjdHaVNh/hbI6XI0sj7+A8CVnN3Kxth6xEiJtl/vQrRCTM2mKfRKtv9Hg/pKK1lbbilvGOgpWheYs= Received: by 10.114.27.20 with SMTP id a20mr2366134waa.1177312841447; Mon, 23 Apr 2007 00:20:41 -0700 (PDT) Received: by 10.114.95.3 with HTTP; Mon, 23 Apr 2007 00:20:41 -0700 (PDT) Message-ID: <6ae06b9f0704230020h6b2feffm19581eae0e6af1fd@mail.gmail.com> Date: Mon, 23 Apr 2007 12:50:41 +0530 From: "Narendran Sivakumar" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [manet] Re : Energy Efficiency in Routing Protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0074901071==" Errors-To: manet-bounces@ietf.org --===============0074901071== Content-Type: multipart/alternative; boundary="----=_Part_50634_26130064.1177312841387" ------=_Part_50634_26130064.1177312841387 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear All , I've implemented DYMO and comparing the performance of DYMO with other protocols. Is there a way to analyze how energy efficient these protocols especially DYMO as i consider energy efficiency a big factor. Any suggestions and ideas relating to this subject are most welcome. Thank You Naren ------=_Part_50634_26130064.1177312841387 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
 Dear All ,
 
I've implemented DYMO and comparing the performance of DYMO with other protocols. Is there a way to analyze how energy efficient these protocols especially DYMO as i consider energy efficiency a big factor.
 
Any suggestions and ideas relating to this subject are most welcome.
 
Thank You
 
Naren
------=_Part_50634_26130064.1177312841387-- --===============0074901071== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0074901071==-- From manet-bounces@ietf.org Mon Apr 23 03:42:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftBb-0002wU-V6; Mon, 23 Apr 2007 03:42:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HftBZ-0002w4-Hz for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 03:42:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftBZ-0002vw-7e for manet@ietf.org; Mon, 23 Apr 2007 03:42:09 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HftBX-0003jW-EI for manet@ietf.org; Mon, 23 Apr 2007 03:42:09 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2AF8E1805F for ; Mon, 23 Apr 2007 13:12:05 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 17B0618051 for ; Mon, 23 Apr 2007 13:12:05 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Apr 2007 13:12:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] MANET Port Name Date: Mon, 23 Apr 2007 13:12:04 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] MANET Port Name Thread-Index: AceENe+MkHp2Bzk/TRWYFRvkFSU11wBRg6gA From: To: , X-OriginalArrivalTime: 23 Apr 2007 07:42:04.0883 (UTC) FILETIME=[E3456A30:01C7857A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I too feel the same. I would prefer PacketBB to MANET. Regards, Ratul Mukhopadhyay =20 -----Original Message----- From: Roger [mailto:rogerwh@gmail.com]=20 Sent: Saturday, April 21, 2007 10:23 PM To: manet Subject: Re: [manet] MANET Port Name There are, and will continue to be, other MANET protocols outside the standards, so we should at least specify that we are talking about standard MANET protocols. As you have said, the experimental RFCs will remain experimental for now. What we should be asking is whether all future MANET standards can be expected to use PacketBB. Given the recent discussions on this list, I do not believe that we can safely say that 10-20 years out. On 4/20/07, Ian Chakeres wrote: >All the MANET protocols that generate control messages (NHDP, DYMO, >OLSRv2) use PacketBB (Packet Building Block) for their packets & >messages. > >Ian > >On 4/20/07, Alexandru Petrescu wrote: >> Ian Chakeres wrote: >> > I'd like to ask people whether they would like the port in the IANA >> > document named "MANET" or "PacketBB". >> > >> > If you have a preference, please reply. >> >> Yes, I have some thoughts on this, thanks for asking. >> >> _If_ PacketBB is something used by most (all?) MANET protocols, then >> indeed the port should be named PacketBB. >> >> _If_ PacketBB is something that works only over UDP and/or TCP then >> again I prefer PacketBB for port name. >> >> If some existing MANET protocols have already ports assigned then a new >> one can't be so called MANET. >> >> But let me say something else. _If_ (only a big _if_) this WG defined >> only one protocol that they called "GRABNET" for example then it could >> have been easier to just have one port called "GRABNET" instead of >> PacketBB which seems to be only a TLV, not a protocol per se. >> >> Because, for example DYMO doesn't necessarily run at network layer (it >> may run at link-layer) so at that point DYMO using PacketBB and PacketBB >> port number wouldn't make much sense; it should have been "DYMO port >> number". >> >> Alex --=20 Roger _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 03:59:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftS7-0007Hp-UW; Mon, 23 Apr 2007 03:59:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HftS6-0007Hg-HL for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 03:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftS6-0007HY-57 for manet@ietf.org; Mon, 23 Apr 2007 03:59:14 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HftS4-0006Zn-Ns for manet@ietf.org; Mon, 23 Apr 2007 03:59:14 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3N7xB6b019837 for ; Mon, 23 Apr 2007 08:59:11 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3N7xBIR021991 for ; Mon, 23 Apr 2007 08:59:11 +0100 Received: from glkms0002.GREENLNK.NET ([10.15.184.2]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 23 Apr 2007 08:59:10 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0002.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Apr 2007 08:59:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] PacketBB Libraries? Date: Mon, 23 Apr 2007 08:59:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] PacketBB Libraries? Thread-Index: AceFV0JRLUiG/HgBTLqmh6Q/Wjs9yQAJdBHg From: "Dearlove, Christopher \(UK\)" To: "manet" X-OriginalArrivalTime: 23 Apr 2007 07:59:10.0591 (UTC) FILETIME=[46A408F0:01C7857D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I'm not aware of one in the public domain yet. (Mine, for example, is not.) -----Original Message----- From: Thomas M. DuBuisson [mailto:thomas.dubuisson@gmail.com]=20 Sent: 23 April 2007 04:27 To: manet Subject: [manet] PacketBB Libraries? *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Is there a library for PacketBB out there? Thomas --=20 "The philosophy behind your actions should never change, on the other hand, the practicality of them is never constant." - Thomas Main DuBuisson _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 04:00:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftTA-00080u-54; Mon, 23 Apr 2007 04:00:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HftT8-0007w6-0m for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 04:00:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftT7-0007vx-Mz for manet@ietf.org; Mon, 23 Apr 2007 04:00:17 -0400 Received: from reserv6.univ-lille1.fr ([193.49.225.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HftT6-0006fj-9p for manet@ietf.org; Mon, 23 Apr 2007 04:00:17 -0400 Received: from malonne.lifl.fr (malonne.lifl.fr [134.206.10.29]) by reserv6.univ-lille1.fr (8.14.0/8.14.0) with ESMTP id l3N805sO011169; Mon, 23 Apr 2007 10:00:07 +0200 Received: from [127.0.0.1] (romy.lifl.fr [134.206.11.216]) by malonne.lifl.fr with ESMTP id l3N803722831 ; Mon, 23 Apr 2007 10:00:03 +0200 (MEST) Message-ID: <462C67A0.2080508@inria.fr> Date: Mon, 23 Apr 2007 10:00:32 +0200 From: Nathalie MITTON User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.7.13) Gecko/20060414 X-Accept-Language: fr, en MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (reserv6.univ-lille1.fr [193.49.225.20]); Mon, 23 Apr 2007 10:00:07 +0200 (CEST) X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: nathalie.mitton@inria.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [manet] [MASS 2007] Call for Workshops' Papers X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- ***** CALL FOR WORKSHOPS PAPERS **** IEEE MASS 2007 WORKSHOPS http://cnd.iit.cnr.it/mass2007/workshops.html Pisa, October 8 & 12, 2007 Sponsored by IEEE, IEEE Computer Society, IEEE Technical Committee on Distributed Processing, and IEEE Technical Committee on Simulation in-cooperation with ACM SIGMOBILE ---------------------------------------------------------------------- The Fourth IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2007) will host 10 workshops on technical subjects related to mobile and wireless ad hoc networking and its applications (see the list below). For more information about the workshops and the paper submission procedures, see http://cnd.iit.cnr.it/mass2007/workshops.html ********* MASS 2007 Workshops *********** ----------------------- Monday, October 8, 2007 ----------------------- PARIS: 1st International Workshop on Protocols and Algorithms for Reliable and Data Intensive Sensor Networks Papers due: April 30, 2007 WSNS: 3rd IEEE International Workshop on Wireless and Sensor Networks Security Papers due: April 30, 2007 MeshTech: 1st IEEE International Workshop on Enabling Technologies and Standards for Wireless Mesh Networking Papers due: May 15, 2007 MHWMN 2007: 3rd IEEE International Workshop on Heterogeneous Multi-Hop Wireless and Mobile Networks Papers due: May 15, 2007 BIONETWORKS 2007: A Workshop on Socially and Biologically Inspired Wired and Wireless Networks Papers due: April 30, 2007 MPPS: 1st International Workshop on Multilateral/Multiuser Privacy in Pervasive Systems Papers due: May 15, 2007 ------------------------ Friday, October 12, 2007 ------------------------ MASS-GHS: 1st International Workshop on Mobile Ad hoc and Sensor Systems for Global and Homeland Security Papers due: May 15, 2007 SensorFusion'07: Second International Workshop on Information Fusion and Dissemination in Wireless Sensor Networks Papers due: May 15, 2007 LOCAN 2007: The Third International Workshop on Localized Communication and Topology Protocols for Ad hoc Networks Papers due: April 30, 2007 MoVeNet 2007: The First International Workshop on Mobile Vehicular Networks Papers due: May 7, 2007 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 04:07:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftZd-00078T-1x; Mon, 23 Apr 2007 04:07:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HftZb-00073X-TQ for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 04:06:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HftZb-000720-Hb for manet@ietf.org; Mon, 23 Apr 2007 04:06:59 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HftZY-0008Ls-1s for manet@ietf.org; Mon, 23 Apr 2007 04:06:59 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3N86tWj025485 for ; Mon, 23 Apr 2007 09:06:55 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3N86sdP028401 for ; Mon, 23 Apr 2007 09:06:54 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 23 Apr 2007 09:06:54 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Apr 2007 09:06:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Date: Mon, 23 Apr 2007 09:06:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Thread-Index: AceE569RpTLCeYn6QQ+gW0W8lFwUIwAAgfpgACT26OA= From: "Dearlove, Christopher \(UK\)" To: "Bound, Jim" , "manet" X-OriginalArrivalTime: 23 Apr 2007 08:06:54.0321 (UTC) FILETIME=[5B0B9E10:01C7857E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Unfortunately the majority of traffic on this list is either this sort of thing, or various student requests for help with protocols and simulators, that are both off-topic. In fact the current number of on-topic postings is what's exceptional (though welcome of course). The only way (short of closing down the WG) that I could see to stop it would be labour intensive (monitoring list, removing postings, and blacklisting posters) and I for one am not going to volunteer for. -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com]=20 Sent: 22 April 2007 15:24 To: wiiat@kis-lab.com; manet Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley,USA) Deadline: June 1 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Folks, is it appropriate to post call for paper on an IETF WG list. I don't think so this is a working group. thanks /jim=20 > -----Original Message----- > From: Jia Hu [mailto:wiiat@kis-lab.com]=20 > Sent: Sunday, April 22, 2007 10:08 AM > To: manet > Subject: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon=20 > Valley,USA) Deadline: June 1 >=20 > [Apologies if you receive this more than once] >=20 > ##################################################################### > IEEE/WIC/ACM WEB INTELLIGENCE 2007 > CALL FOR PAPERS > ##################################################################### >=20 > 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07) >=20 > Silicon Valley, USA, November 2-5, 2007 > Official: http://www.cs.sjsu.edu/wi07/wi/ > Mirror: http://www.maebashi-it.org/wi07/wi/ > (to be collocated with IAT'07, BIBM'07 and GrC'07) >=20 > Sponsored By > IEEE Computer Society > Web Intelligence Consortium (WIC) > Association for Computing Machinery (ACM) >=20 > ###################################################################### > # Conference Chair > # Andrei Broder, VP, Yahoo Fellow, Yahoo! Research > # > # Program Chair and Co-Chairs=09 > # T.Y. Lin, Professor, SJSU, BISC Fellow, UC-Berkeley > # Laura Haas, Director, IBM Almaden Research Center > # Janusz Kacprzyk, Professor, Polish Academy of Science > # Rajeev Motwani, Professor, Stanford University > # > # Organizing Chair=09 > # Howard Ho, Manager, IBM Almaden Research Center=20 > # > # WI-IAT Joint Keynote Speakers (Tentative) # # Vinton G.=20 > Cerf, Turing Award Winner,=20 > # VP and Chief Internet Evangelist, Google=20 > # Anant Jhingran, VP and CTO, IBM Silicon Valley Laboratory #=20 > # (More WI Invited Speakers will be announced) # # (Papers=20 > Due: ** June 1 **, 2007) # Accepted papers will be published=20 > in the conference proceedings # by the IEEE Computer Society=20 > Press, which are indexed by EI. > ###################################################################### >=20 > Web Intelligence (WI) has been recognized as a new direction=20 > for scientific research and development to explore the=20 > fundamental roles as well as practical impacts of Artificial=20 > Intelligence (AI) (e.g., knowledge representation, planning,=20 > knowledge discovery and data mining, intelligent agents, and=20 > social network intelligence) and advanced Information=20 > Technology (IT) (e.g., wireless networks, ubiquitous devices,=20 > social networks, and data/knowledge grids) on the next=20 > generation of Web-empowered products, systems, services, and=20 > activities. It is one of the most important as well as=20 > promising IT research fields in the era of Web and agent intelligence. >=20 > The 2007 IEEE/WIC/ACM International Conference on Web Intelligence > (WI'07) will be jointly held with the 2007 IEEE/WIC/ACM=20 > International Conference on Intelligent Agent Technology=20 > (IAT'07), the 2007 IEEE International Conference on=20 > Bioinformatics and Biomedicine (BIBM'07), and the 2007 IEEE=20 > International Conference on Granular Computing > (GrC'07) for providing synergism among the four research=20 > areas. It will provide opportunities for technical=20 > collaboration beyond that of previous conferences. The four=20 > conferences will have a joint opening, keynote, reception,=20 > and banquet. Attendees only need to register for one=20 > conference and can attend workshops, sessions and tutorials=20 > across the four conferences. We are also planning a joint=20 > panel and joint paper sessions that discuss common problems=20 > in the four areas. >=20 > +++++++++++ > Highlights > +++++++++++ >=20 > The conference will be held in Silicon Valley, California.=20 > Many high-tech companies and three distinguished universities=20 > (Stanford, UC Berkely and UCSC) are just around the corner.=20 > The highlight of the conference is that a unique forum=20 > consisting of a half-day industry/ demo track and free=20 > discussion will be organized to link industries and=20 > academics. Leading IT companies like IBM, Google, and Yahoo=20 > etc will present at the conference. >=20 > The area now known as Silicon Valley has been a center of=20 > technological development since the 1950's. The name Silicon=20 > Valley stems from the early 1970's, when the area had become=20 > the center for many semiconductor companies. While still=20 > hosting semiconductor and microprocessor companies, the=20 > region now hosts the headquarters of high tech companies of=20 > every kind, including many of the best known and most=20 > prestigious names in personal computers, Web search, Internet=20 > auctions, networking, storage, databases, etc. >=20 > +++++++++++++++++++ > Topics of Interest > +++++++++++++++++++ >=20 > The topics and areas include, but not limited to: >=20 > * WI Foundations > - Brain Informatics for WI > - Human level WI > - New cognitive models and computational models for WI > - Granular Computing (GrC) for WI > - Autonomy-Oriented Computing (AOC) for WI >=20 > * World Wide Wisdom Web (W4) > - Meta-Knowledge Discovery and Representation > - Problem Solver Markup Language (PSML) > - Search of Best Means and Ends > - Goal-Directed Services Support > - Distributed Resources Optimization > - Service Self-Aggregation > - Web Inference Engine > - Information and Knowledge Markets > - New Social Interaction Paradigms > - Social and Psychological Contexts > - Regularities and Laws of W4 >=20 > * Social Networks and Social Intelligence > - Social Network Mining > - Web Site Clustering > - Link Topology and Site Hierarchy > - Theories of Small-World Web > - Virtual and Web Communities > - Web-Based Cooperative Work > - Knowledge Community Formation and Support > - Ubiquitous Computing > - Intelligent Wireless Web > - Ubiquitous Learning Systems > - Entertainment >=20 > * Knowledge Grids and Grid Intelligence > - Semantic Grids > - Knowledge Resources and Services Discovery > - On-Demand Planning and Routing > - Brokering and Scheduling > - Middleware Architectures and Tools >=20 > * Web Mining and Farming > - Text Mining > - Data Stream Mining > - Multimedia Data Mining > - Web Content Mining > - Web Log and Usage Mining > - Learning User Profiles > - Context Sensitive Web Mining > - Web Information Clustering > - Web Page Clustering and Mining > - E-Mail Classification > - Web Site Classification > - Web Information Indexing > - Data Warehousing > - Web Farming and Warehousing >=20 > * Semantics and Ontology Engineering > - Ontology-Based Information Extraction and Retrieval > - Ontology-Based Web Mining > - Web-Based Ontology Learning > - Semantic Web >=20 > * Web Agents > - Global Information Foraging > - Distributed Problem Solving > - Coordination > - Resource Intermediary and Coordination Mechanisms > - Self-Organization and Reproduction > - Agent Networks and Topologies > - Mobile Agents > - Macroscopic Behavior Modeling > - Trust Models for Web Agents >=20 > * Web Services > - Service-Oriented Computing > - Matchmaking > - Web Service Reconfiguration > - Web Service Workflow Composition > - Middleware-Based Ubiquitous Services > - Grid Services >=20 > * Web Information Filtering and Retrieval > - Automatic Cataloging and Indexing > - Clustering-Based Recommender Systems > - Collaborative Filtering and Recommendation > - Hybrid Recommendation > - Information Retrieval Criteria and Evaluations > - Web Information Categorization and Ranking > - Proxy and Cache Techniques > - Web Prediction and Prefetching > - Distributed Web Search > - Specifications for Web Information Extraction Process > - Web Crawling Systems > - Search Engines and Meta-search Engines >=20 > * Intelligent Human-Web Interaction > - Adaptive Web Interfaces > - Context-Aware Computing > - Learning User Profiles > - Personalized Interfaces > - Personalized Web Sites > - Remembrance Agents > - Multimedia Representation > - Visualization of Information and Knowledge > - Social and Psychological Issues >=20 > * Web Support Systems > - Information Retrieval Support Systems > - Web Site Navigation Support Systems > - Recommender Support Systems > - Web-Based Decision Support Systems > - Soft Computing (including neural networks, fuzzy logic, > evolutionary computation, rough sets, and granular computing) > and Uncertainty Management for WI >=20 > * Intelligent e-Technology > - Business Intelligence > - Digital Library > - Decentralized Community Communication Techniques > - e-Community > - e-Business and e-Commerce > - e-Finance > - e-Government > - e-Learning > - e-Publishing > - e-Science > - Intelligent Enterprise Portals > - Web-Based Direct Marketing and CRM > - Web-Based EDI > - Web Security, Integrity, Privacy and Trust >=20 > ++++++++++++++++++++++++++++++++++++ > On-Line Submissions and Publication > ++++++++++++++++++++++++++++++++++++ >=20 > High-quality papers in all WI related areas are solicited.=20 > Paper submissions should be limited to a maximum of 7 pages=20 > in the IEEE 2-column format, the same as the camera-ready=20 > format (see the Author Guidelines of last year at=20 > http://www.computer.org/portal/pages/cscps/cps/final/wi06.xml). =20 > All submitted papers will be reviewed by the Program=20 > Committee on the basis of technical quality, relevance,=20 > significance, and clarity.=20 >=20 > Note that WI'07 will accept ONLY on-line submissions,=20 > containing PDF versions. Please use the Submission Form on=20 > the WI'07 website to submit your paper. Accepted papers will=20 > be published in the conference proceedings by the IEEE=20 > Computer Society Press that are indexed by EI. >=20 > Submissions accepted as regular papers will be allocated 7=20 > pages in the proceedings and accorded oral presentation times=20 > in the main conference.=20 > Submissions accepted as short papers will be allocated 4=20 > pages in the proceedings and will have a shorter presentation=20 > time at the conference than regular papers. >=20 > All co-authors will be notified at all time, for the=20 > submission, notification, and confirmation on the attendance.=20 > Submitting a paper to the conference and workshops means=20 > that, if the paper is accepted, at least one author should=20 > attend the conference to present the paper. The acceptance=20 > list and no-show list will be openly published on-line. For=20 > no-show authors, their affiliations will receive a notification.=20 >=20 > A selected number of WI'07 accepted papers will be expanded=20 > and revised for inclusion in Web Intelligence and Agent=20 > Systems: An International Journal=20 > (http://wi-consortium.org/journal.html) and in Annual Review=20 > of Intelligent Informatics (http://www.wi-consortium.org/annual.html). >=20 > More detailed instructions and the On-Line Submission Form=20 > can be found from the WI'07 homepage: http://www.cs.sjsu.edu/wi07/wi/. >=20 > ++++++++++++++++++++++++ > WI'07 Best Paper Awards=20 > ++++++++++++++++++++++++ >=20 > The best paper awards will be conferred at the conference on=20 > the authors of (1) the best research paper and (2) the best=20 > application paper. Application-oriented submissions will be=20 > considered for the best application paper award.=20 >=20 > The full author list and paper title will be announced on the=20 > Web Intelligence Consortium homepage: > http://wi-consortium.org/html/wicawards.html >=20 > ++++++++++++++++++++ > Industry/Demo-Track > ++++++++++++++++++++ >=20 > We solicit Industry/Demo-Track papers by the following methods. >=20 > (1) Industry papers of 4 pages can be submitted on the same=20 > schedule as > the research track. > (2) Separate 2 page demo proposals can submitted at a later schedule. > (3) Full regular paper submissions can include a demo option. > That is, a full paper submissions will be asked to > specify if they would like to give a demonstration; choice of > demonstrations (while utilizing information from the=20 > regular reviewing > process) will be selected based on value as a demonstration. >=20 > For options (1) and (2), please find more detailed=20 > instructions at the homepage: http://www.cs.sjsu.edu/wi07/wi/ >=20 > We are planning to arrange the Industry/Demo track in the=20 > afternoon of November 3 (before and during the conference=20 > reception), jointly with the IAT'07 Demo sessions. Leading IT=20 > companies in Silicon Valley will be invited to attend this track. >=20 > ++++++++++ > Workshops > ++++++++++ >=20 > As an important part of the conference, the workshop program=20 > will focus on new research challenges and initiatives. All=20 > papers accepted for workshops will be included in the=20 > Workshop Proceedings published by the IEEE Computer Society=20 > Press that are indexed by EI, and will be available at the=20 > workshops. Detailed information is available at the=20 > conference homepage. >=20 > Note: we will not have a separate workshop registration fee=20 > (i.e., conference registration covers everything). >=20 > ------------------ > WI 2007 Workshops: > ------------------ > Title: Educating the Web-Generation > Organisers: Elisabeth Heinemann > Email: elisabeth.heinemann@googlemail.com > Web page: http://www.effactory.com/Edu4WebGen/ >=20 > Title: Collective Intelligence on Semantic Web > Organisers: Geun Sik Jo; Jason J. Jung; Ngoc Thanh Nguyen > Email: gsjo@inha.ac.kr; j2jung@intelligent.pe.kr;=20 > thanh@pwr.wroc.pl Web page: > http://intelligent.pe.kr/CISW07/ >=20 > Title: New Computing Paradigms for Web Intelligence and Brain=20 > Informatics > Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter Fensel > Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: >=20 > Title: Web Personalization and Recommender Systems > Organisers: Yue Xu > Email: yue.xu@qut.edu.au > Web page: http://www.wprs07.fit.qut.edu.au/ >=20 > Title: Service Composition > Organisers: M. Brian Blake; Dumitru Roman; Charles Petrie > Email: blakeb@cs.georgetown.edu; dumitru.roman@deri.org Web=20 > site: http://events.deri.at/sercomp2007/ >=20 > Title: Biomedicine applications of Web technologies > Organisers: Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu > Email: chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw;=20 > whlu@mail.ncku.edu.tw Web page:=20 > http://chunnan.iis.sinica.edu.tw/BMWT2007.html >=20 > Title: Intelligent Web Interaction Workshop 2007 1st=20 > Organiser: Prof. Seiji YAMADA > Email: seiji@nii.ac.jp > Web site: http://ymd.ex.nii.ac.jp/ws/iwi/07/ >=20 > Title: Cyberinfrastucture for e-Science > Organisers: Prof. Vasant Honavar; A/prof. Kei Cheung > Email: honavar@cs.iastate.edu; kei.cheung@yale.edu Web page:=20 > http://www.cild.iastate.edu/events/CyIneS2007/ >=20 > Title: 2007 International Workshop on Social Media Analysis > Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu > Email: sma@comp.hkbu.edu.hk > Web page: http://www.comp.hkbu.edu.hk/~sma/ >=20 > Title: Web Security, Integrity, Privacy and Trust > Organisers: Dr. Yiuming Cheung, Prof. Michael Chau, and Prof.=20 > Yong Zhang > Email: ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk;=20 > zhangyong076@gmail.com Web page: >=20 > ------------------- > IAT 2007 Workshops: > ------------------- > Title: Second International Workshop on Communication between=20 > Human and Artificial Agents (CHAA-07) > Organisers: Christel Kemke > Email: ckemke@cs.umanitoba.ca > Web page: http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ >=20 > Title: Rational, Robust, and Secure Negotiations in=20 > Multi-Agent Systems (RRS2007) > Organisers: Takayuki Ito > Email: ito.takayuki@nitech.ac.jp > Web page: http://www-itolab.mta.nitech.ac.jp/RRS2007/ >=20 > Title: P2P Computing and Autonomous Agents > Organisers: Tarek Helmy, Khaled Ragab > Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa Web Page:=20 > http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html >=20 > Title: Multiagent systems in E-business: concepts,=20 > technologies and applications > Organisers: Costin Badica; Maria Ganzha; Marcin Paprzycki > Email: badica_costin@software.ucv.ro; ganzha@euh-e.edu.pl;=20 > marcin.parzycki@swps.edu.pl Web page:=20 > http://software.ucv.ro/~badica_costin/maseb2007/ >=20 > Title: Agent & Data Mining Interaction > Organisers: Pericles A. Mitkas, Longbing Cao, Vladimir=20 > Gorodetsky, Justin Zhan > Email: mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page:=20 > http://issel.ee.auth.gr/ADMI=20 >=20 > For more information, please visit the conference website at=20 > http://www.cs.sjsu.edu/wi07/wi/?index=3Dworkshop. >=20 > ++++++++++ > Tutorials > ++++++++++ >=20 > WI'07 also welcomes Tutorial proposals. WI'07 will include=20 > tutorials providing in-depth background on subjects that are=20 > of broad interest to the Web intelligence community. Both=20 > short (2 hours) and long (half > day) tutorials will be considered. The tutorials will be part=20 > of the main conference technical program. Detailed=20 > information is available at the conference homepage. >=20 > Note: we will not have a separate tutorials registration fee=20 > (i.e., only one conference registration covers everything). >=20 > ++++++++++++++++ > Important Dates > ++++++++++++++++ >=20 > Workshop proposal submission: March 20, 2007 > Electronic submission of full papers: ** June 1, 2007 ** > Tutorial proposal submission: June 15, 2007 > Notification of paper acceptance: July 22, 2007 > Camera-ready copies of accepted papers: August 17, 2007 > Conference: November 2-5, 2007 >=20 > ++++++++++++++++++++++++ > Conference Organization > ++++++++++++++++++++++++ >=20 > Conference Chair: > * Andrei Broder, Yahoo! Research, USA >=20 > Program Chair: > * Tsau Young (T.Y.) Lin, San Jose State University/UC Berkeley, USA >=20 > WI Program Co-Chairs: > * Laura Haas, IBM Almaden Research Center, USA > * Janusz Kacprzyk, Polish Academy of Science, Poland > * Rajeev Motwani, Stanford University, USA >=20 > IAT Program Co-Chairs: > * Jeffrey M. Bradshaw, UWF/Institute for Human and Machine=20 > Cognition, USA > * Matthias Klusch, German Research Center for AI, Germany > * Chengqi Zhang, University of Technology, Sydney, Australia >=20 > Organizing Chair: > * Howard Ho, IBM Almaden Research Center, USA >=20 > Workshop Co-Chairs: > * Vijay Raghavan, University of Louisiana, USA > * Yuefeng Li, Queensland University of Technology, Australia >=20 > Tutorial Chair: > * Pawan Lingras, Saint Mary's University, Canada >=20 > Industry/Demo-Track Chair: > * Jianchang Mao, Yahoo! Inc., USA >=20 > Local Accommodations Co-Chairs: > * David Scot Taylor, San Jose State University, USA > * Tom Qi Zhang, Google, USA >=20 > Publicity Chair:=20 > * James Wang, Clemson University, USA (chair) Publicity Co-Chairs:=20 > * Martine De Cock, Ghent University, Belgium > * Jia Hu, International WIC Institute, China > * Debajyoti Mukhopadhyay, West Bengal University of=20 > Technology, India >=20 > IEEE-CS-TCII Chair: > * Ning Zhong, Maebashi Institute of Technology, Japan >=20 > ACM-SIGART Chair > * Maria Gini, University of Minnesota, USA >=20 > WIC Co-Chairs/Directors: > * Ning Zhong, Maebashi Institute of Technology, Japan > * Jiming Liu, University of Windsor, Canada >=20 > WIC Advisory Board:=20 > * Edward A. Feigenbaum, Stanford University, USA > * Setsuo Ohsuga, Waseda University, Japan > * Benjamin Wah, University of Illinois, Urbana-Champaign, USA > * Philip Yu, IBM Thomas J. Watson Research Center, USA > * L.A. Zadeh, University of California Berkeley, USA >=20 > WIC Tech. Committee & WI/IAT Steering Committee: > * Jeffrey Bradshaw, UWF/Institute for Human and Machine=20 > Cognition, USA > * Nick Cercone, Dalhousie University, Canada > * Dieter Fensel, National University of Ireland, Ireland > * Georg Gottlob, Oxford University, UK > * Lakhmi Jain, University of South Australia, Australia > * Jianchang Mao, Yahoo! Inc., USA > * Pierre Morizet-Mahoudeaux, Compiegne University of=20 > Technology, France > * Hiroshi Motoda, Osaka University, Japan > * Toyoaki Nishida, Kyoto University, Japan > * Andrzej Skowron, Warsaw University, Poland > * Jinglong Wu, Kagawa University, Japan > * Xindong Wu, University of Vermont, USA > * Yiyu Yao, University of Regina, Canada >=20 > Webmaster: > * Albert Sutojo, San Jose State University, USA >=20 > Abbreviation:=20 > WI 2007, WI2007, WI'2007, WI'07, WI07, WI 07, WI-07, WI-2007,=20 > WI-IAT 2007, WI-IAT2007, WI-IAT'2007, WI-IAT'07, WI-IAT07,=20 > WI-IAT 07, WI-IAT-2007, WI-IAT-07, WI/IAT 2007, WI/IAT2007,=20 > WI/IAT'2007, WI/IAT'07, WI/IAT07, WI/IAT 07, WI/IAT-2007, WI/IAT-07 >=20 > *** Contact Information *** >=20 > Jia Hu > International WIC Institute, China > E-mail: hujia@kis-lab.com >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 05:07:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfuWW-0007Fg-15; Mon, 23 Apr 2007 05:07:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfuWU-0007Fb-V0 for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 05:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfuWU-0007FT-KS for manet@ietf.org; Mon, 23 Apr 2007 05:07:50 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfuWQ-0004Wc-HF for manet@ietf.org; Mon, 23 Apr 2007 05:07:50 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1177319265!15393636!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19772 invoked from network); 23 Apr 2007 09:07:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with SMTP; 23 Apr 2007 09:07:45 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3N97jwA012683; Mon, 23 Apr 2007 02:07:45 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3N97iFx008649; Mon, 23 Apr 2007 04:07:44 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3N97Xvb008438; Mon, 23 Apr 2007 04:07:38 -0500 (CDT) Message-ID: <462C774E.3010501@gmail.com> Date: Mon, 23 Apr 2007 11:07:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 90fbdaf3c139ce803b358d56775b59ed Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dearlove, Christopher (UK) wrote: > Unfortunately the majority of traffic on this list is either this > sort of thing, or various student requests for help with protocols > and simulators, that are both off-topic. I agree there is much unwanted traffic, mostly under the form of CfP and simulator discussions. None of these is listed in this WG's Charter. > In fact the current number of on-topic postings is what's exceptional > (though welcome of course). > > The only way (short of closing down the WG) that I could see to stop > it would be labour intensive (monitoring list, removing postings, and > blacklisting posters) and I for one am not going to volunteer for. I _think_ policing the list traffic to agree with its Charter is probably a high effort in the first 1 or 2 months, and then it asymptotically declines to 0. Alex > -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: 22 April 2007 15:24 To: wiiat@kis-lab.com; manet Subject: RE: > [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley,USA) Deadline: June > 1 > > *** WARNING *** > > This mail has originated outside your organization, either from an > external partner or the Global Internet. Keep this in mind if you > answer this message. > > Folks, is it appropriate to post call for paper on an IETF WG list. I > don't think so this is a working group. > > thanks /jim > >> -----Original Message----- From: Jia Hu [mailto:wiiat@kis-lab.com] >> Sent: Sunday, April 22, 2007 10:08 AM To: manet Subject: [manet] >> CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley,USA) Deadline: June 1 >> >> [Apologies if you receive this more than once] >> >> ##################################################################### >> IEEE/WIC/ACM WEB INTELLIGENCE 2007 CALL FOR PAPERS >> ##################################################################### >> >> >> >> 2007 IEEE/WIC/ACM International Conference on Web Intelligence >> (WI'07) >> >> Silicon Valley, USA, November 2-5, 2007 Official: >> http://www.cs.sjsu.edu/wi07/wi/ Mirror: >> http://www.maebashi-it.org/wi07/wi/ (to be collocated with IAT'07, >> BIBM'07 and GrC'07) >> >> Sponsored By IEEE Computer Society Web Intelligence Consortium >> (WIC) Association for Computing Machinery (ACM) >> >> ###################################################################### >> # Conference Chair # Andrei Broder, VP, Yahoo Fellow, Yahoo! >> Research # # Program Chair and Co-Chairs # T.Y. Lin, Professor, >> SJSU, BISC Fellow, UC-Berkeley # Laura Haas, Director, IBM >> Almaden Research Center # Janusz Kacprzyk, Professor, Polish >> Academy of Science # Rajeev Motwani, Professor, Stanford >> University # # Organizing Chair # Howard Ho, Manager, IBM >> Almaden Research Center # # WI-IAT Joint Keynote Speakers >> (Tentative) # # Vinton G. Cerf, Turing Award Winner, # VP and Chief >> Internet Evangelist, Google # Anant Jhingran, VP and CTO, IBM >> Silicon Valley Laboratory # # (More WI Invited Speakers will be >> announced) # # (Papers Due: ** June 1 **, 2007) # Accepted papers >> will be published in the conference proceedings # by the IEEE >> Computer Society Press, which are indexed by EI. >> ###################################################################### >> >> >> >> Web Intelligence (WI) has been recognized as a new direction for >> scientific research and development to explore the fundamental >> roles as well as practical impacts of Artificial Intelligence (AI) >> (e.g., knowledge representation, planning, knowledge discovery and >> data mining, intelligent agents, and social network intelligence) >> and advanced Information Technology (IT) (e.g., wireless networks, >> ubiquitous devices, social networks, and data/knowledge grids) on >> the next generation of Web-empowered products, systems, services, >> and activities. It is one of the most important as well as >> promising IT research fields in the era of Web and agent >> intelligence. >> >> The 2007 IEEE/WIC/ACM International Conference on Web Intelligence >> (WI'07) will be jointly held with the 2007 IEEE/WIC/ACM >> International Conference on Intelligent Agent Technology (IAT'07), >> the 2007 IEEE International Conference on Bioinformatics and >> Biomedicine (BIBM'07), and the 2007 IEEE International Conference >> on Granular Computing (GrC'07) for providing synergism among the >> four research areas. It will provide opportunities for technical >> collaboration beyond that of previous conferences. The four >> conferences will have a joint opening, keynote, reception, and >> banquet. Attendees only need to register for one conference and can >> attend workshops, sessions and tutorials across the four >> conferences. We are also planning a joint panel and joint paper >> sessions that discuss common problems in the four areas. >> >> +++++++++++ Highlights +++++++++++ >> >> The conference will be held in Silicon Valley, California. Many >> high-tech companies and three distinguished universities (Stanford, >> UC Berkely and UCSC) are just around the corner. The highlight of >> the conference is that a unique forum consisting of a half-day >> industry/ demo track and free discussion will be organized to link >> industries and academics. Leading IT companies like IBM, Google, >> and Yahoo etc will present at the conference. >> >> The area now known as Silicon Valley has been a center of >> technological development since the 1950's. The name Silicon Valley >> stems from the early 1970's, when the area had become the center >> for many semiconductor companies. While still hosting semiconductor >> and microprocessor companies, the region now hosts the >> headquarters of high tech companies of every kind, including many >> of the best known and most prestigious names in personal computers, >> Web search, Internet auctions, networking, storage, databases, etc. >> >> >> +++++++++++++++++++ Topics of Interest +++++++++++++++++++ >> >> The topics and areas include, but not limited to: >> >> * WI Foundations - Brain Informatics for WI - Human level WI - New >> cognitive models and computational models for WI - Granular >> Computing (GrC) for WI - Autonomy-Oriented Computing (AOC) for WI >> >> * World Wide Wisdom Web (W4) - Meta-Knowledge Discovery and >> Representation - Problem Solver Markup Language (PSML) - Search of >> Best Means and Ends - Goal-Directed Services Support - Distributed >> Resources Optimization - Service Self-Aggregation - Web Inference >> Engine - Information and Knowledge Markets - New Social Interaction >> Paradigms - Social and Psychological Contexts - Regularities and >> Laws of W4 >> >> * Social Networks and Social Intelligence - Social Network Mining - >> Web Site Clustering - Link Topology and Site Hierarchy - Theories >> of Small-World Web - Virtual and Web Communities - Web-Based >> Cooperative Work - Knowledge Community Formation and Support - >> Ubiquitous Computing - Intelligent Wireless Web - Ubiquitous >> Learning Systems - Entertainment >> >> * Knowledge Grids and Grid Intelligence - Semantic Grids - >> Knowledge Resources and Services Discovery - On-Demand Planning and >> Routing - Brokering and Scheduling - Middleware Architectures and >> Tools >> >> * Web Mining and Farming - Text Mining - Data Stream Mining - >> Multimedia Data Mining - Web Content Mining - Web Log and Usage >> Mining - Learning User Profiles - Context Sensitive Web Mining - >> Web Information Clustering - Web Page Clustering and Mining - >> E-Mail Classification - Web Site Classification - Web Information >> Indexing - Data Warehousing - Web Farming and Warehousing >> >> * Semantics and Ontology Engineering - Ontology-Based Information >> Extraction and Retrieval - Ontology-Based Web Mining - Web-Based >> Ontology Learning - Semantic Web >> >> * Web Agents - Global Information Foraging - Distributed Problem >> Solving - Coordination - Resource Intermediary and Coordination >> Mechanisms - Self-Organization and Reproduction - Agent Networks >> and Topologies - Mobile Agents - Macroscopic Behavior Modeling - >> Trust Models for Web Agents >> >> * Web Services - Service-Oriented Computing - Matchmaking - Web >> Service Reconfiguration - Web Service Workflow Composition - >> Middleware-Based Ubiquitous Services - Grid Services >> >> * Web Information Filtering and Retrieval - Automatic Cataloging >> and Indexing - Clustering-Based Recommender Systems - Collaborative >> Filtering and Recommendation - Hybrid Recommendation - Information >> Retrieval Criteria and Evaluations - Web Information >> Categorization and Ranking - Proxy and Cache Techniques - Web >> Prediction and Prefetching - Distributed Web Search - >> Specifications for Web Information Extraction Process - Web >> Crawling Systems - Search Engines and Meta-search Engines >> >> * Intelligent Human-Web Interaction - Adaptive Web Interfaces - >> Context-Aware Computing - Learning User Profiles - Personalized >> Interfaces - Personalized Web Sites - Remembrance Agents - >> Multimedia Representation - Visualization of Information and >> Knowledge - Social and Psychological Issues >> >> * Web Support Systems - Information Retrieval Support Systems - Web >> Site Navigation Support Systems - Recommender Support Systems - >> Web-Based Decision Support Systems - Soft Computing (including >> neural networks, fuzzy logic, evolutionary computation, rough sets, >> and granular computing) and Uncertainty Management for WI >> >> * Intelligent e-Technology - Business Intelligence - Digital >> Library - Decentralized Community Communication Techniques - >> e-Community - e-Business and e-Commerce - e-Finance - e-Government >> - e-Learning - e-Publishing - e-Science - Intelligent Enterprise >> Portals - Web-Based Direct Marketing and CRM - Web-Based EDI - Web >> Security, Integrity, Privacy and Trust >> >> ++++++++++++++++++++++++++++++++++++ On-Line Submissions and >> Publication ++++++++++++++++++++++++++++++++++++ >> >> High-quality papers in all WI related areas are solicited. Paper >> submissions should be limited to a maximum of 7 pages in the IEEE >> 2-column format, the same as the camera-ready format (see the >> Author Guidelines of last year at >> http://www.computer.org/portal/pages/cscps/cps/final/wi06.xml). All >> submitted papers will be reviewed by the Program Committee on the >> basis of technical quality, relevance, significance, and clarity. >> >> Note that WI'07 will accept ONLY on-line submissions, containing >> PDF versions. Please use the Submission Form on the WI'07 website >> to submit your paper. Accepted papers will be published in the >> conference proceedings by the IEEE Computer Society Press that are >> indexed by EI. >> >> Submissions accepted as regular papers will be allocated 7 pages in >> the proceedings and accorded oral presentation times in the main >> conference. Submissions accepted as short papers will be allocated >> 4 pages in the proceedings and will have a shorter presentation >> time at the conference than regular papers. >> >> All co-authors will be notified at all time, for the submission, >> notification, and confirmation on the attendance. Submitting a >> paper to the conference and workshops means that, if the paper is >> accepted, at least one author should attend the conference to >> present the paper. The acceptance list and no-show list will be >> openly published on-line. For no-show authors, their affiliations >> will receive a notification. >> >> A selected number of WI'07 accepted papers will be expanded and >> revised for inclusion in Web Intelligence and Agent Systems: An >> International Journal (http://wi-consortium.org/journal.html) and >> in Annual Review of Intelligent Informatics >> (http://www.wi-consortium.org/annual.html). >> >> More detailed instructions and the On-Line Submission Form can be >> found from the WI'07 homepage: http://www.cs.sjsu.edu/wi07/wi/. >> >> ++++++++++++++++++++++++ WI'07 Best Paper Awards >> ++++++++++++++++++++++++ >> >> The best paper awards will be conferred at the conference on the >> authors of (1) the best research paper and (2) the best application >> paper. Application-oriented submissions will be considered for the >> best application paper award. >> >> The full author list and paper title will be announced on the Web >> Intelligence Consortium homepage: >> http://wi-consortium.org/html/wicawards.html >> >> ++++++++++++++++++++ Industry/Demo-Track ++++++++++++++++++++ >> >> We solicit Industry/Demo-Track papers by the following methods. >> >> (1) Industry papers of 4 pages can be submitted on the same >> schedule as the research track. (2) Separate 2 page demo proposals >> can submitted at a later schedule. (3) Full regular paper >> submissions can include a demo option. That is, a full paper >> submissions will be asked to specify if they would like to give a >> demonstration; choice of demonstrations (while utilizing >> information from the regular reviewing process) will be selected >> based on value as a demonstration. >> >> For options (1) and (2), please find more detailed instructions at >> the homepage: http://www.cs.sjsu.edu/wi07/wi/ >> >> We are planning to arrange the Industry/Demo track in the afternoon >> of November 3 (before and during the conference reception), >> jointly with the IAT'07 Demo sessions. Leading IT companies in >> Silicon Valley will be invited to attend this track. >> >> ++++++++++ Workshops ++++++++++ >> >> As an important part of the conference, the workshop program will >> focus on new research challenges and initiatives. All papers >> accepted for workshops will be included in the Workshop Proceedings >> published by the IEEE Computer Society Press that are indexed by >> EI, and will be available at the workshops. Detailed information is >> available at the conference homepage. >> >> Note: we will not have a separate workshop registration fee (i.e., >> conference registration covers everything). >> >> ------------------ WI 2007 Workshops: ------------------ Title: >> Educating the Web-Generation Organisers: Elisabeth Heinemann Email: >> elisabeth.heinemann@googlemail.com Web page: >> http://www.effactory.com/Edu4WebGen/ >> >> Title: Collective Intelligence on Semantic Web Organisers: Geun Sik >> Jo; Jason J. Jung; Ngoc Thanh Nguyen Email: gsjo@inha.ac.kr; >> j2jung@intelligent.pe.kr; thanh@pwr.wroc.pl Web page: >> http://intelligent.pe.kr/CISW07/ >> >> Title: New Computing Paradigms for Web Intelligence and Brain >> Informatics Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter >> Fensel Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: >> >> Title: Web Personalization and Recommender Systems Organisers: Yue >> Xu Email: yue.xu@qut.edu.au Web page: >> http://www.wprs07.fit.qut.edu.au/ >> >> Title: Service Composition Organisers: M. Brian Blake; Dumitru >> Roman; Charles Petrie Email: blakeb@cs.georgetown.edu; >> dumitru.roman@deri.org Web site: http://events.deri.at/sercomp2007/ >> >> >> >> Title: Biomedicine applications of Web technologies Organisers: >> Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu Email: >> chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw; >> whlu@mail.ncku.edu.tw Web page: >> http://chunnan.iis.sinica.edu.tw/BMWT2007.html >> >> Title: Intelligent Web Interaction Workshop 2007 1st Organiser: >> Prof. Seiji YAMADA Email: seiji@nii.ac.jp Web site: >> http://ymd.ex.nii.ac.jp/ws/iwi/07/ >> >> Title: Cyberinfrastucture for e-Science Organisers: Prof. Vasant >> Honavar; A/prof. Kei Cheung Email: honavar@cs.iastate.edu; >> kei.cheung@yale.edu Web page: >> http://www.cild.iastate.edu/events/CyIneS2007/ >> >> Title: 2007 International Workshop on Social Media Analysis >> Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu Email: >> sma@comp.hkbu.edu.hk Web page: http://www.comp.hkbu.edu.hk/~sma/ >> >> Title: Web Security, Integrity, Privacy and Trust Organisers: Dr. >> Yiuming Cheung, Prof. Michael Chau, and Prof. Yong Zhang Email: >> ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk; zhangyong076@gmail.com >> Web page: >> >> ------------------- IAT 2007 Workshops: ------------------- Title: >> Second International Workshop on Communication between Human and >> Artificial Agents (CHAA-07) Organisers: Christel Kemke Email: >> ckemke@cs.umanitoba.ca Web page: >> http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ >> >> Title: Rational, Robust, and Secure Negotiations in Multi-Agent >> Systems (RRS2007) Organisers: Takayuki Ito Email: >> ito.takayuki@nitech.ac.jp Web page: >> http://www-itolab.mta.nitech.ac.jp/RRS2007/ >> >> Title: P2P Computing and Autonomous Agents Organisers: Tarek Helmy, >> Khaled Ragab Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa >> Web Page: http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html >> >> Title: Multiagent systems in E-business: concepts, technologies and >> applications Organisers: Costin Badica; Maria Ganzha; Marcin >> Paprzycki Email: badica_costin@software.ucv.ro; >> ganzha@euh-e.edu.pl; marcin.parzycki@swps.edu.pl Web page: >> http://software.ucv.ro/~badica_costin/maseb2007/ >> >> Title: Agent & Data Mining Interaction Organisers: Pericles A. >> Mitkas, Longbing Cao, Vladimir Gorodetsky, Justin Zhan Email: >> mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page: >> http://issel.ee.auth.gr/ADMI >> >> For more information, please visit the conference website at >> http://www.cs.sjsu.edu/wi07/wi/?index=workshop. >> >> ++++++++++ Tutorials ++++++++++ >> >> WI'07 also welcomes Tutorial proposals. WI'07 will include >> tutorials providing in-depth background on subjects that are of >> broad interest to the Web intelligence community. Both short (2 >> hours) and long (half day) tutorials will be considered. The >> tutorials will be part of the main conference technical program. >> Detailed information is available at the conference homepage. >> >> Note: we will not have a separate tutorials registration fee (i.e., >> only one conference registration covers everything). >> >> ++++++++++++++++ Important Dates ++++++++++++++++ >> >> Workshop proposal submission: March 20, 2007 Electronic >> submission of full papers: ** June 1, 2007 ** Tutorial proposal >> submission: June 15, 2007 Notification of paper >> acceptance: July 22, 2007 Camera-ready copies of accepted >> papers: August 17, 2007 Conference: November 2-5, 2007 >> >> ++++++++++++++++++++++++ Conference Organization >> ++++++++++++++++++++++++ >> >> Conference Chair: * Andrei Broder, Yahoo! Research, USA >> >> Program Chair: * Tsau Young (T.Y.) Lin, San Jose State >> University/UC Berkeley, USA >> >> WI Program Co-Chairs: * Laura Haas, IBM Almaden Research Center, >> USA * Janusz Kacprzyk, Polish Academy of Science, Poland * Rajeev >> Motwani, Stanford University, USA >> >> IAT Program Co-Chairs: * Jeffrey M. Bradshaw, UWF/Institute for >> Human and Machine Cognition, USA * Matthias Klusch, German Research >> Center for AI, Germany * Chengqi Zhang, University of Technology, >> Sydney, Australia >> >> Organizing Chair: * Howard Ho, IBM Almaden Research Center, USA >> >> Workshop Co-Chairs: * Vijay Raghavan, University of Louisiana, USA >> * Yuefeng Li, Queensland University of Technology, Australia >> >> Tutorial Chair: * Pawan Lingras, Saint Mary's University, Canada >> >> Industry/Demo-Track Chair: * Jianchang Mao, Yahoo! Inc., USA >> >> Local Accommodations Co-Chairs: * David Scot Taylor, San Jose State >> University, USA * Tom Qi Zhang, Google, USA >> >> Publicity Chair: * James Wang, Clemson University, USA (chair) >> Publicity Co-Chairs: * Martine De Cock, Ghent University, Belgium * >> Jia Hu, International WIC Institute, China * Debajyoti >> Mukhopadhyay, West Bengal University of Technology, India >> >> IEEE-CS-TCII Chair: * Ning Zhong, Maebashi Institute of Technology, >> Japan >> >> ACM-SIGART Chair * Maria Gini, University of Minnesota, USA >> >> WIC Co-Chairs/Directors: * Ning Zhong, Maebashi Institute of >> Technology, Japan * Jiming Liu, University of Windsor, Canada >> >> WIC Advisory Board: * Edward A. Feigenbaum, Stanford University, >> USA * Setsuo Ohsuga, Waseda University, Japan * Benjamin Wah, >> University of Illinois, Urbana-Champaign, USA * Philip Yu, IBM >> Thomas J. Watson Research Center, USA * L.A. Zadeh, University of >> California Berkeley, USA >> >> WIC Tech. Committee & WI/IAT Steering Committee: * Jeffrey >> Bradshaw, UWF/Institute for Human and Machine Cognition, USA * Nick >> Cercone, Dalhousie University, Canada * Dieter Fensel, National >> University of Ireland, Ireland * Georg Gottlob, Oxford University, >> UK * Lakhmi Jain, University of South Australia, Australia * >> Jianchang Mao, Yahoo! Inc., USA * Pierre Morizet-Mahoudeaux, >> Compiegne University of Technology, France * Hiroshi Motoda, Osaka >> University, Japan * Toyoaki Nishida, Kyoto University, Japan * >> Andrzej Skowron, Warsaw University, Poland * Jinglong Wu, Kagawa >> University, Japan * Xindong Wu, University of Vermont, USA * Yiyu >> Yao, University of Regina, Canada >> >> Webmaster: * Albert Sutojo, San Jose State University, USA >> >> Abbreviation: WI 2007, WI2007, WI'2007, WI'07, WI07, WI 07, WI-07, >> WI-2007, WI-IAT 2007, WI-IAT2007, WI-IAT'2007, WI-IAT'07, WI-IAT07, >> WI-IAT 07, WI-IAT-2007, WI-IAT-07, WI/IAT 2007, WI/IAT2007, >> WI/IAT'2007, WI/IAT'07, WI/IAT07, WI/IAT 07, WI/IAT-2007, WI/IAT-07 >> >> >> >> *** Contact Information *** >> >> Jia Hu International WIC Institute, China E-mail: hujia@kis-lab.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 > > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > _______________________________________________ manet mailing list > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 05:33:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfuv7-0001PI-6V; Mon, 23 Apr 2007 05:33:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfuv4-0001Mx-Ib for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 05:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfuv4-0001Mp-72 for manet@ietf.org; Mon, 23 Apr 2007 05:33:14 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfuv2-0002qc-VK for manet@ietf.org; Mon, 23 Apr 2007 05:33:14 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-3.tower-119.messagelabs.com!1177320792!19360784!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.10] Received: (qmail 2028 invoked from network); 23 Apr 2007 09:33:12 -0000 Received: from motgate6.mot.com (HELO motgate.mot.com) (129.188.136.10) by server-3.tower-119.messagelabs.com with SMTP; 23 Apr 2007 09:33:12 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (8.12.11/Motorola) with ESMTP id l3N9XBuZ017147; Mon, 23 Apr 2007 02:33:12 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l3N9XBTM006499; Mon, 23 Apr 2007 04:33:11 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l3N9X5YE006396; Mon, 23 Apr 2007 04:33:08 -0500 (CDT) Message-ID: <462C7D4B.8000402@gmail.com> Date: Mon, 23 Apr 2007 11:32:59 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [manet] Dymo route discovery References: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> <4628D829.80900@gmail.com> <374005f30704220349q394413c4l9794205d95a1e0b2@mail.gmail.com> <462BD0BC.7040100@gmail.com> <462C2D98.1070107@nokia.com> In-Reply-To: <462C2D98.1070107@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Charles E. Perkins wrote: > > Hello Alex, > > I am pretty sure RERR is better, because it can invalidate > many broken routes. An ICMP message would pretty much > be restricted to invalidating only one. The ICMP message > would have to be unicast to the source (and, actually, to the > particular application on the source). The RERR message > is a hop-by-hop broadcast and can do a lot better. > > Does this make sense? Makes sense. For IPv6, distributing RERR seems to happen in multicast mode, ie to a multicast address. > ext Alexandru Petrescu wrote: >>> >>> I would recommend that an ICMP destination unreachable not issued, >>> but I would not require it. Please see my other email on this >>> subject. >> >> I think this sounds like a recommendation on the use of ICMP Destination >> Unreachable. This recommendation should be discussed in my oppinion. >> Currently the draft only talks about a local Dst Unreachable delivered >> to the application. I think what you want is to make sure that no >> router in a network running DYMO sends a ICMP Dst Unreachable, because >> its information may be contradicting the information in RERR. > > I am not sure when the ICMP data would contradict the RERR > message data -- except unless the RERR triggered a route repair > without disturbing the application. Is that what you meant? I mean it is useless to have both ICMP Dst Unreachable and RERR do the same thing. You seem to challenge the fact that their contents would be contradicting each other - probably they won't - but still, one wouldn't want both Dst Unreachable and RERR to be issued for deleting the same route, because for sure one will not find that particular route to delete. In which case DYMO would assume that if RERR is implemented then DstUnreachable shouldn't ever be sent, right? Alex > > Regards, > Charlie P. > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 05:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfv0k-0005h5-25; Mon, 23 Apr 2007 05:39:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfv0h-0005gr-IA for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 05:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfv0g-0005gi-Kx for manet@ietf.org; Mon, 23 Apr 2007 05:39:03 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfv0g-00040p-5h for manet@ietf.org; Mon, 23 Apr 2007 05:39:02 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1177321141!8096593!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24964 invoked from network); 23 Apr 2007 09:39:01 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 23 Apr 2007 09:39:01 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3N9d0iK021114; Mon, 23 Apr 2007 02:39:00 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l3N9d0JI013380; Mon, 23 Apr 2007 04:39:00 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3N9crjJ013262; Mon, 23 Apr 2007 04:38:55 -0500 (CDT) Message-ID: <462C7EA6.8080201@gmail.com> Date: Mon, 23 Apr 2007 11:38:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Dymo route discovery References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> <4628CC1F.1060106@gmail.com> <374005f30704220346o7ea375c8k270ee87c51844431@mail.gmail.com> <462BCFB5.7070305@gmail.com> <374005f30704222105q7c65f4dch49b4628105958adf@mail.gmail.com> In-Reply-To: <374005f30704222105q7c65f4dch49b4628105958adf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: > Comments inline. > > On 4/23/07, Alexandru Petrescu wrote: >> Ian Chakeres wrote: >>> Comments inline. >>> >>> On 4/20/07, Alexandru Petrescu >>> wrote: >>>> Ian Chakeres wrote: >>>>> >>>>> >>>>>> >>>>>> I much prefer if DYMO sends ICMP Destination Unreachable >>>>>> instead of RERR. >>>>>> >>>>>> Because, if one wants DYMO to send RERR instead of ICMP >>>>>> then one must modify the IP stack code to disallow sending >>>>>> ICMP Destination Unreachable. And that _only_ when DYMO >>>>>> runs on the machine. This is too complex IMHO. >>>>> >>>>> RERR messages are disseminated in a controlled manner to >>>>> remove routes that are no longer available/accurate. An >>>>> generic ICMP Destination Unreachable message would not be >>>>> capable of performing this operation. >>>> >>>> Would a generic ICMP Redirect achieve the same effect you look >>>> for? (add a route that overcomes an existing route that is no >>>> longer accurate). >>> >>> ICMP redirect would not convey the same information as a RERR, >>> nor would it be distributed appropriately. >> >> We somehow turn and turn. >> >> Indeed RERR conveys information more similar to ICMP Dst >> Unreachable (it contains the address that is unreachable). > > Here is a short list of some of RERRs features. > > The RERR is disseminated in a limited flood. RERR may contain the > addresses of many now unreachable devices. RERR can be generated > on-demand, instead of waiting for data traffic to flow. I always thought 'on-demand' means data traffic flows demands construction of a route :-) > RERR contain the sequence number related to the addresses for which a > route is not available. Ok, I'll have to check that. >>>>> Can you please talk more as to why you think RERR messaging >>>>> or processing is too complex? Or how we might improve RERR >>>>> operation? >>>> >>>> I meant it is complex to implement the logic whereby one >>>> forbids the generation of ICMP Destination Unreachable. >>>> Presumably, that's what you want to do on a router: if it runs >>>> DYMO and sends RERR then it must not send ICMP Destination >>>> Unreachable, right? >>> >>> ICMP Destination Unreachable messages are for the sources of >>> packets, not the routers in between. >> >> Yes. ICMP Redirect is for routers in between. >> >> But, do you mean that RERR and ICMP Destination Unreachable can >> work simultaneously ok? > > I don't see any reason why they couldn't work together, but as I > mention I wouldn't suggest it. So one has to _disable_ ICMP DstUnreachable generation code, right? That's built-in into the stack. >>> In the AODV/DYMO implementations I've seen, ICMP Destination >>> Unreachable messages are issued by the source if it cannot find a >>> route. >> >> Well, I think that is wrong. The Dst Unreachable is usually >> generated by the last router in the path to the destination that >> has no route to that destination (and not by the source). The >> local source host will not generate a Dst Unreachable because it is >> supposed to have at least a default route. > > The question here is about "having no route". In reactive protocols, > just be cause you don't have a route at this moment, does not mean > you can't find a route. > > >>> I believe this is the chosen proceedure to discourage a sources >>> application from believing that no route is available, since it >>> is likely that the route is only temporarily broken or >>> unavailable and will soon be repaired. >> >> I think better than that can be achieved by always offering a >> default route to the host. >> >> But here again we assume different models for the networks. You >> assume that the application is run on the router that does the >> route discovery as well. I assume the application is run on a host >> that has no routing capabilities, and always has at least a >> default route. I will send a separate message about this, later. > > We do not assume that the application is run on the router. A MANET > router can/will perform route discovery on behalf of its attached > hosts. For my clarification, will a MANET router act as a default router for its attached hosts? Or will it try to provide host-based routes to install in the host's routing table for every correspondent this host talks to? This is very important to the MANEMO analysis, thanks. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 05:52:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvDV-0005ZQ-GM; Mon, 23 Apr 2007 05:52:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfvDT-0005Wu-Kp for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 05:52:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvDT-0005WN-BK for manet@ietf.org; Mon, 23 Apr 2007 05:52:15 -0400 Received: from mail.unina.it ([192.132.34.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfvDO-00007c-Tj for manet@ietf.org; Mon, 23 Apr 2007 05:52:15 -0400 Received: from [143.225.233.194] ([143.225.233.194]) by mail.unina.it (8.13.7/8.13.7) with ESMTP id l3N9sGrW029676 for ; Mon, 23 Apr 2007 11:54:38 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) To: manet Message-Id: <74DF4483-BD61-4821-A0F7-6472580689B0@unina.it> References: <2D91CC98-D9EB-4E5D-9BD5-58F485FC3E23@unina.it> From: Marcello Caleffi Subject: Re: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Date: Mon, 23 Apr 2007 11:50:40 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1102119787==" Errors-To: manet-bounces@ietf.org --===============1102119787== Content-Type: multipart/alternative; boundary=Apple-Mail-4--701338267 --Apple-Mail-4--701338267 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Instead, I think CFPs are usefull to researchers work. If you don't need to them, you could simply discard. Il giorno 22/apr/07, alle ore 22:01, Alexandru Petrescu ha scritto: >>> Marcello Caleffi, Ph.D. student Department of Electronic and Telecommunication Engineering University of Naples "Federico II" Via Claudio 21 80125 Naples ITALY --Apple-Mail-4--701338267 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII

Instead, I think CFPs are usefull to = researchers work. If you don't need to them, you could simply = discard.

Il giorno 22/apr/07, alle ore 22:01, = Alexandru Petrescu ha scritto:


=

Marcello Caleffi, Ph.D. student
Department of Electronic and Telecommunication = Engineering
University of Naples "Federico = II"
Via Claudio 21
80125 Naples ITALY

 =


Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvPk-0000k1-Km; Mon, 23 Apr 2007 06:04:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfvPi-0000jt-U5 for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 06:04:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvPi-0000jl-Kb for manet@ietf.org; Mon, 23 Apr 2007 06:04:54 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfvPh-0003qy-9d for manet@ietf.org; Mon, 23 Apr 2007 06:04:54 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-153.messagelabs.com!1177322692!5330648!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 12941 invoked from network); 23 Apr 2007 10:04:52 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-153.messagelabs.com with SMTP; 23 Apr 2007 10:04:52 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3NA4pOq027316; Mon, 23 Apr 2007 03:04:51 -0700 (MST) Received: from az10vts03 (az10vts03.mot.com [10.64.251.244]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l3NA4ojL008772; Mon, 23 Apr 2007 05:04:50 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l3NA4l6Z008681; Mon, 23 Apr 2007 05:04:48 -0500 (CDT) Message-ID: <462C84B8.6070700@gmail.com> Date: Mon, 23 Apr 2007 12:04:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Marcello Caleffi Subject: Re: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 References: <2D91CC98-D9EB-4E5D-9BD5-58F485FC3E23@unina.it> <74DF4483-BD61-4821-A0F7-6472580689B0@unina.it> In-Reply-To: <74DF4483-BD61-4821-A0F7-6472580689B0@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Marcello Caleffi wrote: > > Instead, I think CFPs are usefull to researchers work. If you don't need > to them, you could simply discard. Hi Marcello. I think indeed CfPs are useful for researchers work in the MANET area. However, I also think there are many other venues for distributing MANET-related CfPs widely, like specialized journals of ACM and IEEE which have very large readerships and available to interested researchers and grads. What's easier for me: discard CfPs every day? Or tell CfPs posters to no longer post on the MANET list? I much prefer the latter. I propose to reject all Call for Papers in the MANET Working Group. Alex > > Il giorno 22/apr/07, alle ore 22:01, Alexandru Petrescu ha scritto: > >>>> > > Marcello Caleffi, Ph.D. student > Department of Electronic and Telecommunication Engineering > University of Naples "Federico II" > Via Claudio 21 > 80125 Naples ITALY > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 06:07:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvSD-0004XG-DD; Mon, 23 Apr 2007 06:07:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfvSB-0004VN-Fj for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 06:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvSB-0004VF-6H for manet@ietf.org; Mon, 23 Apr 2007 06:07:27 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfvS9-0004mI-To for manet@ietf.org; Mon, 23 Apr 2007 06:07:27 -0400 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp2.int-evry.fr (Postfix) with ESMTP id 57BF92FDAA; Mon, 23 Apr 2007 12:07:16 +0200 (CEST) Subject: Re: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 From: Pars Mutaf To: Marcello Caleffi In-Reply-To: <74DF4483-BD61-4821-A0F7-6472580689B0@unina.it> References: <2D91CC98-D9EB-4E5D-9BD5-58F485FC3E23@unina.it> <74DF4483-BD61-4821-A0F7-6472580689B0@unina.it> Content-Type: text/plain Organization: INT Evry Date: Mon, 23 Apr 2007 12:07:16 +0200 Message-Id: <1177322836.8587.2.camel@lor-maknavic3.int-evry.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-MCPCheck: X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org there is also this approach? http://www.google.fr/search?q=CFP+MANET+2007&hl=en&start=10&sa=N > Instead, I think CFPs are usefull to researchers work. If you don't > need to them, you could simply discard. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 06:12:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvXI-0000ME-6O; Mon, 23 Apr 2007 06:12:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfvXG-0000Lu-PR for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 06:12:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvXG-0000Lm-Fu for manet@ietf.org; Mon, 23 Apr 2007 06:12:42 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfvXF-0005jl-WC for manet@ietf.org; Mon, 23 Apr 2007 06:12:42 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3NACejG016821 for ; Mon, 23 Apr 2007 11:12:40 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3NACeUb004570 for ; Mon, 23 Apr 2007 11:12:40 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 23 Apr 2007 11:12:40 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Apr 2007 11:12:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Date: Mon, 23 Apr 2007 11:12:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Thread-Index: AceFjRfVbuq4XdufR/K+Xpfg0mIK6gAAjMhQ From: "Dearlove, Christopher \(UK\)" To: "manet" X-OriginalArrivalTime: 23 Apr 2007 10:12:40.0118 (UTC) FILETIME=[ECB0DD60:01C7858F] X-Spam-Score: 0.6 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1821173120==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1821173120== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7858F.EC90004A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7858F.EC90004A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That would be fine if this were a general manet research mailing list. It's not. It's the mailing list of the IETF MANET WG, whose objectives (spelled out in its charter) are (roughly) the creation of the routing protocols DYMO, OLSRv2 and SMF. Compare with other IETF mailing lists - they don't contain CFPs, student queries and so on, they are focussed on their relevant tasks in hand. =20 Simply discarding is not a sufficient solution. By their nature, being in the majority, they obscure the purpose of the list, and have I'm sure in the past served to put off people whose input on the actual tasks of the group would have been useful. _____ =20 From: Marcello Caleffi [mailto:marcello.caleffi@unina.it]=20 Sent: 23 April 2007 10:51 To: manet Subject: Re: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley,USA) Deadline: June 1 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 =09 Instead, I think CFPs are usefull to researchers work. If you don't need to them, you could simply discard.=20 Il giorno 22/apr/07, alle ore 22:01, Alexandru Petrescu ha scritto: Marcello Caleffi, Ph.D. student Department of Electronic and Telecommunication Engineering University of Naples "Federico II" Via Claudio 21 80125 Naples ITALY ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** ------_=_NextPart_001_01C7858F.EC90004A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
That would be fine if this were a general manet= =20 research mailing list.
It's not. It's the mailing list of the IETF= MANET WG,=20 whose objectives
(spelled out in its charter) are (roughly) the= creation=20 of the routing
protocols DYMO, OLSRv2 and SMF. Compare with= other IETF=20 mailing
lists - they don't contain CFPs, student queries= and so=20 on, they are
focussed on their relevant tasks in=20 hand.
 
Simply discarding is not a sufficient solution.= By=20 their nature, being in
the majority, they obscure the purpose of the= list, and=20 have I'm sure
in the past served to put off people whose input= on the=20 actual tasks
of the group would have been=20 useful.

From: Marcello Caleffi=20 [mailto:marcello.caleffi@unina.it]
Sent: 23 April 2007=20 10:51
To: manet
Subject: Re: [manet] CFP: IEEE/WIC/ACM= WI=20 2007 (Silicon Valley,USA) Deadline: June 1

*** WARNING ***

This= mail=20 has originated outside your organization,
either from an external= =20 partner or the Global Internet.
Keep this in mind if you answer= this=20 message.

Instead, I think= CFPs are=20 usefull to researchers work. If you don't need to them, you could simply=20 discard.

Il giorno 22/apr/07, alle ore 22:01, Alexandru Petrescu ha=20 scritto:



Marcello Caleffi, Ph.D. student
Department of Electronic and Telecommunication=20 Engineering
University of Naples "Federico II"
Via Claudio 21
80125 Naples ITALY



****************************************************************= ****
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

------_=_NextPart_001_01C7858F.EC90004A-- --===============1821173120== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1821173120==-- From manet-bounces@ietf.org Mon Apr 23 06:12:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvXN-0000Os-07; Mon, 23 Apr 2007 06:12:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HfvXL-0000NW-N2 for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 06:12:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfvXL-0000NO-DJ for manet@ietf.org; Mon, 23 Apr 2007 06:12:47 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfvXJ-0005k9-1Z for manet@ietf.org; Mon, 23 Apr 2007 06:12:47 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-128.messagelabs.com!1177323163!8179936!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.105] Received: (qmail 24991 invoked from network); 23 Apr 2007 10:12:43 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (144.189.100.105) by server-8.tower-128.messagelabs.com with SMTP; 23 Apr 2007 10:12:43 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motorola) with ESMTP id l3NACdY0028612; Mon, 23 Apr 2007 03:12:43 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l3NACcT4001914; Mon, 23 Apr 2007 05:12:38 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l3NACUZ9001807; Mon, 23 Apr 2007 05:12:33 -0500 (CDT) Message-ID: <462C868A.5010202@gmail.com> Date: Mon, 23 Apr 2007 12:12:26 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: pars.mutaf@int-evry.fr Subject: Re: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 References: <2D91CC98-D9EB-4E5D-9BD5-58F485FC3E23@unina.it> <74DF4483-BD61-4821-A0F7-6472580689B0@unina.it> <1177322836.8587.2.camel@lor-maknavic3.int-evry.fr> In-Reply-To: <1177322836.8587.2.camel@lor-maknavic3.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Pars Mutaf wrote: > there is also this approach? > > http://www.google.fr/search?q=CFP+MANET+2007&hl=en&start=10&sa=N I agree, active searching for Call for Papers is an effective means to stay updated with what's happening in the field, in general. Alex > > > >> Instead, I think CFPs are usefull to researchers work. If you don't >> need to them, you could simply discard. > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 06:22:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfvh4-0006Bm-Dr; Mon, 23 Apr 2007 06:22:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfvh2-0006Be-FF for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 06:22:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfvh2-0006BV-5Z for manet@ietf.org; Mon, 23 Apr 2007 06:22:48 -0400 Received: from ik-out-1112.google.com ([66.249.90.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfvh1-0008KM-MK for manet@ietf.org; Mon, 23 Apr 2007 06:22:48 -0400 Received: by ik-out-1112.google.com with SMTP id c30so585079ika for ; Mon, 23 Apr 2007 03:22:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pyc4mrhEWbQhPPpcv0wEytMf0EY1MNK976u0S66Mn3fIR4C5pRV3mQFYPcuby+7R0O4eJtWoKbeddxsIw7k9uN/OjzhR2z7PKcoicpca4LsTsApSW0yz0FsEWSXg6KBiPmRkOhoVYovHyHnteuzMmAevKSuGJsKoqURDar19RT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A2w6sOVspKYTLiSDUHcfTSuqukwQFmWr21sJiw6O9XDFEcBqiFJ34eEUZ2ywF9aUqq31DIyqc3rslo78nV4qn/QxAXhvgkxnPiyohUOqogZoMplqY20p2whJw27o+e6Hp1RQRLiKU1wRyjFQJaCcG1XqPsiKAsfT8hPE+dF5A44= Received: by 10.78.204.7 with SMTP id b7mr991606hug.1177323766611; Mon, 23 Apr 2007 03:22:46 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Mon, 23 Apr 2007 03:22:46 -0700 (PDT) Message-ID: <374005f30704230322u48c24d35p4ad793f36f44eb0@mail.gmail.com> Date: Mon, 23 Apr 2007 15:52:46 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Dymo route discovery In-Reply-To: <462C7EA6.8080201@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> <4628CC1F.1060106@gmail.com> <374005f30704220346o7ea375c8k270ee87c51844431@mail.gmail.com> <462BCFB5.7070305@gmail.com> <374005f30704222105q7c65f4dch49b4628105958adf@mail.gmail.com> <462C7EA6.8080201@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 4/23/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > Comments inline. > > > > On 4/23/07, Alexandru Petrescu wrote: > >> Ian Chakeres wrote: > >>> Comments inline. > >>> > >>> On 4/20/07, Alexandru Petrescu > >>> wrote: > >>>> Ian Chakeres wrote: > >>>>> > >>>>> > >>>>>> > >>>>>> I much prefer if DYMO sends ICMP Destination Unreachable > >>>>>> instead of RERR. > >>>>>> > >>>>>> Because, if one wants DYMO to send RERR instead of ICMP > >>>>>> then one must modify the IP stack code to disallow sending > >>>>>> ICMP Destination Unreachable. And that _only_ when DYMO > >>>>>> runs on the machine. This is too complex IMHO. > >>>>> > >>>>> RERR messages are disseminated in a controlled manner to > >>>>> remove routes that are no longer available/accurate. An > >>>>> generic ICMP Destination Unreachable message would not be > >>>>> capable of performing this operation. > >>>> > >>>> Would a generic ICMP Redirect achieve the same effect you look > >>>> for? (add a route that overcomes an existing route that is no > >>>> longer accurate). > >>> > >>> ICMP redirect would not convey the same information as a RERR, > >>> nor would it be distributed appropriately. > >> > >> We somehow turn and turn. > >> > >> Indeed RERR conveys information more similar to ICMP Dst > >> Unreachable (it contains the address that is unreachable). > > > > Here is a short list of some of RERRs features. > > > > The RERR is disseminated in a limited flood. RERR may contain the > > addresses of many now unreachable devices. RERR can be generated > > on-demand, instead of waiting for data traffic to flow. > > I always thought 'on-demand' means data traffic flows demands > construction of a route :-) In reactive/on-demand routing protocols, nodes do no know the routes to all other nodes beforehand. They have to find routes on demand. Using this logic, it is difficult to determine absolutely whether a node is reachable or unreachable. > > RERR contain the sequence number related to the addresses for which a > > route is not available. > > Ok, I'll have to check that. > > >>>>> Can you please talk more as to why you think RERR messaging > >>>>> or processing is too complex? Or how we might improve RERR > >>>>> operation? > >>>> > >>>> I meant it is complex to implement the logic whereby one > >>>> forbids the generation of ICMP Destination Unreachable. > >>>> Presumably, that's what you want to do on a router: if it runs > >>>> DYMO and sends RERR then it must not send ICMP Destination > >>>> Unreachable, right? > >>> > >>> ICMP Destination Unreachable messages are for the sources of > >>> packets, not the routers in between. > >> > >> Yes. ICMP Redirect is for routers in between. > >> > >> But, do you mean that RERR and ICMP Destination Unreachable can > >> work simultaneously ok? > > > > I don't see any reason why they couldn't work together, but as I > > mention I wouldn't suggest it. > > So one has to _disable_ ICMP DstUnreachable generation code, right? > That's built-in into the stack. This is an implementation issue. I myself cannot say how/when ICMP destination unreachable messages are generated. Though as I mentioned above, making the judgement that an ICMP dst unreachable should be issued might be weird in networks running reactive routing protocols. > >>> In the AODV/DYMO implementations I've seen, ICMP Destination > >>> Unreachable messages are issued by the source if it cannot find a > >>> route. > >> > >> Well, I think that is wrong. The Dst Unreachable is usually > >> generated by the last router in the path to the destination that > >> has no route to that destination (and not by the source). The > >> local source host will not generate a Dst Unreachable because it is > >> supposed to have at least a default route. > > > > The question here is about "having no route". In reactive protocols, > > just be cause you don't have a route at this moment, does not mean > > you can't find a route. > > > > > >>> I believe this is the chosen proceedure to discourage a sources > >>> application from believing that no route is available, since it > >>> is likely that the route is only temporarily broken or > >>> unavailable and will soon be repaired. > >> > >> I think better than that can be achieved by always offering a > >> default route to the host. > >> > >> But here again we assume different models for the networks. You > >> assume that the application is run on the router that does the > >> route discovery as well. I assume the application is run on a host > >> that has no routing capabilities, and always has at least a > >> default route. I will send a separate message about this, later. > > > > We do not assume that the application is run on the router. A MANET > > router can/will perform route discovery on behalf of its attached > > hosts. > > For my clarification, will a MANET router act as a default router for > its attached hosts? Or will it try to provide host-based routes to > install in the host's routing table for every correspondent this host > talks to? This is very important to the MANEMO analysis, thanks. A MANET router will act like a router for its attached nodes. In a simple scenario where we have a router with attached hosts, the hosts can be configure the router as their default router. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 06:29:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfvns-0005cu-6x; Mon, 23 Apr 2007 06:29:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfvnq-0005cb-OM for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 06:29:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfvnq-0005cR-EW for manet@ietf.org; Mon, 23 Apr 2007 06:29:50 -0400 Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfvnp-0002Vm-6W for manet@ietf.org; Mon, 23 Apr 2007 06:29:50 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1794919wxd for ; Mon, 23 Apr 2007 03:29:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QuXbC5yKLFpT8mi4zK4PHY7UAAJUWHJBuoGMf1CcY9BD4Qdlc5W2WxPIzeQW1FlTSZqJJJHWDvI90FAm/bT2PcpUIf9sxmbCN8dVLCt9876Wyz/d9yPYFtLaXEwxyFJtqIx5KU0OvuwUqLUtKfNwiVajy+QALNbBYyK4UA4dfkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aIazMeRsZ1Rw75NphbN5Gk68S1BrWevZr7xWz+XES8mJdWTPo3JuOCIKMFMHfp0OLc06uGZE+rZglVY6dex/pM2Y9lNFwroYY7rx6JuZEQnegcImxk5ecosaRMsc4NuLtm9aTswI1vvgi4wTL5JBYBsb21aqqZnJwL4mYTqMtWA= Received: by 10.78.120.6 with SMTP id s6mr330274huc.1177324188169; Mon, 23 Apr 2007 03:29:48 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Mon, 23 Apr 2007 03:29:48 -0700 (PDT) Message-ID: <374005f30704230329y4bb342ap6b167cf5cefd58cc@mail.gmail.com> Date: Mon, 23 Apr 2007 15:59:48 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Dymo route discovery In-Reply-To: <462C7D4B.8000402@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704200623l74d2f12fpe0aea17cd4bc10f4@mail.gmail.com> <4628D829.80900@gmail.com> <374005f30704220349q394413c4l9794205d95a1e0b2@mail.gmail.com> <462BD0BC.7040100@gmail.com> <462C2D98.1070107@nokia.com> <462C7D4B.8000402@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 4/23/07, Alexandru Petrescu wrote: > Charles E. Perkins wrote: > > > > Hello Alex, > > > > I am pretty sure RERR is better, because it can invalidate > > many broken routes. An ICMP message would pretty much > > be restricted to invalidating only one. The ICMP message > > would have to be unicast to the source (and, actually, to the > > particular application on the source). The RERR message > > is a hop-by-hop broadcast and can do a lot better. > > > > Does this make sense? > > Makes sense. For IPv6, distributing RERR seems to happen in multicast > mode, ie to a multicast address. In IPv4 & IPv6 RERR messages are sent to a link local multicast address (LL MANET routers). Upon receipt of a RERR message a DYMO router might generate another RERR message to inform its LL MANET routers. > > ext Alexandru Petrescu wrote: > >>> > >>> I would recommend that an ICMP destination unreachable not issued, > >>> but I would not require it. Please see my other email on this > >>> subject. > >> > >> I think this sounds like a recommendation on the use of ICMP Destination > >> Unreachable. This recommendation should be discussed in my oppinion. > >> Currently the draft only talks about a local Dst Unreachable delivered > >> to the application. I think what you want is to make sure that no > >> router in a network running DYMO sends a ICMP Dst Unreachable, because > >> its information may be contradicting the information in RERR. > > > > I am not sure when the ICMP data would contradict the RERR > > message data -- except unless the RERR triggered a route repair > > without disturbing the application. Is that what you meant? > > I mean it is useless to have both ICMP Dst Unreachable and RERR do the > same thing. You seem to challenge the fact that their contents would be > contradicting each other - probably they won't - but still, one wouldn't > want both Dst Unreachable and RERR to be issued for deleting the same > route, because for sure one will not find that particular route to delete. As far as I know, reception of an ICMP Dst Unreachable does not cause any modification to the routing/forwarding table in nodes. A RERR very clearly has an impact on the DYMO routing protocol and the routing/forwarding tables maintained. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 06:43:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfw1Q-0007yJ-Et; Mon, 23 Apr 2007 06:43:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfw1O-0007yE-FH for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 06:43:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfw1O-0007y6-5X for manet@ietf.org; Mon, 23 Apr 2007 06:43:50 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfw1M-000544-RY for manet@ietf.org; Mon, 23 Apr 2007 06:43:50 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l3NAhmhu008160 for ; Mon, 23 Apr 2007 11:43:48 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l3NAhlCM030701 for ; Mon, 23 Apr 2007 11:43:47 +0100 Received: from glkms0002.GREENLNK.NET ([10.15.184.2]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 23 Apr 2007 11:43:47 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0002.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Apr 2007 11:43:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Date: Mon, 23 Apr 2007 11:43:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Thread-Index: AceE569RpTLCeYn6QQ+gW0W8lFwUIwAAgfpgACT26OAABZEGMAAABLpg From: "Dearlove, Christopher \(UK\)" To: "manet" X-OriginalArrivalTime: 23 Apr 2007 10:43:47.0215 (UTC) FILETIME=[459141F0:01C78594] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc751b94b9e719c152b6b70b67620ccf X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org No, CFPs are not an important part of all mailing lists. Take for example the first other IETF mailing list I thought I'd check, OSPF, whose archive is at http://www1.ietf.org/mail-archive/web/ospf/current/index.html I only bothered looking back to the beginning of 2007. Not a single CFP in the archive, which is as it should be. -----Original Message----- From: Amoakoh Gyasi-Agyei [mailto:a.gyasi-agyei@cqu.edu.au]=20 Sent: 23 April 2007 11:34 To: Dearlove, Christopher (UK) Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley,USA) Deadline: June 1 Hi There, Please note that CFP is an important part of all emailing lists. There're much worse junk mails around than CFPs. Aren't it, sir? Hence, if power is in your hands please support the idea. Thanks =20 -----Original Message----- From: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com]=20 Sent: Monday, April 23, 2007 6:07 PM To: Bound, Jim; manet Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley,USA) Deadline: June 1 Unfortunately the majority of traffic on this list is either this sort of thing, or various student requests for help with protocols and simulators, that are both off-topic. In fact the current number of on-topic postings is what's exceptional (though welcome of course). The only way (short of closing down the WG) that I could see to stop it would be labour intensive (monitoring list, removing postings, and blacklisting posters) and I for one am not going to volunteer for. -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: 22 April 2007 15:24 To: wiiat@kis-lab.com; manet Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley,USA) Deadline: June 1 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Folks, is it appropriate to post call for paper on an IETF WG list. I don't think so this is a working group. thanks /jim=20 > -----Original Message----- > From: Jia Hu [mailto:wiiat@kis-lab.com] > Sent: Sunday, April 22, 2007 10:08 AM > To: manet > Subject: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon > Valley,USA) Deadline: June 1 >=20 > [Apologies if you receive this more than once] >=20 > ##################################################################### > IEEE/WIC/ACM WEB INTELLIGENCE 2007 > CALL FOR PAPERS > ##################################################################### >=20 > 2007 IEEE/WIC/ACM International Conference on Web Intelligence (WI'07) >=20 > Silicon Valley, USA, November 2-5, 2007 > Official: http://www.cs.sjsu.edu/wi07/wi/ > Mirror: http://www.maebashi-it.org/wi07/wi/ > (to be collocated with IAT'07, BIBM'07 and GrC'07) >=20 > Sponsored By > IEEE Computer Society > Web Intelligence Consortium (WIC) > Association for Computing Machinery (ACM) >=20 > ###################################################################### > # Conference Chair > # Andrei Broder, VP, Yahoo Fellow, Yahoo! Research > # > # Program Chair and Co-Chairs=09 > # T.Y. Lin, Professor, SJSU, BISC Fellow, UC-Berkeley > # Laura Haas, Director, IBM Almaden Research Center > # Janusz Kacprzyk, Professor, Polish Academy of Science > # Rajeev Motwani, Professor, Stanford University > # > # Organizing Chair=09 > # Howard Ho, Manager, IBM Almaden Research Center=20 > # > # WI-IAT Joint Keynote Speakers (Tentative) # # Vinton G.=20 > Cerf, Turing Award Winner,=20 > # VP and Chief Internet Evangelist, Google=20 > # Anant Jhingran, VP and CTO, IBM Silicon Valley Laboratory # # (More=20 > WI Invited Speakers will be announced) # # (Papers > Due: ** June 1 **, 2007) # Accepted papers will be published in the=20 > conference proceedings # by the IEEE Computer Society Press, which are > indexed by EI. > ###################################################################### >=20 > Web Intelligence (WI) has been recognized as a new direction for=20 > scientific research and development to explore the fundamental roles=20 > as well as practical impacts of Artificial Intelligence (AI) (e.g.,=20 > knowledge representation, planning, knowledge discovery and data=20 > mining, intelligent agents, and social network intelligence) and=20 > advanced Information Technology (IT) (e.g., wireless networks,=20 > ubiquitous devices, social networks, and data/knowledge grids) on the=20 > next generation of Web-empowered products, systems, services, and=20 > activities. It is one of the most important as well as promising IT=20 > research fields in the era of Web and agent intelligence. >=20 > The 2007 IEEE/WIC/ACM International Conference on Web Intelligence > (WI'07) will be jointly held with the 2007 IEEE/WIC/ACM International=20 > Conference on Intelligent Agent Technology (IAT'07), the 2007 IEEE=20 > International Conference on Bioinformatics and Biomedicine (BIBM'07),=20 > and the 2007 IEEE International Conference on Granular Computing > (GrC'07) for providing synergism among the four research areas. It=20 > will provide opportunities for technical collaboration beyond that of=20 > previous conferences. The four conferences will have a joint opening,=20 > keynote, reception, and banquet. Attendees only need to register for=20 > one conference and can attend workshops, sessions and tutorials across > the four conferences. We are also planning a joint panel and joint=20 > paper sessions that discuss common problems in the four areas. >=20 > +++++++++++ > Highlights > +++++++++++ >=20 > The conference will be held in Silicon Valley, California.=20 > Many high-tech companies and three distinguished universities=20 > (Stanford, UC Berkely and UCSC) are just around the corner. > The highlight of the conference is that a unique forum consisting of a > half-day industry/ demo track and free discussion will be organized to > link industries and academics. Leading IT companies like IBM, Google,=20 > and Yahoo etc will present at the conference. >=20 > The area now known as Silicon Valley has been a center of=20 > technological development since the 1950's. The name Silicon Valley=20 > stems from the early 1970's, when the area had become the center for=20 > many semiconductor companies. While still hosting semiconductor and=20 > microprocessor companies, the region now hosts the headquarters of=20 > high tech companies of every kind, including many of the best known=20 > and most prestigious names in personal computers, Web search, Internet > auctions, networking, storage, databases, etc. >=20 > +++++++++++++++++++ > Topics of Interest > +++++++++++++++++++ >=20 > The topics and areas include, but not limited to: >=20 > * WI Foundations > - Brain Informatics for WI > - Human level WI > - New cognitive models and computational models for WI > - Granular Computing (GrC) for WI > - Autonomy-Oriented Computing (AOC) for WI >=20 > * World Wide Wisdom Web (W4) > - Meta-Knowledge Discovery and Representation > - Problem Solver Markup Language (PSML) > - Search of Best Means and Ends > - Goal-Directed Services Support > - Distributed Resources Optimization > - Service Self-Aggregation > - Web Inference Engine > - Information and Knowledge Markets > - New Social Interaction Paradigms > - Social and Psychological Contexts > - Regularities and Laws of W4 >=20 > * Social Networks and Social Intelligence > - Social Network Mining > - Web Site Clustering > - Link Topology and Site Hierarchy > - Theories of Small-World Web > - Virtual and Web Communities > - Web-Based Cooperative Work > - Knowledge Community Formation and Support > - Ubiquitous Computing > - Intelligent Wireless Web > - Ubiquitous Learning Systems > - Entertainment >=20 > * Knowledge Grids and Grid Intelligence > - Semantic Grids > - Knowledge Resources and Services Discovery > - On-Demand Planning and Routing > - Brokering and Scheduling > - Middleware Architectures and Tools >=20 > * Web Mining and Farming > - Text Mining > - Data Stream Mining > - Multimedia Data Mining > - Web Content Mining > - Web Log and Usage Mining > - Learning User Profiles > - Context Sensitive Web Mining > - Web Information Clustering > - Web Page Clustering and Mining > - E-Mail Classification > - Web Site Classification > - Web Information Indexing > - Data Warehousing > - Web Farming and Warehousing >=20 > * Semantics and Ontology Engineering > - Ontology-Based Information Extraction and Retrieval > - Ontology-Based Web Mining > - Web-Based Ontology Learning > - Semantic Web >=20 > * Web Agents > - Global Information Foraging > - Distributed Problem Solving > - Coordination > - Resource Intermediary and Coordination Mechanisms > - Self-Organization and Reproduction > - Agent Networks and Topologies > - Mobile Agents > - Macroscopic Behavior Modeling > - Trust Models for Web Agents >=20 > * Web Services > - Service-Oriented Computing > - Matchmaking > - Web Service Reconfiguration > - Web Service Workflow Composition > - Middleware-Based Ubiquitous Services > - Grid Services >=20 > * Web Information Filtering and Retrieval > - Automatic Cataloging and Indexing > - Clustering-Based Recommender Systems > - Collaborative Filtering and Recommendation > - Hybrid Recommendation > - Information Retrieval Criteria and Evaluations > - Web Information Categorization and Ranking > - Proxy and Cache Techniques > - Web Prediction and Prefetching > - Distributed Web Search > - Specifications for Web Information Extraction Process > - Web Crawling Systems > - Search Engines and Meta-search Engines >=20 > * Intelligent Human-Web Interaction > - Adaptive Web Interfaces > - Context-Aware Computing > - Learning User Profiles > - Personalized Interfaces > - Personalized Web Sites > - Remembrance Agents > - Multimedia Representation > - Visualization of Information and Knowledge > - Social and Psychological Issues >=20 > * Web Support Systems > - Information Retrieval Support Systems > - Web Site Navigation Support Systems > - Recommender Support Systems > - Web-Based Decision Support Systems > - Soft Computing (including neural networks, fuzzy logic, > evolutionary computation, rough sets, and granular computing) > and Uncertainty Management for WI >=20 > * Intelligent e-Technology > - Business Intelligence > - Digital Library > - Decentralized Community Communication Techniques > - e-Community > - e-Business and e-Commerce > - e-Finance > - e-Government > - e-Learning > - e-Publishing > - e-Science > - Intelligent Enterprise Portals > - Web-Based Direct Marketing and CRM > - Web-Based EDI > - Web Security, Integrity, Privacy and Trust >=20 > ++++++++++++++++++++++++++++++++++++ > On-Line Submissions and Publication > ++++++++++++++++++++++++++++++++++++ >=20 > High-quality papers in all WI related areas are solicited.=20 > Paper submissions should be limited to a maximum of 7 pages in the=20 > IEEE 2-column format, the same as the camera-ready format (see the=20 > Author Guidelines of last year at=20 > http://www.computer.org/portal/pages/cscps/cps/final/wi06.xml). > All submitted papers will be reviewed by the Program Committee on the=20 > basis of technical quality, relevance, significance, and clarity. >=20 > Note that WI'07 will accept ONLY on-line submissions, containing PDF=20 > versions. Please use the Submission Form on the WI'07 website to=20 > submit your paper. Accepted papers will be published in the conference > proceedings by the IEEE Computer Society Press that are indexed by EI. >=20 > Submissions accepted as regular papers will be allocated 7 pages in=20 > the proceedings and accorded oral presentation times in the main=20 > conference. > Submissions accepted as short papers will be allocated 4 pages in the=20 > proceedings and will have a shorter presentation time at the=20 > conference than regular papers. >=20 > All co-authors will be notified at all time, for the submission,=20 > notification, and confirmation on the attendance. > Submitting a paper to the conference and workshops means that, if the=20 > paper is accepted, at least one author should attend the conference to > present the paper. The acceptance list and no-show list will be openly > published on-line. For no-show authors, their affiliations will=20 > receive a notification. >=20 > A selected number of WI'07 accepted papers will be expanded and=20 > revised for inclusion in Web Intelligence and Agent > Systems: An International Journal > (http://wi-consortium.org/journal.html) and in Annual Review of=20 > Intelligent Informatics (http://www.wi-consortium.org/annual.html). >=20 > More detailed instructions and the On-Line Submission Form can be=20 > found from the WI'07 homepage: http://www.cs.sjsu.edu/wi07/wi/. >=20 > ++++++++++++++++++++++++ > WI'07 Best Paper Awards > ++++++++++++++++++++++++ >=20 > The best paper awards will be conferred at the conference on the=20 > authors of (1) the best research paper and (2) the best application=20 > paper. Application-oriented submissions will be considered for the=20 > best application paper award. >=20 > The full author list and paper title will be announced on the Web=20 > Intelligence Consortium homepage: > http://wi-consortium.org/html/wicawards.html >=20 > ++++++++++++++++++++ > Industry/Demo-Track > ++++++++++++++++++++ >=20 > We solicit Industry/Demo-Track papers by the following methods. >=20 > (1) Industry papers of 4 pages can be submitted on the same schedule=20 > as > the research track. > (2) Separate 2 page demo proposals can submitted at a later schedule. > (3) Full regular paper submissions can include a demo option. > That is, a full paper submissions will be asked to > specify if they would like to give a demonstration; choice of > demonstrations (while utilizing information from the regular=20 > reviewing > process) will be selected based on value as a demonstration. >=20 > For options (1) and (2), please find more detailed instructions at the > homepage: http://www.cs.sjsu.edu/wi07/wi/ >=20 > We are planning to arrange the Industry/Demo track in the afternoon of > November 3 (before and during the conference reception), jointly with=20 > the IAT'07 Demo sessions. Leading IT companies in Silicon Valley will=20 > be invited to attend this track. >=20 > ++++++++++ > Workshops > ++++++++++ >=20 > As an important part of the conference, the workshop program will=20 > focus on new research challenges and initiatives. All papers accepted > for workshops will be included in the Workshop Proceedings published=20 > by the IEEE Computer Society Press that are indexed by EI, and will be > available at the workshops. Detailed information is available at the=20 > conference homepage. >=20 > Note: we will not have a separate workshop registration fee (i.e.,=20 > conference registration covers everything). >=20 > ------------------ > WI 2007 Workshops: > ------------------ > Title: Educating the Web-Generation > Organisers: Elisabeth Heinemann > Email: elisabeth.heinemann@googlemail.com > Web page: http://www.effactory.com/Edu4WebGen/ >=20 > Title: Collective Intelligence on Semantic Web > Organisers: Geun Sik Jo; Jason J. Jung; Ngoc Thanh Nguyen > Email: gsjo@inha.ac.kr; j2jung@intelligent.pe.kr; thanh@pwr.wroc.pl=20 > Web page: > http://intelligent.pe.kr/CISW07/ >=20 > Title: New Computing Paradigms for Web Intelligence and Brain=20 > Informatics > Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter Fensel > Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: >=20 > Title: Web Personalization and Recommender Systems > Organisers: Yue Xu > Email: yue.xu@qut.edu.au > Web page: http://www.wprs07.fit.qut.edu.au/ >=20 > Title: Service Composition > Organisers: M. Brian Blake; Dumitru Roman; Charles Petrie > Email: blakeb@cs.georgetown.edu; dumitru.roman@deri.org Web > site: http://events.deri.at/sercomp2007/ >=20 > Title: Biomedicine applications of Web technologies > Organisers: Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu > Email: chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw;=20 > whlu@mail.ncku.edu.tw Web page: > http://chunnan.iis.sinica.edu.tw/BMWT2007.html >=20 > Title: Intelligent Web Interaction Workshop 2007 1st > Organiser: Prof. Seiji YAMADA > Email: seiji@nii.ac.jp > Web site: http://ymd.ex.nii.ac.jp/ws/iwi/07/ >=20 > Title: Cyberinfrastucture for e-Science > Organisers: Prof. Vasant Honavar; A/prof. Kei Cheung > Email: honavar@cs.iastate.edu; kei.cheung@yale.edu Web page:=20 > http://www.cild.iastate.edu/events/CyIneS2007/ >=20 > Title: 2007 International Workshop on Social Media Analysis > Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu > Email: sma@comp.hkbu.edu.hk > Web page: http://www.comp.hkbu.edu.hk/~sma/ >=20 > Title: Web Security, Integrity, Privacy and Trust > Organisers: Dr. Yiuming Cheung, Prof. Michael Chau, and Prof.=20 > Yong Zhang > Email: ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk;=20 > zhangyong076@gmail.com Web page: >=20 > ------------------- > IAT 2007 Workshops: > ------------------- > Title: Second International Workshop on Communication between Human=20 > and Artificial Agents (CHAA-07) > Organisers: Christel Kemke > Email: ckemke@cs.umanitoba.ca > Web page: http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ >=20 > Title: Rational, Robust, and Secure Negotiations in Multi-Agent=20 > Systems (RRS2007) > Organisers: Takayuki Ito > Email: ito.takayuki@nitech.ac.jp > Web page: http://www-itolab.mta.nitech.ac.jp/RRS2007/ >=20 > Title: P2P Computing and Autonomous Agents > Organisers: Tarek Helmy, Khaled Ragab > Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa Web Page:=20 > http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html >=20 > Title: Multiagent systems in E-business: concepts, technologies and=20 > applications > Organisers: Costin Badica; Maria Ganzha; Marcin Paprzycki > Email: badica_costin@software.ucv.ro; ganzha@euh-e.edu.pl;=20 > marcin.parzycki@swps.edu.pl Web page: > http://software.ucv.ro/~badica_costin/maseb2007/ >=20 > Title: Agent & Data Mining Interaction > Organisers: Pericles A. Mitkas, Longbing Cao, Vladimir Gorodetsky,=20 > Justin Zhan > Email: mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page:=20 > http://issel.ee.auth.gr/ADMI >=20 > For more information, please visit the conference website at=20 > http://www.cs.sjsu.edu/wi07/wi/?index=3Dworkshop. >=20 > ++++++++++ > Tutorials > ++++++++++ >=20 > WI'07 also welcomes Tutorial proposals. WI'07 will include tutorials=20 > providing in-depth background on subjects that are of broad interest=20 > to the Web intelligence community. Both short (2 hours) and long (half > day) tutorials will be considered. The tutorials will be part of the=20 > main conference technical program. Detailed information is available=20 > at the conference homepage. >=20 > Note: we will not have a separate tutorials registration fee (i.e.,=20 > only one conference registration covers everything). >=20 > ++++++++++++++++ > Important Dates > ++++++++++++++++ >=20 > Workshop proposal submission: March 20, 2007 > Electronic submission of full papers: ** June 1, 2007 ** > Tutorial proposal submission: June 15, 2007 > Notification of paper acceptance: July 22, 2007 > Camera-ready copies of accepted papers: August 17, 2007 > Conference: November 2-5, 2007 >=20 > ++++++++++++++++++++++++ > Conference Organization > ++++++++++++++++++++++++ >=20 > Conference Chair: > * Andrei Broder, Yahoo! Research, USA >=20 > Program Chair: > * Tsau Young (T.Y.) Lin, San Jose State University/UC Berkeley, USA >=20 > WI Program Co-Chairs: > * Laura Haas, IBM Almaden Research Center, USA > * Janusz Kacprzyk, Polish Academy of Science, Poland > * Rajeev Motwani, Stanford University, USA >=20 > IAT Program Co-Chairs: > * Jeffrey M. Bradshaw, UWF/Institute for Human and Machine=20 > Cognition, USA > * Matthias Klusch, German Research Center for AI, Germany > * Chengqi Zhang, University of Technology, Sydney, Australia >=20 > Organizing Chair: > * Howard Ho, IBM Almaden Research Center, USA >=20 > Workshop Co-Chairs: > * Vijay Raghavan, University of Louisiana, USA > * Yuefeng Li, Queensland University of Technology, Australia >=20 > Tutorial Chair: > * Pawan Lingras, Saint Mary's University, Canada >=20 > Industry/Demo-Track Chair: > * Jianchang Mao, Yahoo! Inc., USA >=20 > Local Accommodations Co-Chairs: > * David Scot Taylor, San Jose State University, USA > * Tom Qi Zhang, Google, USA >=20 > Publicity Chair:=20 > * James Wang, Clemson University, USA (chair) Publicity Co-Chairs:=20 > * Martine De Cock, Ghent University, Belgium > * Jia Hu, International WIC Institute, China > * Debajyoti Mukhopadhyay, West Bengal University of Technology,=20 > India >=20 > IEEE-CS-TCII Chair: > * Ning Zhong, Maebashi Institute of Technology, Japan >=20 > ACM-SIGART Chair > * Maria Gini, University of Minnesota, USA >=20 > WIC Co-Chairs/Directors: > * Ning Zhong, Maebashi Institute of Technology, Japan > * Jiming Liu, University of Windsor, Canada >=20 > WIC Advisory Board:=20 > * Edward A. Feigenbaum, Stanford University, USA > * Setsuo Ohsuga, Waseda University, Japan > * Benjamin Wah, University of Illinois, Urbana-Champaign, USA > * Philip Yu, IBM Thomas J. Watson Research Center, USA > * L.A. Zadeh, University of California Berkeley, USA >=20 > WIC Tech. Committee & WI/IAT Steering Committee: > * Jeffrey Bradshaw, UWF/Institute for Human and Machine Cognition,=20 > USA > * Nick Cercone, Dalhousie University, Canada > * Dieter Fensel, National University of Ireland, Ireland > * Georg Gottlob, Oxford University, UK > * Lakhmi Jain, University of South Australia, Australia > * Jianchang Mao, Yahoo! Inc., USA > * Pierre Morizet-Mahoudeaux, Compiegne University of Technology,=20 > France > * Hiroshi Motoda, Osaka University, Japan > * Toyoaki Nishida, Kyoto University, Japan > * Andrzej Skowron, Warsaw University, Poland > * Jinglong Wu, Kagawa University, Japan > * Xindong Wu, University of Vermont, USA > * Yiyu Yao, University of Regina, Canada >=20 > Webmaster: > * Albert Sutojo, San Jose State University, USA >=20 > Abbreviation:=20 > WI 2007, WI2007, WI'2007, WI'07, WI07, WI 07, WI-07, WI-2007, WI-IAT=20 > 2007, WI-IAT2007, WI-IAT'2007, WI-IAT'07, WI-IAT07, WI-IAT 07,=20 > WI-IAT-2007, WI-IAT-07, WI/IAT 2007, WI/IAT2007, WI/IAT'2007,=20 > WI/IAT'07, WI/IAT07, WI/IAT 07, WI/IAT-2007, WI/IAT-07 >=20 > *** Contact Information *** >=20 > Jia Hu > International WIC Institute, China > E-mail: hujia@kis-lab.com >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 07:54:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfx7S-00043L-6W; Mon, 23 Apr 2007 07:54:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfx7Q-0003zG-3l for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 07:54:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfx7P-0003yT-Gc for manet@ietf.org; Mon, 23 Apr 2007 07:54:07 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfx7N-0004mg-46 for manet@ietf.org; Mon, 23 Apr 2007 07:54:07 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-128.messagelabs.com!1177329243!13239102!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19348 invoked from network); 23 Apr 2007 11:54:04 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-14.tower-128.messagelabs.com with SMTP; 23 Apr 2007 11:54:04 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3NBs3nf021336; Mon, 23 Apr 2007 04:54:03 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l3NBs3Dq008249; Mon, 23 Apr 2007 06:54:03 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l3NBs1g0008193; Mon, 23 Apr 2007 06:54:01 -0500 (CDT) Message-ID: <462C9E53.9020704@gmail.com> Date: Mon, 23 Apr 2007 13:53:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] Dymo route discovery References: <462892FD.3060701@gmail.com> <4628A81F.90401@gmail.com> <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> <4628CC1F.1060106@gmail.com> <374005f30704220346o7ea375c8k270ee87c51844431@mail.gmail.com> <462BCFB5.7070305@gmail.com> <374005f30704222105q7c65f4dch49b4628105958adf@mail.gmail.com> <462C7EA6.8080201@gmail.com> <374005f30704230322u48c24d35p4ad793f36f44eb0@mail.gmail.com> In-Reply-To: <374005f30704230322u48c24d35p4ad793f36f44eb0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres wrote: [...] >>> I don't see any reason why they couldn't work together, but as I >>> mention I wouldn't suggest it. >> >> So one has to _disable_ ICMP DstUnreachable generation code, right? >> That's built-in into the stack. > > This is an implementation issue. I myself cannot say how/when ICMP > destination unreachable messages are generated. I can say when they're generated: when a packet travelling to a destination hits a router having no route to that destination, and no default route. Any router will generate such an ICMP DstUnreachable. Do you agree? > Though as I mentioned above, making the judgement that an ICMP dst > unreachable should be issued might be weird in networks running > reactive routing protocols. I think we diverge here. ICMP DestUnreachable is specified and implemented and most if not all routers do implement it. But I agree it would be weird for a network using RERR messages to also issue ICMP DstUnreachable. Should this be clarified in the DYMO draft? Should the DYMO draft say that when DYMO is run then ICMP DstUnreachable should not be issued by any router in the MANET? I think yes. [...] >> For my clarification, will a MANET router act as a default router >> for its attached hosts? Or will it try to provide host-based >> routes to install in the host's routing table for every >> correspondent this host talks to? This is very important to the >> MANEMO analysis, thanks. > > A MANET router will act like a router for its attached nodes. In a > simple scenario where we have a router with attached hosts, the hosts > can be configure the router as their default router. Ok, this is a common behaviour with NEMO moving networks, where LFNs (Local Fixed Nodes) often can auto-configure a default route to the Mobile Router, with stateless address auto-configuration. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 10:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfzds-0005ey-FI; Mon, 23 Apr 2007 10:35:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfzdo-0005cH-7X for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 10:35:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfzdn-0005bg-PD for manet@ietf.org; Mon, 23 Apr 2007 10:35:43 -0400 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfzdm-0001HK-AK for manet@ietf.org; Mon, 23 Apr 2007 10:35:43 -0400 Received: by nz-out-0506.google.com with SMTP id z6so1414967nzd for ; Mon, 23 Apr 2007 07:35:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ZsG8BDBMEUG/jyFwZvondhxXa3ab2/vE2uI/CcTkz1JlH4PplENO4ar5wAeUAajYsVX9gGaRy9VSHBqwrWbnmtytmwo8eT0iSyGxrF5Cu9LJebop8GZbiVwlEhqxKfTComzJ0TOWO1okKsfB/T2khUUGQE0g8Esvy3gQMPEqeIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=GvXxhdWk2Am9E9DMp1tIMedbbJDXE0pylZAFfnbLIq2MaKqJ16aPY930slrakro9rKT5TVFCiCjcdxOAPLZE+M8SH+x6AOvaY2jViAm/Y0p7mfNIl3lm6q3r6iS4RKCZKJf1JO5rcMPk1unx/12A599ZxZPSTlbHUDm/uYmIK6Y= Received: by 10.115.79.1 with SMTP id g1mr966170wal.1177338941463; Mon, 23 Apr 2007 07:35:41 -0700 (PDT) Received: by 10.114.95.3 with HTTP; Mon, 23 Apr 2007 07:35:41 -0700 (PDT) Message-ID: <6ae06b9f0704230735h7a7d1255n948d607731c9048e@mail.gmail.com> Date: Mon, 23 Apr 2007 20:05:41 +0530 From: "Narendran Sivakumar" To: "Ian Chakeres" , manet@ietf.org Subject: Re: [manet] Re : Energy Efficiency in Routing Protocols In-Reply-To: <374005f30704230304p82c10cq5b09bac0ebbfbfd6@mail.gmail.com> MIME-Version: 1.0 References: <6ae06b9f0704230020h6b2feffm19581eae0e6af1fd@mail.gmail.com> <374005f30704230304p82c10cq5b09bac0ebbfbfd6@mail.gmail.com> X-Spam-Score: 1.0 (+) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0400553149==" Errors-To: manet-bounces@ietf.org --===============0400553149== Content-Type: multipart/alternative; boundary="----=_Part_58357_17451697.1177338941412" ------=_Part_58357_17451697.1177338941412 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Ian, Well , In a wireless environment the energy levels used while transmission is also important as higher the transmission power, higher is the range for the nodes to transmit. Is it possible to add an Intelligence Mechanism to DYMO which would use energy levels automatically based on the topology. For Example : If a node X is transmitting to Y with I and J are the intermediate nodes and the path is X-I-J-Y.If Y moves out of range of J, X would again initiate Route Discovery to Y. If an intelligence mechanism is used to increase the transmission power of J so that Y is within range even if Y changes the location thereby saving time for another Route Discovery process and less delay. On the flip side if Y is well within range of J, then that same mechanism should be able to adjust the transmission power in accordance with the closer Y, thereby saving energy. I believe that in a wireless environment , energy efficiency holds the key in determining the effectiveness of an Routing Protocol, further more to DYMO Thanks Naren On 4/23/07, Ian Chakeres wrote: > > I think it will be difficult to analyze energy efficiency. I also > think there are also lots of little tweaks that you could do to > improve efficiency, depending on your measure of course. > > Ian > > > On 4/23/07, Narendran Sivakumar wrote: > > Dear All , > > > > I've implemented DYMO and comparing the performance of DYMO with other > > protocols. Is there a way to analyze how energy efficient these > protocols > > especially DYMO as i consider energy efficiency a big factor. > > > > Any suggestions and ideas relating to this subject are most welcome. > > > > Thank You > > > > Naren > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > ------=_Part_58357_17451697.1177338941412 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Ian,
 
Well , In a wireless environment the energy levels used while transmission is also important as higher the transmission power, higher is the range for the nodes to transmit.
 
Is it possible to add an Intelligence Mechanism to DYMO which would use energy levels automatically based on the topology.
For Example : If a node X is transmitting to Y with I and J are the intermediate nodes and the path is X-I-J-Y.If Y moves out of range of J, X would again initiate Route Discovery to Y. If an intelligence mechanism is used to increase the transmission power of J so that Y is within range even if Y changes the location thereby saving time for another Route Discovery process and less delay. On the flip side if Y is well within range of J, then that same mechanism should be able to adjust the transmission power in accordance with the closer Y, thereby saving energy.
 
I believe that in a wireless environment , energy efficiency holds the key in determining the effectiveness of an Routing Protocol, further more to DYMO
 
Thanks
 
Naren

 
On 4/23/07, Ian Chakeres <ian.chakeres@gmail.com> wrote:
I think it will be difficult to analyze energy efficiency. I also
think there are also lots of little tweaks that you could do to
improve efficiency, depending on your measure of course.

Ian


On 4/23/07, Narendran Sivakumar <snarendran86@gmail.com> wrote:
>  Dear All ,
>
> I've implemented DYMO and comparing the performance of DYMO with other
> protocols. Is there a way to analyze how energy efficient these protocols
> especially DYMO as i consider energy efficiency a big factor.
>
> Any suggestions and ideas relating to this subject are most welcome.
>
> Thank You
>
> Naren
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
>
>

------=_Part_58357_17451697.1177338941412-- --===============0400553149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0400553149==-- From manet-bounces@ietf.org Mon Apr 23 10:39:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfzh0-0001pY-Eg; Mon, 23 Apr 2007 10:39:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfzgy-0001pK-OP for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 10:39:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfzgy-0001pC-En for manet@ietf.org; Mon, 23 Apr 2007 10:39:00 -0400 Received: from bay0-omc3-s38.bay0.hotmail.com ([65.54.246.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfzgx-0002TN-42 for manet@ietf.org; Mon, 23 Apr 2007 10:39:00 -0400 Received: from BAY108-W18 ([65.54.162.118]) by bay0-omc3-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 23 Apr 2007 07:38:58 -0700 Message-ID: X-Originating-IP: [193.49.124.107] From: mohammad diab To: Date: Mon, 23 Apr 2007 14:38:58 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2007 14:38:58.0715 (UTC) FILETIME=[20AD46B0:01C785B5] X-Spam-Score: 2.2 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [manet] BSSBasicrateset X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1603184002==" Errors-To: manet-bounces@ietf.org --===============1603184002== Content-Type: multipart/alternative; boundary="_3a7aa455-bd3f-49ce-8c10-c2055949d8b3_" --_3a7aa455-bd3f-49ce-8c10-c2055949d8b3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello every body, Please I would like to know how is defined an BSSBasicRateSet? when? which = bit rates contain? can we modify it? Thank you in advance. Mohammad. _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Space= s. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=3Dcreate&wx_url=3D/friends.= aspx&mkt=3Den-us= --_3a7aa455-bd3f-49ce-8c10-c2055949d8b3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello every body,
Please I would like to know how is defined an BSSBasicRateSet? when? which = bit rates contain?  can we modify it?
Thank you in advance.
Mohammad.

Invite your mail contacts to join your friends lis= t with Windows Live Spaces. It's easy! Try it! = --_3a7aa455-bd3f-49ce-8c10-c2055949d8b3_-- --===============1603184002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1603184002==-- From manet-bounces@ietf.org Mon Apr 23 10:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfzm2-0004Bq-Ng; Mon, 23 Apr 2007 10:44:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hfzm1-0004Bl-CE for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 10:44:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfzm1-0004Bd-2Z for manet@ietf.org; Mon, 23 Apr 2007 10:44:13 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfzly-00041O-3J for manet@ietf.org; Mon, 23 Apr 2007 10:44:13 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3NEhi7k024139; Mon, 23 Apr 2007 10:43:44 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007042310434211745 ; Mon, 23 Apr 2007 10:43:42 -0400 From: "Joe Macker" To: "'Bound, Jim'" , , "'manet'" References: <816DD9299957E547B5D758D7F977D6DC01C8BD85@tayexc14.americas.cpqcorp.net> Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline: June 1 Date: Mon, 23 Apr 2007 10:43:41 -0400 Message-ID: <078501c785b5$c91108a0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceE569RpTLCeYn6QQ+gW0W8lFwUIwAAgfpgADLivJA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC01C8BD85@tayexc14.americas.cpqcorp.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d273fad2623d4a35a7bb17d92c76f399 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I would agree, please refrain from CFP postings. Only WG product related events (e.g., INTEROPS) are considered relevant. I you have a doubt ask the chairs. -Joe >-----Original Message----- >From: Bound, Jim [mailto:Jim.Bound@hp.com] >Sent: Sunday, April 22, 2007 10:24 AM >To: wiiat@kis-lab.com; manet >Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon >Valley,USA) Deadline: June 1 > >Folks, is it appropriate to post call for paper on an IETF WG >list. I don't think so this is a working group. > >thanks >/jim > >> -----Original Message----- >> From: Jia Hu [mailto:wiiat@kis-lab.com] >> Sent: Sunday, April 22, 2007 10:08 AM >> To: manet >> Subject: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon >> Valley,USA) Deadline: June 1 >> >> [Apologies if you receive this more than once] >> >> ##################################################################### >> IEEE/WIC/ACM WEB INTELLIGENCE 2007 >> CALL FOR PAPERS >> ##################################################################### >> >> 2007 IEEE/WIC/ACM International Conference on Web >Intelligence (WI'07) >> >> Silicon Valley, USA, November 2-5, 2007 >> Official: http://www.cs.sjsu.edu/wi07/wi/ >> Mirror: http://www.maebashi-it.org/wi07/wi/ >> (to be collocated with IAT'07, BIBM'07 and GrC'07) >> >> Sponsored By >> IEEE Computer Society >> Web Intelligence Consortium (WIC) >> Association for Computing Machinery (ACM) >> >> >###################################################################### >> # Conference Chair >> # Andrei Broder, VP, Yahoo Fellow, Yahoo! Research >> # >> # Program Chair and Co-Chairs >> # T.Y. Lin, Professor, SJSU, BISC Fellow, UC-Berkeley >> # Laura Haas, Director, IBM Almaden Research Center >> # Janusz Kacprzyk, Professor, Polish Academy of Science >> # Rajeev Motwani, Professor, Stanford University >> # >> # Organizing Chair >> # Howard Ho, Manager, IBM Almaden Research Center >> # >> # WI-IAT Joint Keynote Speakers (Tentative) # # Vinton G. >> Cerf, Turing Award Winner, >> # VP and Chief Internet Evangelist, Google >> # Anant Jhingran, VP and CTO, IBM Silicon Valley Laboratory ># # (More >> WI Invited Speakers will be announced) # # (Papers >> Due: ** June 1 **, 2007) # Accepted papers will be published in the >> conference proceedings # by the IEEE Computer Society Press, >which are >> indexed by EI. >> >###################################################################### >> >> Web Intelligence (WI) has been recognized as a new direction for >> scientific research and development to explore the fundamental roles >> as well as practical impacts of Artificial Intelligence (AI) (e.g., >> knowledge representation, planning, knowledge discovery and data >> mining, intelligent agents, and social network intelligence) and >> advanced Information Technology (IT) (e.g., wireless networks, >> ubiquitous devices, social networks, and data/knowledge >grids) on the >> next generation of Web-empowered products, systems, services, and >> activities. It is one of the most important as well as promising IT >> research fields in the era of Web and agent intelligence. >> >> The 2007 IEEE/WIC/ACM International Conference on Web Intelligence >> (WI'07) will be jointly held with the 2007 IEEE/WIC/ACM >International >> Conference on Intelligent Agent Technology (IAT'07), the 2007 IEEE >> International Conference on Bioinformatics and Biomedicine >(BIBM'07), >> and the 2007 IEEE International Conference on Granular Computing >> (GrC'07) for providing synergism among the four research areas. It >> will provide opportunities for technical collaboration >beyond that of >> previous conferences. The four conferences will have a joint >opening, >> keynote, reception, and banquet. Attendees only need to register for >> one conference and can attend workshops, sessions and >tutorials across >> the four conferences. We are also planning a joint panel and joint >> paper sessions that discuss common problems in the four areas. >> >> +++++++++++ >> Highlights >> +++++++++++ >> >> The conference will be held in Silicon Valley, California. >> Many high-tech companies and three distinguished universities >> (Stanford, UC Berkely and UCSC) are just around the corner. >> The highlight of the conference is that a unique forum >consisting of a >> half-day industry/ demo track and free discussion will be >organized to >> link industries and academics. Leading IT companies like >IBM, Google, >> and Yahoo etc will present at the conference. >> >> The area now known as Silicon Valley has been a center of >> technological development since the 1950's. The name Silicon Valley >> stems from the early 1970's, when the area had become the center for >> many semiconductor companies. While still hosting semiconductor and >> microprocessor companies, the region now hosts the headquarters of >> high tech companies of every kind, including many of the best known >> and most prestigious names in personal computers, Web >search, Internet >> auctions, networking, storage, databases, etc. >> >> +++++++++++++++++++ >> Topics of Interest >> +++++++++++++++++++ >> >> The topics and areas include, but not limited to: >> >> * WI Foundations >> - Brain Informatics for WI >> - Human level WI >> - New cognitive models and computational models for WI >> - Granular Computing (GrC) for WI >> - Autonomy-Oriented Computing (AOC) for WI >> >> * World Wide Wisdom Web (W4) >> - Meta-Knowledge Discovery and Representation >> - Problem Solver Markup Language (PSML) >> - Search of Best Means and Ends >> - Goal-Directed Services Support >> - Distributed Resources Optimization >> - Service Self-Aggregation >> - Web Inference Engine >> - Information and Knowledge Markets >> - New Social Interaction Paradigms >> - Social and Psychological Contexts >> - Regularities and Laws of W4 >> >> * Social Networks and Social Intelligence >> - Social Network Mining >> - Web Site Clustering >> - Link Topology and Site Hierarchy >> - Theories of Small-World Web >> - Virtual and Web Communities >> - Web-Based Cooperative Work >> - Knowledge Community Formation and Support >> - Ubiquitous Computing >> - Intelligent Wireless Web >> - Ubiquitous Learning Systems >> - Entertainment >> >> * Knowledge Grids and Grid Intelligence >> - Semantic Grids >> - Knowledge Resources and Services Discovery >> - On-Demand Planning and Routing >> - Brokering and Scheduling >> - Middleware Architectures and Tools >> >> * Web Mining and Farming >> - Text Mining >> - Data Stream Mining >> - Multimedia Data Mining >> - Web Content Mining >> - Web Log and Usage Mining >> - Learning User Profiles >> - Context Sensitive Web Mining >> - Web Information Clustering >> - Web Page Clustering and Mining >> - E-Mail Classification >> - Web Site Classification >> - Web Information Indexing >> - Data Warehousing >> - Web Farming and Warehousing >> >> * Semantics and Ontology Engineering >> - Ontology-Based Information Extraction and Retrieval >> - Ontology-Based Web Mining >> - Web-Based Ontology Learning >> - Semantic Web >> >> * Web Agents >> - Global Information Foraging >> - Distributed Problem Solving >> - Coordination >> - Resource Intermediary and Coordination Mechanisms >> - Self-Organization and Reproduction >> - Agent Networks and Topologies >> - Mobile Agents >> - Macroscopic Behavior Modeling >> - Trust Models for Web Agents >> >> * Web Services >> - Service-Oriented Computing >> - Matchmaking >> - Web Service Reconfiguration >> - Web Service Workflow Composition >> - Middleware-Based Ubiquitous Services >> - Grid Services >> >> * Web Information Filtering and Retrieval >> - Automatic Cataloging and Indexing >> - Clustering-Based Recommender Systems >> - Collaborative Filtering and Recommendation >> - Hybrid Recommendation >> - Information Retrieval Criteria and Evaluations >> - Web Information Categorization and Ranking >> - Proxy and Cache Techniques >> - Web Prediction and Prefetching >> - Distributed Web Search >> - Specifications for Web Information Extraction Process >> - Web Crawling Systems >> - Search Engines and Meta-search Engines >> >> * Intelligent Human-Web Interaction >> - Adaptive Web Interfaces >> - Context-Aware Computing >> - Learning User Profiles >> - Personalized Interfaces >> - Personalized Web Sites >> - Remembrance Agents >> - Multimedia Representation >> - Visualization of Information and Knowledge >> - Social and Psychological Issues >> >> * Web Support Systems >> - Information Retrieval Support Systems >> - Web Site Navigation Support Systems >> - Recommender Support Systems >> - Web-Based Decision Support Systems >> - Soft Computing (including neural networks, fuzzy logic, >> evolutionary computation, rough sets, and granular computing) >> and Uncertainty Management for WI >> >> * Intelligent e-Technology >> - Business Intelligence >> - Digital Library >> - Decentralized Community Communication Techniques >> - e-Community >> - e-Business and e-Commerce >> - e-Finance >> - e-Government >> - e-Learning >> - e-Publishing >> - e-Science >> - Intelligent Enterprise Portals >> - Web-Based Direct Marketing and CRM >> - Web-Based EDI >> - Web Security, Integrity, Privacy and Trust >> >> ++++++++++++++++++++++++++++++++++++ >> On-Line Submissions and Publication >> ++++++++++++++++++++++++++++++++++++ >> >> High-quality papers in all WI related areas are solicited. >> Paper submissions should be limited to a maximum of 7 pages in the >> IEEE 2-column format, the same as the camera-ready format (see the >> Author Guidelines of last year at >> http://www.computer.org/portal/pages/cscps/cps/final/wi06.xml). >> All submitted papers will be reviewed by the Program >Committee on the >> basis of technical quality, relevance, significance, and clarity. >> >> Note that WI'07 will accept ONLY on-line submissions, containing PDF >> versions. Please use the Submission Form on the WI'07 website to >> submit your paper. Accepted papers will be published in the >conference >> proceedings by the IEEE Computer Society Press that are >indexed by EI. >> >> Submissions accepted as regular papers will be allocated 7 pages in >> the proceedings and accorded oral presentation times in the main >> conference. >> Submissions accepted as short papers will be allocated 4 >pages in the >> proceedings and will have a shorter presentation time at the >> conference than regular papers. >> >> All co-authors will be notified at all time, for the submission, >> notification, and confirmation on the attendance. >> Submitting a paper to the conference and workshops means >that, if the >> paper is accepted, at least one author should attend the >conference to >> present the paper. The acceptance list and no-show list will >be openly >> published on-line. For no-show authors, their affiliations will >> receive a notification. >> >> A selected number of WI'07 accepted papers will be expanded and >> revised for inclusion in Web Intelligence and Agent >> Systems: An International Journal >> (http://wi-consortium.org/journal.html) and in Annual Review of >> Intelligent Informatics (http://www.wi-consortium.org/annual.html). >> >> More detailed instructions and the On-Line Submission Form can be >> found from the WI'07 homepage: http://www.cs.sjsu.edu/wi07/wi/. >> >> ++++++++++++++++++++++++ >> WI'07 Best Paper Awards >> ++++++++++++++++++++++++ >> >> The best paper awards will be conferred at the conference on the >> authors of (1) the best research paper and (2) the best application >> paper. Application-oriented submissions will be considered for the >> best application paper award. >> >> The full author list and paper title will be announced on the Web >> Intelligence Consortium homepage: >> http://wi-consortium.org/html/wicawards.html >> >> ++++++++++++++++++++ >> Industry/Demo-Track >> ++++++++++++++++++++ >> >> We solicit Industry/Demo-Track papers by the following methods. >> >> (1) Industry papers of 4 pages can be submitted on the same schedule >> as >> the research track. >> (2) Separate 2 page demo proposals can submitted at a later schedule. >> (3) Full regular paper submissions can include a demo option. >> That is, a full paper submissions will be asked to >> specify if they would like to give a demonstration; choice of >> demonstrations (while utilizing information from the regular >> reviewing >> process) will be selected based on value as a demonstration. >> >> For options (1) and (2), please find more detailed >instructions at the >> homepage: http://www.cs.sjsu.edu/wi07/wi/ >> >> We are planning to arrange the Industry/Demo track in the >afternoon of >> November 3 (before and during the conference reception), >jointly with >> the IAT'07 Demo sessions. Leading IT companies in Silicon >Valley will >> be invited to attend this track. >> >> ++++++++++ >> Workshops >> ++++++++++ >> >> As an important part of the conference, the workshop program will >> focus on new research challenges and initiatives. All >papers accepted >> for workshops will be included in the Workshop Proceedings published >> by the IEEE Computer Society Press that are indexed by EI, >and will be >> available at the workshops. Detailed information is available at the >> conference homepage. >> >> Note: we will not have a separate workshop registration fee (i.e., >> conference registration covers everything). >> >> ------------------ >> WI 2007 Workshops: >> ------------------ >> Title: Educating the Web-Generation >> Organisers: Elisabeth Heinemann >> Email: elisabeth.heinemann@googlemail.com >> Web page: http://www.effactory.com/Edu4WebGen/ >> >> Title: Collective Intelligence on Semantic Web >> Organisers: Geun Sik Jo; Jason J. Jung; Ngoc Thanh Nguyen >> Email: gsjo@inha.ac.kr; j2jung@intelligent.pe.kr; thanh@pwr.wroc.pl >> Web page: >> http://intelligent.pe.kr/CISW07/ >> >> Title: New Computing Paradigms for Web Intelligence and Brain >> Informatics >> Organisers: Dr. Yuefeng Li; Dr. Yulin Qin, Prof. Dieter Fensel >> Email: y2.li@qut.edu.au; dieter.fensel@deri.org Web page: >> >> Title: Web Personalization and Recommender Systems >> Organisers: Yue Xu >> Email: yue.xu@qut.edu.au >> Web page: http://www.wprs07.fit.qut.edu.au/ >> >> Title: Service Composition >> Organisers: M. Brian Blake; Dumitru Roman; Charles Petrie >> Email: blakeb@cs.georgetown.edu; dumitru.roman@deri.org Web >> site: http://events.deri.at/sercomp2007/ >> >> Title: Biomedicine applications of Web technologies >> Organisers: Chun-Nan Hsu; Vincent Shin-Mu Tseng; Wen-Hsiang Lu >> Email: chunnan@iis.sinica.edu.tw; tsengsm@mail.ncku.edu.tw; >> whlu@mail.ncku.edu.tw Web page: >> http://chunnan.iis.sinica.edu.tw/BMWT2007.html >> >> Title: Intelligent Web Interaction Workshop 2007 1st >> Organiser: Prof. Seiji YAMADA >> Email: seiji@nii.ac.jp >> Web site: http://ymd.ex.nii.ac.jp/ws/iwi/07/ >> >> Title: Cyberinfrastucture for e-Science >> Organisers: Prof. Vasant Honavar; A/prof. Kei Cheung >> Email: honavar@cs.iastate.edu; kei.cheung@yale.edu Web page: >> http://www.cild.iastate.edu/events/CyIneS2007/ >> >> Title: 2007 International Workshop on Social Media Analysis >> Organisers: Chun-hung Li, William K. Cheung, Quoping Qiu >> Email: sma@comp.hkbu.edu.hk >> Web page: http://www.comp.hkbu.edu.hk/~sma/ >> >> Title: Web Security, Integrity, Privacy and Trust >> Organisers: Dr. Yiuming Cheung, Prof. Michael Chau, and Prof. >> Yong Zhang >> Email: ymc@Comp.HKBU.Edu.HK; mchau@business.hku.hk; >> zhangyong076@gmail.com Web page: >> >> ------------------- >> IAT 2007 Workshops: >> ------------------- >> Title: Second International Workshop on Communication between Human >> and Artificial Agents (CHAA-07) >> Organisers: Christel Kemke >> Email: ckemke@cs.umanitoba.ca >> Web page: http://www.cs.umanitoba.ca/~ckemke/CHAA-07/ >> >> Title: Rational, Robust, and Secure Negotiations in Multi-Agent >> Systems (RRS2007) >> Organisers: Takayuki Ito >> Email: ito.takayuki@nitech.ac.jp >> Web page: http://www-itolab.mta.nitech.ac.jp/RRS2007/ >> >> Title: P2P Computing and Autonomous Agents >> Organisers: Tarek Helmy, Khaled Ragab >> Email: helmy@ccse.kfupm.edu.sa; helmy@kfupm.edu.sa Web Page: >> http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html >> >> Title: Multiagent systems in E-business: concepts, technologies and >> applications >> Organisers: Costin Badica; Maria Ganzha; Marcin Paprzycki >> Email: badica_costin@software.ucv.ro; ganzha@euh-e.edu.pl; >> marcin.parzycki@swps.edu.pl Web page: >> http://software.ucv.ro/~badica_costin/maseb2007/ >> >> Title: Agent & Data Mining Interaction >> Organisers: Pericles A. Mitkas, Longbing Cao, Vladimir Gorodetsky, >> Justin Zhan >> Email: mitkas@eng.auth.gr; lbcao@it.uts.edu.au Web page: >> http://issel.ee.auth.gr/ADMI >> >> For more information, please visit the conference website at >> http://www.cs.sjsu.edu/wi07/wi/?index=workshop. >> >> ++++++++++ >> Tutorials >> ++++++++++ >> >> WI'07 also welcomes Tutorial proposals. WI'07 will include tutorials >> providing in-depth background on subjects that are of broad interest >> to the Web intelligence community. Both short (2 hours) and >long (half >> day) tutorials will be considered. The tutorials will be part of the >> main conference technical program. Detailed information is available >> at the conference homepage. >> >> Note: we will not have a separate tutorials registration fee (i.e., >> only one conference registration covers everything). >> >> ++++++++++++++++ >> Important Dates >> ++++++++++++++++ >> >> Workshop proposal submission: March 20, 2007 >> Electronic submission of full papers: ** June 1, 2007 ** >> Tutorial proposal submission: June 15, 2007 >> Notification of paper acceptance: July 22, 2007 >> Camera-ready copies of accepted papers: August 17, 2007 >> Conference: November 2-5, 2007 >> >> ++++++++++++++++++++++++ >> Conference Organization >> ++++++++++++++++++++++++ >> >> Conference Chair: >> * Andrei Broder, Yahoo! Research, USA >> >> Program Chair: >> * Tsau Young (T.Y.) Lin, San Jose State University/UC Berkeley, USA >> >> WI Program Co-Chairs: >> * Laura Haas, IBM Almaden Research Center, USA >> * Janusz Kacprzyk, Polish Academy of Science, Poland >> * Rajeev Motwani, Stanford University, USA >> >> IAT Program Co-Chairs: >> * Jeffrey M. Bradshaw, UWF/Institute for Human and Machine >> Cognition, USA >> * Matthias Klusch, German Research Center for AI, Germany >> * Chengqi Zhang, University of Technology, Sydney, Australia >> >> Organizing Chair: >> * Howard Ho, IBM Almaden Research Center, USA >> >> Workshop Co-Chairs: >> * Vijay Raghavan, University of Louisiana, USA >> * Yuefeng Li, Queensland University of Technology, Australia >> >> Tutorial Chair: >> * Pawan Lingras, Saint Mary's University, Canada >> >> Industry/Demo-Track Chair: >> * Jianchang Mao, Yahoo! Inc., USA >> >> Local Accommodations Co-Chairs: >> * David Scot Taylor, San Jose State University, USA >> * Tom Qi Zhang, Google, USA >> >> Publicity Chair: >> * James Wang, Clemson University, USA (chair) Publicity Co-Chairs: >> * Martine De Cock, Ghent University, Belgium >> * Jia Hu, International WIC Institute, China >> * Debajyoti Mukhopadhyay, West Bengal University of Technology, >> India >> >> IEEE-CS-TCII Chair: >> * Ning Zhong, Maebashi Institute of Technology, Japan >> >> ACM-SIGART Chair >> * Maria Gini, University of Minnesota, USA >> >> WIC Co-Chairs/Directors: >> * Ning Zhong, Maebashi Institute of Technology, Japan >> * Jiming Liu, University of Windsor, Canada >> >> WIC Advisory Board: >> * Edward A. Feigenbaum, Stanford University, USA >> * Setsuo Ohsuga, Waseda University, Japan >> * Benjamin Wah, University of Illinois, Urbana-Champaign, USA >> * Philip Yu, IBM Thomas J. Watson Research Center, USA >> * L.A. Zadeh, University of California Berkeley, USA >> >> WIC Tech. Committee & WI/IAT Steering Committee: >> * Jeffrey Bradshaw, UWF/Institute for Human and Machine Cognition, >> USA >> * Nick Cercone, Dalhousie University, Canada >> * Dieter Fensel, National University of Ireland, Ireland >> * Georg Gottlob, Oxford University, UK >> * Lakhmi Jain, University of South Australia, Australia >> * Jianchang Mao, Yahoo! Inc., USA >> * Pierre Morizet-Mahoudeaux, Compiegne University of Technology, >> France >> * Hiroshi Motoda, Osaka University, Japan >> * Toyoaki Nishida, Kyoto University, Japan >> * Andrzej Skowron, Warsaw University, Poland >> * Jinglong Wu, Kagawa University, Japan >> * Xindong Wu, University of Vermont, USA >> * Yiyu Yao, University of Regina, Canada >> >> Webmaster: >> * Albert Sutojo, San Jose State University, USA >> >> Abbreviation: >> WI 2007, WI2007, WI'2007, WI'07, WI07, WI 07, WI-07, WI-2007, WI-IAT >> 2007, WI-IAT2007, WI-IAT'2007, WI-IAT'07, WI-IAT07, WI-IAT 07, >> WI-IAT-2007, WI-IAT-07, WI/IAT 2007, WI/IAT2007, WI/IAT'2007, >> WI/IAT'07, WI/IAT07, WI/IAT 07, WI/IAT-2007, WI/IAT-07 >> >> *** Contact Information *** >> >> Jia Hu >> International WIC Institute, China >> E-mail: hujia@kis-lab.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 manet-bounces@ietf.org Mon Apr 23 11:34:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0YX-00066X-HP; Mon, 23 Apr 2007 11:34:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hg0YW-00066S-Gr for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 11:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0YW-00066K-7P for manet@ietf.org; Mon, 23 Apr 2007 11:34:20 -0400 Received: from ovs01.rockwellcollins.com ([205.175.225.231] helo=vs01.rockwellcollins.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0YV-0004bE-0c for manet@ietf.org; Mon, 23 Apr 2007 11:34:20 -0400 Received: from vs01.rockwellcollins.com (localhost [127.0.0.1]) by localhost.rockwellcollins.com (Postfix) with ESMTP id 3579231A64 for ; Mon, 23 Apr 2007 10:34:17 -0500 (CDT) Received: from crnotes2.rockwellcollins.com (crnotes2.rockwellcollins.com [131.198.64.109]) by vs01.rockwellcollins.com (Postfix) with ESMTP id 7933F31A4C for ; Mon, 23 Apr 2007 10:34:17 -0500 (CDT) In-Reply-To: To: manet@ietf.org Subject: RE: [manet] MANET Port Name MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: From: jasteven@rockwellcollins.com Date: Mon, 23 Apr 2007 10:34:10 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 7.0.1FP1 HF151|January 16, 2007) at 04/23/2007 10:34:27 AM, Serialize complete at 04/23/2007 10:34:27 AM X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0724509484==" Errors-To: manet-bounces@ietf.org This is a multipart message in MIME format. --===============0724509484== Content-Type: multipart/alternative; boundary="=_alternative 0055872C862572C6_=" This is a multipart message in MIME format. --=_alternative 0055872C862572C6_= Content-Type: text/plain; charset="US-ASCII" I agree with other posters. I prefer PacketBB to MANET for the port in the IANA document. Regards, Jim Stevens --=_alternative 0055872C862572C6_= Content-Type: text/html; charset="US-ASCII"
I agree with other posters.  I prefer PacketBB to MANET for the port in the IANA document.

Regards,
Jim Stevens

--=_alternative 0055872C862572C6_=-- --===============0724509484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0724509484==-- From manet-bounces@ietf.org Mon Apr 23 13:02:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1vc-0005sK-Ed; Mon, 23 Apr 2007 13:02:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hg1va-0005sE-Gk for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 13:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1va-0005s6-78 for manet@ietf.org; Mon, 23 Apr 2007 13:02:14 -0400 Received: from mx3.iit.cnr.it ([146.48.98.150] helo=smtp.iit.cnr.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1vY-0001ma-LQ for manet@ietf.org; Mon, 23 Apr 2007 13:02:14 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 8E50623DCC1 for ; Mon, 23 Apr 2007 19:02:04 +0200 (CEST) Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx3.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31249-07 for ; Mon, 23 Apr 2007 19:02:03 +0200 (CEST) X-SMTP-Auth: no Received: from mx3.iit.cnr.it (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 8EB0023DCA8 for ; Mon, 23 Apr 2007 19:02:03 +0200 (CEST) Received: from bruno.iit.cnr.it (HELO [146.48.98.79]) (146.48.98.79) (smtp-auth username raffaele.bruno@iit.cnr.it, mechanism plain) by mx3.iit.cnr.it (qpsmtpd/0.32) with ESMTP; Mon, 23 Apr 2007 19:02:03 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: quoted-printable Message-Id: Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed To: manet@ietf.org From: Raffaele Bruno Date: Mon, 23 Apr 2007 19:02:04 +0200 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: Debian amavisd-new at mx3.iit.cnr.it X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Subject: [manet] =?windows-1252?q?CFP_-_IEEE_MASS-GHS=9207=3A_Int=2E_Work?= =?windows-1252?q?shop_on_Mobile_Ad_hoc_and_Sensor_Systems_for_Global_and_?= =?windows-1252?q?Homeland_Security_?= X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Please accept our apologies if you receive multiple copies of this CFP. ---------------------------------------------------------------------- First International Workshop on Mobile Ad hoc and Sensor Systems for =20 Global and Homeland Security (MASS-GHS=9207) http://www.eecs.wsu.edu/~holder/mass-ghs07 Pisa, Italy =96 October 12, 2007 In conjunction with the 4th IEEE Conference on Mobile Ad-hoc and =20 Sensor Systems (MASS=9207) http://cnd.iit.cnr.it/mass2007/ ---------------------------------------------------------------------- THEME AND SCOPE The development, deployment and coordination of mobile ad hoc and =20 sensor systems (MASS) has been studied for a number of years, and =20 much of this research is beginning to transition into real solutions =20 for a variety of domains. One domain that is ripe for MASS research =20 and development is global and homeland security. Much of the security =20= mission involves the monitoring of various environments (e.g., ports, =20= borders, mass transit hubs, financial centers, power grids, the =20 Internet) and the prediction and detection of threats to these =20 environments. MASS represent a general solution to maintaining =20 security in these environments. In this workshop we seek to bring together researchers and =20 practitioners representing the state-of-the-art in MASS research and =20 technology targeted toward the global and homeland security domain. =20 Specific topics of interest include (but are not limited to) the =20 following. All papers must have a clear, stated, and ideally tested =20 application to global and homeland security. =B7 Development of novel sensors and sensor systems for threat =20 detection =B7 Efficient and effective deployment of mobile devices and = sensors =B7 Heterogeneous systems for surveillance and threat detection =B7 Novel architectures for use of MASS in Global and Homeland =20 security =B7 Secure and fault tolerant coordination and communication =B7 Information fusion for prediction and detection of threats =B7 Integration and registration of data from multiple sources =B7 Effective decision-making in dynamic environments =B7 Testing and evaluation of MASS for security =B7 Simulation and modeling of MASS, environments, and scenarios =B7 Simulation and modeling of threats and environments relevant =20= to sensor response =B7 Simulation and modeling of temporal threat events relevant to =20= sensor response =B7 Prototype models of secure environments =B7 Secure smart environments =B7 Disaster mitigation and emergency response PAPER SUBMISSIONS Papers are limited to eight (8) pages and must be formatted according =20= to the main conference=92s formatting requirements and submitted via =20 the EDAS paper management system (see workshop website for details). =20 Accepted papers will be published by IEEE in the MASS=9207 conference =20= proceedings. At least one author of each accepted paper must register =20= for the conference at the full conference rate. Pending approval of a =20= special issue of the Pervasive and Mobile Computing Journal, authors =20 of high-quality papers presented at the workshop will be invited to =20 submit extended versions for this special issue. IMPORTANT DATES Submission due: May 15, 2007 Acceptance Notification: July 15, 2007 Final Manuscript due: August 10, 2007 Workshop: October 12, 2007 WORKSHOP CO-CHAIRS Larry Holder, Washington State Univ., USA (holder@wsu.edu) Mohan Kumar, Univ. of Texas at Arlington, USA (mkumar@uta.edu) Raffaele Bruno, Institute for Informatics and Telematics, Italy =20 (raffaele.bruno@iit.cnr.it) PROGRAM COMMITTEE Cesare Alippi, Politecnico di Milano, Italy Giuseppe Anastasi, Univ. of Pisa, Italy Paolo Bellavista, Univ. of Bologna, Italy Sajal Das, Univ. of Texas at Arlington, USA Silvia Giordano, Univ. of Applied Science, Switzerland Ajay Gupta, Western Michigan Univ., USA Jadwiga Indulska, Queensland Unversity, Australia William Kaiser, Univ. of California Los Angeles, USA Yonghe Liu, Univ. of Texas at Arlington, USA Murali Medidi, Washington State Univ., USA Sirisha Medidi, Washington State Univ., USA Scott Midkiff, Virginia Tech, USA Vinayak Naik, Univ. of California Los Angeles, USA Stephan Olariu, Old Dominion Univ., USA Leslie Owens, Booz Allen Hamilton, USA Marimuthu Palaniswami, Univ. of Melbourne, Australia Adrian Pearce, Univ. of Melbourne, Australia Marius Portmann, Univ. of Queensland, Australia Mohammad Rahimi, Univ. of California Los Angeles, USA Mallikarjun Shankar, Oak Ridge National Laboratory, USA Behrooz Shirazi, Washington State Univ., USA Mukesh Singhal, Univ. of Kentucky, USA --------------------------------------------------------- Raffaele Bruno, Ph.D., Researcher Pervasive Computing & Networking Lab. (PerLab) IIT Institute - Italian National Research Council (CNR) Via G. Moruzzi 1, 56124 Pisa, ITALY Tel.: +39 050 315 3078 (direct) Fax.: +39 050 315 2593 (institute) Email: raffaele.bruno@iit.cnr.it Website: bruno1.iit.cnr.it/~bruno/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 13:05:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1zD-0007Wn-F7; Mon, 23 Apr 2007 13:05:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hg1zC-0007Ul-4r for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 13:05:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1zB-0007U3-RA for manet@ietf.org; Mon, 23 Apr 2007 13:05:57 -0400 Received: from web32704.mail.mud.yahoo.com ([68.142.207.248]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg1z7-0002er-Lu for manet@ietf.org; Mon, 23 Apr 2007 13:05:57 -0400 Received: (qmail 7895 invoked by uid 60001); 23 Apr 2007 17:05:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=tmKNIDH75y0NiIyLrMe6CjqwgKkHS89sfCNQqwzduDNGS0S8LalWJ6Sg0gfvXBHUF/slZxGpy3h7SC2RpVKo6ZcW+yHQl+u/z7D68tzIja4RIi0/tRrPfgC+S3hWtUtn6Mymt8ue7gWE22SCgZAvbEfcXDp9aDyfCm2DNVecC64=; X-YMail-OSG: y8nEDY8VM1k6F0Tgr6VRS1VWpTkS7IMfz_l7L8RYxCJR8iQOPL1tnAakKmVElVLnqw-- Received: from [80.191.197.111] by web32704.mail.mud.yahoo.com via HTTP; Mon, 23 Apr 2007 10:05:52 PDT Date: Mon, 23 Apr 2007 10:05:52 -0700 (PDT) From: hamid reza To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <944458.7745.qm@web32704.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [manet] Carrier Sensing X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear all, I have Two questions Which i cant give my answer from some resources. Can you guide me? 1- How Carrier Sensing(CS) works in below situation? Suppose node A sends a packet to Node B and Node B in transmission range of node A . Does Node B sense Node A after full reception of a packet or node B can sense activity of Node A During this transmission? 2- Suppose a packet trigger EIFS in SIFS duration of a Node. Does EIFS turn on related timer after Expiring SIFS or as soon as Recognizing error in FCS? I m appreciating that hear from you as soon as possible. Best Regards Hamid Reza __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 13:43:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Zq-0006Iv-7G; Mon, 23 Apr 2007 13:43:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hg2Zo-0006Cv-Ck for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 13:43:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Zo-0006Cn-35 for manet@ietf.org; Mon, 23 Apr 2007 13:43:48 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg2Zm-0003SA-Hu for manet@ietf.org; Mon, 23 Apr 2007 13:43:48 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-6.tower-153.messagelabs.com!1177350225!1302589!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 32120 invoked from network); 23 Apr 2007 17:43:45 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-6.tower-153.messagelabs.com with SMTP; 23 Apr 2007 17:43:45 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id l3NHhiMa016298; Mon, 23 Apr 2007 10:43:45 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l3NHhh7w002752; Mon, 23 Apr 2007 12:43:43 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l3NHhf2v002734; Mon, 23 Apr 2007 12:43:42 -0500 (CDT) Message-ID: <462CF04D.4080602@gmail.com> Date: Mon, 23 Apr 2007 19:43:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Raffaele Bruno Subject: Re: [manet] CFP - IEEE =?windows-1252?Q?MASS-GHS=9207=3A_Int=2E?= =?windows-1252?Q?_Workshop_on_Mobile_Ad_hoc_and_Sensor_S?= =?windows-1252?Q?ystems_for_Global_and_Homeland_Security_?= References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 000735-1, 21/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Raffaele Bruno wrote: > > Please accept our apologies if you receive multiple copies of this > CFP. Rafaelle, please refrain from further posting Call for Papers on the MANET WG mailing list. Only WG product related events (eg INTEROPS) are considered relevant. If you have a doubt please ask the Chairs before posting a Call for Papers. Thanks, Alex > > ---------------------------------------------------------------------- > First International Workshop on Mobile Ad hoc and Sensor Systems for > Global and Homeland Security (MASS-GHS’07) > http://www.eecs.wsu.edu/~holder/mass-ghs07 > > Pisa, Italy – October 12, 2007 > > In conjunction with the 4th IEEE Conference on Mobile Ad-hoc and > Sensor Systems (MASS’07) http://cnd.iit.cnr.it/mass2007/ > ---------------------------------------------------------------------- > > > THEME AND SCOPE > > The development, deployment and coordination of mobile ad hoc and > sensor systems (MASS) has been studied for a number of years, and > much of this research is beginning to transition into real solutions > for a variety of domains. One domain that is ripe for MASS research > and development is global and homeland security. Much of the > security mission involves the monitoring of various environments > (e.g., ports, borders, mass transit hubs, financial centers, power > grids, the Internet) and the prediction and detection of threats to > these environments. MASS represent a general solution to maintaining > security in these environments. > > In this workshop we seek to bring together researchers and > practitioners representing the state-of-the-art in MASS research and > technology targeted toward the global and homeland security domain. > Specific topics of interest include (but are not limited to) the > following. All papers must have a clear, stated, and ideally tested > application to global and homeland security. > > · Development of novel sensors and sensor systems for threat > detection · Efficient and effective deployment of mobile > devices and sensors · Heterogeneous systems for surveillance > and threat detection · Novel architectures for use of MASS in > Global and Homeland security · Secure and fault tolerant > coordination and communication · Information fusion for > prediction and detection of threats · Integration and > registration of data from multiple sources · Effective > decision-making in dynamic environments · Testing and > evaluation of MASS for security · Simulation and modeling of > MASS, environments, and scenarios · Simulation and modeling of > threats and environments relevant to sensor response · > Simulation and modeling of temporal threat events relevant to sensor > response · Prototype models of secure environments · > Secure smart environments · Disaster mitigation and emergency > response > > > PAPER SUBMISSIONS > > Papers are limited to eight (8) pages and must be formatted according > to the main conference’s formatting requirements and submitted via > the EDAS paper management system (see workshop website for details). > Accepted papers will be published by IEEE in the MASS’07 conference > proceedings. At least one author of each accepted paper must > register for the conference at the full conference rate. Pending > approval of a special issue of the Pervasive and Mobile Computing > Journal, authors of high-quality papers presented at the workshop > will be invited to submit extended versions for this special issue. > > IMPORTANT DATES > > Submission due: May 15, 2007 Acceptance > Notification: July 15, 2007 Final Manuscript due: August 10, > 2007 Workshop: October 12, 2007 > > > WORKSHOP CO-CHAIRS > > Larry Holder, Washington State Univ., USA (holder@wsu.edu) Mohan > Kumar, Univ. of Texas at Arlington, USA (mkumar@uta.edu) Raffaele > Bruno, Institute for Informatics and Telematics, Italy > (raffaele.bruno@iit.cnr.it) > > > PROGRAM COMMITTEE > > Cesare Alippi, Politecnico di Milano, Italy Giuseppe Anastasi, Univ. > of Pisa, Italy Paolo Bellavista, Univ. of Bologna, Italy Sajal Das, > Univ. of Texas at Arlington, USA Silvia Giordano, Univ. of Applied > Science, Switzerland Ajay Gupta, Western Michigan Univ., USA Jadwiga > Indulska, Queensland Unversity, Australia William Kaiser, Univ. of > California Los Angeles, USA Yonghe Liu, Univ. of Texas at Arlington, > USA Murali Medidi, Washington State Univ., USA Sirisha Medidi, > Washington State Univ., USA Scott Midkiff, Virginia Tech, USA Vinayak > Naik, Univ. of California Los Angeles, USA Stephan Olariu, Old > Dominion Univ., USA Leslie Owens, Booz Allen Hamilton, USA Marimuthu > Palaniswami, Univ. of Melbourne, Australia Adrian Pearce, Univ. of > Melbourne, Australia Marius Portmann, Univ. of Queensland, Australia > Mohammad Rahimi, Univ. of California Los Angeles, USA Mallikarjun > Shankar, Oak Ridge National Laboratory, USA Behrooz Shirazi, > Washington State Univ., USA Mukesh Singhal, Univ. of Kentucky, USA > > --------------------------------------------------------- Raffaele > Bruno, Ph.D., Researcher Pervasive Computing & Networking Lab. > (PerLab) > > IIT Institute - Italian National Research Council (CNR) Via G. > Moruzzi 1, 56124 Pisa, ITALY Tel.: +39 050 315 3078 (direct) Fax.: > +39 050 315 2593 (institute) Email: raffaele.bruno@iit.cnr.it > Website: bruno1.iit.cnr.it/~bruno/ > > > > > > > > _______________________________________________ manet mailing list > manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 14:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3QD-00008j-P4; Mon, 23 Apr 2007 14:37:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hg3QC-0008Ua-4L for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 14:37:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3QB-0008TL-QU for manet@ietf.org; Mon, 23 Apr 2007 14:37:55 -0400 Received: from smtp4.na.baesystems.com ([63.164.202.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3Q1-0000Zu-HE for manet@ietf.org; Mon, 23 Apr 2007 14:37:55 -0400 Received: from BLUMS0022.bluelnk.net (blums0022.na.baesystems.com [10.40.96.145]) by smtp4.na.baesystems.com (8.13.6/8.13.6) with ESMTP id l3NIbThx020894 for ; Mon, 23 Apr 2007 14:37:34 -0400 (EDT) Received: from blums0002.bluelnk.net (blums0002.na.baesystems.com [10.40.96.102]) by smtp1.na.baesystems.com (8.13.6/8.13.6) with ESMTP id l3NIbU9p002231; Mon, 23 Apr 2007 14:37:30 -0400 (EDT) Received: from BLUMS0005.bluelnk.net ([10.40.96.105]) by blums0002.bluelnk.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 23 Apr 2007 14:37:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Dymo route discovery Date: Mon, 23 Apr 2007 14:37:29 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Dymo route discovery Thread-Index: AceFnie3sz9LTb7VSJuDpuRm7z20vgAMDqTQ From: "Weber, Michael J. \(US SSA\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 23 Apr 2007 18:37:30.0218 (UTC) FILETIME=[72FF54A0:01C785D6] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I think it may be helpful to consider the role of the IP stack and the role of a DYMO process on a node. As a routing protocol, I think it is DYMO's responsibility to discover and maintain routes to reachable networks and reachable nodes. DYMO provides routes that (should) be usable by IP to reach the described destinations. As a datagram delivery service, I think it is IP's responsibility to move datagrams from host to host on a best-effort basis until the destination host is reached. It is quite possible that an IP packet addressed to a particular host address on a network serviced by a router running DYMO is undeliverable because the host assigned that address is turned off (or otherwise unavailable) and not because of any routing errors on DYMO's part. In that case, an ICMP destination unreachable delivered to the originator of the packet is quite appropriate. We realize, of course, that the packet never would have reached that final step if not for routes provided, perhaps fully or in part, by DYMO. In the reactive routing protocol case there is always the delicate interface between the IP stack and the routing protocol. The routing protocol needs a chance to dynamically discover routes, but does not necessarily want to take over all the responsibilities of the IP stack, the forwarding engine, and the firewall. These are topics for other discussions, I believe. In this particular case I think it is appropriate for DYMO to specify the messaging required to insure its full and correct operation and for the IP stack to consume or ignore and generate or withhold ICMP messages per the site administrator's wishes. =20 Additional comments below. > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Monday, April 23, 2007 7:54 AM > To: Ian Chakeres > Cc: Alexandru Petrescu; manet > Subject: Re: [manet] Dymo route discovery >=20 > Ian Chakeres wrote: > [...] > >>> I don't see any reason why they couldn't work together, but as I=20 > >>> mention I wouldn't suggest it. > >>=20 > >> So one has to _disable_ ICMP DstUnreachable generation code, right? > >> That's built-in into the stack. > >=20 > > This is an implementation issue. I myself cannot say how/when ICMP=20 > > destination unreachable messages are generated. >=20 > I can say when they're generated: when a packet travelling to=20 > a destination hits a router having no route to that=20 > destination, and no default route. Any router will generate=20 > such an ICMP DstUnreachable.=20 > Do you agree? Two comments here: If the router is responsible for the target network for the packet in question, it may (if so configured) generate an ICMP destination unreachable if it cannot successfully transmit the packet to the target host even if a default route is available. This makes sense, because the default route is only for networks which we do not otherwise know how to reach, and directly connected networks are always known. Also, the generation and consumption of ICMP messages can be site-specific. The common IP stacks I've seen (windows, linux, macos) can be instructed to disable or ignore receipt of various ICMP messages, either explicitly or with the aid of firewall filters. Many sites consider ICMP redirect in particular a security risk and ignore it. It does not seem beneficial to me to tie DYMO to ICMP's fate in any particular network deployment. Best, Mike _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 23 16:29:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5AN-0002O6-He; Mon, 23 Apr 2007 16:29:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hg5AM-0002KH-2d for manet-confirm+ok@megatron.ietf.org; Mon, 23 Apr 2007 16:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg58u-00019A-BQ for manet@ietf.org; Mon, 23 Apr 2007 16:28:12 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hg58u-0001R3-0W for manet@ietf.org; Mon, 23 Apr 2007 16:28:12 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-14.tower-119.messagelabs.com!1177360090!19816234!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 16215 invoked from network); 23 Apr 2007 20:28:11 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-14.tower-119.messagelabs.com with SMTP; 23 Apr 2007 20:28:11 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l3NKSAf3021688; Mon, 23 Apr 2007 13:28:10 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l3NKS95t022669; Mon, 23 Apr 2007 15:28:09 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.57]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l3NKS6tm022619; Mon, 23 Apr 2007 15:28:07 -0500 (CDT) Message-ID: <462D16D6.5040203@gmail.com> Date: Mon, 23 Apr 2007 22:28:06 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Weber, Michael J. \(US SSA\)" Subject: Re: [manet] Dymo route discovery References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-2, 23/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Alexandru Petrescu , manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Weber, Michael J. (US SSA) wrote: > I think it may be helpful to consider the role of the IP stack and > the role of a DYMO process on a node. > > As a routing protocol, I think it is DYMO's responsibility to > discover and maintain routes to reachable networks and reachable > nodes. DYMO provides routes that (should) be usable by IP to reach > the described destinations. > > As a datagram delivery service, I think it is IP's responsibility to > move datagrams from host to host on a best-effort basis until the > destination host is reached. > > It is quite possible that an IP packet addressed to a particular host > address on a network serviced by a router running DYMO is > undeliverable because the host assigned that address is turned off > (or otherwise unavailable) and not because of any routing errors on > DYMO's part. In that case, an ICMP destination unreachable delivered > to the originator of the packet is quite appropriate. We realize, of > course, that the packet never would have reached that final step if > not for routes provided, perhaps fully or in part, by DYMO. I think it makes sense. It does illustrate however a picture where end2end communication happens from a host to another host, through routers that maintain routes with DYMO process and send ICMP DstUnreachable sometimes. This is very much inline with how a NEMO moving network is being seen, hosts not supporting any form of mobility run applications and intermediary routers support Mobile IPv6 mobility. I will post separately later of where I see this similarity going. > In the reactive routing protocol case there is always the delicate > interface between the IP stack and the routing protocol. The routing > protocol needs a chance to dynamically discover routes, but does not > necessarily want to take over all the responsibilities of the IP > stack, the forwarding engine, and the firewall. These are topics for > other discussions, I believe. > > In this particular case I think it is appropriate for DYMO to specify > the messaging required to insure its full and correct operation and > for the IP stack to consume or ignore and generate or withhold ICMP > messages per the site administrator's wishes. > > Additional comments below. > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Monday, April 23, 2007 >> 7:54 AM To: Ian Chakeres Cc: Alexandru Petrescu; manet Subject: >> Re: [manet] Dymo route discovery >> >> Ian Chakeres wrote: [...] >>>>> I don't see any reason why they couldn't work together, but >>>>> as I mention I wouldn't suggest it. >>>> So one has to _disable_ ICMP DstUnreachable generation code, >>>> right? That's built-in into the stack. >>> This is an implementation issue. I myself cannot say how/when >>> ICMP destination unreachable messages are generated. >> I can say when they're generated: when a packet travelling to a >> destination hits a router having no route to that destination, and >> no default route. Any router will generate such an ICMP >> DstUnreachable. Do you agree? > > Two comments here: > > If the router is responsible for the target network for the packet in > question, it may (if so configured) generate an ICMP destination > unreachable if it cannot successfully transmit the packet to the > target host even if a default route is available. This makes sense, > because the default route is only for networks which we do not > otherwise know how to reach, and directly connected networks are > always known. > > Also, the generation and consumption of ICMP messages can be > site-specific. The common IP stacks I've seen (windows, linux, macos) > can be instructed to disable or ignore receipt of various ICMP > messages, either explicitly or with the aid of firewall filters. Many > sites consider ICMP redirect in particular a security risk and > ignore it. Security risks of Redirect and DDoS ICMP Echo Req/Rep are probably completely irrelevant threats in a MANET network which is presumably administered by a same unique administrator/team. The Redirect and ICMP Echo Req/Rep DDoS are threats that can _only_ happen in the Internet at large, where no central administration controls everything. Not sure there's a threat analysis document for MANET... > It does not seem beneficial to me to tie DYMO to ICMP's fate in any > particular network deployment. Presented this way, it may make sense. It depends very much about what the particular deployment looks like. I completely agree that particular deployments have very specific needs, to which some protocols can fully satisfy. It may very well be that some particular deployments are so static that routes are established once, for a long time, and then change very very little. Such a deployment will not see any Redirect and any DstUnreachable for maybe a long time. Alex > > Best, Mike > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 01:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgDVF-0000Fg-1k; Tue, 24 Apr 2007 01:23:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgDVD-0000Ck-7U for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 01:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgDVC-0000Bp-Qm for manet@ietf.org; Tue, 24 Apr 2007 01:23:46 -0400 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgDVB-0001p0-HR for manet@ietf.org; Tue, 24 Apr 2007 01:23:46 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1718273wri for ; Mon, 23 Apr 2007 22:23:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VB0ZBXkdlkeB5cTMAk+PF098DdjHJCcrfQA3T75rdIbGjxOXGY6ls6GNp32lwha1IqQqjXJyEfMh/str5QbUUQdmVXPg+Rfq4RehOxT3LWL7yCJg6nrXrhTMHcWYGe5D85Ho7Ii9TUbJ5wn4x2gxVfiJPXb3OFVlALhRVUUddoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XtPUBVwLNHBqCq8hsQfTgO3xISElEyTmSOcSyYP/2INrPA0xKPIcx+vNk6LGf0ctDEguZvKjti+cXo/7heyi5PTzysxUQflpgvs6jy9pLbtb/xmC0aqAcKMT9mbBVCFCpunpiBaiO7ozCI03o48zeVmsa7MGufFU/IaBrRZyUhs= Received: by 10.78.183.15 with SMTP id g15mr354844huf.1177392224042; Mon, 23 Apr 2007 22:23:44 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Mon, 23 Apr 2007 22:23:43 -0700 (PDT) Message-ID: <374005f30704232223m308b1e07y9b71ec92c6f69dde@mail.gmail.com> Date: Tue, 24 Apr 2007 10:53:43 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [manet] Dymo route discovery In-Reply-To: <462C9E53.9020704@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4628A81F.90401@gmail.com> <374005f30704200633w68679911s4f7bcc4eb8579b7e@mail.gmail.com> <4628CC1F.1060106@gmail.com> <374005f30704220346o7ea375c8k270ee87c51844431@mail.gmail.com> <462BCFB5.7070305@gmail.com> <374005f30704222105q7c65f4dch49b4628105958adf@mail.gmail.com> <462C7EA6.8080201@gmail.com> <374005f30704230322u48c24d35p4ad793f36f44eb0@mail.gmail.com> <462C9E53.9020704@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 4/23/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > [...] > >>> I don't see any reason why they couldn't work together, but as I > >>> mention I wouldn't suggest it. > >> > >> So one has to _disable_ ICMP DstUnreachable generation code, right? > >> That's built-in into the stack. > > > > This is an implementation issue. I myself cannot say how/when ICMP > > destination unreachable messages are generated. > > I can say when they're generated: when a packet travelling to a > destination hits a router having no route to that destination, and no > default route. Any router will generate such an ICMP DstUnreachable. > Do you agree? > > > Though as I mentioned above, making the judgement that an ICMP dst > > unreachable should be issued might be weird in networks running > > reactive routing protocols. > > I think we diverge here. ICMP DestUnreachable is specified and > implemented and most if not all routers do implement it. > > But I agree it would be weird for a network using RERR messages to also > issue ICMP DstUnreachable. > > Should this be clarified in the DYMO draft? Should the DYMO draft say > that when DYMO is run then ICMP DstUnreachable should not be issued by > any router in the MANET? I think yes. I will add the following text to the dymo draft in the "route maintenance" section. The paragraph is talking about issuing RERR when data is to be forwarded and no forwarding route exists. """ In this case, an ICMP Destination Unreachable message SHOULD NOT be generated, unless this router is responsible for the IP.Destination and the IP.Destination is not reachable. """ Do you have any textual recommendations? > [...] > >> For my clarification, will a MANET router act as a default router > >> for its attached hosts? Or will it try to provide host-based > >> routes to install in the host's routing table for every > >> correspondent this host talks to? This is very important to the > >> MANEMO analysis, thanks. > > > > A MANET router will act like a router for its attached nodes. In a > > simple scenario where we have a router with attached hosts, the hosts > > can be configure the router as their default router. > > Ok, this is a common behaviour with NEMO moving networks, where LFNs > (Local Fixed Nodes) often can auto-configure a default route to the > Mobile Router, with stateless address auto-configuration. > > Alex > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 03:35:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFYY-0008K8-VO; Tue, 24 Apr 2007 03:35:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgFYX-0008Fc-Ap for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 03:35:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgFYW-0008El-So for manet@ietf.org; Tue, 24 Apr 2007 03:35:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0c6-0000NK-La for manet@ietf.org; Mon, 23 Apr 2007 11:38:02 -0400 Received: from postis1.generic.se ([194.68.102.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0c4-0006Z4-4e for manet@ietf.org; Mon, 23 Apr 2007 11:38:02 -0400 Received: from [172.16.16.9] by [172.31.100.7] with TFS Secure Messaging Server; Mon, 23 Apr 2007 17:37:43 +0200 Received: from (unknown [172.16.16.9]) by GenFilter.intra.generic.se with smtp id 3a31_fac30bde_f1b0_11db_912e_001143cd4a5e; Mon, 23 Apr 2007 17:40:36 +0200 Subject: Fw: [manet] Re : Energy Efficiency in Routing Protocols To: manet@ietf.org X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Carl-Johan.Larsson@generic.se Date: Mon, 23 Apr 2007 17:37:39 +0200 X-MIMETrack: Serialize by Router on Luna/Server/Generic(Release 7.0.2|September 26, 2006) at 2007-04-23 17:37:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-TMDA-Confirmed: Tue, 24 Apr 2007 03:35:20 -0400 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I all, I most interested in this thought, I'm been doing som work on adding Preemptive Route Maintenance on AODV by using simulated GPS coordinates, The idea behind this is to change the route by a Route discovery before the break occures like you, Naeendran, proposed. I'm beeen using GPS coordinates to get the distance as a threashold when to activate the mechanism. How where you going to measure the distance you talk about Narendran, by signal power or gps strength? regards Calle "Narendran Sivakumar" "Ian Chakeres" , 2007-04-23 16:37 manet@ietf.org cc Subject Re: [manet] Re : Energy Efficiency in Routing Protocols Hi Ian, Well , In a wireless environment the energy levels used while transmission is also important as higher the transmission power, higher is the range for the nodes to transmit. Is it possible to add an Intelligence Mechanism to DYMO which would use energy levels automatically based on the topology. For Example : If a node X is transmitting to Y with I and J are the intermediate nodes and the path is X-I-J-Y.If Y moves out of range of J, X would again initiate Route Discovery to Y. If an intelligence mechanism is used to increase the transmission power of J so that Y is within range even if Y changes the location thereby saving time for another Route Discovery process and less delay. On the flip side if Y is well within range of J, then that same mechanism should be able to adjust the transmission power in accordance with the closer Y, thereby saving energy. I believe that in a wireless environment , energy efficiency holds the key in determining the effectiveness of an Routing Protocol, further more to DYMO Thanks Naren On 4/23/07, Ian Chakeres wrote: I think it will be difficult to analyze energy efficiency. I also think there are also lots of little tweaks that you could do to improve efficiency, depending on your measure of course. Ian On 4/23/07, Narendran Sivakumar wrote: > Dear All , > > I've implemented DYMO and comparing the performance of DYMO with other > protocols. Is there a way to analyze how energy efficient these protocols > especially DYMO as i consider energy efficiency a big factor. > > Any suggestions and ideas relating to this subject are most welcome. > > Thank You > > Naren > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 03:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFpx-00035K-7M; Tue, 24 Apr 2007 03:53:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgFpv-000358-SJ for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 03:53:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFpv-000350-I7 for manet@ietf.org; Tue, 24 Apr 2007 03:53:19 -0400 Received: from beru.its.uow.edu.au ([130.130.68.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFpv-0002Uw-0r for manet@ietf.org; Tue, 24 Apr 2007 03:53:19 -0400 Received: from jinn-nat.its.uow.edu.au ([130.130.68.211] helo=jinn.its.uow.edu.au) by beru.its.uow.edu.au with esmtp (Exim 4.63) (envelope-from ) id 1HgFpt-0006Nn-Rm; Tue, 24 Apr 2007 17:53:17 +1000 Received: from minerva.its.uow.edu.au (minerva.its.uow.edu.au [130.130.68.27]) by jinn.its.uow.edu.au (MOS 3.8.3-GA) with ESMTP id ACI29283; Tue, 24 Apr 2007 17:53:17 +1000 (EST) Received: (from minerva.its.uow.edu.au [130.130.68.101]) by minerva.its.uow.edu.au (MOS 3.8.2-GA) with HTTP/1.1 id ACS44858 (AUTH mehrana); Tue, 24 Apr 2007 17:53:17 +1000 (EST) From: Mehran Abolhasan Subject: Re: Fw: [manet] Re : Energy Efficiency in Routing Protocols To: Carl-Johan.Larsson@generic.se, manet@ietf.org X-Mailer: Mirapoint Webmail Direct 3.8.2-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20070424175317.ACS44858@minerva.its.uow.edu.au> Date: Tue, 24 Apr 2007 17:53:17 +1000 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi guys, Take a look at FORP routing protocol, i think they proposed something similar to what you are talking about (i.e. detecting route failure before it occurs using GPS). Regards, Mehran ---- Original message ---- >Date: Mon, 23 Apr 2007 17:37:39 +0200 >From: Carl-Johan.Larsson@generic.se >Subject: Fw: [manet] Re : Energy Efficiency in Routing Protocols >To: manet@ietf.org > > >I all, I most interested in this thought, I'm been doing som work on adding >Preemptive Route Maintenance on AODV by using simulated GPS coordinates, >The idea behind this is to change the route by a Route discovery before the >break occures like you, Naeendran, proposed. I'm beeen using GPS >coordinates to get the distance as a threashold when to activate the >mechanism. How where you going to measure the distance you talk about >Narendran, by signal power or gps strength? > >regards Calle > > "Narendran > Sivakumar" > il.com> "Ian Chakeres" > , > 2007-04-23 16:37 manet@ietf.org > cc > > Subject > Re: [manet] Re : Energy Efficiency > in Routing Protocols > > > > > > > > > > >Hi Ian, > >Well , In a wireless environment the energy levels used while transmission >is also important as higher the transmission power, higher is the range for >the nodes to transmit. > >Is it possible to add an Intelligence Mechanism to DYMO which would use >energy levels automatically based on the topology. >For Example : If a node X is transmitting to Y with I and J are the >intermediate nodes and the path is X-I-J-Y.If Y moves out of range of J, X >would again initiate Route Discovery to Y. If an intelligence mechanism is >used to increase the transmission power of J so that Y is within range even >if Y changes the location thereby saving time for another Route Discovery >process and less delay. On the flip side if Y is well within range of J, >then that same mechanism should be able to adjust the transmission power in >accordance with the closer Y, thereby saving energy. > >I believe that in a wireless environment , energy efficiency holds the key >in determining the effectiveness of an Routing Protocol, further more to >DYMO > >Thanks > >Naren > > >On 4/23/07, Ian Chakeres wrote: > I think it will be difficult to analyze energy efficiency. I also > think there are also lots of little tweaks that you could do to > improve efficiency, depending on your measure of course. > > Ian > > > On 4/23/07, Narendran Sivakumar wrote: > > Dear All , > > > > I've implemented DYMO and comparing the performance of DYMO with > other > > protocols. Is there a way to analyze how energy efficient these > protocols > > especially DYMO as i consider energy efficiency a big factor. > > > > Any suggestions and ideas relating to this subject are most > welcome. > > > > Thank You > > > > Naren > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 04:11:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgG7j-0006lu-T5; Tue, 24 Apr 2007 04:11:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgG7i-0006fz-Ml for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 04:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgG7i-0006ad-17 for manet@ietf.org; Tue, 24 Apr 2007 04:11:42 -0400 Received: from postis1.generic.se ([194.68.102.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgG7e-00070f-Fs for manet@ietf.org; Tue, 24 Apr 2007 04:11:42 -0400 Received: from [172.16.16.9] by [172.31.100.7] with TFS Secure Messaging Server; Tue, 24 Apr 2007 10:11:00 +0200 Received: from (unknown [172.16.16.9]) by GenFilter.intra.generic.se with smtp id 4ba2_bda27754_f23b_11db_a378_001143cd4a5e; Tue, 24 Apr 2007 10:13:53 +0200 In-Reply-To: <20070424175317.ACS44858@minerva.its.uow.edu.au> Subject: Re: Fw: [manet] Re : Energy Efficiency in Routing Protocols To: Mehran Abolhasan X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Carl-Johan.Larsson@generic.se Date: Tue, 24 Apr 2007 10:10:58 +0200 X-MIMETrack: Serialize by Router on Luna/Server/Generic(Release 7.0.2|September 26, 2006) at 2007-04-24 10:11:00 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Yeah thats true. It is exacly the same idea like FORP, but I wounder what Narendran was going to use to measure his distance in the mechanism proposed, you could to the exacly same thing as FORP but use the signal strength instead of gps... Regards, Calle >Hi guys, > >Take a look at FORP routing protocol, i think they proposed something similar to what you are talking about (i.e. detecting route failure before it >occurs using GPS). > >Regards, > >Mehran > >>>> ---- Original message ---- >Date: Mon, 23 Apr 2007 17:37:39 +0200 >From: Carl-Johan.Larsson@generic.se >Subject: Fw: [manet] Re : Energy Efficiency in Routing Protocols >To: manet@ietf.org > > >I all, I most interested in this thought, I'm been doing som work on adding >Preemptive Route Maintenance on AODV by using simulated GPS coordinates, >The idea behind this is to change the route by a Route discovery before the >break occures like you, Naeendran, proposed. I'm beeen using GPS >coordinates to get the distance as a threashold when to activate the >mechanism. How where you going to measure the distance you talk about >Narendran, by signal power or gps strength? > >regards Calle > > "Narendran > Sivakumar" > il.com> "Ian Chakeres" > , > 2007-04-23 16:37 manet@ietf.org > cc > > Subject > Re: [manet] Re : Energy Efficiency > in Routing Protocols > > > > > > > > > > >Hi Ian, > >Well , In a wireless environment the energy levels used while transmission >is also important as higher the transmission power, higher is the range for >the nodes to transmit. > >Is it possible to add an Intelligence Mechanism to DYMO which would use >energy levels automatically based on the topology. >For Example : If a node X is transmitting to Y with I and J are the >intermediate nodes and the path is X-I-J-Y.If Y moves out of range of J, X >would again initiate Route Discovery to Y. If an intelligence mechanism is >used to increase the transmission power of J so that Y is within range even >if Y changes the location thereby saving time for another Route Discovery >process and less delay. On the flip side if Y is well within range of J, >then that same mechanism should be able to adjust the transmission power in >accordance with the closer Y, thereby saving energy. > >I believe that in a wireless environment , energy efficiency holds the key >in determining the effectiveness of an Routing Protocol, further more to >DYMO > >Thanks > >Naren > > >On 4/23/07, Ian Chakeres wrote: > I think it will be difficult to analyze energy efficiency. I also > think there are also lots of little tweaks that you could do to > improve efficiency, depending on your measure of course. > > Ian > > > On 4/23/07, Narendran Sivakumar wrote: > > Dear All , > > > > I've implemented DYMO and comparing the performance of DYMO with > other > > protocols. Is there a way to analyze how energy efficient these > protocols > > especially DYMO as i consider energy efficiency a big factor. > > > > Any suggestions and ideas relating to this subject are most > welcome. > > > > Thank You > > > > Naren > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 04:19:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgGFN-0000TJ-2w; Tue, 24 Apr 2007 04:19:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgGFK-0000SH-IS for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 04:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgGFK-0000Re-54 for manet@ietf.org; Tue, 24 Apr 2007 04:19:34 -0400 Received: from smtp2.eurecom.fr ([193.55.113.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgGFI-00005p-EN for manet@ietf.org; Tue, 24 Apr 2007 04:19:34 -0400 Received: from monza.eurecom.fr ([192.168.106.15]) by smtp2.eurecom.fr with ESMTP; 24 Apr 2007 10:19:31 +0200 X-IronPort-AV: i="4.14,445,1170630000"; d="scan'208"; a="1371002:sNHT19043490" Received: from [172.17.20.174] (krabboss.eurecom.fr [172.17.20.174]) by monza.eurecom.fr (Postfix) with ESMTP id 452473C39D; Tue, 24 Apr 2007 10:19:31 +0200 (MEST) Message-ID: <462DBD91.1000901@eurecom.fr> Date: Tue, 24 Apr 2007 10:19:29 +0200 From: Jerome Haerri User-Agent: Thunderbird 2.0.0.0 (X11/20070326) MIME-Version: 1.0 To: Mehran Abolhasan Subject: Re: Fw: [manet] Re : Energy Efficiency in Routing Protocols References: <20070424175317.ACS44858@minerva.its.uow.edu.au> In-Reply-To: <20070424175317.ACS44858@minerva.its.uow.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi guys, Using GPS information for a lot of maintenance task in MANET has been well studied in the last two years under various names (Dead Reckoning, Mobility Prediction, Context Awareness). In most cases, it was able to successfully improve the tested protocol. I am also a strong supporter and active developer of this approach in order to improve MANET protocols. However, the GPS information needs to be obtained and exchanged between nodes. Besides, as everything should be compliant with standardized protocols DYMO, OLSRv2, W-OSPF, the geo-localization transmission should be compliant with the message structure of MANET protocols. We developed a IETF draft for that matter that may be of some interest to you in case you would like to adapt GPS information to DYMO and OLSRv2. You may find the geo-localization information in MANET problem statement here http://www.ietf.org/internet-drafts/draft-haerri-manet-position-problem-statement-00.txt and the description of a message format (TLV format) compliant with PacketBB here http://www.ietf.org/internet-drafts/draft-haerri-manet-position-signaling-00.txt Nevertheless, I think the objective of the MANET WG is to develop protocols that works in all cases (the GPS availability is a too strong assumption in MANET in general). Then, based on this, extension may be proposed (such as energy-based criterion, or GPS enhancement). I therefore think that "intelligent mechanisms" should not be standardized at that point, but maybe only cited as possible extensions. Then, based on a standardized and working version, it is always possible to develop improvements. Regards, Jerome Mehran Abolhasan wrote: > Hi guys, > > Take a look at FORP routing protocol, i think they proposed something similar to what you are talking about (i.e. detecting route failure before it occurs using GPS). > > Regards, > > Mehran > > > ---- Original message ---- >> Date: Mon, 23 Apr 2007 17:37:39 +0200 >> From: Carl-Johan.Larsson@generic.se >> Subject: Fw: [manet] Re : Energy Efficiency in Routing Protocols >> To: manet@ietf.org >> >> >> I all, I most interested in this thought, I'm been doing som work on adding >> Preemptive Route Maintenance on AODV by using simulated GPS coordinates, >> The idea behind this is to change the route by a Route discovery before the >> break occures like you, Naeendran, proposed. I'm beeen using GPS >> coordinates to get the distance as a threashold when to activate the >> mechanism. How where you going to measure the distance you talk about >> Narendran, by signal power or gps strength? >> >> regards Calle >> >> "Narendran >> Sivakumar" >> > il.com> "Ian Chakeres" >> , >> 2007-04-23 16:37 manet@ietf.org >> cc >> >> Subject >> Re: [manet] Re : Energy Efficiency >> in Routing Protocols >> >> >> >> >> >> >> >> >> >> >> Hi Ian, >> >> Well , In a wireless environment the energy levels used while transmission >> is also important as higher the transmission power, higher is the range for >> the nodes to transmit. >> >> Is it possible to add an Intelligence Mechanism to DYMO which would use >> energy levels automatically based on the topology. >> For Example : If a node X is transmitting to Y with I and J are the >> intermediate nodes and the path is X-I-J-Y.If Y moves out of range of J, X >> would again initiate Route Discovery to Y. If an intelligence mechanism is >> used to increase the transmission power of J so that Y is within range even >> if Y changes the location thereby saving time for another Route Discovery >> process and less delay. On the flip side if Y is well within range of J, >> then that same mechanism should be able to adjust the transmission power in >> accordance with the closer Y, thereby saving energy. >> >> I believe that in a wireless environment , energy efficiency holds the key >> in determining the effectiveness of an Routing Protocol, further more to >> DYMO >> >> Thanks >> >> Naren >> >> >> On 4/23/07, Ian Chakeres wrote: >> I think it will be difficult to analyze energy efficiency. I also >> think there are also lots of little tweaks that you could do to >> improve efficiency, depending on your measure of course. >> >> Ian >> >> >> On 4/23/07, Narendran Sivakumar wrote: >> > Dear All , >> > >> > I've implemented DYMO and comparing the performance of DYMO with >> other >> > protocols. Is there a way to analyze how energy efficient these >> protocols >> > especially DYMO as i consider energy efficiency a big factor. >> > >> > Any suggestions and ideas relating to this subject are most >> welcome. >> > >> > Thank You >> > >> > Naren >> > _______________________________________________ >> > manet mailing 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 -- Jerome Haerri Ph.D Candidate Eurecom Institute Mobile Communications Department 2229, Route des Cretes B.P. 193 06904 Sophia-Antipolis Cedex France Home : +33 (0)4 92 38 97 09 Office : +33 (0)4 93 00 26 76 Mob : +33 (0)6 10 79 72 83 E-mail : jerome.haerri@eurecom.fr Web : http://www.eurecom.fr/people/haerri.en.htm _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 05:46:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHb7-000260-Cf; Tue, 24 Apr 2007 05:46:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgHb5-00025q-Pb for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 05:46:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgHb5-00025E-FG for manet@ietf.org; Tue, 24 Apr 2007 05:46:07 -0400 Received: from evaki.its.uow.edu.au ([130.130.68.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgHb3-0004GY-5E for manet@ietf.org; Tue, 24 Apr 2007 05:46:05 -0400 Received: from jinn-nat.its.uow.edu.au ([130.130.68.211] helo=jinn.its.uow.edu.au) by evaki.its.uow.edu.au with esmtp (Exim 4.63) (envelope-from ) id 1HgHb1-0003W3-Kr; Tue, 24 Apr 2007 19:46:03 +1000 Received: from minerva.its.uow.edu.au (minerva.its.uow.edu.au [130.130.68.27]) by jinn.its.uow.edu.au (MOS 3.8.3-GA) with ESMTP id ACI31990; Tue, 24 Apr 2007 19:46:02 +1000 (EST) Received: (from minerva.its.uow.edu.au [130.130.68.101]) by minerva.its.uow.edu.au (MOS 3.8.2-GA) with HTTP/1.1 id ACS47640 (AUTH mehrana); Tue, 24 Apr 2007 19:46:02 +1000 (EST) From: Mehran Abolhasan Subject: Re: Fw: [manet] Re : Energy Efficiency in Routing Protocols To: Carl-Johan.Larsson@generic.se X-Mailer: Mirapoint Webmail Direct 3.8.2-GA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20070424194602.ACS47640@minerva.its.uow.edu.au> Date: Tue, 24 Apr 2007 19:46:02 +1000 (EST) X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Changing the Tx power to manipulate the topology is an area which has also received some attention, have a look at "topology control in ad hoc networks". Basically several strategies have been proposed which dynamically adjust the Tx power to ensure a more power efficient network. However, this is not to say that there is not much work left to be done here, particularly when routing is concerned. Regards, Mehran Abolhasan ---- Original message ---- >Date: Tue, 24 Apr 2007 10:10:58 +0200 >From: Carl-Johan.Larsson@generic.se >Subject: Re: Fw: [manet] Re : Energy Efficiency in Routing Protocols >To: Mehran Abolhasan >Cc: manet@ietf.org > >Yeah thats true. It is exacly the same idea like FORP, but I wounder what >Narendran was going to use to measure his distance in the mechanism >proposed, you could to the exacly same thing as FORP but use the signal >strength instead of gps... > >Regards, > >Calle > > >>Hi guys, >> >>Take a look at FORP routing protocol, i think they proposed something >similar to what you are talking about (i.e. detecting route failure before >it >occurs using GPS). >> >>Regards, >> >>Mehran >> >>>>> > > >---- Original message ---- >>Date: Mon, 23 Apr 2007 17:37:39 +0200 >>From: Carl-Johan.Larsson@generic.se >>Subject: Fw: [manet] Re : Energy Efficiency in Routing Protocols >>To: manet@ietf.org >> >> >>I all, I most interested in this thought, I'm been doing som work on >adding >>Preemptive Route Maintenance on AODV by using simulated GPS coordinates, >>The idea behind this is to change the route by a Route discovery before >the >>break occures like you, Naeendran, proposed. I'm beeen using GPS >>coordinates to get the distance as a threashold when to activate the >>mechanism. How where you going to measure the distance you talk about >>Narendran, by signal power or gps strength? >> >>regards Calle >> > >> "Narendran > >> Sivakumar" > >> >> il.com> "Ian Chakeres" > >> , > >> 2007-04-23 16:37 manet@ietf.org > >> cc > >> > >> Subject > >> Re: [manet] Re : Energy Efficiency > >> in Routing Protocols > >> > >> > >> > >> > >> > >> > >> >> >> >> >>Hi Ian, >> >>Well , In a wireless environment the energy levels used while transmission >>is also important as higher the transmission power, higher is the range >for >>the nodes to transmit. >> >>Is it possible to add an Intelligence Mechanism to DYMO which would use >>energy levels automatically based on the topology. >>For Example : If a node X is transmitting to Y with I and J are the >>intermediate nodes and the path is X-I-J-Y.If Y moves out of range of J, X >>would again initiate Route Discovery to Y. If an intelligence mechanism is >>used to increase the transmission power of J so that Y is within range >even >>if Y changes the location thereby saving time for another Route Discovery >>process and less delay. On the flip side if Y is well within range of J, >>then that same mechanism should be able to adjust the transmission power >in >>accordance with the closer Y, thereby saving energy. >> >>I believe that in a wireless environment , energy efficiency holds the key >>in determining the effectiveness of an Routing Protocol, further more to >>DYMO >> >>Thanks >> >>Naren >> >> >>On 4/23/07, Ian Chakeres wrote: >> I think it will be difficult to analyze energy efficiency. I also >> think there are also lots of little tweaks that you could do to >> improve efficiency, depending on your measure of course. >> >> Ian >> >> >> On 4/23/07, Narendran Sivakumar wrote: >> > Dear All , >> > >> > I've implemented DYMO and comparing the performance of DYMO with >> other >> > protocols. Is there a way to analyze how energy efficient these >> protocols >> > especially DYMO as i consider energy efficiency a big factor. >> > >> > Any suggestions and ideas relating to this subject are most >> welcome. >> > >> > Thank You >> > >> > Naren >> > _______________________________________________ >> > manet mailing 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 manet-bounces@ietf.org Tue Apr 24 06:35:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgIMQ-0003B1-L5; Tue, 24 Apr 2007 06:35:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgIMP-0003Ao-7m for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 06:35:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgIMO-0003Ag-Sh for manet@ietf.org; Tue, 24 Apr 2007 06:35:00 -0400 Received: from relay.uclm.es ([161.67.124.26]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HgIML-0002l7-VP for manet@ietf.org; Tue, 24 Apr 2007 06:35:00 -0400 Received: from al-basit.dsi.uclm.es (al-basit.dsi.uclm.es [161.67.132.10]) by relay.uclm.es (8.11.6/8.11.6) with ESMTP id l3OAYQo19112; Tue, 24 Apr 2007 12:34:26 +0200 Received: from localhost (al-basit [127.0.0.1]) by al-basit.dsi.uclm.es (Postfix) with ESMTP id 995726BC81E; Tue, 24 Apr 2007 12:34:25 +0200 (CEST) Received: from al-basit.dsi.uclm.es ([127.0.0.1]) by localhost (al-basit.dsi.uclm.es [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 01129-04-89; Tue, 24 Apr 2007 12:34:21 +0200 (CEST) Received: from [161.67.8.77] (luna.info-ab.uclm.es [161.67.8.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by al-basit.dsi.uclm.es (Postfix) with ESMTP id AE7E46BC826; Tue, 24 Apr 2007 12:34:11 +0200 (CEST) Message-ID: <462DDC3B.4010004@dsi.uclm.es> Date: Tue, 24 Apr 2007 12:30:19 +0200 From: "M. Blanca Caminero Herraez" Organization: DSI - UCLM User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: amavisd-new at dsi.uclm.es Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by relay.uclm.es id l3OAYQo19112 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: rwerner@site.uottawa.ca Subject: [manet] First Call for Papers: 2nd ACM International PM2HW2N 2007 Workshop X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [Apologies if you receive multiple copies of this CFPs] ---------------------------------------------------------- CALL FOR PAPERS =20 2nd ACM International Workshop on Performance Monitoring, Measurement, and Evaluation of Heterogeneous Wireless and Wired Networks- PM2HW2N'07 http://www.i3a.uclm.es/pm2hw2n07/ To be held in conjunction with 10th ACM/IEEE International Symposium on =20 Modeling, Analysis and Simulation of Wireless and Mobile Systems - MSWiM'07 http://www.cs.unibo.it/projects/mswim2007/ October 22 - 26, 2007 Chania, Crete Island, Greece SCOPE: Wireless networks, including ad hoc, sensor, along with ubiquitous, have witnessed over the past few years their fastest growth period and have become increasingly complex. Nonetheless, their performance evaluation and analysis have been conducted mostly through software simulations (e.g. using ns-2 or OPNET tools). Very recently, some research efforts have been directed towards measuring real-world commercial and experimental networks; constructing models based on real-world data and using prototypes to more realistically and comprehensively evaluate the suggested solutions and more specifically validate the assumptions and the conclusions reached via the simulation approach. The monitoring, measurements, and evaluation of heterogeneous wired and wireless mobile networks poses a new set of unique challenges due to the unique inherent properties of these systems and due to the characteristics of the wireless transmission medium. The aim of this workshop, whose 1st edition was held in 2006 in Torremolinos (Spain), is to bring together scientists, engineers, and practitioners to share and exchange their experiences, discuss challenges, and report state-of-the-art and in-progress research on all aspects of performance measurements, monitoring, and evaluation of heterogeneous wired and wireless mobile networks, including, wireless ad hoc, sensor, and ubiquitous networks. A detailed list on the workshop topics can be found at the PM2HW2N07's site: http://www.i3a.uclm.es/pm2hw2n07/ ORGANIZATION: General Chair Mohamed OULD-KHAOUA, University of Glasgow, Glasgow, UK Contact: mohamed at dcs.gla.ac.uk Program Chair Blanca CAMINERO, University of Castilla-La Mancha, Albacete, Spain Contact: blanca at dsi.uclm.es Program Vice-Chair Richard PAZZI, University of Ottawa, Ottawa, Canada Contact: rwerner at site.uottawa.ca TECHNICAL PROGRAM COMMITTEE (in progress) N. Abu-Ghazaleh, SUNY-Binghamton (USA) K. Al-Begain, University of Glamorgan (UK) I. Awan, University of Bradford (UK) A. Bermudez, University of Castilla-La Mancha (Spain) R. Beyah, GSU (USA) J.C. Cano, Technical University of Valencia (Spain) C. Carrion, University of Castilla-La Mancha (Spain) M. Colajanni, University of Modena (Italy) P. Cuenca, University of Castilla-La Mancha (Spain) G. Dodero, Free University of Bozen-Bolzano (Italy) E. Fleury, INSA de Lyon (France) X. Jin,University of Bradford (UK) E. Karatza, Aristotle University of Thessaloniki (Greece) A. Ksentini, University of Cergy-Pontoise (France) G. Min, University of Bradford (UK) M. Naimi, University of Cergy-Pontoise (France) S. Nikoletseas, University of Patras and CTI (Greece) T. Olivares, University of Castilla-La Mancha (Spain) L. Orozco-Barbosa, University of Castilla-La Mancha (Spain) A. Passarella, CNR-IIT Pisa (Italy) M. Perez-Malumbres, Miguel Hernandez University (Spain) F. Quiles, University of Castilla-La Mancha (Spain) P. Ruiz, University of Murcia (Spain) J. A. Sanchez-Laguna, University of Murcia (Spain) M. S. Squillante, IBM T.J. Watson Research Center (USA) C. Skianis, NCSR Demokritos (Greece) S. Tilak, San Diego Supercomputing Center/UCSD (USA) A. Zomaya, University of Sydney (Australia) PAPER SUBMISSION: Authors are invited to submit manuscripts reporting original unpublished research and recent developments in the topics related to the workshop. The length of the papers should not exceed 10 single-spaced pages, formatted using the ACM style. LaTex2e and MS Word templates can be found at http://www.acm.org/sigs/pubs/proceed/template.html. All papers will be peer reviewed and the comments will be provided to the authors. Accepted papers will appear in the workshop proceedings, published by ACM. At least one author of accepted papers is expected to attend the workshop to present its contribution. Paper submission must be done electronically through the OpenConf system at http://investigacion.uclm.es/pm2hw2n07/. IMPORTANT DATES: Submission Deadline: 1 June 2007 Author Notification: 1 July 2007 Camera ready: TBA --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NUEVA DIRECCION DE CORREO / NEW E-MAIL ADDRESS --> blanca@dsi.uclm.es =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Maria Blanca Caminero Herraez Prof. Contratado Doctor - CD Professor Dpto. Sistemas Inform=E1ticos - Computer Systems Department Escuela Polit=E9cnica Superior Universidad de Castilla-La Mancha 02071 - Albacete (SPAIN) --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NUEVA DIRECCION DE CORREO / NEW E-MAIL ADDRESS --> blanca@dsi.uclm.es =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Maria Blanca Caminero Herraez Prof. Contratado Doctor - CD Professor Dpto. Sistemas Inform=E1ticos - Computer Systems Department Escuela Polit=E9cnica Superior Universidad de Castilla-La Mancha 02071 - Albacete (SPAIN) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 06:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgISW-0001mE-Nb; Tue, 24 Apr 2007 06:41:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgISU-0001m7-Ka for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 06:41:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgISU-0001lz-B0 for manet@ietf.org; Tue, 24 Apr 2007 06:41:18 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgISR-00062S-Of for manet@ietf.org; Tue, 24 Apr 2007 06:41:18 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1177411274!8205818!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 8256 invoked from network); 24 Apr 2007 10:41:14 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 24 Apr 2007 10:41:14 -0000 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l3OAfDfX005847; Tue, 24 Apr 2007 03:41:13 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr01.mot.com (8.13.5/Vontu) with SMTP id l3OAfDFq003939; Tue, 24 Apr 2007 05:41:13 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id l3OAfAfs003855; Tue, 24 Apr 2007 05:41:11 -0500 (CDT) Message-ID: <462DDEBE.7070108@gmail.com> Date: Tue, 24 Apr 2007 12:41:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "M. Blanca Caminero Herraez" Subject: Re: [manet] First Call for Papers: 2nd ACM International PM2HW2N 2007 Workshop References: <462DDC3B.4010004@dsi.uclm.es> In-Reply-To: <462DDC3B.4010004@dsi.uclm.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000735-2, 23/04/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: manet@ietf.org, rwerner@site.uottawa.ca X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi M. Blanca Caminero Herraez, Please refrain from further posting Call for Papers on the MANET WG mailing list. Only WG product related events (eg INTEROPS) are considered relevant. If you have a doubt please ask the Chairs before posting a Call for Papers. Thanks, Alex M. Blanca Caminero Herraez wrote: > ================================================================ > > [Apologies if you receive multiple copies of this CFPs] > ---------------------------------------------------------- > CALL FOR PAPERS > 2nd ACM International Workshop on Performance Monitoring, Measurement, > and Evaluation of Heterogeneous Wireless and Wired Networks- PM2HW2N'07 > > http://www.i3a.uclm.es/pm2hw2n07/ > > To be held in conjunction with 10th ACM/IEEE International Symposium on > Modeling, Analysis and Simulation > of Wireless and Mobile Systems - MSWiM'07 > http://www.cs.unibo.it/projects/mswim2007/ > > October 22 - 26, 2007 > Chania, Crete Island, Greece > > > SCOPE: > Wireless networks, including ad hoc, sensor, along with ubiquitous, have > witnessed over the past few years their fastest growth period and have > become increasingly complex. Nonetheless, their performance evaluation > and analysis have been conducted mostly through software simulations > (e.g. using ns-2 or OPNET tools). Very recently, some research efforts > have been directed towards measuring real-world commercial and > experimental networks; constructing models based on real-world data and > using prototypes to more realistically and comprehensively evaluate the > suggested solutions and more specifically validate the assumptions and > the conclusions reached via the simulation approach. > > The monitoring, measurements, and evaluation of heterogeneous wired and > wireless mobile networks poses a new set of unique challenges due to the > unique inherent properties of these systems and due to the > characteristics of the wireless transmission medium. > > The aim of this workshop, whose 1st edition was held in 2006 in > Torremolinos (Spain), is to bring together scientists, engineers, and > practitioners to share and exchange their experiences, discuss > challenges, and report state-of-the-art and in-progress research on all > aspects of performance measurements, monitoring, and evaluation of > heterogeneous wired and wireless mobile networks, including, wireless ad > hoc, sensor, and ubiquitous networks. > > A detailed list on the workshop topics can be found at the PM2HW2N07's > site: http://www.i3a.uclm.es/pm2hw2n07/ > > ORGANIZATION: > General Chair Mohamed OULD-KHAOUA, University of Glasgow, Glasgow, UK > Contact: mohamed at dcs.gla.ac.uk > > Program Chair > Blanca CAMINERO, University of Castilla-La Mancha, Albacete, Spain > Contact: blanca at dsi.uclm.es > > Program Vice-Chair > Richard PAZZI, University of Ottawa, Ottawa, Canada > Contact: rwerner at site.uottawa.ca > > > TECHNICAL PROGRAM COMMITTEE > (in progress) > > N. Abu-Ghazaleh, SUNY-Binghamton (USA) > K. Al-Begain, University of Glamorgan (UK) > I. Awan, University of Bradford (UK) > A. Bermudez, University of Castilla-La Mancha (Spain) > R. Beyah, GSU (USA) > J.C. Cano, Technical University of Valencia (Spain) > C. Carrion, University of Castilla-La Mancha (Spain) > M. Colajanni, University of Modena (Italy) > P. Cuenca, University of Castilla-La Mancha (Spain) > G. Dodero, Free University of Bozen-Bolzano (Italy) > E. Fleury, INSA de Lyon (France) > X. Jin,University of Bradford (UK) > E. Karatza, Aristotle University of Thessaloniki (Greece) > A. Ksentini, University of Cergy-Pontoise (France) > G. Min, University of Bradford (UK) > M. Naimi, University of Cergy-Pontoise (France) > S. Nikoletseas, University of Patras and CTI (Greece) > T. Olivares, University of Castilla-La Mancha (Spain) > L. Orozco-Barbosa, University of Castilla-La Mancha (Spain) > A. Passarella, CNR-IIT Pisa (Italy) > M. Perez-Malumbres, Miguel Hernandez University (Spain) > F. Quiles, University of Castilla-La Mancha (Spain) > P. Ruiz, University of Murcia (Spain) > J. A. Sanchez-Laguna, University of Murcia (Spain) > M. S. Squillante, IBM T.J. Watson Research Center (USA) > C. Skianis, NCSR Demokritos (Greece) > S. Tilak, San Diego Supercomputing Center/UCSD (USA) > A. Zomaya, University of Sydney (Australia) > > PAPER SUBMISSION: > Authors are invited to submit manuscripts reporting original unpublished > research and recent developments in the topics related to the workshop. > The length of the papers should not exceed 10 single-spaced pages, > formatted using the ACM style. LaTex2e and MS Word templates can be > found at http://www.acm.org/sigs/pubs/proceed/template.html. > > All papers will be peer reviewed and the comments will be provided to > the authors. Accepted papers will appear in the workshop proceedings, > published by ACM. At least one author of accepted papers is expected to > attend the workshop to present its contribution. > > Paper submission must be done electronically through the OpenConf system > at http://investigacion.uclm.es/pm2hw2n07/. > > IMPORTANT DATES: > Submission Deadline: 1 June 2007 > Author Notification: 1 July 2007 > Camera ready: TBA > > > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 07:17:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJ12-0006kb-QC; Tue, 24 Apr 2007 07:17:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgJ10-0006kM-SX for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 07:16:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJ10-0006kD-Iz for manet@ietf.org; Tue, 24 Apr 2007 07:16:58 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgJ0y-0004g5-BW for manet@ietf.org; Tue, 24 Apr 2007 07:16:58 -0400 Received: by wx-out-0506.google.com with SMTP id h31so2226858wxd for ; Tue, 24 Apr 2007 04:16:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=AU/m/SZWJybsdVNIrLMsChdqnW5dLxl+Sm5aKanB9sb8IqHL+TQVd2uo83BJI16iJ+xGm7Pgx2tMWStorpIfLFbQosEAT38FNpH6X47pm6KwkOCmc+A4USiwrwT2K6rBcYopMitVJr182wN9eCgdqtUFkeI+av77CcYahCJfCfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=iWRS0scrR9+1tIL4r7nfqjVXUqygwvF9yxjpkj1zofgO+wShnSM/IkoWHJMUWGwdm1oYaXJPTTpxlsxHzYsmrSjQT/lGAkaCPgJQfEN8HFHvfmpewbjASJhDfzAfpvUnYUCX+5yUt+AIL8HZJIbuP0ohWeoOLIwIgmROq7xG3to= Received: by 10.90.99.20 with SMTP id w20mr5729492agb.1177413415862; Tue, 24 Apr 2007 04:16:55 -0700 (PDT) Received: by 10.90.74.16 with HTTP; Tue, 24 Apr 2007 04:16:55 -0700 (PDT) Message-ID: Date: Tue, 24 Apr 2007 13:16:55 +0200 From: "Romain Thouvenin" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [manet] DYMO comments X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Having now a big part of the DYMO specs implemented, I reread the whole document to see if I have some general comments that I could provide. I found some : - Well this one is just a question actually. According to the recommendations, ROUTE_NEW_TIMEOUT = ROUTE_USED_TIMEOUT. So one could use just one ROUTE_USED timer and set it at the creation of the route. It would take less memory and be simpler to implement. When is it relevant to have different timers ? - A detail : though section 4.2.2 does not mention MsgHdr.HopCnt, sections 5.3.1, 5.3.2, 5.3.4 and 5.5.3 do. Furthermore, packetbb does not allow the message header to have a HopLimit but not a HopCnt. Thus I guess 4.2.2 should also require MsgHdr.HopCnt - section 5.3.4, "Next, this node checks whether its routing table has an entry to the AddBlk.OrigNode.Address using longest-prefix matching." Before doing that, ThisNode must check whether it is the originator of the message. Otherwise it may add a route for himself, a (wrong) route for additional nodes in the RM, and it may forward it, introducing a lot of replicate messages. I agree this is kind of obvious, but actually I didn't think about it at first, and I saw the result... - section 5.5.2, "To avoid removing forwarding routes that are being used, a node SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT for the route to the IP.SourceAddress upon receiving a data packet.". I am working on sensor networks, and in this context it's quite often that, most of the time, nodes send data measurement to a base station, which will not reply. So the reverse route is not going to be used soon, and it is useless to keep it for long. Maybe setting the timer should be administratively configurable ? Here is what I found, hope it helps. Regards, Romain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 08:49:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKSp-0003ir-M8; Tue, 24 Apr 2007 08:49:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgKSn-0003ik-Oq for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 08:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKSn-0003ic-FI for manet@ietf.org; Tue, 24 Apr 2007 08:49:45 -0400 Received: from postis1.generic.se ([194.68.102.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKSm-0006z2-S5 for manet@ietf.org; Tue, 24 Apr 2007 08:49:45 -0400 Received: from [172.16.16.9] by [172.31.100.7] with TFS Secure Messaging Server; Tue, 24 Apr 2007 14:49:09 +0200 Received: from (unknown [172.16.16.9]) by GenFilter.intra.generic.se with smtp id 4c00_98f3dad4_f262_11db_985d_001143cd4a5e; Tue, 24 Apr 2007 14:52:02 +0200 In-Reply-To: <462DF918.9090309@ornl.gov> Subject: Re: Fw: [manet] Re : Energy Efficiency in Routing Protocols To: Lawrence MacIntyre X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Carl-Johan.Larsson@generic.se Date: Tue, 24 Apr 2007 14:49:07 +0200 X-MIMETrack: Serialize by Router on Luna/Server/Generic(Release 7.0.2|September 26, 2006) at 2007-04-24 14:49:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org yeah, that sounds like the same conclutions I made. Has anyone tried to predict the link break on basis of both GPS and Signal Strength?? A combination of them both maybe can be a good approximation of the world around the node.. Just a thought... regards calle Calle: On flat terrain, the GPS measurement is valuable, and it works well. However, most of the time, terrain effects will render the absolute distance almost useless UNLESS you take the local topography into account. So if you have a topographical map of the area, you could probably make this work. The other problem is that GPS takes a lot of power, and the signal path computations take a lot of power. In the case of battery-powered routers, this would be another problem with that approach. This one time, at band camp, Carl-Johan.Larsson@generic.se wrote: > I all, I most interested in this thought, I'm been doing som work on adding > Preemptive Route Maintenance on AODV by using simulated GPS coordinates, > The idea behind this is to change the route by a Route discovery before the > break occures like you, Naeendran, proposed. I'm beeen using GPS > coordinates to get the distance as a threashold when to activate the > mechanism. How where you going to measure the distance you talk about > Narendran, by signal power or gps strength? > > regards Calle > > "Narendran > Sivakumar" > il.com> "Ian Chakeres" > , > 2007-04-23 16:37 manet@ietf.org > cc > > Subject > Re: [manet] Re : Energy Efficiency > in Routing Protocols > > > > > > > > > > > Hi Ian, > > Well , In a wireless environment the energy levels used while transmission > is also important as higher the transmission power, higher is the range for > the nodes to transmit. > > Is it possible to add an Intelligence Mechanism to DYMO which would use > energy levels automatically based on the topology. > For Example : If a node X is transmitting to Y with I and J are the > intermediate nodes and the path is X-I-J-Y.If Y moves out of range of J, X > would again initiate Route Discovery to Y. If an intelligence mechanism is > used to increase the transmission power of J so that Y is within range even > if Y changes the location thereby saving time for another Route Discovery > process and less delay. On the flip side if Y is well within range of J, > then that same mechanism should be able to adjust the transmission power in > accordance with the closer Y, thereby saving energy. > > I believe that in a wireless environment , energy efficiency holds the key > in determining the effectiveness of an Routing Protocol, further more to > DYMO > > Thanks > > Naren > > > On 4/23/07, Ian Chakeres wrote: > I think it will be difficult to analyze energy efficiency. I also > think there are also lots of little tweaks that you could do to > improve efficiency, depending on your measure of course. > > Ian > > > On 4/23/07, Narendran Sivakumar wrote: > > Dear All , > > > > I've implemented DYMO and comparing the performance of DYMO with > other > > protocols. Is there a way to analyze how energy efficient these > protocols > > especially DYMO as i consider energy efficiency a big factor. > > > > Any suggestions and ideas relating to this subject are most > welcome. > > > > Thank You > > > > Naren > > _______________________________________________ > > manet mailing 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 > -- Lawrence MacIntyre macintyrelp@ornl.gov Oak Ridge National Laboratory 865.574.8696 Cyber Space and Information Intelligence Research Group SIPRNet: macintyrelp@ornl.doe.sgov.gov ICMail: ormaclp@doe.ic.gov _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 10:46:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMHV-00064d-Qp; Tue, 24 Apr 2007 10:46:13 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgMHU-00064Q-PQ for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 10:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgMHU-00063q-Fb for manet@ietf.org; Tue, 24 Apr 2007 10:46:12 -0400 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgMHP-00043g-5h for manet@ietf.org; Tue, 24 Apr 2007 10:46:12 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 9E73D340EC; Tue, 24 Apr 2007 10:46:04 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 10:45:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline:June 1 Date: Tue, 24 Apr 2007 10:45:48 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC01CC6B7A@tayexc14.americas.cpqcorp.net> In-Reply-To: <462C84B8.6070700@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon Valley, USA) Deadline:June 1 Thread-Index: AceFjuEhjSs7Y7LXQY+cbrjdFZpL/QA8B8Vg References: <2D91CC98-D9EB-4E5D-9BD5-58F485FC3E23@unina.it><74DF4483-BD61-4821-A0F7-6472580689B0@unina.it> <462C84B8.6070700@gmail.com> From: "Bound, Jim" To: "Alexandru Petrescu" , "Marcello Caleffi" X-OriginalArrivalTime: 24 Apr 2007 14:45:50.0113 (UTC) FILETIME=[404D6110:01C7867F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I support Alex's request. The IETF mission is not to support researhers, but rather all work, researhers included, to submit ideas to further the enhancment of Internet protocols predmominantly within working groups. It is not a marketing mail list to request CFPs. /jim=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Monday, April 23, 2007 6:05 AM > To: Marcello Caleffi > Cc: manet > Subject: Re: [manet] CFP: IEEE/WIC/ACM WI 2007 (Silicon=20 > Valley, USA) Deadline:June 1 >=20 > Marcello Caleffi wrote: > >=20 > > Instead, I think CFPs are usefull to researchers work. If you don't=20 > > need to them, you could simply discard. >=20 > Hi Marcello. I think indeed CfPs are useful for researchers=20 > work in the MANET area. However, I also think there are many=20 > other venues for distributing MANET-related CfPs widely, like=20 > specialized journals of ACM and IEEE which have very large=20 > readerships and available to interested researchers and grads. >=20 > What's easier for me: discard CfPs every day? Or tell CfPs=20 > posters to no longer post on the MANET list? I much prefer=20 > the latter. >=20 > I propose to reject all Call for Papers in the MANET Working Group. >=20 > Alex >=20 > >=20 > > Il giorno 22/apr/07, alle ore 22:01, Alexandru Petrescu ha scritto: > >=20 > >>>> > >=20 > > Marcello Caleffi, Ph.D. student > > Department of Electronic and Telecommunication Engineering=20 > University=20 > > of Naples "Federico II" > > Via Claudio 21 > > 80125 Naples ITALY > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit=20 > http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 13:39:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOy4-00079p-LQ; Tue, 24 Apr 2007 13:38:20 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgOy3-00079g-D5 for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 13:38:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgOy3-00079Y-3V for manet@ietf.org; Tue, 24 Apr 2007 13:38:19 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgOy2-00078b-Kw for manet@ietf.org; Tue, 24 Apr 2007 13:38:19 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3OHcBA0000605; Tue, 24 Apr 2007 20:38:15 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 20:38:14 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 12:38:11 -0500 Received: from [10.162.28.213] ([10.162.28.213]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 12:38:09 -0500 Message-ID: <462E407C.3040909@nokia.com> Date: Tue, 24 Apr 2007 10:38:04 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Romain Thouvenin Subject: Re: [manet] DYMO comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2007 17:38:10.0471 (UTC) FILETIME=[53A2CB70:01C78697] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Romain, Your questions raise some interesting issues about the current documents. ext Romain Thouvenin wrote: > - section 5.5.2, "To avoid removing forwarding routes that are being > used, a node SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT > for the route to the IP.SourceAddress upon receiving a data packet.". > I am working on sensor networks, and in this context it's quite often > that, most of the time, nodes send data measurement to a base station, > which will not reply. So the reverse route is not going to be used > soon, and it is useless to keep it for long. Maybe setting the timer > should be administratively configurable ? Actually, I think there are two points here. First, I think that a route request should be able to require that the destination be the node to supply a RREP, which means that intermediate nodes are disqualified. This was implicit in early versions of DYMO, and the current specification provides this functionality if the originator of a RREQ does not include the destination sequence number (but see below). There is already the specification for gratuitous RREP, which is a huge win for bidirectional routes. When only the destination is allowed to respond, then there is no need for the gratuitous RREP, but I think that would be a natural conclusion from the existing specification when only the destination can send RREP. I would prefer that there be a flag to control this behavior of maintaining reverse routes. This flag would also inhibit the sending of gratuituous RREP. If intermediate nodes were explicitly excluded from sending RREP, then they could still maintain reverse routes, so these features are not tightly bound even though there is some relationship. I'd also be in favor of an explicit flag for excluding RREPs from intermediate node, instead of the abovementioned implicit behavior. This would have the side benefit of avoiding unnecessary incrementation of sequence number for this case, which would only matter depending on how often the intermediate node RREP were disabled in practice. Just where to put the flags is not so clear to me. In the abstract, I am very much in favor of making use of a generalized header for DYMO messages (which is the intent in packetbb). However, as noted previously I think the balance has to be tilted towards energy conservation whenever possible. I didn't see right off where to put flags in the generalized header unless it would be in the "message-semantics" field. If we can't have message flags, then I think the design is wrong. But I might have missed something. I still owe a review of the packetbb specification, which I have not completed. I hope I find out where to put flags before I finish the review. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 16:17:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRRm-00006j-MA; Tue, 24 Apr 2007 16:17:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgRRk-0008Ut-TO for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 16:17:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRRk-0008Ul-Jx for manet@ietf.org; Tue, 24 Apr 2007 16:17:08 -0400 Received: from wr-out-0506.google.com ([64.233.184.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgRRk-00028r-AP for manet@ietf.org; Tue, 24 Apr 2007 16:17:08 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1997198wri for ; Tue, 24 Apr 2007 13:17:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MfqslfnVoltB7fvfz9Pg8hGaw6K/FAjjtVGaJIp7JZH1TaCxTKhmIHfncp30zRrS8VCvPU8hYfLLstQ0IG8qNUkHLvabiC+jguFWpX0ksjD5oMP0Aw4rngkLAqcU3JonQEJI9mRktyP6rBslCBAWjRsylsglShhY5SJbSvK37NE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UWP47np9IBVplqyubhG0yZQeuhYMOyNQPieyNq2W53R2o5QkqRPoTtmJ+PxW7twbq6wrVj4buful7kajijpkooPWgRF/Qec62Mab02qCW8NMm/W0lPz9wBS7z99/sQSWdzZbDCDWJq8GF6bfqwOHKUfufpuIqSLadTmEf2QgNi8= Received: by 10.90.52.18 with SMTP id z18mr2361287agz.1177445827803; Tue, 24 Apr 2007 13:17:07 -0700 (PDT) Received: by 10.90.74.16 with HTTP; Tue, 24 Apr 2007 13:17:07 -0700 (PDT) Message-ID: Date: Tue, 24 Apr 2007 22:17:07 +0200 From: "Romain Thouvenin" To: "Charles E. Perkins" Subject: Re: [manet] DYMO comments In-Reply-To: <462E407C.3040909@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462E407C.3040909@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 4/24/07, Charles E. Perkins wrote: > > Hello Romain, > > Your questions raise some interesting issues about > the current documents. > > ext Romain Thouvenin wrote: > > - section 5.5.2, "To avoid removing forwarding routes that are being > > used, a node SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT > > for the route to the IP.SourceAddress upon receiving a data packet.". > > I am working on sensor networks, and in this context it's quite often > > that, most of the time, nodes send data measurement to a base station, > > which will not reply. So the reverse route is not going to be used > > soon, and it is useless to keep it for long. Maybe setting the timer > > should be administratively configurable ? > Actually, I think there are two points here. > > First, I think that a route request should be able to > require that the destination be the node to supply > a RREP, which means that intermediate nodes are > disqualified. This was implicit in early versions of > DYMO, and the current specification provides this > functionality if the originator of a RREQ does not > include the destination sequence number (but see > below). > > There is already the specification for gratuitous RREP, > which is a huge win for bidirectional routes. When > only the destination is allowed to respond, then there is > no need for the gratuitous RREP, but I think that would > be a natural conclusion from the existing specification > when only the destination can send RREP. > > I would prefer that there be a flag to control this > behavior of maintaining reverse routes. This flag would > also inhibit the sending of gratuituous RREP. If > intermediate nodes were explicitly excluded from > sending RREP, then they could still maintain reverse > routes, so these features are not tightly bound even > though there is some relationship. > > I'd also be in favor of an explicit flag for excluding > RREPs from intermediate node, instead of the > abovementioned implicit behavior. This would > have the side benefit of avoiding unnecessary > incrementation of sequence number for this case, > which would only matter depending on how often > the intermediate node RREP were disabled in > practice. I agree. Also, for sensor networks again, routes may be quite stable. So it would save quite a lot of messages and energy if a new node could get the routes from its neighbors, even if it has no idea of the destination's sequence number. It would be even better if the new node had a mean of asking for any additional information that intermediate RREP senders would find useful, with another flag I guess. > Just where to put the flags is not so clear to me. > In the abstract, I am very much in favor of making > use of a generalized header for DYMO messages > (which is the intent in packetbb). However, as > noted previously I think the balance has to be > tilted towards energy conservation whenever > possible. I didn't see right off where to put flags > in the generalized header unless it would be in the > "message-semantics" field. If we can't have message > flags, then I think the design is wrong. But I might > have missed something. I can't see either. The only place where protocols can put protocol-specific information that apply to the whole message in the TLV-block. Using a TLV is definitely too much where a few bits could do it. I guess you're right, packetbb misses a flag system. > I still owe a review of the packetbb specification, > which I have not completed. I hope I find out > where to put flags before I finish the review. I also would like to take some time to comment packetbb. In my DYMO format we previously discussed, address blocks and address-tlv blocks are the same block, and included values are specified with DYMO-specific flags in the block header. Since routing protocols probably don't need 256 TLV types, but rather less than 8 (or maybe 16), this kind of
{
}* block might be interesting for packetbb. Regards, Romain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 16:21:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRVW-000435-47; Tue, 24 Apr 2007 16:21:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgRVU-0003ti-1R for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 16:21:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgRVT-0003rg-Mw for manet@ietf.org; Tue, 24 Apr 2007 16:20:59 -0400 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgRVS-0003D4-Gh for manet@ietf.org; Tue, 24 Apr 2007 16:20:59 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1998846wri for ; Tue, 24 Apr 2007 13:20:58 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Gin/wGp07y8CuNIrlXJJzobi6ksjITmq/2zkl8qyXTkCO4RpKhcZWN66Hr6IkwVlx2HC5r/W/bbgsFwkq1Fa0tiEiU3j1o/ll3gjgVYDYdHg/F46Ii1n3srCsncx+1xo1ASNjWxgGPuM0tVPyy2pxqTlgRbZE4AYMM5BxtbWqiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t2x5eGOCua0tThJ5raFazTXsiP+ZqxZmcEu4C5OIm9hf7Ga3KQ7AMYXBgP50A5Eq1YoPiUStdo72IzKptxW5SW03GwWKx7aLYMdvDC84KuGz/XwyM/G6o6SXAA9ckX9CuD4eFf1CL/JPGMECrqpCSYCOMpJOSOjFqrUDM8JLMyM= Received: by 10.90.113.18 with SMTP id l18mr3059561agc.1177446057918; Tue, 24 Apr 2007 13:20:57 -0700 (PDT) Received: by 10.90.74.16 with HTTP; Tue, 24 Apr 2007 13:20:57 -0700 (PDT) Message-ID: Date: Tue, 24 Apr 2007 22:20:57 +0200 From: "Romain Thouvenin" To: "Charles E. Perkins" Subject: Re: [manet] DYMO comments In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <462E407C.3040909@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 4/24/07, Romain Thouvenin wrote: > I can't see either. The only place where protocols can put > protocol-specific information that apply to the whole message in the > TLV-block. Please read : "seems to be the TLV block". Romain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Apr 24 21:50:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWdd-0000GS-He; Tue, 24 Apr 2007 21:49:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgWdb-0000GF-J5 for manet-confirm+ok@megatron.ietf.org; Tue, 24 Apr 2007 21:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWda-0000G4-5X for manet@ietf.org; Tue, 24 Apr 2007 21:49:42 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgWdU-00047m-S8 for manet@ietf.org; Tue, 24 Apr 2007 21:49:42 -0400 Received: by wr-out-0506.google.com with SMTP id 71so57569wri for ; Tue, 24 Apr 2007 18:49:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=dDamqN2NCQDs0phlOK+4oJnZh1P0F3dJ3oOic6o1h2FSF99EDQNjFAyeV0t6qTxzeO1dZOcks98+MCQQiIrECvnLeA42LK24TlzSyvlRhVt5qIxrUHV3XO86nfwoM6+Ryu+mWhbGsXsuuPPpbkhKKV+C4aKk8a3hOIaAK6pZ9KY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=BgqFPrr2dHtD8qc6yDDnTcsPg3BMaNRpec3aciZP1bmk/lc8+xHFQM5cXl4ug7VUtQag/xlfIfs3v/STJ8uuTCMXfv+1V9ZIevE8n1BdydXtB92w7dMG/xId+OyjboVmd3CZ5kwZkulgqwP4cd89havcklP3j4gyUSIZ/pPJ49I= Received: by 10.78.145.5 with SMTP id s5mr22731hud.1177465775724; Tue, 24 Apr 2007 18:49:35 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Tue, 24 Apr 2007 18:49:35 -0700 (PDT) Message-ID: <374005f30704241849q55ad8853pf92a456befce38a3@mail.gmail.com> Date: Wed, 25 Apr 2007 07:19:35 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [manet] MANET Mailing List - Only IETF related discussion X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org In an effort to increase the relevance of all emails posted on the MANET list we will be enforcing a posting policy. Mailing list discussion will be limited to IETF policy, meetings, activities, or technical concerns. In response to all CFP, simulator questions, and other discussion clearly unrelated to IETF policy, meetings, activities, or technical concerns; we will be issuing public emails to inappropriate traffic authors. We will also moderate posting privileges for repeat offenders. If you have any doubt about the relevance of your posting, please email myself or Joe. Sincerely, Ian Chakeres ====OTHER LISTS FOR CFP & SIMULATORS BELOW==== For call for papers/journals/conferences/workshops/grants/etc , I suggest you subscribe or post to the TCCC list at http://www.comsoc.org/~tccc/. For simulator questions, I suggest you subscribe or post to NS2 mailing list information at http://www.isi.edu/nsnam/ns/ns-lists.html. GlomoSim mailing list information at http://lists.ucla.edu/cgi-bin/mailman/listinfo/glomosim-users-l. Qualnet support information available at http://www.scalable-networks.com/training_and_support/support/forums/index.php. Opnet support is available at http://www.opnet.com/support/home3.html. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 25 04:41:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgd3z-0007Pu-55; Wed, 25 Apr 2007 04:41:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hgd3x-0007Pc-4O for manet-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 04:41:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgd3w-0007PT-HY for manet@ietf.org; Wed, 25 Apr 2007 04:41:20 -0400 Received: from web39206.mail.mud.yahoo.com ([209.191.87.243]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hgd3s-0003uw-C5 for manet@ietf.org; Wed, 25 Apr 2007 04:41:20 -0400 Received: (qmail 79626 invoked by uid 60001); 25 Apr 2007 08:41:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=efn8lrU4mwGhiO0tf5p31l3sWwXRHSOXIpvdqqdv53cyef/b5APGAs1l+Jq/XXkKdbqapos4w3PFUkpGbdJeci2cL66r+SoGIA/lcUoNMy3C5bZCco6NQW5uxEWx9kONHH95ohiQv8/hPOIVbXoDLrdtkCC2kIduedhGgrLNRko=; X-YMail-OSG: ctXalrIVM1mmd4LJp8yqcypFoioG2M9pjOZux4nD7NKMZca_lBKvM12FH1WX1KdPhQ-- Received: from [194.225.238.145] by web39206.mail.mud.yahoo.com via HTTP; Wed, 25 Apr 2007 09:41:15 BST Date: Wed, 25 Apr 2007 09:41:15 +0100 (BST) From: omid abedi To: manet@ietf.org MIME-Version: 1.0 Message-ID: <765278.78582.qm@web39206.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [manet] guide X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0547809806==" Errors-To: manet-bounces@ietf.org --===============0547809806== Content-Type: multipart/alternative; boundary="0-707328513-1177490475=:78582" Content-Transfer-Encoding: 8bit --0-707328513-1177490475=:78582 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit dear all, I want use manhattan mobility model in glomosim. are there anyone that help me? thank you. Send instant messages to your online friends http://uk.messenger.yahoo.com --0-707328513-1177490475=:78582 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
dear all,
I want use manhattan mobility model in glomosim.
are there anyone that help me?
thank you.

Send instant messages to your online friends http://uk.messenger.yahoo.com --0-707328513-1177490475=:78582-- --===============0547809806== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0547809806==-- From manet-bounces@ietf.org Wed Apr 25 05:47:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hge5l-0008Al-Vp; Wed, 25 Apr 2007 05:47:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hge5l-0008Ad-0B for manet-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 05:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hge5k-0008AV-JJ for manet@ietf.org; Wed, 25 Apr 2007 05:47:16 -0400 Received: from ik-out-1112.google.com ([66.249.90.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hge5j-0007X2-95 for manet@ietf.org; Wed, 25 Apr 2007 05:47:16 -0400 Received: by ik-out-1112.google.com with SMTP id c30so148395ika for ; Wed, 25 Apr 2007 02:47:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TRUHfs6fp9jolT1e677ZBQPhXMOa9lKF+kuRLx78NkcR9BcLHL2/n9n/9amwbGgEVQxfDGsKMyecIVqA9V3e0R942RKTr2QDnaO0seP2dnmBVZ0pG3VAPn3rUO1kqL8vGpfPmAa5ChikGzPQxTiKCSb/80lmvzhHV8U7bJufYLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ojWZHOGfG0SsMvwel2sRaSdRt8fxRU1iKyvflVAKYT4Hmaf5wpC6xHfO4kTYucIqZaJGk/09F+Qa8yck+rRv3FEA+aAUoBkzLiKty/MpBNyUg9IEuQKaltamdIfjYgxB5E7uzuLoPcHJfWNPnyXWkTBcKcB9yBOnAaaC4CXtZVE= Received: by 10.78.180.16 with SMTP id c16mr101700huf.1177494434462; Wed, 25 Apr 2007 02:47:14 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Wed, 25 Apr 2007 02:47:14 -0700 (PDT) Message-ID: <374005f30704250247x5ff88cbfw9644a6d9eb30c3ec@mail.gmail.com> Date: Wed, 25 Apr 2007 15:17:14 +0530 From: "Ian Chakeres" To: "omid abedi" Subject: Re: [manet] guide In-Reply-To: <765278.78582.qm@web39206.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <765278.78582.qm@web39206.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Please do not post simulator questions on the MANET mailing list. MANET mailing list discussion is limited to IETF policy, meetings, activities, or technical concerns. For simulator specific questions, please contact the appropriate simulator mailing list. Sincerely, Ian Chakeres P.S. GlomoSim mailing list information is located at http://lists.ucla.edu/cgi-bin/mailman/listinfo/glomosim-users-l. On 4/25/07, omid abedi wrote: > dear all, > I want use manhattan mobility model in glomosim. > are there anyone that help me? > thank you. > > Send instant messages to your online friends http://uk.messenger.yahoo.com > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 25 05:59:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgeHW-0001j7-9G; Wed, 25 Apr 2007 05:59:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgeHU-0001iz-EN for manet-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 05:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgeHU-0001io-4B for manet@ietf.org; Wed, 25 Apr 2007 05:59:24 -0400 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgeHT-00046e-Ra for manet@ietf.org; Wed, 25 Apr 2007 05:59:24 -0400 Received: by wr-out-0506.google.com with SMTP id 71so167212wri for ; Wed, 25 Apr 2007 02:59:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Zx5ya8nWjoRsmU0Q28R08AbOQc1X/4DOV0jSiGt37qvaSqDbl48vB36hQBwoOxLpLoxuKdThxwkcsNU/E4GkTPRwnWl7E6zWMclgDM5XJyuu82rwCFP4zjeNMGNRUu6ans6oCoa88GIa4vA4/cCU+e6Pottp5Htwep4SPaEcthw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=rToBmLZXleFdn34YDLmI9xTLs2Mj9q7ulKl7rGXWTAD2fD9iZ3ilqyrOMm4Riw0VE7dZRo+FzprlaYrcB5VboJ68t2rpzNqdAW42C34XdaXLds1eVncHuJfVREekheJ7AdHz9TFv/dqI2hMBZ/xsDpyrbtPF4UvLYKA1mVHy/i0= Received: by 10.78.178.5 with SMTP id a5mr97388huf.1177495162948; Wed, 25 Apr 2007 02:59:22 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Wed, 25 Apr 2007 02:59:22 -0700 (PDT) Message-ID: <374005f30704250259u1a0b5f60jf8d53f6d2d68b36e@mail.gmail.com> Date: Wed, 25 Apr 2007 15:29:22 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [manet] Call for sergeant-at-arms X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org As I emailed earlier, we are attempting to stop MANET mailing list discussion that is not related to IETF policy, meetings, activities, or technical concerns. - please see note at the bottom Traditionally, the MANET WG chair has been the moderator (with a rather light hand) of the IETF MANET list. In this discussion, the chair is an active participant in the work and the discussion; it seems inappropriate to ask the chair to also decide whether or not posts are off-topic and/or abusive. Luckily, the IETF list charter (RFC 3005) has a solution: The IETF Chair, the IETF Executive Director, or a sergeant-at-arms appointed by the Chair is empowered to restrict posting by a person, or of a thread, when the content is inappropriate and represents a pattern of abuse. So - I'm hereby asking for volunteers for the job - which is a thankless one, but will not go unthanked! You should: - Be a regular reader of the MANET list (at least a few times a week) - Be willing to monitor and moderate the list according to the rules in the MANET list charter (RFC 3005), rather than your personal opinion - Be willing to commit to doing the job for at least 3 months - Have a thick skin :-) Anyone who is willing to do this job - send us a note (privately), and we will pick one (or more, if I have a convincing argument that this is appropriate). Thanks in advance! Ian Chakeres P.S. I suspect the next month will require the most attention. After that I believe inappropriate email will taper off. NOTE: *the snippet above is copied almost unmodified from a post by Harald Alvestrand. He said it so well, I saw no reason to recompose the content - http://www1.ietf.org/mail-archive/web/ietf/current/msg30921.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 25 07:27:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgfeN-00008t-D0; Wed, 25 Apr 2007 07:27:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgfeL-0008Hy-48 for manet-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 07:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgfeK-0008EE-Lb for manet@ietf.org; Wed, 25 Apr 2007 07:27:04 -0400 Received: from psmtp03.wxs.nl ([195.121.247.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgfeJ-0005XB-DM for manet@ietf.org; Wed, 25 Apr 2007 07:27:04 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by psmtp03.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JH100AFJX4ZP9@psmtp03.wxs.nl> for manet@ietf.org; Wed, 25 Apr 2007 13:27:02 +0200 (MEST) Date: Wed, 25 Apr 2007 13:28:02 +0200 From: Teco Boot To: 'Ian Chakeres' Message-id: <002601c7872c$ca1282b0$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceHLMkCqCvHnt8nQwiyTyfqYu2ztA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: manet@ietf.org Subject: [manet] manet-iana WG Last Call: site-local address and UDP only X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Ian, You request a site-local multicast address. I cannot find any usage of it in the current I-Ds. Do we need this? Or always perform hop-by-hop forwarding using a link-local address? I think the latter is used by OLSRv2 and DYMO protocols, but I can miss something. You also do not request an IP protocol number. Maybe I missed a discussion before and the outcome could be using UDP only, (may be TCP also). I cannot find any reference. Using UDP checksum is a reason. Regards, Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 25 07:28:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgffF-00023v-5D; Wed, 25 Apr 2007 07:28:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgffC-00023X-UK for manet-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 07:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgffC-00023K-Kg for manet@ietf.org; Wed, 25 Apr 2007 07:27:58 -0400 Received: from ik-out-1112.google.com ([66.249.90.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgffC-0005el-82 for manet@ietf.org; Wed, 25 Apr 2007 07:27:58 -0400 Received: by ik-out-1112.google.com with SMTP id c30so173326ika for ; Wed, 25 Apr 2007 04:27:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c5kK7rVp5yAwbZafi69WTuXWPZnMDdgLaHEKZjRI2JRAiFPO4lpmBhQ0hKFzv9W3ytcLRXP5AFKwt3mYjttdSDp7lUlu6wqRr+B0lrwTgqNwttOYfTdFfjZNjLG/kd4c3+jvo8jwV+ytuPGxH7xjqTbtsveg0D+RNVp+5ixrW7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YRNKFGmPsrOL+m+SB7u6ngbnbVLJg3edJV4o22RSOZmKAmq+0l13uStgcVvJu1maVJKCttnyQX+YJa1rkn2gArVemLVkSfxHgxhtZdTlpoCxEyaEV/u5enlVlI2W2m9rvllxL3EgJBr+FcvvR7qtsImZ1J4xPKkdYhAmKj4L8tc= Received: by 10.82.151.14 with SMTP id y14mr1002885bud.1177500477473; Wed, 25 Apr 2007 04:27:57 -0700 (PDT) Received: by 10.82.166.5 with HTTP; Wed, 25 Apr 2007 04:27:57 -0700 (PDT) Message-ID: Date: Wed, 25 Apr 2007 07:27:57 -0400 From: "Marshall Eubanks" To: "Ian Chakeres" Subject: Re: [manet] MANET Mailing List - Only IETF related discussion In-Reply-To: <374005f30704241849q55ad8853pf92a456befce38a3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704241849q55ad8853pf92a456befce38a3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 4/24/07, Ian Chakeres wrote: > In an effort to increase the relevance of all emails posted on the > MANET list we will be enforcing a posting policy. > > Mailing list discussion will be limited to IETF policy, meetings, > activities, or technical concerns. > > In response to all CFP, simulator questions, and other discussion > clearly unrelated to IETF policy, meetings, activities, or technical > concerns; we will be issuing public emails to inappropriate traffic > authors. We will also moderate posting privileges for repeat > offenders. > > If you have any doubt about the relevance of your posting, please > email myself or Joe. > > Sincerely, > Ian Chakeres > > ====OTHER LISTS FOR CFP & SIMULATORS BELOW==== > > For call for papers/journals/conferences/workshops/grants/etc , I > suggest you subscribe or post to the TCCC list at > http://www.comsoc.org/~tccc/. > > For simulator questions, I suggest you subscribe or post to > > NS2 mailing list information at http://www.isi.edu/nsnam/ns/ns-lists.html. > > GlomoSim mailing list information at > http://lists.ucla.edu/cgi-bin/mailman/listinfo/glomosim-users-l. This URL gives : No such list glomosim-users-l Regards Marshall > > Qualnet support information available at > http://www.scalable-networks.com/training_and_support/support/forums/index.php. > > Opnet support is available at http://www.opnet.com/support/home3.html. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 25 08:24:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HggXz-0000XG-Sz; Wed, 25 Apr 2007 08:24:35 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HggXy-0000S4-CQ for manet-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 08:24:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HggXy-0000Qs-2C for manet@ietf.org; Wed, 25 Apr 2007 08:24:34 -0400 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HggXw-0000BK-N2 for manet@ietf.org; Wed, 25 Apr 2007 08:24:34 -0400 Received: by wr-out-0506.google.com with SMTP id 71so201329wri for ; Wed, 25 Apr 2007 05:24:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=W7l2jjoUDwPZTZig99mw0j1hY7FCj0HTAzGcCYGfu9wsabeRo5kmoVQxxY8tEWdZ2irbhXiTvTxK/3Fh4vK8OEmP2NoETHK+VlCWQDu0Ze72DZM8pResp8wBOQvGxx1SMeSzCT2LbSdr8g1cSLNn4tELCAGmsEmPF0Yjbso9CAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lJK6IFQAAtYRZL88sdUdwP3WTLmE4/xIYvb5LlTKK7dnTDrLWcWT89Y9XVKpjjJtGASKICfLS/JawmxaJ7FletwacSi+//Z28QUAyPlkS+twUHJkXaERXKiFMR0tdsIJi4mPhltrtTuslWfVQnSqoxRP6diGchqMbnpCE2SSdys= Received: by 10.78.136.9 with SMTP id j9mr127693hud.1177503858815; Wed, 25 Apr 2007 05:24:18 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Wed, 25 Apr 2007 05:24:18 -0700 (PDT) Message-ID: <374005f30704250524o4a4420bes76f03fdbda2b4f8a@mail.gmail.com> Date: Wed, 25 Apr 2007 17:54:18 +0530 From: "Ian Chakeres" To: "Marshall Eubanks" , abedicomp@yahoo.com Subject: Re: [manet] MANET Mailing List - Only IETF related discussion In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704241849q55ad8853pf92a456befce38a3@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Sorry about the bad glomosim list link, access to the list via this link appears to be gone. On the glomosim download (http://pcl.cs.ucla.edu/projects/glomosim/obtaining_glomosim.html) page it says """ There is a GloMoSim mailing list that can (only) be subscribed to during GloMoSim registration. Simply reregister if you want to get on this list. """ I will replace the welcome text to state that http://pcl.cs.ucla.edu/projects/glomosim/obtaining_glomosim.html is the place to signup for the glomosim mailing list. Ian Chakeres On 4/25/07, Marshall Eubanks wrote: > On 4/24/07, Ian Chakeres wrote: > > In an effort to increase the relevance of all emails posted on the > > MANET list we will be enforcing a posting policy. > > > > Mailing list discussion will be limited to IETF policy, meetings, > > activities, or technical concerns. > > > > In response to all CFP, simulator questions, and other discussion > > clearly unrelated to IETF policy, meetings, activities, or technical > > concerns; we will be issuing public emails to inappropriate traffic > > authors. We will also moderate posting privileges for repeat > > offenders. > > > > If you have any doubt about the relevance of your posting, please > > email myself or Joe. > > > > Sincerely, > > Ian Chakeres > > > > ====OTHER LISTS FOR CFP & SIMULATORS BELOW==== > > > > For call for papers/journals/conferences/workshops/grants/etc , I > > suggest you subscribe or post to the TCCC list at > > http://www.comsoc.org/~tccc/. > > > > For simulator questions, I suggest you subscribe or post to > > > > NS2 mailing list information at http://www.isi.edu/nsnam/ns/ns-lists.html. > > > > GlomoSim mailing list information at > > http://lists.ucla.edu/cgi-bin/mailman/listinfo/glomosim-users-l. > > This URL gives : > No such list glomosim-users-l > > Regards > Marshall > > > > > > > Qualnet support information available at > > http://www.scalable-networks.com/training_and_support/support/forums/index.php. > > > > Opnet support is available at http://www.opnet.com/support/home3.html. > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 25 13:43:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HglVt-0000h5-PJ; Wed, 25 Apr 2007 13:42:45 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HglVr-0000XG-HZ for manet-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 13:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HglVr-0000Vr-70 for manet@ietf.org; Wed, 25 Apr 2007 13:42:43 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HglVo-0002Rt-VQ for manet@ietf.org; Wed, 25 Apr 2007 13:42:43 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3PHgMhY022807; Wed, 25 Apr 2007 20:42:38 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 20:42:22 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 12:41:41 -0500 Received: from [10.162.83.238] ([10.162.83.238]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 12:41:40 -0500 Message-ID: <462F92D0.4030802@nokia.com> Date: Wed, 25 Apr 2007 10:41:36 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <461BAE34.6000706@nokia.com> <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <20070411232836.GI13224@che.ojctech.com> <374005f30704120513k3a956c59lc23e16958b21f088@mail.gmail.com> <461E5E2F.7050304@nokia.com> <374005f30704130107x6ed261fegc22f9afa7dfe2cc7@mail.gmail.com> In-Reply-To: <374005f30704130107x6ed261fegc22f9afa7dfe2cc7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 17:41:41.0418 (UTC) FILETIME=[FBC880A0:01C78760] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian, ext Ian Chakeres wrote: > Let me simply respond regarding IPv4 packets. > > A - DPD based on IPID > > There is no additional packet overhead (when the source inserts a > sequence number into the IPID field as specified in the SMF document). > On the DPD detection side, a node need only keep a sequence number and > window (for a particular tuple). I believe this is extremely light weight. For IPv4, I am very happy to use the IP_ID field without any additional hashing, along with the source IP address. Do we have agreement this is O.K.? With this agreement, then we would only specify hashing for use with IPv6. I only mentioned IPv4 because I was under the impression that some people did not think the IP_ID field was sufficient for the task. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 25 13:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HglbV-0007LW-CP; Wed, 25 Apr 2007 13:48:33 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HglbT-0007LO-VL for manet-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 13:48:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HglbT-0007LG-Lt for manet@ietf.org; Wed, 25 Apr 2007 13:48:31 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HglbS-0003Wm-7f for manet@ietf.org; Wed, 25 Apr 2007 13:48:31 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3PHmIMP008366; Wed, 25 Apr 2007 20:48:27 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 20:48:18 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 12:47:58 -0500 Received: from [10.162.83.238] ([10.162.83.238]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 12:47:57 -0500 Message-ID: <462F9449.3070501@nokia.com> Date: Wed, 25 Apr 2007 10:47:53 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] Need for DPD header (SMF document discussion) - Valid Reason for Tagger ID References: <374005f30704130357r4852deb2qa270ddf6140a4bd0@mail.gmail.com> In-Reply-To: <374005f30704130357r4852deb2qa270ddf6140a4bd0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 17:47:57.0921 (UTC) FILETIME=[DC324D10:01C78761] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian, ext Ian Chakeres wrote: > The tagger id is needed to differentiate between taggers, in the event > that the source itself (or other ensure-ably unique path element) has > not tagged the packet. Since IPv6 requires a new option to carry the > IPID, the new option optionally includes the tagger id. > > The tagger id disambiguates the ID space of different taggers. > > Ian > It is for the case of IPv6 that I am proposing we use a hash function and relegate the use of the new option for only those rare cases where the hash function does not properly distinguish two different packets. I've been doing some more testing with hash functions, and even MD5 seems to work very, very well for this purpose, even if one only retains 64 bits of the hash result. Keeping smaller hash results should help with reducing memory requirements. But we could keep the DPD option for IPv6 for the once in a billion times [or even more rare!] occurrence of hash duplication. As another point of discussion, if a tagger encounters two exactly identical packets, shouldn't it anyway assume that they are duplicates and only forward one of them? What if two different taggers encounter the same packet? Doesn't the tagging introduce a false difference between the packets? Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Apr 25 15:10:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgmsZ-0006os-IB; Wed, 25 Apr 2007 15:10:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HgmsX-0006ol-PG for manet-confirm+ok@megatron.ietf.org; Wed, 25 Apr 2007 15:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgmsX-0006od-Ex for manet@ietf.org; Wed, 25 Apr 2007 15:10:13 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgmsV-0003Nw-W3 for manet@ietf.org; Wed, 25 Apr 2007 15:10:13 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3PJA3aH003761 for ; Wed, 25 Apr 2007 22:10:10 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 22:10:09 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 14:10:07 -0500 Received: from [10.162.83.238] ([10.162.83.238]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 14:10:07 -0500 Message-ID: <462FA789.1050108@nokia.com> Date: Wed, 25 Apr 2007 12:10:01 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Manet" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 19:10:07.0609 (UTC) FILETIME=[5684FE90:01C7876D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [manet] Hash results with MD5 (would be useful for IPv6 DPD) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello folks, I've run MD5 up to 32 million different input strings, saving only 64 bits of output, and gotten _zero_ duplication. Running md5_test | sort | uniq -d shows no output at all. This is pretty good, and now when I test larger datasets my laptop goes catatonic. Also, I am getting timing estimates as low as one millisecond per iteration, with almost no programming optimizations. That's very fast. I could do larger datasets, or try saving fewer bits of the hash result, but these are details. I reckon with more study we can improve on my basic results quite a bit. I am still awaiting some more exact data on the comparison between processing power and transmission power, but anyway I think it is at least clear that MD5 is pretty effective on different input strings, even if it is not the most resistant hash function against determined adversaries for verifying message integrity. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 26 09:24:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3xA-0007hs-GE; Thu, 26 Apr 2007 09:24:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hh3x8-0007hn-Ua for manet-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 09:24:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh3x8-0007hf-Ks for manet@ietf.org; Thu, 26 Apr 2007 09:24:06 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh3x6-0003Oc-77 for manet@ietf.org; Thu, 26 Apr 2007 09:24:06 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3QDNO4r009390; Thu, 26 Apr 2007 09:23:29 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007042609232427557 ; Thu, 26 Apr 2007 09:23:24 -0400 From: "Joe Macker" To: "'Jerome Haerri'" , "'Mehran Abolhasan'" References: <20070424175317.ACS44858@minerva.its.uow.edu.au> <462DBD91.1000901@eurecom.fr> Subject: RE: Fw: [manet] Re : Energy Efficiency in Routing Protocols Date: Thu, 26 Apr 2007 09:23:22 -0400 Message-ID: <003b01c78806$0fdde490$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceGSVM0uRiQHiwySG6U/xCu+pNGfgBu/PsA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <462DBD91.1000901@eurecom.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Jerome: I think this is an interesting post re. an optional GPS (or location information) extension. It may warrant its own subject heading so people could follow any relevant thread. As you state, the WG goal priority is to develop protocols that operate without dependency on such information. Nonetheless, methods to extend the protocols are of interest. -Joe >-----Original Message----- >From: Jerome Haerri [mailto:Jerome.Haerri@eurecom.fr] >Sent: Tuesday, April 24, 2007 4:19 AM >To: Mehran Abolhasan >Cc: manet@ietf.org >Subject: Re: Fw: [manet] Re : Energy Efficiency in Routing Protocols > >Hi guys, > >Using GPS information for a lot of maintenance task in MANET >has been well studied in the last two years under various >names (Dead Reckoning, Mobility Prediction, Context >Awareness). In most cases, it was able to successfully improve >the tested protocol. > >I am also a strong supporter and active developer of this >approach in order to improve MANET protocols. However, the GPS >information needs to be obtained and exchanged between nodes. >Besides, as everything should be compliant with standardized >protocols DYMO, OLSRv2, W-OSPF, the geo-localization >transmission should be compliant with the message structure of >MANET protocols. > >We developed a IETF draft for that matter that may be of some >interest to you in case you would like to adapt GPS >information to DYMO and OLSRv2. You may find the >geo-localization information in MANET problem statement here > >http://www.ietf.org/internet-drafts/draft-haerri-manet-position -problem-statement-00.txt > >and the description of a message format (TLV format) compliant >with PacketBB here > >http://www.ietf.org/internet-drafts/draft-haerri-manet-position -signaling-00.txt > >Nevertheless, I think the objective of the MANET WG is to >develop protocols that works in all cases (the GPS >availability is a too strong assumption in MANET in general). >Then, based on this, extension may be proposed (such as >energy-based criterion, or GPS enhancement). > >I therefore think that "intelligent mechanisms" should not be >standardized at that point, but maybe only cited as possible >extensions. >Then, based on a standardized and working version, it is >always possible to develop improvements. > >Regards, > >Jerome > > >Mehran Abolhasan wrote: >> Hi guys, >> >> Take a look at FORP routing protocol, i think they proposed >something similar to what you are talking about (i.e. >detecting route failure before it occurs using GPS). >> >> Regards, >> >> Mehran >> >> >> ---- Original message ---- >>> Date: Mon, 23 Apr 2007 17:37:39 +0200 >>> From: Carl-Johan.Larsson@generic.se >>> Subject: Fw: [manet] Re : Energy Efficiency in Routing Protocols >>> To: manet@ietf.org >>> >>> >>> I all, I most interested in this thought, I'm been doing >som work on >>> adding Preemptive Route Maintenance on AODV by using simulated GPS >>> coordinates, The idea behind this is to change the route by a Route >>> discovery before the break occures like you, Naeendran, >proposed. I'm >>> beeen using GPS coordinates to get the distance as a >threashold when >>> to activate the mechanism. How where you going to measure the >>> distance you talk about Narendran, by signal power or gps strength? >>> >>> regards Calle >>> > >>> "Narendran > >>> Sivakumar" > >>> To >>> il.com> "Ian Chakeres" > >>> >, >>> 2007-04-23 16:37 manet@ietf.org > >>> > >>> cc >>> > >>> > Subject >>> Re: [manet] Re : >Energy Efficiency >>> in Routing Protocols > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> >>> >>> >>> Hi Ian, >>> >>> Well , In a wireless environment the energy levels used while >>> transmission is also important as higher the transmission power, >>> higher is the range for the nodes to transmit. >>> >>> Is it possible to add an Intelligence Mechanism to DYMO which would >>> use energy levels automatically based on the topology. >>> For Example : If a node X is transmitting to Y with I and J are the >>> intermediate nodes and the path is X-I-J-Y.If Y moves out >of range of >>> J, X would again initiate Route Discovery to Y. If an intelligence >>> mechanism is used to increase the transmission power of J so that Y >>> is within range even if Y changes the location thereby saving time >>> for another Route Discovery process and less delay. On the >flip side >>> if Y is well within range of J, then that same mechanism should be >>> able to adjust the transmission power in accordance with >the closer Y, thereby saving energy. >>> >>> I believe that in a wireless environment , energy efficiency holds >>> the key in determining the effectiveness of an Routing Protocol, >>> further more to DYMO >>> >>> Thanks >>> >>> Naren >>> >>> >>> On 4/23/07, Ian Chakeres wrote: >>> I think it will be difficult to analyze energy >efficiency. I also >>> think there are also lots of little tweaks that you could do to >>> improve efficiency, depending on your measure of course. >>> >>> Ian >>> >>> >>> On 4/23/07, Narendran Sivakumar wrote: >>> > Dear All , >>> > >>> > I've implemented DYMO and comparing the performance >of DYMO with >>> other >>> > protocols. Is there a way to analyze how energy >efficient these >>> protocols >>> > especially DYMO as i consider energy efficiency a big factor. >>> > >>> > Any suggestions and ideas relating to this subject are most >>> welcome. >>> > >>> > Thank You >>> > >>> > Naren >>> > _______________________________________________ >>> > manet mailing 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 > > >-- >Jerome Haerri >Ph.D Candidate > >Eurecom Institute >Mobile Communications Department >2229, Route des Cretes >B.P. 193 >06904 Sophia-Antipolis Cedex >France > >Home : +33 (0)4 92 38 97 09 >Office : +33 (0)4 93 00 26 76 >Mob : +33 (0)6 10 79 72 83 > >E-mail : jerome.haerri@eurecom.fr > >Web : http://www.eurecom.fr/people/haerri.en.htm > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 26 12:20:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6hq-0007Sh-Lc; Thu, 26 Apr 2007 12:20:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hh6hp-0007Sb-HB for manet-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 12:20:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6ho-0007SR-0a for manet@ietf.org; Thu, 26 Apr 2007 12:20:28 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6hn-0008VY-HM for manet@ietf.org; Thu, 26 Apr 2007 12:20:27 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3QGKN17019711; Thu, 26 Apr 2007 12:20:23 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007042612202228655 ; Thu, 26 Apr 2007 12:20:22 -0400 From: "Joe Macker" To: "'Charles E. Perkins'" , "'ext Henderson, Thomas R'" References: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <461D509A.1050209@nokia.com> Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Thu, 26 Apr 2007 12:20:20 -0400 Message-ID: <006e01c7881e$c8fd0510$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd8f5qcr1yKqLD/TFuc0XzjoT3xKQLmyOWQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <461D509A.1050209@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org While we collected previous data with a variety of hash algorithms a few years ago and looked at high rate multicast traffic flows like video,etc we were not convinced it was the right general approach. At the time, we tried to examine a 32 bit hash result that was also a fast algorithm for per-packet processing use. I think we are also interested in regathering specific data included processing/delay tradeoffs. Certainly the text of SMF allows for hashing approaches but SHOULDs the implementation of DPD for IPv6. I think this is still correct and allows for implementable experimentation. Your IPv4 results are encouraging to hear about. FYI, there reamin IPv6 applications that can produce very common looking header/data portions. It may be more frequent with video streaming etc. I've seen this with IPv6/UDP vlc streams. IN this case its not one-in-a-billion without additional assistance. -Joe >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >Sent: Wednesday, April 11, 2007 5:18 PM >To: ext Henderson, Thomas R >Cc: manet@ietf.org >Subject: Re: [manet] Need for DPD header (SMF document discussion) > > >Hello Tom, > >ext Henderson, Thomas R wrote: >> >>> We just proved otherwise -- that a good hash function completely >>> disambiguates based on IP header alone. There is no need >to include >>> payload data. >>> >> >> It would be nice to see some data regarding how heavyweight the >> hashing is for the classes of devices under consideration. Is that >> posted in a previous list message or presentation? I agree >that if it >> is inexpensive, a hash on the packet would be preferable to >the tagger >> ID solution. >I am in the process of finding out what inexpensive hash >functions are sufficiently effective for the job. So far, we >have found that SHA-1 can completely disambiguate packets that >are different only in the ip_id field, storing only 32 bits of >the hash result (e.g., not 160 bits). To me, that means SHA-1 >is "too good", and we can make do with less. > >I'll also try to get a count of the instruction cycles needed. > >> However, I do not see why you would need (or want) to hash just the >> header; the hash output will be larger than or commensurate with >> storing the header fields themselves. Plus, I have been told that >> many multicast sources do not have distinguishing IP ID fields. >> >I don't claim that we should avoid including the payload. >Exactly what needs to be hashed is a matter for further >clarification. My statement was really targeted towards >making the case that hashing is good and cheap. If we can get >away with hashing only 512 bits of data, that would be nice, >but it is not a showstopper if we need to use more. > >And, again, for cases where hashing does not disambiguate, >then we can use the DPD option. This would, of course, be >fine as a backup strategy. > >Regards, >Charlie P. > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 26 13:13:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7XL-0002rG-Ck; Thu, 26 Apr 2007 13:13:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hh7XJ-0002rB-KU for manet-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 13:13:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7XJ-0002r3-B1 for manet@ietf.org; Thu, 26 Apr 2007 13:13:41 -0400 Received: from insomnia.liquidweb.com ([64.91.225.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7XI-0001oV-47 for manet@ietf.org; Thu, 26 Apr 2007 13:13:41 -0400 Received: from confprom by insomnia.liquidweb.com with local (Exim 4.63) (envelope-from ) id 1Hh7XG-00052c-68; Thu, 26 Apr 2007 13:13:38 -0400 Received: from 138.232.65.129 ([138.232.65.129]) (SquirrelMail authenticated user vicky@confpromo.com) by www.confpromo.com with HTTP; Thu, 26 Apr 2007 13:13:38 -0400 (EDT) Message-ID: <17628.138.232.65.129.1177607618.squirrel@www.confpromo.com> Date: Thu, 26 Apr 2007 13:13:38 -0400 (EDT) From: "Vicky Star" To: manet@ietf.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - insomnia.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32132 32133] / [47 12] X-AntiAbuse: Sender Address Domain - confpromo.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: pdini@cisco.com Subject: [manet] MUTL 2007 || WSNEXT 2007 || VVSSearch 2007 || (November 4-9, 2007 - Papeete) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org ========================================= Invitation: Please consider to contribute and distribute to the appropriate groups the following CALL FOR PAPERS, TUTORIALS, PANELS Submission deadline: May 15, 2007 Workshops date:: November 4-9, 2007 - Papeete, French Polynesia (Tahiti) MUTL 2007, International Workshop on Mobile and Ubiquitous Technologies for Learning Site: http://www.iaria.org/conferences2007/MUTL.html Call and Committee: http://www.iaria.org/conferences2007/MUTL.html#CallForPapers WSNEXT 2007, International Workshop on Web Services Evolution and Applications Site: http://www.iaria.org/conferences2007/WSNEXT.html Call and Committee: http://www.iaria.org/conferences2007/WSNEXT.html#CallForPapers VVSSearch 2007, International Workshop on Advanced Searching On Voice, Video, and Speech Contents Site: http://www.iaria.org/conferences2007/VVSSearch.html Call: http://www.iaria.org/conferences2007/VVSSearch.html#CallForPapers ============ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 26 14:32:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8lF-0000s4-79; Thu, 26 Apr 2007 14:32:09 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hh8lD-0000rA-RX for manet-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 14:32:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8lD-0000qA-HC for manet@ietf.org; Thu, 26 Apr 2007 14:32:07 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8lB-0005CA-UK for manet@ietf.org; Thu, 26 Apr 2007 14:32:07 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3QIVv8q000845; Thu, 26 Apr 2007 21:32:00 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 21:32:00 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 13:31:58 -0500 Received: from [10.162.85.26] ([10.162.85.26]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 13:31:57 -0500 Message-ID: <4630F017.5000006@nokia.com> Date: Thu, 26 Apr 2007 11:31:51 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Joe Macker Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <461D509A.1050209@nokia.com> <006e01c7881e$c8fd0510$165cfa84@SEXTANT> In-Reply-To: <006e01c7881e$c8fd0510$165cfa84@SEXTANT> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2007 18:31:57.0735 (UTC) FILETIME=[2C0FB370:01C78831] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: "'ext Henderson, Thomas R'" , manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Joe, First, let me be clear about what I am proposing. I am _not_ arguing against having a DPD header as an optional protocol element. It is even O.K. with me to require all ad hoc nodes to implement the DPD option. What I want, is for nodes to _typically_ rely on the hash function to disambiguate different multicast packets. If the hash function does not work, then the DPD header SHOULD be inserted into the packet by the source. This requires that we specify the hash function so that the source will know whether or not the recipients can disambiguate based on the hash function. For IPv4, the sense of the recent discussion seems to be that we do not need DPD header or hash functions at all, because the IP_ID field will disambiguate. This seems like the best possible solution to me. For IPv6, it matters, and I am by now pretty confident that the hash function will work at least 99.9999% of the time if not 99.99999999% of the time. For the times when it works, we save energy and maybe even time (depending on the transmission rate). For the time when hashing does not work, we would have the DPD header. If you have datasets that MD5 cannot disambiguate, I'd love to see them. As far as I can tell, even changing one single bit causes the hash results to be different. One has to search long and hard to find two input strings that have the same results, or else be an expert cryptographer with insights about recent publications showing the weakness of MD5 against determined adversaries. Regards, Charlie P. ext Joe Macker wrote: > While we collected previous data with a variety of hash algorithms a few > years ago and looked at high rate multicast traffic flows like video,etc we > were not convinced it was the right general approach. At the time, we tried > to examine a 32 bit hash result that was also a fast algorithm for > per-packet processing use. I think we are also interested in regathering > specific data included processing/delay tradeoffs. Certainly the text of > SMF allows for hashing approaches but SHOULDs the implementation of DPD for > IPv6. I think this is still correct and allows for implementable > experimentation. Your IPv4 results are encouraging to hear about. > > FYI, there reamin IPv6 applications that can produce very common looking > header/data portions. It may be more frequent with video streaming etc. > I've seen this with IPv6/UDP vlc streams. IN this case its not > one-in-a-billion without additional assistance. > > -Joe > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >> Sent: Wednesday, April 11, 2007 5:18 PM >> To: ext Henderson, Thomas R >> Cc: manet@ietf.org >> Subject: Re: [manet] Need for DPD header (SMF document discussion) >> >> >> Hello Tom, >> >> ext Henderson, Thomas R wrote: >> >>>> We just proved otherwise -- that a good hash function completely >>>> disambiguates based on IP header alone. There is no need >>>> >> to include >> >>>> payload data. >>>> >>>> >>> It would be nice to see some data regarding how heavyweight the >>> hashing is for the classes of devices under consideration. Is that >>> posted in a previous list message or presentation? I agree >>> >> that if it >> >>> is inexpensive, a hash on the packet would be preferable to >>> >> the tagger >> >>> ID solution. >>> >> I am in the process of finding out what inexpensive hash >> functions are sufficiently effective for the job. So far, we >> have found that SHA-1 can completely disambiguate packets that >> are different only in the ip_id field, storing only 32 bits of >> the hash result (e.g., not 160 bits). To me, that means SHA-1 >> is "too good", and we can make do with less. >> >> I'll also try to get a count of the instruction cycles needed. >> >> >>> However, I do not see why you would need (or want) to hash just the >>> header; the hash output will be larger than or commensurate with >>> storing the header fields themselves. Plus, I have been told that >>> many multicast sources do not have distinguishing IP ID fields. >>> >>> >> I don't claim that we should avoid including the payload. >> Exactly what needs to be hashed is a matter for further >> clarification. My statement was really targeted towards >> making the case that hashing is good and cheap. If we can get >> away with hashing only 512 bits of data, that would be nice, >> but it is not a showstopper if we need to use more. >> >> And, again, for cases where hashing does not disambiguate, >> then we can use the DPD option. This would, of course, be >> fine as a backup strategy. >> >> Regards, >> Charlie P. >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >> > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 26 15:35:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9ka-0000Kf-Rs; Thu, 26 Apr 2007 15:35:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hh9kZ-0000KU-TU for manet-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 15:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh9kZ-0000KC-79 for manet@ietf.org; Thu, 26 Apr 2007 15:35:31 -0400 Received: from ik-out-1112.google.com ([66.249.90.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh9kP-0001j4-HD for manet@ietf.org; Thu, 26 Apr 2007 15:35:31 -0400 Received: by ik-out-1112.google.com with SMTP id b35so100539ika for ; Thu, 26 Apr 2007 12:35:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:reply-to:from:to:subject:date:organization:message-id:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:importance:thread-index:sender; b=HlSgI2euSFOVFE5We0ZSQW/c5lbVdr+viMSGp+3DuK8edC4LbAy70iaNZcJgup7NSNAVBzkc25G68eX1siv27cMCmNi5SquOVblmeYMSnj8pSFUfABLCaGVm3Ti9GvjxRDBvaxPcwr1UIX0KDWKJ+MG6dw4owwfXlYvudWmcZBs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:reply-to:from:to:subject:date:organization:message-id:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:importance:thread-index:sender; b=ryZjovbN3mk2uBUOMqeerVVkAMrygMSnQnddXAWI9Z3xpO6878zAmyL8ws9EBcxCV6TNxskIFClkuFAk+ZpgUI1mbSoHy9Xg/+uMLlXOrkSmBNclBvWEp1HrveDqGykfapO1XQZvz1wrumXN3g9TqFTh6S0GEb4GZSbCSYvUXIk= Received: by 10.82.189.6 with SMTP id m6mr3996621buf.1177616120632; Thu, 26 Apr 2007 12:35:20 -0700 (PDT) Received: from simula073 ( [193.157.236.76]) by mx.google.com with ESMTP id y6sm27604341mug.2007.04.26.12.35.19; Thu, 26 Apr 2007 12:35:19 -0700 (PDT) From: "Yan ZHANG" To: Date: Thu, 26 Apr 2007 21:35:18 +0200 Organization: Simula Research Laboratory, Norway Message-ID: <001301c7883a$0628db10$4cec9dc1@simula.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Importance: High Thread-index: AceCJpQxLBl9/6ZLSUq1tKkznSsi2gF6k3MgAAo2zaA= X-Spam-Score: 0.4 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Subject: [manet] 2007 International Workshop on Cooperative Wireless Communications and Networking (CoNET-07) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yanzhang@ieee.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org =20 [Apologies if you receive this more than once] ***************************************************************** =20 2007 International Workshop on Cooperative Wireless Communications and Networking (CoNET-07) =20 Jeju-Island, Korea, December 6-8, 2007 in conjunction with FGCN 2007 http://home.simula.no/~yanzhang/CoNET07/ =20 Submission Deadline: 15 July 2007 =20 Distinguished papers accepted and presented in CoNET-07, will be invited = to contribute in the book Cooperative Wireless Communications, Auerbach Publications, Taylor&Francis Group =20 ***************************************************************** =20 General Information: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CoNET'07 will be held in conjunction with the 2007 International = Conference on Future Generation Communication and Networking (FGCN 2007) on = December 6-8, 2007, in Lotte Hotel, Jeju Island, Korea, http://www.sersc.org/FGCN2007/. All accepted papers in CoNET'07 will be included in the conference proceedings published by IEEE Computer = Society and in the IEEE Xplore database, and will be indexed by EI.=20 =20 Distinguished papers accepted and presented in CoNET-07, will be invited = to contribute in the book Cooperative Wireless Communications, Auerbach Publications, Taylor&Francis Group. =20 Scope and Topics: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Cooperative wireless communications and networking is emerging as a promising technology to enhance system performance by sharing resources among wireless nodes. With cooperation at all layers of the protocol = stack, the wireless network can achieve higher throughput, higher system reliability, higher energy efficiency, lower bit-error rate, and smaller packet loss rate. A variety of research in recent years have actively focused on design, simulation, modeling, and applying cooperative communications in wireless ad hoc, mesh, and sensor networks, etc.International standards organizations have been initialized various activities to apply cooperation mechanisms in the wireless LAN, PAN and MAN.For instance, the IEEE 802.16j working group is actively calling for contributions for relay metropolitan networks. =20 The idea of cooperative wireless communications and networking can be tracked back to the work of the theoretic properties of relay channels. = By sharing antennas in a multi-user environment, single-antenna wireless devices enable a virtual multiple-input multiple-output (MIMO) system = that allows them to achieve transmit diversity, and hence obtain advantages = of MIMO with reduced size, cost, and complexity of the hardware/software. = Upon cooperation at physical, MAC, network, and application layer, various cooperative signaling methods are widely explored and many new = mechanisms are under development with respects to routing, medium access, location management, scheduling, energy management, and so on. =20 This workshop intends to bring together researchers, engineers, and = students to present new results, describe work in progress, and explore = relationships among their diverse approaches. =20 Topics covered by the workshop will include, but are not limited to, the following: =20 . Cooperative diversity . Virtual MIMO . Channel capacity . Cooperative channel coding . Cognitive radio networks . Cooperating services . Grid Computing . Middleware . Performance analysis, simulation and experiment . Services, = applications and systems . Testbed, prototype, practical system and case studies . Resource management . Mobility management . Energy management . Security management . Cross-layer cooperation and optimization . Cooperative and distributed relaying . Relay networking . Regenerative cooperative = systems . Protocols for relay and multi-hop channels . Distributed = relay-assignment algorithm . Routing, packet forwarding, multicast . Cooperative = scheduling . Cooperative MAC protocol . Power control . Network Coding . Security architecture and mechanisms . QoS provisioning . Topology control . Synchronization . Cooperative schemes in Wireless PAN, LAN, MAN . Cooperative schemes in B3G, 4G System . Cooperation in ad hoc networks = . Cooperation in wireless mesh networks . Cooperation in wireless sensor networks . peer-to-peer networks . Cooperative schemes in IEEE 802.x families, e.g. 802.11, 802.15, 802.16, 802.20 =20 Important Dates: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Submission due: 15 July 2007 Acceptance notification: 31 August 2007 Camera-ready due: 10 September 2007 Workshop: 6-8 December 2007 =20 Submissions and Publications: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Technical papers describing original, previously unpublished research, = not currently under review somewhere else, are solicited. Submissions should include abstract, key words, the e-mail address of the corresponding = author. The length of the papers should be limited up to 8 pages, including = tables, references and figures. The papers should follow the standard IEEE camera-ready format. Only PDF format is acceptable. Submission of a = paper should be regarded as an undertaking that, should the paper be accepted, = at least one of the authors will register and attend the workshop to = present the work. =20 All papers will be peer reviewed and the comments will be provided to = the authors. All accepted papers will be included in the conference = proceedings published by IEEE Computer Society and in the IEEE Xplore database, and = will be indexed by EI. Distinguished papers accepted and presented in = CoNET'07, will be invited to contribute in the book Cooperative Wireless Communications, Auerbach Publications, Taylor&Francis Group. =20 Workshop Committee: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Steering Co-Chairs: =20 Jong Hyuk Park, Hanwha S&C Co., Ltd., Korea=20 Laurence T. Yang, St Francis Xavier University, Canada=20 Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan =20 International Advisory Committee: =20 Noureddine Boudriga, University of Carthage, Tunisia=20 Masayuki Fujise, NiCT Asia Research Center, Thailand=20 Taihoon Kim, SERSC, Korea=20 Pentti Lepp=E4nen, University of Oulu, Finland=20 Jianhua Ma, Hosei University, Japan=20 Youju Mao, Chongqing University of Posts and Telecommunications, China=20 Jelena Misic, University of Manitoba, Canada=20 Nandana Rajatheva, Asian Institute of Technology, Thailand=20 A.B. Sharma, Helsinki University of Technology, Finland=20 =20 General Co-Chairs: =20 Yan Zhang, Simula Research Laboratory, Norway=20 Mieso Denko, University of Guelph, Canada=20 Chenyang Yang, Beihang University, China=20 Wonjun Lee, Korea University, Korea =20 Technical Program Co-Chairs: Ming-Tuo Zhou, NICT Singapore Jun Zheng, University of Ottawa, Canada Tolis Papathanassiou, Intel Corporation, USA =20 Publicity Co-Chairs: Tao Jiang, University of Michigan, USA Yifan Chen, Nanyang Technological University, Singapore=20 Supeng Leng, University of Electronic Science and Technology of China, = China =20 Web Management Chair: Jie Xiang. Simula Research Laboratory, Norway _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 26 17:07:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBBN-0002KG-LX; Thu, 26 Apr 2007 17:07:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhBBL-0002Ji-83 for manet-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 17:07:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhBBK-0002Ja-Un for manet@ietf.org; Thu, 26 Apr 2007 17:07:14 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhBBK-0005xX-I4 for manet@ietf.org; Thu, 26 Apr 2007 17:07:14 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3QL7DhP006559; Thu, 26 Apr 2007 17:07:14 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007042617071330879 ; Thu, 26 Apr 2007 17:07:13 -0400 From: "Joe Macker" To: "'Charles E. Perkins'" References: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <461D509A.1050209@nokia.com> <006e01c7881e$c8fd0510$165cfa84@SEXTANT> <4630F017.5000006@nokia.com> Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Thu, 26 Apr 2007 17:07:11 -0400 Message-ID: <00a501c78846$db6954b0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceIMTLGBa0ey9adS2Otu1VZBfEDOgADgFJA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4630F017.5000006@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I think I understand you. I think there is more to it than that and there are several issues. Let me try to outline my issues. I am very much a fan of keeping the specification flexible to allow hashing experimentation. Hopefully the folling clarifies some issues. I think we agree IPv4 approach is good enough for now so this is also about IPv6 (1) Ambiguity of hash results - I think we agree given a good data set this can be made very improbable. No argument. - Changing 1 bit is very good for a good hash algorithm. No argument. Hash algorithms should be well-balanced. - However, if we sample part or all of the packet (these may fast flows, video) there is a chance an application may produce a same in parts or possible completely the same packet (UDP IPv6 without RTP in vlc video stream for example). - Is this disallowed for an application ever to do this? I know the hybrid approach (3) deals with this. (2) Heterogeneity of Flows at Forwarder and History Management - SMF is forwarding multiple flows possible from the same source or heterogeneous sources. These flows can arrive at orders of magnitude different rates (e.g., Video vs. chat). - a present SMF DPD tuple-based bitmap "sliding window implementation" is pretty efficient straightforward engineering approach to handle this, deals with out of order packets properly, and will not swamp out a slower flows due to queue history management problems by one source-receiver flow dominating the DPD queue. - This is the same code as IPv4 code so its not like something different is done. - With the monolithic hashing approach for all packets will it be a homogeneous FIFO for all packets,etc.? Timeout per packet? - Or will we use a hash for the flow and a hash for the DPD. - I am open to discussion on this. (3) The Hybrid Approach to detect (1) and only add DPD in .00000001% of time ;-) as you put it is allowed but I am still concerned about (2). Please don't get me wrong I agree hashing approaches are relatively fast and feel they adding great value to IP flow analysis tools,etc. I know it can run fast so that is not my engineering concern and perhaps the older SMF text needs updating in that regard. It feel managing the tuple-based DPD histories is important in a heterogeneous environment. It can be harder to test and check this. -Joe >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >Sent: Thursday, April 26, 2007 2:32 PM >To: ext Joe Macker >Cc: 'ext Henderson, Thomas R'; manet@ietf.org >Subject: Re: [manet] Need for DPD header (SMF document discussion) > > >Hello Joe, > >First, let me be clear about what I am proposing. > >I am _not_ arguing against having a DPD header as an optional >protocol element. It is even O.K. with me to require all ad >hoc nodes to implement the DPD option. > >What I want, is for nodes to _typically_ rely on the hash >function to disambiguate different multicast packets. If the >hash function does not work, then the DPD header SHOULD be >inserted into the packet by the source. > >This requires that we specify the hash function so that the >source will know whether or not the recipients can >disambiguate based on the hash function. > >For IPv4, the sense of the recent discussion seems to be that >we do not need DPD header or hash functions at all, because >the IP_ID field will disambiguate. This seems like the best >possible solution to me. > >For IPv6, it matters, and I am by now pretty confident that >the hash function will work at least 99.9999% of the time if >not 99.99999999% of the time. For the times when it works, we >save energy and maybe even time (depending on the transmission >rate). For the time when hashing does not work, we would have >the DPD header. > >If you have datasets that MD5 cannot disambiguate, I'd love to >see them. As far as I can tell, even changing one single bit >causes the hash results to be different. One has to search >long and hard to find two input strings that have the same >results, or else be an expert cryptographer with insights >about recent publications showing the weakness of MD5 against >determined adversaries. > >Regards, >Charlie P. > > >ext Joe Macker wrote: >> While we collected previous data with a variety of hash algorithms a >> few years ago and looked at high rate multicast traffic flows like >> video,etc we were not convinced it was the right general >approach. At >> the time, we tried to examine a 32 bit hash result that was also a >> fast algorithm for per-packet processing use. I think we are also >> interested in regathering specific data included processing/delay >> tradeoffs. Certainly the text of SMF allows for hashing approaches >> but SHOULDs the implementation of DPD for IPv6. I think >this is still >> correct and allows for implementable experimentation. Your >IPv4 results are encouraging to hear about. >> >> FYI, there reamin IPv6 applications that can produce very common >> looking header/data portions. It may be more frequent with >video streaming etc. >> I've seen this with IPv6/UDP vlc streams. IN this case its not >> one-in-a-billion without additional assistance. >> >> -Joe >> >>> -----Original Message----- >>> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >>> Sent: Wednesday, April 11, 2007 5:18 PM >>> To: ext Henderson, Thomas R >>> Cc: manet@ietf.org >>> Subject: Re: [manet] Need for DPD header (SMF document discussion) >>> >>> >>> Hello Tom, >>> >>> ext Henderson, Thomas R wrote: >>> >>>>> We just proved otherwise -- that a good hash function completely >>>>> disambiguates based on IP header alone. There is no need >>>>> >>> to include >>> >>>>> payload data. >>>>> >>>>> >>>> It would be nice to see some data regarding how heavyweight the >>>> hashing is for the classes of devices under consideration. > Is that >>>> posted in a previous list message or presentation? I agree >>>> >>> that if it >>> >>>> is inexpensive, a hash on the packet would be preferable to >>>> >>> the tagger >>> >>>> ID solution. >>>> >>> I am in the process of finding out what inexpensive hash functions >>> are sufficiently effective for the job. So far, we have found that >>> SHA-1 can completely disambiguate packets that are >different only in >>> the ip_id field, storing only 32 bits of the hash result (e.g., not >>> 160 bits). To me, that means SHA-1 is "too good", and we >can make do >>> with less. >>> >>> I'll also try to get a count of the instruction cycles needed. >>> >>> >>>> However, I do not see why you would need (or want) to hash >just the >>>> header; the hash output will be larger than or commensurate with >>>> storing the header fields themselves. Plus, I have been told that >>>> many multicast sources do not have distinguishing IP ID fields. >>>> >>>> >>> I don't claim that we should avoid including the payload. >>> Exactly what needs to be hashed is a matter for further >>> clarification. My statement was really targeted towards making the >>> case that hashing is good and cheap. If we can get away >with hashing >>> only 512 bits of data, that would be nice, but it is not a >>> showstopper if we need to use more. >>> >>> And, again, for cases where hashing does not disambiguate, then we >>> can use the DPD option. This would, of course, be fine as a backup >>> strategy. >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>> >>> >> >> >> > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Apr 26 20:22:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhEDw-0001mE-Ry; Thu, 26 Apr 2007 20:22:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhEDw-0001m4-1F for manet-confirm+ok@megatron.ietf.org; Thu, 26 Apr 2007 20:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhEDv-0001lw-Nz for manet@ietf.org; Thu, 26 Apr 2007 20:22:07 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhEDv-0000lj-8F for manet@ietf.org; Thu, 26 Apr 2007 20:22:07 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3R0M49q007044; Fri, 27 Apr 2007 03:22:04 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 03:22:04 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 19:22:01 -0500 Received: from [172.18.141.154] ([172.18.141.154]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Apr 2007 19:22:00 -0500 Message-ID: <46314228.1000507@nokia.com> Date: Thu, 26 Apr 2007 17:22:00 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Joe Macker Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <461D509A.1050209@nokia.com> <006e01c7881e$c8fd0510$165cfa84@SEXTANT> <4630F017.5000006@nokia.com> <00a501c78846$db6954b0$165cfa84@SEXTANT> In-Reply-To: <00a501c78846$db6954b0$165cfa84@SEXTANT> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 00:22:01.0026 (UTC) FILETIME=[12FF9220:01C78862] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Joe, I don't understand a couple of things that you said: ext Joe Macker wrote: > (1) Ambiguity of hash results > - I think we agree given a good data set this can be made very improbable. > No argument. > I'm saying, given practically any two different data sets, the has results will differ. > - Changing 1 bit is very good for a good hash algorithm. No argument. Hash > algorithms should be well-balanced. > This, I did not understand... > - However, if we sample part or all of the packet (these may fast flows, > video) there is a chance an application may produce a same in parts or > possible completely the same packet (UDP IPv6 without RTP in vlc video > stream for example). > For any such scenario, the DPD header could be applied. > - Is this disallowed for an application ever to do this? I know the hybrid > approach (3) deals with this. > I did not understand the questoin, unfortunately. I do not think that the application would insert the DPD header, or calculate the hash. > (2) Heterogeneity of Flows at Forwarder and History Management > - SMF is forwarding multiple flows possible from the same source or > heterogeneous sources. These flows can arrive at orders of magnitude > different rates (e.g., Video vs. chat). > - a present SMF DPD tuple-based bitmap "sliding window implementation" is > pretty efficient straightforward engineering approach to handle this, deals > with out of order packets properly, and will not swamp out a slower flows > due to queue history management problems by one source-receiver flow > dominating the DPD queue. > If you wanted to specify that, after a certain high rate of packet sourcing, a node SHOULD begin to insert DPD options, that would be fine with me. For sensor nodes, I don't see this happening very often. > - This is the same code as IPv4 code so its not like something different is > done. > - With the monolithic hashing approach for all packets will it be a > homogeneous FIFO for all packets,etc.? Timeout per packet? > I was thinking about a single list of hash results for single packets, but if you believe there should be multiple lists we could work on that...(?) > - Or will we use a hash for the flow and a hash for the DPD. > I did not understand this... > - I am open to discussion on this. > > (3) The Hybrid Approach to detect (1) and only add DPD in .00000001% of time > ;-) as you put it is allowed but I am still concerned about (2). > (2) basically means too many packets will cause the loss of hash results for packets that are still actively being forwarded, if I understand correctly. > Please don't get me wrong I agree hashing approaches are relatively fast and > feel they adding great value to IP flow analysis tools,etc. But we are discussing DPD, not flow analysis...(?) Sorry if I am missing something obvious! Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 01:57:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJS1-0003ew-GU; Fri, 27 Apr 2007 01:57:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhJRz-0003em-FT for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 01:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhJRz-0003ee-2Q for manet@ietf.org; Fri, 27 Apr 2007 01:56:59 -0400 Received: from wr-out-0506.google.com ([64.233.184.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhJRw-00086i-SP for manet@ietf.org; Fri, 27 Apr 2007 01:56:59 -0400 Received: by wr-out-0506.google.com with SMTP id 71so842489wri for ; Thu, 26 Apr 2007 22:56:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=DcMSP6t5qApJD4R1ScVd1V93mj+8Ax8soXhV023OGogyMMhvoXnNM0gOzbA/C0nwVdgTdKNazryl9I4do/UQ03/BukrWYSb43ZyWMrjjJJVrWoQDxx1VozdypDchGkt38kHpJRVbqJhp9f3/huayRcMXRO1ZuSs/jKT1SQ/8ue0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=BrMJUjpKcqxJ9I3jFwe59kil+M0ecw4isa57CLXgcKheOVBmPNXZFlxuXpHG0eFJ8NZTKD1OFx5rZQpH3eqNtFqiH3GTFZmUOsVqiCkFuri2gYVQHmhIdxxw0dCneHBTcS8OQIB1fXC6kyBbBGulMUimmuEm+kdRlereHEMRJHs= Received: by 10.78.118.5 with SMTP id q5mr696484huc.1177653415974; Thu, 26 Apr 2007 22:56:55 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Thu, 26 Apr 2007 22:56:55 -0700 (PDT) Message-ID: <374005f30704262256y2d25970ax46982e0083bdc061@mail.gmail.com> Date: Fri, 27 Apr 2007 11:26:55 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [manet] sergeant-at-arms X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ratul Mukhopadhyay has agreed to be the MANET mailing list sergeant-at-arms. If you obtain satisfaction in his noble effort to stop inappropriate discussion on the MANET list, please send him a private thank you note. Thank you Ratul. Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 02:48:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKFW-00011u-UK; Fri, 27 Apr 2007 02:48:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhKFV-00011O-3v for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 02:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKFR-00010a-6A for manet@ietf.org; Fri, 27 Apr 2007 02:48:05 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhKFQ-000381-RN for manet@ietf.org; Fri, 27 Apr 2007 02:48:05 -0400 Received: by ug-out-1314.google.com with SMTP id 72so615200ugd for ; Thu, 26 Apr 2007 23:47:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tH31rdfvsW2lJb5T6iyGSAxJs3JK8jZS46Im41qJL8q0Adnt9890qFaOuSDpEQiIJLJs8HcN9OX/wka+Q1gvdyuYVNQ3iAlLr/jv6ygcEE5z2afdLnzJWJlS+yrdcjnO54ADx301BzLS8GJFv4r5yLbVC67/t2HgLBz0VSOP5Go= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i8TFTAUUp7m4ynYva8QdeOZDdS0WId9hCiS9Sb4Uf/4yGGCJ3KCneDLjhbYRtkVsL/313H43Wxh5aj1+3XikVS+CjeyU/Oze3AN40izl7hs+thXVERjOt32HJNc003q3bhfj+zqyg+MfUcq8SaPGezuJvgc7WpwJIU8FGKqNDzU= Received: by 10.78.180.18 with SMTP id c18mr707326huf.1177656479237; Thu, 26 Apr 2007 23:47:59 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Thu, 26 Apr 2007 23:47:54 -0700 (PDT) Message-ID: <374005f30704262347i543566d6mc0f21dd0b4b4351b@mail.gmail.com> Date: Fri, 27 Apr 2007 12:17:54 +0530 From: "Ian Chakeres" To: "Charles E. Perkins" Subject: Re: [manet] Need for DPD header (SMF document discussion) - Valid Reason for Tagger ID In-Reply-To: <462F9449.3070501@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704130357r4852deb2qa270ddf6140a4bd0@mail.gmail.com> <462F9449.3070501@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I believe your main problem with using a sequence number in the DPD option is the consisten overhead of the option. Is that correct Charlie? Charlie do you have any suggestion on how we might uniformly compare the overhead of the option (more bits, small memory, small CPU) vs. the overhead of hashing (higher CPU, larger memory requirements, some complexity in adding DPD sometimes, some more bits sometimes)? Other comments inline. On 4/25/07, Charles E. Perkins wrote: > Hello Ian, > > ext Ian Chakeres wrote: > > The tagger id is needed to differentiate between taggers, in the event > > that the source itself (or other ensure-ably unique path element) has > > not tagged the packet. Since IPv6 requires a new option to carry the > > IPID, the new option optionally includes the tagger id. > > > > The tagger id disambiguates the ID space of different taggers. > > > > Ian > > > It is for the case of IPv6 that I am proposing we use a hash > function and relegate the use of the new option for only those > rare cases where the hash function does not properly distinguish > two different packets. > > I've been doing some more testing with hash functions, and > even MD5 seems to work very, very well for this purpose, > even if one only retains 64 bits of the hash result. Keeping > smaller hash results should help with reducing memory > requirements. Would you agree that using a sequence number could be more efficient in terms of reducing memory requirements and CPU requirements? > But we could keep the DPD option for IPv6 for the once > in a billion times [or even more rare!] occurrence of hash > duplication. I think for certain applications, duplicate IP packets will be generated often. I do not want or think these should applications to stop working when SMF DPD is used. > As another point of discussion, if a tagger encounters two > exactly identical packets, shouldn't it anyway assume that > they are duplicates and only forward one of them? What > if two different taggers encounter the same packet? > Doesn't the tagging introduce a false difference between > the packets? If there are two taggers, yes they will introduce a difference versions of the same packet - effectively creating two different packets with different DPD options. I do not see an alternative to stop disseminations of otherwise identical packets. If the tagger id is not used, we can have lots of packet loss if two taggers sequence numbers get synchronized. I believe this is much worse. If you know of an alternative way to solve this problem, please let me know. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 03:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKXc-0005l5-1z; Fri, 27 Apr 2007 03:06:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhKXZ-0005iL-PP for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 03:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhKXZ-0005iD-Dq for manet@ietf.org; Fri, 27 Apr 2007 03:06:49 -0400 Received: from web27611.mail.ukl.yahoo.com ([217.146.177.230]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhKXX-0000D3-Gq for manet@ietf.org; Fri, 27 Apr 2007 03:06:49 -0400 Received: (qmail 87856 invoked by uid 60001); 27 Apr 2007 07:06:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=j7UCcHgGxbS9KvY9CS/qCO0d3USIIIxavVt2rXx09st0SjvpMl2f5fe0KHXUwuTa1Xh6gJRH2HIe4xPFYmLgE3B/okJXDchNBIzNDtnj0mCrF1E3yelMO/cJPj0QhsBDlaSZ0+yjdF3uKrXL/Ycqx2p4/u3BqBs400Td6gsAziU=; X-YMail-OSG: 9ae1XNEVM1magkdd_FDi4d3P4o.v02Ot9CRuGtS.rZXfpNI4cJH6G7A78.3jI20HYFtShVonGv4ej0Tf.DytKejAFh8exeuUGzynCHm7gy05gyhGajzhZNS25_k- Received: from [193.95.37.75] by web27611.mail.ukl.yahoo.com via HTTP; Fri, 27 Apr 2007 07:06:45 GMT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.10 Date: Fri, 27 Apr 2007 07:06:45 +0000 (GMT) From: nadia mansouri To: manet MIME-Version: 1.0 Message-ID: <144440.83416.qm@web27611.mail.ukl.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [manet] help about AOMDV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0319917343==" Errors-To: manet-bounces@ietf.org --===============0319917343== Content-Type: multipart/alternative; boundary="0-1325971952-1177657605=:83416" --0-1325971952-1177657605=:83416 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello,=0APlease i need a response for my question,=0AI want to know if AOMD= V load the balancing and if the code of AOMDV in the site of Glomosim use m= ultiple path to transmit data between a source and a destination.=0Aplease= help me and thanks in advance.=0A=0A=0A =0A__________________________= _________________________________________________ =0AD=E9couvrez une nouvel= le fa=E7on d'obtenir des r=E9ponses =E0 toutes vos questions ! =0AProfitez = des connaissances, des opinions et des exp=E9riences des internautes sur Ya= hoo! Questions/R=E9ponses =0Ahttp://fr.answers.yahoo.com --0-1325971952-1177657605=:83416 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A
Hello,
=0A
Please i need a response f= or my question,
=0A
I want to know if AOMDV load the balancing&nbs= p;and if the code of AOMDV in the site of Glomosim use multiple path t= o transmit data between a source and  a destination.
=0A
plea= se help me and thanks in advance.

=0A=0A=0A =0A= =0A
=0AD=E9couvrez une nouvelle fa=E7on d'obtenir des = r=E9ponses =E0 toutes vos questions ! =0AProfitez des connaissances, des op= inions et des exp=E9riences des internautes sur Yahoo! Questions/R=E9ponse= s. --0-1325971952-1177657605=:83416-- --===============0319917343== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0319917343==-- From manet-bounces@ietf.org Fri Apr 27 03:56:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLJc-0006BY-Tf; Fri, 27 Apr 2007 03:56:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhLJb-00064M-8C for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 03:56:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLJa-00061L-9F for manet@ietf.org; Fri, 27 Apr 2007 03:56:26 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhLJZ-0002uW-3q for manet@ietf.org; Fri, 27 Apr 2007 03:56:26 -0400 Received: by wr-out-0506.google.com with SMTP id 71so866660wri for ; Fri, 27 Apr 2007 00:56:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=TMKIsLglg1vIkmg8j4CSDURwecqRGeHCz6YYLmEXEFIUH8sJx5gmw29dUWJmmYEsfqqqRuYcq6zr6rZTNYTQH3FRT+FxtgYjm1wsF8Z5QJg42v24JA9T8A27kXAfrDusuZqfxODnhT70vWA90Ur6CJzmx+k0Sj6s8rjo248NdIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=nxNn8r7/cSl80cBPm98B+sgZ77/5SF+Ew1eRAoGMVX+2qaCJaJeQIznvBfAmdAh6ry8cqqVj0BP/t5F8mHcW1DKUFL20ad5ankxk+3qKMPkta/VtVPMg/uuypjEoYyvqE/0TmZijBtA8n2VhAKzYVwRVa+2YjQ6zLZ14UPbkUys= Received: by 10.78.17.1 with SMTP id 1mr710242huq.1177660584068; Fri, 27 Apr 2007 00:56:24 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Fri, 27 Apr 2007 00:56:24 -0700 (PDT) Message-ID: <374005f30704270056k2f507a37vf03d56c72b25a6ae@mail.gmail.com> Date: Fri, 27 Apr 2007 13:26:24 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [manet] MANET sergeant-at-arms X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ratul Mukhopadhyay has agreed to be the MANET mailing list sergeant-at-arms. If you obtain satisfaction in his noble effort to stop inappropriate discussion on the MANET list, please send him a private thank you note. Thank you Ratul. Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 04:25:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLla-0007AJ-Ln; Fri, 27 Apr 2007 04:25:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhLlZ-0007AE-D4 for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 04:25:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhLlY-0007A3-Vd for manet@ietf.org; Fri, 27 Apr 2007 04:25:20 -0400 Received: from psmtp02.wxs.nl ([195.121.247.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhLlY-0007rj-Iv for manet@ietf.org; Fri, 27 Apr 2007 04:25:20 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by psmtp02.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JH500EOJE24BU@psmtp02.wxs.nl> for manet@ietf.org; Fri, 27 Apr 2007 10:25:19 +0200 (MEST) Date: Fri, 27 Apr 2007 10:26:18 +0200 From: Teco Boot Subject: RE: [manet] Need for DPD header (SMF document discussion) In-reply-to: <46314228.1000507@nokia.com> To: "'Charles E. Perkins'" , 'ext Joe Macker' Message-id: <000c01c788a5$bb2935d0$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceIYk6WHxF6KQHmT8WXBjhJ5AzRyQAPVIMw X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Joe, Charlie, I still don't feel comfortable with IPv4 IP header DPD testing. RFC791 needs an update for enforcing unique headers specifying a node SHOULD use IP Identification, even if the don't fragment bit is set. I monitored some traffic on my XP laptop, sending multicast looks OK. But for unicast, I received multiple copies of exactly the same IP header (checksum is same for all packets), for different sessions. I think it is not that difficult to find traffic with identical first 64 bytes for different packets. For example, I received TCP ACK frames with ID set on zeros. In combination with packet loss, the duplicate packet is needed by TCP. In theory, the problem is the same with reliable multicast and there could be systems out there having the problem. I mentioned earlier DPD would be a nice mechanism for dampening ping-ponged packets during a routing loop. And providing support for fragmentation should not be that difficult. I still think IPv4 and IPv6 specific drafts for DPD would be helpful. The drafts would describe the mechanism for unicast and multicast. SMF DPD text can be used as a start and SMF could reference to the 2 drafts. The DPD drafts would become Standards Track RFCs. And the IPv4 RFC would update RFC791. Regards, Teco > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: vrijdag 27 april 2007 2:22 > To: ext Joe Macker > Cc: manet@ietf.org > Subject: Re: [manet] Need for DPD header (SMF document discussion) > > > Hello Joe, > > I don't understand a couple of things that you said: > > ext Joe Macker wrote: > > (1) Ambiguity of hash results > > - I think we agree given a good data set this can be made very > improbable. > > No argument. > > > I'm saying, given practically any two different data sets, the > has results will differ. > > - Changing 1 bit is very good for a good hash algorithm. No argument. > Hash > > algorithms should be well-balanced. > > > This, I did not understand... > > - However, if we sample part or all of the packet (these may fast flows, > > video) there is a chance an application may produce a same in parts or > > possible completely the same packet (UDP IPv6 without RTP in vlc video > > stream for example). > > > For any such scenario, the DPD header could be applied. > > > - Is this disallowed for an application ever to do this? I know the > hybrid > > approach (3) deals with this. > > > I did not understand the questoin, unfortunately. I do not > think that the application would insert the DPD header, or > calculate the hash. > > (2) Heterogeneity of Flows at Forwarder and History Management > > - SMF is forwarding multiple flows possible from the same source or > > heterogeneous sources. These flows can arrive at orders of magnitude > > different rates (e.g., Video vs. chat). > > - a present SMF DPD tuple-based bitmap "sliding window implementation" > is > > pretty efficient straightforward engineering approach to handle this, > deals > > with out of order packets properly, and will not swamp out a slower > flows > > due to queue history management problems by one source-receiver flow > > dominating the DPD queue. > > > If you wanted to specify that, after a certain high rate > of packet sourcing, a node SHOULD begin to insert > DPD options, that would be fine with me. For sensor > nodes, I don't see this happening very often. > > - This is the same code as IPv4 code so its not like something > different is > > done. > > - With the monolithic hashing approach for all packets will it be a > > homogeneous FIFO for all packets,etc.? Timeout per packet? > > > I was thinking about a single list of hash results for single > packets, but if you believe there should be multiple lists > we could work on that...(?) > > - Or will we use a hash for the flow and a hash for the DPD. > > > I did not understand this... > > - I am open to discussion on this. > > > > (3) The Hybrid Approach to detect (1) and only add DPD in .00000001% of > time > > ;-) as you put it is allowed but I am still concerned about (2). > > > (2) basically means too many packets will cause the loss of hash > results for packets that are still actively being forwarded, if I > understand correctly. > > Please don't get me wrong I agree hashing approaches are relatively fast > and > > feel they adding great value to IP flow analysis tools,etc. > But we are discussing DPD, not flow analysis...(?) > > Sorry if I am missing something obvious! > > Regards, > Charlie P. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 04:46:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhM6P-00051O-3m; Fri, 27 Apr 2007 04:46:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhM6M-00051E-Tv for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 04:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhM6M-000513-At for manet@ietf.org; Fri, 27 Apr 2007 04:46:50 -0400 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhM6M-00026k-30 for manet@ietf.org; Fri, 27 Apr 2007 04:46:50 -0400 Received: by wr-out-0506.google.com with SMTP id 71so877764wri for ; Fri, 27 Apr 2007 01:46:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TcQaKru/o2yYwsH5rAW+PPEfxe6G/+XHBARrcLZr264dOkwbRb4zFS8A0YGGlZCNaqM0o4vaMaNY6+aJlvCpkWdbxNwFKJcsQy5Z+xr7WPmmWRQORpoJZcZbCh09mohUCc6gpEZk6WBC7dbY4FtiT/QkRTfLUsUbZqna9F+tU5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oBy6VNsXjfdDUgz6N3eIxnROgu0rJ8vdAwVOaWybSs88B+RthBim1Ixo7ihh5ECMhHWeZVuTSv2T+1pMu5YWw7I7YezXeJH6LqM93kGYrQBnHpw0XkGtJyumQRRRedm6RLccI8UiDCHSXzWS8VJbhD0W3CgwWqiGouZpfazx5iE= Received: by 10.78.131.8 with SMTP id e8mr741568hud.1177663609154; Fri, 27 Apr 2007 01:46:49 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Fri, 27 Apr 2007 01:46:49 -0700 (PDT) Message-ID: <374005f30704270146v8ac2a65vce2094bca2d22084@mail.gmail.com> Date: Fri, 27 Apr 2007 14:16:49 +0530 From: "Ian Chakeres" To: "Romain Thouvenin" Subject: Re: [manet] DYMO comments In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On 4/24/07, Romain Thouvenin wrote: > Having now a big part of the DYMO specs implemented, I reread the > whole document to see if I have some general comments that I could > provide. I found some : > > - Well this one is just a question actually. According to the > recommendations, ROUTE_NEW_TIMEOUT = ROUTE_USED_TIMEOUT. So one could > use just one ROUTE_USED timer and set it at the creation of the route. > It would take less memory and be simpler to implement. When is it > relevant to have different timers ? The different timers have different events upon expiration. If your implementation fulfills the criteria spelled out, you can do it however you like. This is one of the reasons, we explicitly called out the different functionality, so that an implementor can take it at liberty to implement it anyway they like. In earlier versions of DYMO, we actually used one timer (value) with different flags. This type of implementation is now optional. > - A detail : though section 4.2.2 does not mention MsgHdr.HopCnt, > sections 5.3.1, 5.3.2, 5.3.4 and 5.5.3 do. Furthermore, packetbb does > not allow the message header to have a HopLimit but not a HopCnt. Thus > I guess 4.2.2 should also require MsgHdr.HopCnt Done. > - section 5.3.4, "Next, this node checks whether its routing table has > an entry to the AddBlk.OrigNode.Address using longest-prefix > matching." Before doing that, ThisNode must check whether it is the > originator of the message. Otherwise it may add a route for himself, a > (wrong) route for additional nodes in the RM, and it may forward it, > introducing a lot of replicate messages. I agree this is kind of > obvious, but actually I didn't think about it at first, and I saw the > result... Done. > - section 5.5.2, "To avoid removing forwarding routes that are being > used, a node SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT > for the route to the IP.SourceAddress upon receiving a data packet.". > I am working on sensor networks, and in this context it's quite often > that, most of the time, nodes send data measurement to a base station, > which will not reply. So the reverse route is not going to be used > soon, and it is useless to keep it for long. Maybe setting the timer > should be administratively configurable ? The behavior you describe is why SHOULD is there. Would you recommend we lighten the restriction and change it to a MAY? To subtly indicate the relative importance, I did switch the IP.DestinationAddress (first) and IP.SourceAddress (second) route updates position within the draft. Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 05:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMVy-00063s-PW; Fri, 27 Apr 2007 05:13:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhMVx-00063C-Ba for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 05:13:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMVw-000630-Ny for manet@ietf.org; Fri, 27 Apr 2007 05:13:16 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhMVv-0000fA-He for manet@ietf.org; Fri, 27 Apr 2007 05:13:16 -0400 Received: by wx-out-0506.google.com with SMTP id h31so870099wxd for ; Fri, 27 Apr 2007 02:13:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hUpOJ/nI+3+tEFt1kSgjdRlwb5zL5cL6/JnTP3v4MIA0ejXdS+gRQrJhZV2dBDHyw8KiqmlTLgb+aAVEeuXwuSY1kcZWNFDgO4Xe05znUuQyBf7o1PBOQUp7doNSnJswVZUZLpEfO//PIgzkBibEPARfLTK/UG+wGZivUn+HLOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=l5BHMqPMEQRlHPzRi/pDYbrtn0VaMASOiteHR7xPu2hYy4MqAHUPJ6U+JoObgQIAh/sWyrmfUSzwv+t+xopZDJiLmgT/AYx6wWPztbJ8jUHLU/g8PGv7zVAnEVsWiVsDIt7xAv8Ors6WdHaii8sa9LOegI5ZeNWh4keg81OJfm4= Received: by 10.90.87.5 with SMTP id k5mr3113106agb.1177665195298; Fri, 27 Apr 2007 02:13:15 -0700 (PDT) Received: by 10.90.74.16 with HTTP; Fri, 27 Apr 2007 02:13:15 -0700 (PDT) Message-ID: Date: Fri, 27 Apr 2007 11:13:15 +0200 From: "Romain Thouvenin" To: "Ian Chakeres" Subject: Re: [manet] DYMO comments In-Reply-To: <374005f30704270146v8ac2a65vce2094bca2d22084@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30704270146v8ac2a65vce2094bca2d22084@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 4/27/07, Ian Chakeres wrote: > > > - section 5.5.2, "To avoid removing forwarding routes that are being > > used, a node SHOULD set a timeout (ROUTE_USED) to ROUTE_USED_TIMEOUT > > for the route to the IP.SourceAddress upon receiving a data packet.". > > I am working on sensor networks, and in this context it's quite often > > that, most of the time, nodes send data measurement to a base station, > > which will not reply. So the reverse route is not going to be used > > soon, and it is useless to keep it for long. Maybe setting the timer > > should be administratively configurable ? > > The behavior you describe is why SHOULD is there. Would you recommend > we lighten the restriction and change it to a MAY? > > To subtly indicate the relative importance, I did switch the > IP.DestinationAddress (first) and IP.SourceAddress (second) route > updates position within the draft. > > Ian > I think SHOULD is better. I suggested administratively configurable because, depending on the context of use, the timer either SHOULD or SHOULD NOT be set, and an implementation that may be used in both context would benefit from having the choice. Romain _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 07:22:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOX1-00063U-Jm; Fri, 27 Apr 2007 07:22:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhOWy-0005vU-FX for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 07:22:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOWy-0005tv-4r for manet@ietf.org; Fri, 27 Apr 2007 07:22:28 -0400 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOWw-0007us-UE for manet@ietf.org; Fri, 27 Apr 2007 07:22:28 -0400 Received: by wr-out-0506.google.com with SMTP id 71so912185wri for ; Fri, 27 Apr 2007 04:22:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XJMo6Ax8LFAJfLF/y4AEAxvt6OTFUWHCAgHA7pT78vm6fYHPzM2+I4Ff5PLtumoO9OdaG6ryEND8AbJgEUDjT3mo8jPllW5gbdi1w85t1uS+C+rBoTifveeS6JjUI6Ecl6o3HrYveiDQEC73tUgY7nyaKgT9PNPVcICBuDheDTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K+FDOAw9BB9QAlWIjdoT0g4BksnQB7oGLVSAOzeBdkGyllkB4oZw76cuNEx0LGGMn30Of9dFoRiSQcJKkwiqrJaDhFtU5H35GVA/Yl7o3zva9ogoeHAX0p64s4YdU6DFwywN/+tvciZWsKs7RdpHtJZyeZH8f3GoJIc2wnkfUE4= Received: by 10.78.204.20 with SMTP id b20mr817615hug.1177672946020; Fri, 27 Apr 2007 04:22:26 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Fri, 27 Apr 2007 04:22:25 -0700 (PDT) Message-ID: <374005f30704270422nb56dae9t250366cd271a8b42@mail.gmail.com> Date: Fri, 27 Apr 2007 16:52:25 +0530 From: "Ian Chakeres" To: "Teco Boot" In-Reply-To: <002601c7872c$ca1282b0$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002601c7872c$ca1282b0$0202a8c0@Teco> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: manet@ietf.org Subject: [manet] Re: manet-iana WG Last Call: site-local address and UDP only X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org *Site scoped muilticast OLSRv2 & DYMO are not currently sending any site-scoped multicast messages. SMF does discuss briefly discuss site-scoped multicast messaging. This was discussed in a few meetings and on the list. The consensus was that we should allocate the site-scoped multicast address, in addition to the link-local. I personally think that it would be useful to have a well-known IP address for addressing MANET routers greater than one IP hop. The thought is that we should allocate this now, so that we can start using it. *IP protocol number UDP is the mode of transport the protocols we've specified. Ian On 4/25/07, Teco Boot wrote: > Hi Ian, > > You request a site-local multicast address. I cannot find any usage of it in > the current I-Ds. Do we need this? Or always perform hop-by-hop forwarding > using a link-local address? I think the latter is used by OLSRv2 and DYMO > protocols, but I can miss something. > > You also do not request an IP protocol number. Maybe I missed a discussion > before and the outcome could be using UDP only, (may be TCP also). I cannot > find any reference. Using UDP checksum is a reason. > > Regards, Teco > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 07:52:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOzw-0006Fa-2T; Fri, 27 Apr 2007 07:52:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhOzu-0006FU-Do for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 07:52:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOzu-0006FM-4G for manet@ietf.org; Fri, 27 Apr 2007 07:52:22 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOzr-00031w-Uz for manet@ietf.org; Fri, 27 Apr 2007 07:52:22 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 7AB5C180BD for ; Fri, 27 Apr 2007 17:22:18 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 5EFA918051 for ; Fri, 27 Apr 2007 17:22:18 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Apr 2007 17:22:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [manet] guide Date: Fri, 27 Apr 2007 17:22:18 +0530 Message-ID: In-Reply-To: <765278.78582.qm@web39206.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] guide Thread-Index: AceHFZJp0zf371kZTs6KccPFu27TZgBrUCHA From: To: , X-OriginalArrivalTime: 27 Apr 2007 11:52:18.0015 (UTC) FILETIME=[81728EF0:01C788C2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1090938116==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1090938116== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C788C2.8172A9F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C788C2.8172A9F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Omid, This is the official mailing list of the IETF MANET WG. All discussions over here are meant to be limited to IETF policy, meetings, activities, or technical concerns. Any other mail not concerned with the above stated issues will only blur the important discussions that happen here. =20 It is extremely unlikely that your queries regarding Glomosim will be answered here. Please redirect them to the appropriate mailing list:=20 http://pcl.cs.ucla.edu/projects/glomosim/obtaining_glomosim.html =20 Regards, Ratul Mukhopadhyay. =20 =20 =20 =20 ________________________________ From: omid abedi [mailto:abedicomp@yahoo.com]=20 Sent: Wednesday, April 25, 2007 2:11 PM To: manet@ietf.org Subject: [manet] guide =20 dear all,=20 I want use manhattan mobility model in glomosim. are there anyone that help me? thank you. Send instant messages to your online friends http://uk.messenger.yahoo.com=20 ------_=_NextPart_001_01C788C2.8172A9F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Omid,

   This = is the official mailing list of the IETF MANET WG. All discussions over here are meant = to be limited to IETF policy, meetings, activities, or technical concerns. Any = other mail not concerned with the above stated issues will only blur the = important discussions that happen here.

 

It is extremely = unlikely that your queries regarding Glomosim will be answered here. Please = redirect them to the appropriate mailing list:

http://pcl.cs.ucla.edu/projects/glomosim/obtaining_glomosim.html

 

Regards,

Ratul = Mukhopadhyay.

 

 

 

 

From: omid = abedi [mailto:abedicomp@yahoo.com]
Sent: Wednesday, April = 25, 2007 2:11 PM
To: manet@ietf.org
Subject: [manet] = guide

 

dear all,

I want use manhattan mobility model in = glomosim.

are there anyone that help me?

thank you.

 Send instant messages to your online friends http://uk.messenger.yahoo.com =

------_=_NextPart_001_01C788C2.8172A9F1-- --===============1090938116== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1090938116==-- From manet-bounces@ietf.org Fri Apr 27 08:04:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPBs-0004HJ-RY; Fri, 27 Apr 2007 08:04:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhPBr-0004H8-De for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 08:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPBr-0004H0-42 for manet@ietf.org; Fri, 27 Apr 2007 08:04:43 -0400 Received: from wip-cdc-wd.wipro.com ([203.91.201.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPBn-00079W-H9 for manet@ietf.org; Fri, 27 Apr 2007 08:04:43 -0400 Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3A3AE180C0; Fri, 27 Apr 2007 17:34:38 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 1D1E318051; Fri, 27 Apr 2007 17:34:38 +0530 (IST) Received: from BLR-EC-MBX02.wipro.com ([10.201.50.164]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Apr 2007 17:34:37 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [manet] 2007 International Workshop on Cooperative WirelessCommunications and Networking (CoNET-07) Date: Fri, 27 Apr 2007 17:34:37 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] 2007 International Workshop on Cooperative WirelessCommunications and Networking (CoNET-07) Thread-Index: AceCJpQxLBl9/6ZLSUq1tKkznSsi2gF6k3MgAAo2zaAAIpe5EAAAYCEQ From: To: , X-OriginalArrivalTime: 27 Apr 2007 12:04:37.0938 (UTC) FILETIME=[3A79D920:01C788C4] X-Spam-Score: 0.2 (/) X-Scan-Signature: f251f249fc9a04067ce354aa0943ab98 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1654336824==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1654336824== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C788C4.3A4CB320" This is a multi-part message in MIME format. ------_=_NextPart_001_01C788C4.3A4CB320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi Yan, =20 This is the official mailing list of the IETF MANET WG. All discussions over here are meant to be limited to IETF policy, meetings, activities, or technical concerns. Any other mail not concerned with the above stated issues will only blur the important discussions that happen here. =20 This is not the appropriate list to post call for papers. It is highly recommended that you do so at the TCCC list: http://www.comsoc.org/~tccc/ =20 Repeated abuse will warrant moderation by the IETF Chair. Hoping you would comply with our request. =20 =20 Regards, Ratul Mukhopadhyay. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 -----Original Message----- From: Yan ZHANG [mailto:yanzhang@ieee.org]=20 Sent: Friday, April 27, 2007 1:05 AM To: manet@ietf.org Subject: [manet] 2007 International Workshop on Cooperative WirelessCommunications and Networking (CoNET-07) Importance: High =20 =20 [Apologies if you receive this more than once] ***************************************************************** =20 2007 International Workshop on Cooperative Wireless Communications and Networking (CoNET-07) =20 Jeju-Island, Korea, December 6-8, 2007 in conjunction with FGCN 2007 http://home.simula.no/~yanzhang/CoNET07/ =20 Submission Deadline: 15 July 2007 =20 Distinguished papers accepted and presented in CoNET-07, will be invited to contribute in the book Cooperative Wireless Communications, Auerbach Publications, Taylor&Francis Group =20 ***************************************************************** =20 General Information: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CoNET'07 will be held in conjunction with the 2007 International Conference on Future Generation Communication and Networking (FGCN 2007) on December 6-8, 2007, in Lotte Hotel, Jeju Island, Korea, http://www.sersc.org/FGCN2007/. All accepted papers in CoNET'07 will be included in the conference proceedings published by IEEE Computer Society and in the IEEE Xplore database, and will be indexed by EI.=20 =20 Distinguished papers accepted and presented in CoNET-07, will be invited to contribute in the book Cooperative Wireless Communications, Auerbach Publications, Taylor&Francis Group. =20 ------_=_NextPart_001_01C788C4.3A4CB320 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi Yan,

 

   This is the official mailing list of the IETF MANET = WG. All discussions over here are meant to be limited to IETF policy, = meetings, activities, or technical concerns. Any other mail not concerned with the above = stated issues will only blur the important discussions that happen = here.

 

This is not the appropriate list to post call for papers. It is = highly recommended that you do so at the TCCC = list:

http://www.comsoc.org/~tccc/

  

Repeated abuse will warrant moderation by the IETF Chair. Hoping = you would comply with our request.

 

 

Regards,

Ratul Mukhopadhyay.

 

 

 

 

 

 

 

 

 

 

-----Original Message-----
From: Yan ZHANG [mailto:yanzhang@ieee.org]
Sent: Friday, April 27, 2007 1:05 AM
To: manet@ietf.org
Subject: [manet] 2007 International Workshop on Cooperative WirelessCommunications and Networking (CoNET-07)
Importance: High

 

 

[Apologies if you receive this more than = once]

*****************************************************************=

 

2007 International Workshop on Cooperative Wireless = Communications and

Networking (CoNET-07)

 

Jeju-Island, Korea, = December 6-8, 2007

in conjunction with FGCN 2007

http://home.simula.no/~yanzhang/CoNET07/=

 

Submission Deadline: 15 July 2007

 

Distinguished papers accepted and presented in CoNET-07, will be invited to

contribute in the book Cooperative Wireless Communications, = Auerbach

Publications, Taylor&Francis = Group

 

*****************************************************************=

 

General Information:

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

CoNET'07 will be held in conjunction with the 2007 International Conference

on Future Generation Communication and Networking (FGCN 2007) on = December

6-8, 2007, in Lotte Hotel, Jeju Island, Korea,

http://www.sersc.org/FGCN2007/. All accepted papers in CoNET'07 = will be

included in the conference proceedings published by IEEE = Computer Society

and in the IEEE Xplore database, and will be indexed by EI. =

 

Distinguished papers accepted and presented in CoNET-07, will be invited to

contribute in the book Cooperative Wireless Communications, = Auerbach

Publications, Taylor&Francis = Group.

 

------_=_NextPart_001_01C788C4.3A4CB320-- --===============1654336824== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1654336824==-- From manet-bounces@ietf.org Fri Apr 27 10:22:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRL4-00076o-Ub; Fri, 27 Apr 2007 10:22:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhRL3-00076b-CL for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 10:22:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRL3-00076S-2m for manet@ietf.org; Fri, 27 Apr 2007 10:22:21 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRL1-0000JV-KP for manet@ietf.org; Fri, 27 Apr 2007 10:22:21 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3REMAAc016064; Fri, 27 Apr 2007 17:22:17 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 17:22:15 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:22:10 -0500 Received: from [10.162.63.23] ([10.162.63.23]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:22:09 -0500 Message-ID: <46320707.2020703@nokia.com> Date: Fri, 27 Apr 2007 07:21:59 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Teco Boot Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <000c01c788a5$bb2935d0$0202a8c0@Teco> In-Reply-To: <000c01c788a5$bb2935d0$0202a8c0@Teco> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 14:22:10.0426 (UTC) FILETIME=[715795A0:01C788D7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Teco, ext Teco Boot wrote: > Hi Joe, Charlie, > > I still don't feel comfortable with IPv4 IP header DPD testing. > RFC791 needs an update for enforcing unique headers specifying a node SHOULD > use IP Identification, even if the don't fragment bit is set. > I think this means that any method for suppressing duplicates specified in the [manet] working group should be slated for a standards-track document. I agree with this. > > I still think IPv4 and IPv6 specific drafts for DPD would be helpful. The > drafts would describe the mechanism for unicast and multicast. SMF DPD text > can be used as a start and SMF could reference to the 2 drafts. The DPD > drafts would become Standards Track RFCs. And the IPv4 RFC would update > RFC791. > But any standards track document for duplicate suppression could be interpreted as updating RFC 791. Getting support for a new IP option for IPv4 is going to be monstrously difficult. We tried this many years ago for Mobile IP and it was already too difficult. Requiring a new protocol (i.e., not a new option) for this would be almost humorously difficult. Where would the DPD option go? And why would we imagine it to be easier for source nodes to implement than the IP_ID management (which is trivial)? If the DPD option is only for gateways, then there is still the difficulty to enable IPv4 nodes receiving the packet correctly. I think the situation for IPv6 is a lot better, but from a technical standpoint still tilted mostly towards avoiding requiring the transmission of extra header bytes. By the way, having multiple tagger IDs is a detrimental factor that could affect header compression designs. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 10:48:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRkO-0007h4-K2; Fri, 27 Apr 2007 10:48:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhRkM-0007el-UA for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 10:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRjc-0007BE-UO for manet@ietf.org; Fri, 27 Apr 2007 10:47:44 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRW4-0004At-Ll for manet@ietf.org; Fri, 27 Apr 2007 10:33:45 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3REXK7u005852; Fri, 27 Apr 2007 17:33:41 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 17:33:37 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:33:35 -0500 Received: from [10.162.63.23] ([10.162.63.23]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 09:33:34 -0500 Message-ID: <463209B9.7020203@nokia.com> Date: Fri, 27 Apr 2007 07:33:29 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] Need for DPD header (SMF document discussion) - Valid Reason for Tagger ID References: <374005f30704130357r4852deb2qa270ddf6140a4bd0@mail.gmail.com> <462F9449.3070501@nokia.com> <374005f30704262347i543566d6mc0f21dd0b4b4351b@mail.gmail.com> In-Reply-To: <374005f30704262347i543566d6mc0f21dd0b4b4351b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 14:33:34.0758 (UTC) FILETIME=[093C5C60:01C788D9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian, ext Ian Chakeres wrote: > I believe your main problem with using a sequence number in the DPD > option is the consisten overhead of the option. Is that correct > Charlie? Yes, that is definitely my concern. > > Charlie do you have any suggestion on how we might uniformly compare > the overhead of the option (more bits, small memory, small CPU) vs. > the overhead of hashing (higher CPU, larger memory requirements, some > complexity in adding DPD sometimes, some more bits sometimes)? We can measure the energy expenditure for typical cases. Each bit transmitted will take a certain amount of energy. I am sure you can write the equations, and then we need to determine the parameters: - # of instruction cycles for hashing - energy per bit transmitted - energy per instruction cycle - size of typical DPD option - number of bytes of input data to be hashed (in blocks, perhaps). I believe the number of instructions for hashing can be made typically small enough so that the energy budget is far smaller than for the radio transmission. The memory requirement can be an issue, but if each hash result is only 64 bits or 32 bits, and if we are not keeping thousands of results around, I do not find it at all persuasive. Every time I turn around, prices for memory are dropping. Pretty soon a gigabyte of processor memory will cost the same as your lunch. It's already drastically cheap for disk. Regards, Charlie P. > > Other comments inline. > > On 4/25/07, Charles E. Perkins wrote: >> Hello Ian, >> >> ext Ian Chakeres wrote: >> > The tagger id is needed to differentiate between taggers, in the event >> > that the source itself (or other ensure-ably unique path element) has >> > not tagged the packet. Since IPv6 requires a new option to carry the >> > IPID, the new option optionally includes the tagger id. >> > >> > The tagger id disambiguates the ID space of different taggers. >> > >> > Ian >> > >> It is for the case of IPv6 that I am proposing we use a hash >> function and relegate the use of the new option for only those >> rare cases where the hash function does not properly distinguish >> two different packets. >> >> I've been doing some more testing with hash functions, and >> even MD5 seems to work very, very well for this purpose, >> even if one only retains 64 bits of the hash result. Keeping >> smaller hash results should help with reducing memory >> requirements. > > Would you agree that using a sequence number could be more efficient > in terms of reducing memory requirements and CPU requirements? > >> But we could keep the DPD option for IPv6 for the once >> in a billion times [or even more rare!] occurrence of hash >> duplication. > > I think for certain applications, duplicate IP packets will be > generated often. I do not want or think these should applications to > stop working when SMF DPD is used. > >> As another point of discussion, if a tagger encounters two >> exactly identical packets, shouldn't it anyway assume that >> they are duplicates and only forward one of them? What >> if two different taggers encounter the same packet? >> Doesn't the tagging introduce a false difference between >> the packets? > > If there are two taggers, yes they will introduce a difference > versions of the same packet - effectively creating two different > packets with different DPD options. I do not see an alternative to > stop disseminations of otherwise identical packets. If the tagger id > is not used, we can have lots of packet loss if two taggers sequence > numbers get synchronized. I believe this is much worse. > > If you know of an alternative way to solve this problem, please let me > know. > > Ian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 10:59:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRvH-0007rd-NP; Fri, 27 Apr 2007 10:59:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhRvG-0007me-7M for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 10:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRrn-0005GN-K0 for manet@ietf.org; Fri, 27 Apr 2007 10:56:11 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRqo-0003aO-UQ for manet@ietf.org; Fri, 27 Apr 2007 10:55:13 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3REtAjf013741; Fri, 27 Apr 2007 10:55:10 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007042710550904631 ; Fri, 27 Apr 2007 10:55:09 -0400 From: "Joe Macker" To: "'Teco Boot'" , "'Charles E. Perkins'" References: <46314228.1000507@nokia.com> <000c01c788a5$bb2935d0$0202a8c0@Teco> Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Fri, 27 Apr 2007 10:55:07 -0400 Message-ID: <005901c788dc$0b83d400$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000c01c788a5$bb2935d0$0202a8c0@Teco> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceIYk6WHxF6KQHmT8WXBjhJ5AzRyQAPVIMwAA6K0hA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I want to make it clear that for IPv4 multicast the SMF prototype implementation can override the ID field to properly sequence it? The present prototype code support deterministic ID field updating for source multicast traffic. The use of ID fields is known to not be uniformly implemented across OSes and it is well known there are problems. So even if one chose to do hashing for IPv4 this is important and you might want to use it. Other IETF groups like ROHC have described this as well. Why you may have interest we don't mess with unicast in SMF so that may warrant a separate discussion. We've contemplated writing a separate DPD IPv4 document that would provide a more robust method, but I am fan of leaving this out for the EXP SMF submission and gaining more experience. If there is interest in generalizing DPD for unicast as well we should have a separate thread since that is a new topic. >-----Original Message----- >From: Teco Boot [mailto:teco@inf-net.nl] >Sent: Friday, April 27, 2007 4:26 AM >To: 'Charles E. Perkins'; 'ext Joe Macker' >Cc: manet@ietf.org >Subject: RE: [manet] Need for DPD header (SMF document discussion) > >Hi Joe, Charlie, > >I still don't feel comfortable with IPv4 IP header DPD testing. >RFC791 needs an update for enforcing unique headers specifying >a node SHOULD use IP Identification, even if the don't >fragment bit is set. > >I monitored some traffic on my XP laptop, sending multicast >looks OK. But for unicast, I received multiple copies of >exactly the same IP header (checksum is same for all packets), >for different sessions. I think it is not that difficult to >find traffic with identical first 64 bytes for different >packets. For example, I received TCP ACK frames with ID set on >zeros. In combination with packet loss, the duplicate packet >is needed by TCP. In theory, the problem is the same with >reliable multicast and there could be systems out there having >the problem. > >I mentioned earlier DPD would be a nice mechanism for >dampening ping-ponged packets during a routing loop. And >providing support for fragmentation should not be that difficult. > >I still think IPv4 and IPv6 specific drafts for DPD would be >helpful. The drafts would describe the mechanism for unicast >and multicast. SMF DPD text can be used as a start and SMF >could reference to the 2 drafts. The DPD drafts would become >Standards Track RFCs. And the IPv4 RFC would update RFC791. > >Regards, Teco > > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >> Sent: vrijdag 27 april 2007 2:22 >> To: ext Joe Macker >> Cc: manet@ietf.org >> Subject: Re: [manet] Need for DPD header (SMF document discussion) >> >> >> Hello Joe, >> >> I don't understand a couple of things that you said: >> >> ext Joe Macker wrote: >> > (1) Ambiguity of hash results >> > - I think we agree given a good data set this can be made very >> improbable. >> > No argument. >> > >> I'm saying, given practically any two different data sets, the has >> results will differ. >> > - Changing 1 bit is very good for a good hash algorithm. >No argument. >> Hash >> > algorithms should be well-balanced. >> > >> This, I did not understand... >> > - However, if we sample part or all of the packet (these may fast >flows, >> > video) there is a chance an application may produce a same >in parts >> > or possible completely the same packet (UDP IPv6 without >RTP in vlc >> > video stream for example). >> > >> For any such scenario, the DPD header could be applied. >> >> > - Is this disallowed for an application ever to do this? I know >> > the >> hybrid >> > approach (3) deals with this. >> > >> I did not understand the questoin, unfortunately. I do not >think that >> the application would insert the DPD header, or calculate the hash. >> > (2) Heterogeneity of Flows at Forwarder and History Management >> > - SMF is forwarding multiple flows possible from the same >source or >> > heterogeneous sources. These flows can arrive at orders of >> > magnitude different rates (e.g., Video vs. chat). >> > - a present SMF DPD tuple-based bitmap "sliding window >implementation" >> is >> > pretty efficient straightforward engineering approach to handle >> > this, >> deals >> > with out of order packets properly, and will not swamp out a slower >> flows >> > due to queue history management problems by one >source-receiver flow >> > dominating the DPD queue. >> > >> If you wanted to specify that, after a certain high rate of packet >> sourcing, a node SHOULD begin to insert DPD options, that would be >> fine with me. For sensor nodes, I don't see this happening very >> often. >> > - This is the same code as IPv4 code so its not like something >> different is >> > done. >> > - With the monolithic hashing approach for all packets >will it be a >> > homogeneous FIFO for all packets,etc.? Timeout per packet? >> > >> I was thinking about a single list of hash results for >single packets, >> but if you believe there should be multiple lists we could work on >> that...(?) >> > - Or will we use a hash for the flow and a hash for the DPD. >> > >> I did not understand this... >> > - I am open to discussion on this. >> > >> > (3) The Hybrid Approach to detect (1) and only add DPD in >.00000001% >> > of >> time >> > ;-) as you put it is allowed but I am still concerned about (2). >> > >> (2) basically means too many packets will cause the loss of hash >> results for packets that are still actively being forwarded, if I >> understand correctly. >> > Please don't get me wrong I agree hashing approaches are >relatively >> > fast >> and >> > feel they adding great value to IP flow analysis tools,etc. >> But we are discussing DPD, not flow analysis...(?) >> >> Sorry if I am missing something obvious! >> >> Regards, >> Charlie P. >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 11:01:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRwY-00021W-VM; Fri, 27 Apr 2007 11:01:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhRwX-0001rp-85 for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRwW-0001oe-Qv for manet@ietf.org; Fri, 27 Apr 2007 11:01:04 -0400 Received: from smtp17.wxs.nl ([195.121.247.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRwU-00067T-FC for manet@ietf.org; Fri, 27 Apr 2007 11:01:04 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by smtp17.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JH500A9ZVZ7CI@smtp17.wxs.nl> for manet@ietf.org; Fri, 27 Apr 2007 16:52:22 +0200 (CEST) Date: Fri, 27 Apr 2007 16:53:21 +0200 From: Teco Boot Subject: RE: [manet] Need for DPD header (SMF document discussion) In-reply-to: <46320707.2020703@nokia.com> To: "'Charles E. Perkins'" Message-id: <004b01c788db$cd0dfd90$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceI13g94yFuOsreRlOFKxl/UF3PKwAAc9OA X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Charlie, I do not propose a new IPv4 header option. I propose better specification of usage of the Identification field. It would be a smooth update / upgrade. It could take a long term migration. Nodes that do not fill in the Id field as required by DPD would have their packets dropped in the MANET. I doubt if this is a large problem, nowadays there is no "connected" MANET which means no connectivity at all. For IPv6 headers, there is nothing available for making packets unique. So we need the DPD option. Doable, but IMHO more difficult than IPv4. For example, we could introduce a trigger start sending packets with the DPD option on the source. With DPD option, header compression algorithm is somewhat more complex. But I don't see big problems. And it should not add BW requirements, assuming sequenced Ids and an extension on some RFCs implemented. First focus on finishing SMF as experimental and then start the real DPD stuff going as STD? Regards, Teco > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: vrijdag 27 april 2007 16:22 > To: ext Teco Boot > Cc: manet@ietf.org > Subject: Re: [manet] Need for DPD header (SMF document discussion) > > > Hello Teco, > > ext Teco Boot wrote: > > Hi Joe, Charlie, > > > > I still don't feel comfortable with IPv4 IP header DPD testing. > > RFC791 needs an update for enforcing unique headers specifying a node > SHOULD > > use IP Identification, even if the don't fragment bit is set. > > > I think this means that any method for suppressing duplicates specified > in the [manet] working group should be slated for a standards-track > document. I agree with this. > > > > I still think IPv4 and IPv6 specific drafts for DPD would be helpful. > The > > drafts would describe the mechanism for unicast and multicast. SMF DPD > text > > can be used as a start and SMF could reference to the 2 drafts. The DPD > > drafts would become Standards Track RFCs. And the IPv4 RFC would update > > RFC791. > > > But any standards track document for duplicate suppression could > be interpreted as updating RFC 791. Getting support for a new > IP option for IPv4 is going to be monstrously difficult. We tried > this many years ago for Mobile IP and it was already too difficult. > Requiring a new protocol (i.e., not a new option) for this would > be almost humorously difficult. Where would the DPD option go? > And why would we imagine it to be easier for source nodes to > implement than the IP_ID management (which is trivial)? If the > DPD option is only for gateways, then there is still the difficulty > to enable IPv4 nodes receiving the packet correctly. > > I think the situation for IPv6 is a lot better, but from a technical > standpoint still tilted mostly towards avoiding requiring the > transmission of extra header bytes. > > By the way, having multiple tagger IDs is a detrimental factor > that could affect header compression designs. > > Regards, > Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 11:01:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRwa-0002BP-6W; Fri, 27 Apr 2007 11:01:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhRwX-0001uA-Oe for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:01:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRwX-0001s0-AY for manet@ietf.org; Fri, 27 Apr 2007 11:01:05 -0400 Received: from smtp17.wxs.nl ([195.121.247.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRwW-00067T-UE for manet@ietf.org; Fri, 27 Apr 2007 11:01:05 -0400 Received: from Teco (ip56530916.direct-adsl.nl [86.83.9.22]) by smtp17.wxs.nl (iPlanet Messaging Server 5.2 HotFix 2.15 (built Nov 14 2006)) with ESMTP id <0JH500DSHWB0U9@smtp17.wxs.nl> for manet@ietf.org; Fri, 27 Apr 2007 16:59:27 +0200 (CEST) Date: Fri, 27 Apr 2007 17:00:25 +0200 From: Teco Boot Subject: RE: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID In-reply-to: <463209B9.7020203@nokia.com> To: "'Charles E. Perkins'" Message-id: <004c01c788dc$ca0c60e0$0202a8c0@Teco> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceI20MzRI9actCdReOF2erx8xDIAAAAItxQ X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Small comment: If memory is really cheap and memory lookups can be performed faster than hash calculations, the DPD code could use packet header lookup instead of hash lookup. Functionality is the same. Both mechanisms rely on unique packet headers (say 1st 64 bytes or defined fields). That is what should be specified in the standard. Which method is used for verifying duplicates is an implementation issue. Regards, Teco > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: vrijdag 27 april 2007 16:33 > To: ext Ian Chakeres > Cc: manet > Subject: Re: [manet] Need for DPD header (SMF document discussion) - > ValidReason for Tagger ID > > > Hello Ian, > > ext Ian Chakeres wrote: > > I believe your main problem with using a sequence number in the DPD > > option is the consisten overhead of the option. Is that correct > > Charlie? > Yes, that is definitely my concern. > > > > Charlie do you have any suggestion on how we might uniformly compare > > the overhead of the option (more bits, small memory, small CPU) vs. > > the overhead of hashing (higher CPU, larger memory requirements, some > > complexity in adding DPD sometimes, some more bits sometimes)? > We can measure the energy expenditure for typical cases. > Each bit transmitted will take a certain amount of energy. > I am sure you can write the equations, and then we need to > determine the parameters: > - # of instruction cycles for hashing > - energy per bit transmitted > - energy per instruction cycle > - size of typical DPD option > - number of bytes of input data to be hashed > (in blocks, perhaps). > > I believe the number of instructions for hashing can be > made typically small enough so that the energy budget > is far smaller than for the radio transmission. > > The memory requirement can be an issue, but if each hash > result is only 64 bits or 32 bits, and if we are not keeping > thousands of results around, I do not find it at all > persuasive. Every time I turn around, prices for memory > are dropping. Pretty soon a gigabyte of processor > memory will cost the same as your lunch. It's already > drastically cheap for disk. > > Regards, > Charlie P. > > > > > Other comments inline. > > > > On 4/25/07, Charles E. Perkins wrote: > >> Hello Ian, > >> > >> ext Ian Chakeres wrote: > >> > The tagger id is needed to differentiate between taggers, in the > event > >> > that the source itself (or other ensure-ably unique path element) has > >> > not tagged the packet. Since IPv6 requires a new option to carry the > >> > IPID, the new option optionally includes the tagger id. > >> > > >> > The tagger id disambiguates the ID space of different taggers. > >> > > >> > Ian > >> > > >> It is for the case of IPv6 that I am proposing we use a hash > >> function and relegate the use of the new option for only those > >> rare cases where the hash function does not properly distinguish > >> two different packets. > >> > >> I've been doing some more testing with hash functions, and > >> even MD5 seems to work very, very well for this purpose, > >> even if one only retains 64 bits of the hash result. Keeping > >> smaller hash results should help with reducing memory > >> requirements. > > > > Would you agree that using a sequence number could be more efficient > > in terms of reducing memory requirements and CPU requirements? > > > >> But we could keep the DPD option for IPv6 for the once > >> in a billion times [or even more rare!] occurrence of hash > >> duplication. > > > > I think for certain applications, duplicate IP packets will be > > generated often. I do not want or think these should applications to > > stop working when SMF DPD is used. > > > >> As another point of discussion, if a tagger encounters two > >> exactly identical packets, shouldn't it anyway assume that > >> they are duplicates and only forward one of them? What > >> if two different taggers encounter the same packet? > >> Doesn't the tagging introduce a false difference between > >> the packets? > > > > If there are two taggers, yes they will introduce a difference > > versions of the same packet - effectively creating two different > > packets with different DPD options. I do not see an alternative to > > stop disseminations of otherwise identical packets. If the tagger id > > is not used, we can have lots of packet loss if two taggers sequence > > numbers get synchronized. I believe this is much worse. > > > > If you know of an alternative way to solve this problem, please let me > > know. > > > > Ian > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 11:09:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhS54-0003vK-L8; Fri, 27 Apr 2007 11:09:54 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhS52-0003vE-Jz for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhS52-0003v6-AT for manet@ietf.org; Fri, 27 Apr 2007 11:09:52 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhS52-0008FO-0U for manet@ietf.org; Fri, 27 Apr 2007 11:09:52 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3RF9hrx014707; Fri, 27 Apr 2007 11:09:51 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007042711095104733 ; Fri, 27 Apr 2007 11:09:51 -0400 From: "Joe Macker" To: "'Charles E. Perkins'" References: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <461D509A.1050209@nokia.com> <006e01c7881e$c8fd0510$165cfa84@SEXTANT> <4630F017.5000006@nokia.com> <00a501c78846$db6954b0$165cfa84@SEXTANT> <46314228.1000507@nokia.com> Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Fri, 27 Apr 2007 11:09:48 -0400 Message-ID: <006601c788de$193269c0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46314228.1000507@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceIYhfA3lioQ1XNTDar0a5DwaFDiwAegExg X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >Sent: Thursday, April 26, 2007 8:22 PM >To: ext Joe Macker >Cc: manet@ietf.org >Subject: Re: [manet] Need for DPD header (SMF document discussion) > > >Hello Joe, > >I don't understand a couple of things that you said: > >ext Joe Macker wrote: >> (1) Ambiguity of hash results >> - I think we agree given a good data set this can be made >very improbable. >> No argument. >> >I'm saying, given practically any two different data sets, the >has results will differ. Right we agree assuming certain conditions: length of sample set and quality and length of hash result. We agree this is feasible with different data sets. >> - Changing 1 bit is very good for a good hash algorithm. No >> argument. Hash algorithms should be well-balanced. >> >This, I did not understand... We agree. You said changing even 1 bit produced a different hash. Of course that is true as a property of a good hash algorithm. >> - However, if we sample part or all of the packet (these may fast >> flows, >> video) there is a chance an application may produce a same >in parts or >> possible completely the same packet (UDP IPv6 without RTP in >vlc video >> stream for example). >> >For any such scenario, the DPD header could be applied. > >> - Is this disallowed for an application ever to do this? I >know the >> hybrid approach (3) deals with this. >> >I did not understand the questoin, unfortunately. I do not >think that the application would insert the DPD header, or >calculate the hash. We are saying the same thing here. >> (2) Heterogeneity of Flows at Forwarder and History Management >> - SMF is forwarding multiple flows possible from the same source or >> heterogeneous sources. These flows can arrive at orders of >magnitude >> different rates (e.g., Video vs. chat). >> - a present SMF DPD tuple-based bitmap "sliding window >> implementation" is pretty efficient straightforward engineering >> approach to handle this, deals with out of order packets >properly, and >> will not swamp out a slower flows due to queue history management >> problems by one source-receiver flow dominating the DPD queue. >> >If you wanted to specify that, after a certain high rate of >packet sourcing, a node SHOULD begin to insert DPD options, >that would be fine with me. For sensor nodes, I don't see >this happening very often. I think we both I understand and I am just less convinced until I see an implementation experimented with lots of heterogeneous flows. >> - This is the same code as IPv4 code so its not like something >> different is done. >> - With the monolithic hashing approach for all packets will it be a >> homogeneous FIFO for all packets,etc.? Timeout per packet? >> >I was thinking about a single list of hash results for single >packets, but if you believe there should be multiple lists we >could work on that...(?) Right that is my point. I am less convinced a single list is good. You realize we are keeping very little state on individual packets (1 bit) and can implement a sliding window per tuple? >> - Or will we use a hash for the flow and a hash for the DPD. >> >I did not understand this... Same as above just pointing out potential for multiple lists...but I don't see an advantage over tuple-based. >> - I am open to discussion on this. >> >> (3) The Hybrid Approach to detect (1) and only add DPD in .00000001% >> of time >> ;-) as you put it is allowed but I am still concerned about (2). >> >(2) basically means too many packets will cause the loss of >hash results for packets that are still actively being >forwarded, if I understand correctly. Yes, that is a concern. Remember this is about envisioning a larger set of heterogeneous forwarders and how stale entries will be purged,etc. We borrowed some of your previous thoughts here on how to control purging the data. Each node is potentially handling very different data sets at different rates and potentially varying sources/destination. I think we need to further experiment with issues in this regard in maanging the DPD. >> Please don't get me wrong I agree hashing approaches are relatively >> fast and feel they adding great value to IP flow analysis tools,etc. >But we are discussing DPD, not flow analysis...(?) > >Sorry if I am missing something obvious! > >Regards, >Charlie P. > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 11:54:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSlm-0001Qc-NX; Fri, 27 Apr 2007 11:54:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhSll-0001Pu-BI for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSll-0001Pm-16 for manet@ietf.org; Fri, 27 Apr 2007 11:54:01 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSlj-0000G3-O8 for manet@ietf.org; Fri, 27 Apr 2007 11:54:01 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3RFriRQ006362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Apr 2007 08:53:58 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3RFrilf003514; Fri, 27 Apr 2007 08:53:44 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3RFrhPI003498; Fri, 27 Apr 2007 08:53:44 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 08:53:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Fri, 27 Apr 2007 08:53:41 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED763@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <004b01c788db$cd0dfd90$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Need for DPD header (SMF document discussion) Thread-Index: AceI13g94yFuOsreRlOFKxl/UF3PKwAAc9OAAAI8+UA= References: <46320707.2020703@nokia.com> <004b01c788db$cd0dfd90$0202a8c0@Teco> From: "Templin, Fred L" To: "Teco Boot" , "Charles E. Perkins" X-OriginalArrivalTime: 27 Apr 2007 15:53:41.0941 (UTC) FILETIME=[3A8A4650:01C788E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org =20 Teco, > I do not propose a new IPv4 header option. I propose better=20 > specification of > usage of the Identification field. Although I agree that the network cannot currently rely on the ip_id field to contribute uniqueness information for DPD, the setting of ip_id is an end-to-end consideration between the source and destination(s). So, it would be unreasonable to mandate a specific behavior that a source host must use (e.g., monotonically-increasing) strictly for the purpose of being friendly to network middleboxes. Fred fred.l.templin@boeing.com _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 11:58:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSq0-0006wn-Jw; Fri, 27 Apr 2007 11:58:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhSpy-0006ZI-I3 for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 11:58:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSpx-0006TJ-W9 for manet@ietf.org; Fri, 27 Apr 2007 11:58:22 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSpw-0001X4-GN for manet@ietf.org; Fri, 27 Apr 2007 11:58:21 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RFw6xf010425; Fri, 27 Apr 2007 18:58:18 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 18:58:10 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 10:58:08 -0500 Received: from [10.162.63.23] ([10.162.63.23]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 10:58:07 -0500 Message-ID: <46321D8A.2030305@nokia.com> Date: Fri, 27 Apr 2007 08:58:02 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Teco Boot Subject: Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID References: <004c01c788dc$ca0c60e0$0202a8c0@Teco> In-Reply-To: <004c01c788dc$ca0c60e0$0202a8c0@Teco> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 15:58:08.0228 (UTC) FILETIME=[D9427240:01C788E4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Teco, ext Teco Boot wrote: > If memory is really cheap and memory lookups can be performed faster than > hash calculations, the DPD code could use packet header lookup instead of > hash lookup. Functionality is the same. Check. > Both mechanisms rely on unique > packet headers (say 1st 64 bytes or defined fields). The defined fields could include some amount of payload. > That is what should be > specified in the standard. Which method is used for verifying duplicates is > an implementation issue. > I think for IPv6 has also to specify which hash function to use. For IPv4 I am hoping we do not need a hash function or any DPD header. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 12:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT4O-0006SJ-Jq; Fri, 27 Apr 2007 12:13:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhT4N-0006Rr-3S for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 12:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT4M-0006Rd-Pq for manet@ietf.org; Fri, 27 Apr 2007 12:13:14 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhT4L-0006Ra-AI for manet@ietf.org; Fri, 27 Apr 2007 12:13:14 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RGCtDn014879; Fri, 27 Apr 2007 19:13:11 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 19:13:01 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 11:12:45 -0500 Received: from [10.162.63.23] ([10.162.63.23]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 11:12:44 -0500 Message-ID: <463220F6.6040203@nokia.com> Date: Fri, 27 Apr 2007 09:12:38 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Joe Macker Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <461D509A.1050209@nokia.com> <006e01c7881e$c8fd0510$165cfa84@SEXTANT> <4630F017.5000006@nokia.com> <00a501c78846$db6954b0$165cfa84@SEXTANT> <46314228.1000507@nokia.com> <006601c788de$193269c0$165cfa84@SEXTANT> In-Reply-To: <006601c788de$193269c0$165cfa84@SEXTANT> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 16:12:44.0796 (UTC) FILETIME=[E3BC1BC0:01C788E6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Joe, Thanks for the clarifications. ext Joe Macker wrote: >> >> I'm saying, given practically any two different data sets, the >> has results will differ. >> > > Right we agree assuming certain conditions: length of sample set and quality > and length of hash result. > > My claim was specific to 64 bits of MD5 hash result. Under those conditions, I think that practically any two inputs will produce different hash results, regardless of length or "quality" -- as long as they are actually different. > >> If you wanted to specify that, after a certain high rate of >> packet sourcing, a node SHOULD begin to insert DPD options, >> that would be fine with me. For sensor nodes, I don't see >> this happening very often. >> > > I think we both I understand and I am just less convinced until I see an > implementation experimented with lots of heterogeneous flows. > Actually, in this case I think relying on experimentation would be unwise. If you have some flow datasets you'd like to try, I'd be happy to run them through and get the results. However, relying on empirical data using real traffic would be problematic for two reasons: - we already agree that the failure condition would be quite rare - it would be very very difficult to debug in practice. I think it is better to abstractly characterize the kind of data that the hash function has to distinguish, and then run a few billion test cases. Do you have an abstract characterization of the kinds of data you'd like to see handled properly by the hash function? > > Right that is my point. I am less convinced a single list is good. You > realize we are keeping very little state on individual packets (1 bit) and > can implement a sliding window per tuple? > More on this later... I am wondering about it. However, I do understand what you are saying. > > > Each node is potentially handling very different data sets at > different rates and potentially varying sources/destination. I think we > need to further experiment with issues in this regard in maanging the DPD. > Having multiple queues of hash results is doable, but I'm not yet persuaded that we have to go to the trouble of actually doing it. I think it would be better to just require the extra DPD header for such high-volume flows. In this case, putting the functionality at the gateway makes sense to me. It seems more likely to me that any such problem would arise as a result of multiple downloads into the ad hoc network from multiple points of connectivity to the Internet. Maybe the jungle crews are watching several different TV shows :-) Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 12:54:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTiI-0002hk-Ck; Fri, 27 Apr 2007 12:54:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhTiG-0002hf-TN for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 12:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTiG-0002hM-JV for manet@ietf.org; Fri, 27 Apr 2007 12:54:28 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhTiF-0008Is-13 for manet@ietf.org; Fri, 27 Apr 2007 12:54:28 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l3RGsQIG020624; Fri, 27 Apr 2007 12:54:26 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007042712542605252 ; Fri, 27 Apr 2007 12:54:26 -0400 From: "Joe Macker" To: "'Charles E. Perkins'" References: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <461D509A.1050209@nokia.com> <006e01c7881e$c8fd0510$165cfa84@SEXTANT> <4630F017.5000006@nokia.com> <00a501c78846$db6954b0$165cfa84@SEXTANT> <46314228.1000507@nokia.com> <006601c788de$193269c0$165cfa84@SEXTANT> <463220F6.6040203@nokia.com> Subject: RE: [manet] Need for DPD header (SMF document discussion) Date: Fri, 27 Apr 2007 12:54:23 -0400 Message-ID: <007601c788ec$b52f16d0$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <463220F6.6040203@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceI5vZVBSgxxmXbSE64MLoZlB2z2AAAZnmQ X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >Sent: Friday, April 27, 2007 12:13 PM >To: ext Joe Macker >Cc: manet@ietf.org >Subject: Re: [manet] Need for DPD header (SMF document discussion) > > >Hello Joe, > >Thanks for the clarifications. > >ext Joe Macker wrote: >>> >>> I'm saying, given practically any two different data sets, the has >>> results will differ. >>> >> >> Right we agree assuming certain conditions: length of sample set and >> quality and length of hash result. >> >> > >My claim was specific to 64 bits of MD5 hash result. >Under those conditions, I think that practically any two >inputs will produce different hash results, regardless of >length or "quality" -- as long as they are actually different. Agreed. >> >>> If you wanted to specify that, after a certain high rate of packet >>> sourcing, a node SHOULD begin to insert DPD options, that would be >>> fine with me. For sensor nodes, I don't see this happening very >>> often. >>> >> >> I think we both I understand and I am just less convinced >until I see >> an implementation experimented with lots of heterogeneous flows. >> > >Actually, in this case I think relying on experimentation >would be unwise. If you have some flow datasets you'd like to >try, I'd be happy to run them through and get the results. >However, relying on empirical data using real traffic would be >problematic for two reasons: >- we already agree that the failure condition would be quite rare >- it would be very very difficult to debug in practice. > >I think it is better to abstractly characterize the kind of >data that the hash function has to distinguish, and then run a >few billion test cases. > >Do you have an abstract characterization of the kinds of data >you'd like to see handled properly by the hash function? I am talking about the heterogeneity of flows and DPD purging and state maintenance. Some fast flows some slow flows from the samce source to different destinations. Lets say multicast video-over-IP and multicast chat (with keep alives,etc). Also in the forwarding the handling of set of heterogeneous flows and purging of old DPD data. Are you planning on maintaining additional timing state per DPD entry, etc or just use some large FIFO list. All these issues are important. ---------------------------------------- Let me try to summarize you thoughts so we can move. I think we can agree there is a more to learn. IPv4 approach presently is fine or you hope so as do I. It certainly has been working in a mobile emulation testbed for many years now. For IPv6 you are not against a DPD header to add some header variability "on demand" but you are of the opinion that a hash list is your preferred method for the majority of cases. -Joe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Apr 27 15:35:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWDf-0007nH-Tj; Fri, 27 Apr 2007 15:35:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HhWDe-0007n5-BT for manet-confirm+ok@megatron.ietf.org; Fri, 27 Apr 2007 15:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWDe-0007mw-1k for manet@ietf.org; Fri, 27 Apr 2007 15:35:02 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhWDc-0008EE-Ib for manet@ietf.org; Fri, 27 Apr 2007 15:35:02 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3RJYkZW003665; Fri, 27 Apr 2007 22:34:58 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 22:34:56 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 14:34:54 -0500 Received: from [10.162.63.23] ([10.162.63.23]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 14:34:53 -0500 Message-ID: <46325057.3070909@nokia.com> Date: Fri, 27 Apr 2007 12:34:47 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Joe Macker Subject: Re: [manet] Need for DPD header (SMF document discussion) References: <77F357662F8BFA4CA7074B0410171B6D04049256@XCH-NW-5V1.nw.nos.boeing.com> <461D509A.1050209@nokia.com> <006e01c7881e$c8fd0510$165cfa84@SEXTANT> <4630F017.5000006@nokia.com> <00a501c78846$db6954b0$165cfa84@SEXTANT> <46314228.1000507@nokia.com> <006601c788de$193269c0$165cfa84@SEXTANT> <463220F6.6040203@nokia.com> <007601c788ec$b52f16d0$165cfa84@SEXTANT> In-Reply-To: <007601c788ec$b52f16d0$165cfa84@SEXTANT> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 19:34:53.0952 (UTC) FILETIME=[21467000:01C78903] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Joe, To put it briefly, ext Joe Macker wrote: > > Let me try to summarize you thoughts so we can move. I think we can agree > there is a more to learn. > > IPv4 approach presently is fine or you hope so as do I. It certainly has > been working in a mobile emulation testbed for many years now. For IPv6 you > are not against a DPD header to add some header variability "on demand" but > you are of the opinion that a hash list is your preferred method for the > majority of cases. Yes. Regards, Charlie P. PS. If it is the preferred method for _only me_ , and no one else on the mailing list wants to emphasize energy cost over the other considerations, then I am happy to give up the discussion! _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Apr 30 07:11:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTmy-0002T6-Vl; Mon, 30 Apr 2007 07:11:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HiTmx-0002IP-Fg for manet-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 07:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiTmx-0002F9-3L for manet@ietf.org; Mon, 30 Apr 2007 07:11:27 -0400 Received: from web51108.mail.re2.yahoo.com ([206.190.38.150]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiTmt-0005mc-LE for manet@ietf.org; Mon, 30 Apr 2007 07:11:27 -0400 Received: (qmail 62701 invoked by uid 60001); 30 Apr 2007 11:11:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=AtEmDGs4Tyex+ov3GUos18JsOx3FDEPPuFT5AMG59pFkTf9z7qiDSWjFNZtCcKueWLoTDRDqlNplFoGS6zRXWRqeHKKs7piHTWBITr16j6fYztMGXdAjVjT541o1pGIf9fT4Uy3PltHylz37xlSqDXkl5V6QVPX4XH0naaWuKVA=; X-YMail-OSG: jP3BNdAVM1mU0GV60z65Z6UIy2mIn.107ksyLKL43PW6cgcq8ugZ0aygfywJG.GLfQW8_tPW76turo6Dj5C_SYIFrA-- Received: from [62.135.70.204] by web51108.mail.re2.yahoo.com via HTTP; Mon, 30 Apr 2007 04:11:23 PDT Date: Mon, 30 Apr 2007 04:11:23 -0700 (PDT) From: AHMED SALAH To: manet@ietf.org MIME-Version: 1.0 Message-ID: <496408.62505.qm@web51108.mail.re2.yahoo.com> X-Spam-Score: 2.1 (++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [manet] problem with new protocl implementation X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1034541519==" Errors-To: manet-bounces@ietf.org --===============1034541519== Content-Type: multipart/alternative; boundary="0-825559140-1177931483=:62505" Content-Transfer-Encoding: 8bit --0-825559140-1177931483=:62505 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit dear all, I am new user to ns Iam using ns-2.1b7a on linux fedora opereating system I have to run new protocol not included in ns2 so we have modfied some ns files such(cmu-trace.cc, cmu-trace.h, god.cc, god.h, ns-packet.tcl, packet.h, Makefile.in,ll.cc) when I use the command "make" to recompil ns I get the following error message cmu-trace.cc: In member function `void CMUTrace::format_rtp(Packet*, int)': cmu-trace.cc:370: error: 'struct hdr_rtp' has no member named 'pktsendtime_' make: *** [cmu-trace.o] Error 1 *********************************** the following lins from cmu-trace.ccthat caus the problem***************************** void CMUTrace::format_rtp(Packet *p, int offset) { struct hdr_cmn *ch = HDR_CMN(p); struct hdr_rtp *rh = HDR_RTP(p); struct hdr_ip *ih = HDR_IP(p); Node* thisnode = Node::get_node_by_address(src_); //hacking, needs to change later, int dst = Address::instance().get_nodeaddr(ih->daddr()); if (dst == src_){ // I just received a cbr data packet if (thisnode->energy_model() && thisnode->energy_model()->powersavingflag()) { thisnode->energy_model()->set_node_state(EnergyModel::INROUTE); } } if (newtrace_) { sprintf(wrk_ + offset, "-Pn cbr -Pi %d -Pf %d -Po %d -Pt %.9f", rh->seqno_, ch->num_forwards(), ch->opt_num_forwards(), rh->pktsendtime_); } else { sprintf(wrk_ + offset, "[%d] %d %d", rh->seqno_, ch->num_forwards(), ********************************************************************* regards ahmad, --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. --0-825559140-1177931483=:62505 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

dear all, I am new user to ns
Iam using ns-2.1b7a on linux fedora opereating system
I have to run new protocol  not included in ns2 so we have modfied some ns files such(cmu-trace.cc, cmu-trace.h, god.cc, god.h, ns-packet.tcl, packet.h, Makefile.in,ll.cc)
when I use the command "make" to recompil ns  I get the following error message
 

cmu-trace.cc: In member function `void CMUTrace::format_rtp(Packet*, int)':
cmu-trace.cc:370: error: 'struct hdr_rtp' has no member named 'pktsendtime_'
make: *** [cmu-trace.o] Error 1
 
*********************************** the following lins from cmu-trace.ccthat caus the problem*****************************
 
 
void
CMUTrace::format_rtp(Packet *p, int offset)
{
struct hdr_cmn *ch = HDR_CMN(p);
struct hdr_rtp *rh = HDR_RTP(p);
struct hdr_ip *ih = HDR_IP(p);
        Node* thisnode = Node::get_node_by_address(src_);
//hacking, needs to change later,
        int dst = Address::instance().get_nodeaddr(ih->daddr());
if (dst == src_){
// I just received a cbr data packet
if (thisnode->energy_model() &&
    thisnode->energy_model()->powersavingflag()) {
thisnode->energy_model()->set_node_state(EnergyModel::INROUTE);
}
        }
if (newtrace_) {
sprintf(wrk_ + offset,
"-Pn cbr -Pi %d -Pf %d -Po %d -Pt %.9f",
rh->seqno_,
ch->num_forwards(),
ch->opt_num_forwards(),
rh->pktsendtime_);
} else {
sprintf(wrk_ + offset,
"[%d] %d %d",
rh->seqno_,
ch->num_forwards(),
*********************************************************************
 
regards ahmad,

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-825559140-1177931483=:62505-- --===============1034541519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1034541519==-- From manet-bounces@ietf.org Mon Apr 30 08:36:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiV7X-0006tn-IQ; Mon, 30 Apr 2007 08:36:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HiV7W-0006ti-Hw for manet-confirm+ok@megatron.ietf.org; Mon, 30 Apr 2007 08:36:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiV7W-0006ta-67 for manet@ietf.org; Mon, 30 Apr 2007 08:36:46 -0400 Received: from web56714.mail.re3.yahoo.com ([66.196.97.73]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HiV7U-0001sw-7Q for manet@ietf.org; Mon, 30 Apr 2007 08:36:45 -0400 Received: (qmail 53156 invoked by uid 60001); 30 Apr 2007 12:36:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=i6vQxQONJ9M3dIOQN/5vZKhstHLki7GxEdJ6zerLpRZGLJsvmDtKxpz0ndrrccWNyU1akf16WI3+tKYY9oBASM/V6G0UaVmxuViDFZMY3v29HJYkNKej7eI40jknOQ8tmbGiPGYCSA4XxiqNutdJ+UR64Jc6rnR/5EX0jpsH1p8=; X-YMail-OSG: A9BoKR8VM1m4s3XiM2RV7ZxYwAIJssprZtLe2UmcJa4nnL_7yFwob9PEwLPJwnQHzw-- Received: from [217.218.101.38] by web56714.mail.re3.yahoo.com via HTTP; Mon, 30 Apr 2007 05:36:43 PDT Date: Mon, 30 Apr 2007 05:36:43 -0700 (PDT) From: naimeh karbalaei To: manet@ietf.org MIME-Version: 1.0 Message-ID: <90203.52992.qm@web56714.mail.re3.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [manet] last modification in odmrp X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1889611932==" Errors-To: manet-bounces@ietf.org --===============1889611932== Content-Type: multipart/alternative; boundary="0-1088697685-1177936603=:52992" Content-Transfer-Encoding: 8bit --0-1088697685-1177936603=:52992 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I am not able to find the mobility prediction part in the ODMRP routing protocol provided in the Glomosim library. I intended to modify the codes before generating the simulation results for analysis in my thesis. All I find is "The mobility prediction using GPS is not included in this implementation." inside the odmrp.pc file inside the network folder. I was wondering if anyone could kindly provide me some guidance on how to simulate my modified mobility prediction methodology. I would be very grateful for some tips, thank you. best regard karbalaei --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. --0-1088697685-1177936603=:52992 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I am not able to find the mobility prediction part in the ODMRP routing
protocol provided in the Glomosim library. I intended to modify the codes
before generating the simulation results for analysis in my thesis. All I
find is "The mobility prediction using GPS is not included in this
implementation." inside the odmrp.pc file inside the network folder. I was
wondering if anyone could kindly provide me some guidance on how to simulate
my modified mobility prediction methodology. I would be very grateful for
some tips, thank you.
 
best regard
karbalaei

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-1088697685-1177936603=:52992-- --===============1889611932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1889611932==--