From manet-bounces@ietf.org Tue May 01 11:57: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 1HiujV-0001IK-PL; Tue, 01 May 2007 11:57:41 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HiujT-0001Ge-SC for manet-confirm+ok@megatron.ietf.org; Tue, 01 May 2007 11:57:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiujT-0001GV-Ie for manet@ietf.org; Tue, 01 May 2007 11:57:39 -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 1HiujS-0006cm-3p for manet@ietf.org; Tue, 01 May 2007 11:57:39 -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 l41FvNTE012610; Tue, 1 May 2007 18:57:35 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 18:57:27 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 10:57:00 -0500 Received: from [10.162.83.70] ([10.162.83.70]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 May 2007 10:56:59 -0500 Message-ID: <46376347.2040504@nokia.com> Date: Tue, 01 May 2007 08:56:55 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Joe Macker Subject: Hashing (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> <46325057.3070909@nokia.com> In-Reply-To: <46325057.3070909@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2007 15:56:59.0654 (UTC) FILETIME=[5A09E260:01C78C09] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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've done some more testing, enough to be satisfied with the results at least for the current purposes. I have tested thousands of random IP addresses. For all the addresses I have tested, I supplied every possible combination of 16 bits as payload. I am pretty sure the results would be almost identical for 65,536 different payloads of almost any description, but my payloads turned out to be very fast to implement :-) For these payloads, 44 bits of MD5 hash did not produce even one single instance of duplication, for any of the IP addresses I tested. If I run the same test with 40 bits of MD5 hash, over the thousands of IP addresses, I get duplication for only three of the random IP addresses. I think that, practically speaking, 40 bits is enough, but we might want to go for overkill and use 48 bits anyway. I also think that MD5 can be modified to do a lot less work and still produce 48 bits. Now, it works hard enough to produce 128 bits, and two-thirds of that result will be wasted; we might want to use a much simpler hash function. Maybe we could get the processor expense down into the tens of microseconds. And, again, time per trial is about 1 millisecond, from which we could guesstimate the number of processor instructions per data block. The very fast speed of MD5 on today's processors exposes a bug in the RFC 1321 code, since the start time equals the end time. Unless you fix the problem, the speed computation then involves dividing by zero. I found some other bugs as well, sigh... Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 02 08:16: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 1HjDki-000191-Lf; Wed, 02 May 2007 08:16:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjDkg-00018w-8x for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 08:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjDkf-00018o-Vo for manet@ietf.org; Wed, 02 May 2007 08:16:09 -0400 Received: from web56313.mail.re3.yahoo.com ([216.252.110.237]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjDke-0000hL-Od for manet@ietf.org; Wed, 02 May 2007 08:16:09 -0400 Received: (qmail 4030 invoked by uid 60001); 2 May 2007 12:16:08 -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=aaU5TrGj7Wm2An44bzk9uq7K6h4BXrq6WVtEfZve2iBblwI6xsY/Z4KW3SE0ikWgKTLI4wouMKACAROyySa9uZoA2/aVh3eXRQcJfEe+4H5VEMdH1gCcdvGk8bof6/0kNpRRJjIbzFCPV912+K/iIVPfbsAw6rfa4kWytoFvX3M=; X-YMail-OSG: MriXvvcVM1l.KSuw3EzyNgN1dtxGITielsy6.iDLbvJ3S5UsjEKu4YVECoirgYXdf4IPCfrdIRXiiVxYr4hTbHIzfI9NwSPGz.XViO3iB80BFA6tB3tLgg0UOs7znQ_Yyar3kXekrfAxGaHB1dRMfuOp Received: from [80.191.210.252] by web56313.mail.re3.yahoo.com via HTTP; Wed, 02 May 2007 13:16:08 BST Date: Wed, 2 May 2007 13:16:08 +0100 (BST) From: alireza jomeiry To: manet@ietf.org MIME-Version: 1.0 Message-ID: <605682.3881.qm@web56313.mail.re3.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [manet] please GLS 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="===============0119176299==" Errors-To: manet-bounces@ietf.org --===============0119176299== Content-Type: multipart/alternative; boundary="0-1576223429-1178108168=:3881" Content-Transfer-Encoding: 8bit --0-1576223429-1178108168=:3881 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hello friends how can I find GLS code in GloMoSim? thanks for any help. Send instant messages to your online friends http://uk.messenger.yahoo.com --0-1576223429-1178108168=:3881 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
hello friends
how can I find GLS code in GloMoSim?
thanks for any help.
 

Send instant messages to your online friends http://uk.messenger.yahoo.com --0-1576223429-1178108168=:3881-- --===============0119176299== 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 --===============0119176299==-- From manet-bounces@ietf.org Wed May 02 10: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 1HjFb9-0005V2-2q; Wed, 02 May 2007 10:14:27 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjFb7-0005Uu-8W for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 10:14:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjFb6-0005Um-VE for manet@ietf.org; Wed, 02 May 2007 10:14:24 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjFb5-0000s4-Iz for manet@ietf.org; Wed, 02 May 2007 10:14:24 -0400 Received: by an-out-0708.google.com with SMTP id d30so157905and for ; Wed, 02 May 2007 07:14: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:mime-version:content-type:content-transfer-encoding:content-disposition; b=NE5XZCrE6Ih0rZlhlCE/fbTtI83BQNwcZGkM25eBUFVgsOedNaWuFhQsuohKJTHpoSRxvyNcKiF/YmEjVBBo4P2erHm4lyvSod12TDCNidojf8JNzx4ww0paQg6QpnbdgS/1WYWhI6oZEKXC1jxh+HsJo8E6jRcZKxdkYUnRBmE= 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=gXv51k3odGPXGfhtdI4c/dBg61Zk0A8+75504THD7091dAOBYTWPbYsjRkjY5krsmybvxKTO3vq3831A4RGNYhqBwZVmvoJn7DsUnQ9MeoPFvAfnYPH1zlmqUuHjvoKg1nGfibc4JIdCJjuOAIuBUAhnKIZnt3fxZcuKIq1w0ms= Received: by 10.100.163.12 with SMTP id l12mr471337ane.1178115258514; Wed, 02 May 2007 07:14:18 -0700 (PDT) Received: by 10.100.107.9 with HTTP; Wed, 2 May 2007 07:14:18 -0700 (PDT) Message-ID: Date: Wed, 2 May 2007 16:14:18 +0200 From: MoSO To: manet , isworld@lyris.isworld.org, public-sws-ig@w3.org, semantic-web@w3c.org, service-orientated-architecture@yahoogroups.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.5 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: Subject: [manet] cfp: IJSWIS Special Issue on Mobile Services and Ontologies MoSO 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 ***We apologize for cross-postings*** Call for Papers International Journal on Semantic Web and Information Systems http://www.idea-group.com/journals/details.asp?ID=3D4625 Special Issue on Mobile Services and Ontologies Submission Deadline: May 31, 2007 Guest Editors - Christoph Bussler (Cisco Systems, Inc., USA) chbussler@aol.com - Birgitta K=F6nig-Ries (University of Jena, Germany) koenig@informatik.uni-jena.de - Dumitru Roman (DERI Innsbruck, Austria) dumitru.roman@deri.org - Jari Veijalainen (University of Jyvaskyla, Finland) veijalai@cs.jyu.fi Scope and Topics Today, computers are changing from big, grey, and noisy equipment on our desks to small, portable, and constantly connected devices most of us are carrying around. This new form of device mobility imposes a shift in how we view computers and the way we use them. Services offer the possibility to overcome the limitations of individual mo= bile devices by making functionality offered by others available on an as-needed basis. Thus, using the service-oriented computing paradigm in mobile environments = will considerably enlarge the variety of accessible applications and will enable= new business opportunities in the mobile space by delivering integrated functionalities across wireless networks. Network-hosted mobile services will allow mobile operators and third party mobile service providers to extend their businesses by making their services available to a broader audience (e.g. developers, service providers, etc.); device-hosted services will allow great potential for major innovations for applications and services that can be provided to individual mobile device owners. These mobile services offer functionalities and behaviours that can be described, advertised, discovered, and composed by others. Eventually, services will be able to interoperate even though they have not been designed to work together. This type of interoperability is based on the ability to understand other services and reason about their functionalities and behaviours when necessary. In this respect, mobile services could benefit from the techniques developed for the Semantic Web. Use of Semantic Web languages, techniques and technologies, including ontologies, semantic annotations (of both content and services), automatic metadata extraction, reasoning, etc. may offer new capabilities for mobile applications. However, standard semantic web tools and technologies are too heavy-weight for small mobile devices. The need to appropriately combine and adapt mobility and semantic grounded data sharing= has generated and is continuously triggering challenging questions in several areas of computer science, engineering and networking. This special issue will cover research problems around methods, concepts, models, languages and technologies that enable new opportunities in the mobile spac= e through adoption, usage, and integration of mobile services with ontologies= and other Semantic Web enablers. Of particular interest are methodologies and technologies that will allow automatic tasks to be performed with respect to mobile serv= ices and the use of ontologies and semantic techniques in this context. Topics of interest include, but are not limited to the following which invo= lve ontologies or other Semantic Web capabilities: Architectures for mobile internet services - languages for describing mobile services - discovery and matchmaking of ontology based mobile services - adaptive selection of mobile services - ontology management in mobile environments - contracting and negotiation with ontology-based mobile services (service level agreements) - Semantic annotation and reasoning involving semantic metadata - combining thematic metadata with locational/georeference metadata in mobile applications - approaches to composition of ontology based mobile services - invocation, adaptive execution, monitoring, and management of mobile services - interaction protocols and conversation models for mobile services - ontology-based security and privacy issues in mobile services - mobile service applications - analysis and design approaches for mobile services - reasoning with mobile services - ontology-based policies for mobile services - tools for discovery, matchmaking, selection, mediation, composition, management, and monitoring of mobile services - mobile service development - multi agent systems and mobile services Submission Process Submissions to this special issue should follow the journal's guidelines fo= r submission (http://www.idea-group.com/journals/details.asp?ID=3D4625&v=3Dgu= idelines). After submitting the paper, please also inform guest editors by an email with the paper ID assigned by the submission system. Papers must be of high quality = and should clearly state the technical issue(s) being addressed as related to mobile services and ontologies. Research papers should present a proof of concept for any novel technique they are proposing. Case studies should discuss the significance and applicability of their proposed architecture/system. If a submission is based on a prior publication in a workshop or conference= , the journal submission must involve substantial advance (a min. of 30%) in conceptual terms as well as in exposition (e.g., more comprehensive testing/evaluation/validation or additional applications/usage). All papers must be submitted by May 31, 2007. The editors recommend that th= e number of pages should not exceed 35. All papers are subject to peer review performed by three established researchers selected from a panel of reviewe= rs established for this special issue. Accepted papers have an opportunity for further revision and an additional round of reviewer feedback. Information on the journal with online submission can be found at: http://www.ijswis.org. Please submit manuscripts through that online system. Online call for this special issue can be found at http://www.ijswis.org/cfp/mobileservices.html Important Dates -------------------- - Submissions: May 31, 2007 - Completion of first round of reviews July 31 - Notifications: August 15, 2007 - Revised papers: October 31, 2007 - Notifications of final acceptance: November 30, 2007 - Final papers: December 31, 2007 - Publication: First or Second issue 2008 (Vol. 4, issue 1 or 2) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 02 12:38: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 1HjHpx-0000rZ-NB; Wed, 02 May 2007 12:37:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjHpw-0000rP-4p for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 12:37:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjHpv-0000rG-RZ; Wed, 02 May 2007 12:37:51 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjHpu-0003dO-FL; Wed, 02 May 2007 12:37: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 l42Gbffq000154; Wed, 2 May 2007 12:37:46 -0400 (EDT) Received: from [132.250.92.151] ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007050212374502797 ; Wed, 02 May 2007 12:37:46 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 2 May 2007 12:37:43 -0400 To: manet@ietf.org, manet-dt@ietf.org From: Brian Adamson Subject: Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID X-Spam-Score: 1.0 (+) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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="===============0945350904==" Errors-To: manet-bounces@ietf.org --===============0945350904== Content-Type: multipart/alternative; boundary="============_-1033998631==_ma============" --============_-1033998631==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Charlie, Teco Do either you have implementations of hash or packet lookup approaches that we could try or incorporate into our "nrlsmf" implementation so we can look at the performance/computation complexity/space trade-offs more? I am concerned that complexity/space needed for these approaches may be prohibitive for some applications (and I am curious about the performance of the hash to not have false duplicates) compared to our current approach. But I am not opposed to allowing for both approaches to be specified or options if appropriate. The other issue is that imposing a requirement on applications to generate unique packet payloads (while probably generally good practice) may be inappropriate for a network layer specification? Also, Teco had mentioned in an earlier email he was concerned that "a bit table with packets received with offsets to a sequence number base (as often used in IPsec replay detection code) is not usable" ... I am not sure if that comment was limited to the fragmentation issue that was being discussed or with regard to SMF DPD in general? We have used this sort of approach successfully with IPv4 and IPv6 in fairly extensive laboratory and field tests for the past few years (although not with any fragmentation). However, it is not strictly a a packet bit mask, a timer is used to detect/prune stale packet flows as well, and there is a strategy involved to allow for the bitmask to provide a sort of "sliding window" At 8:58:02 AM -0700 4/27/07, Charles E. Perkins wrote: >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. -- Brian __________________________________ Brian Adamson --============_-1033998631==_ma============ Content-Type: text/html; charset="us-ascii" Re: [manet] Need for DPD header (SMF document discussion)

Charlie, Teco

Do either you have implementations of hash or packet lookup approaches that we could try or incorporate into our "nrlsmf" implementation so we can look at the performance/computation complexity/space trade-offs more?

I am concerned that complexity/space needed for these approaches may be prohibitive for some applications (and I am curious about the performance of the hash to not have false duplicates) compared to our current approach.  But I am not opposed to allowing for both approaches to be specified or options if appropriate.

The other issue is that imposing a requirement on applications to generate unique packet payloads (while probably generally good practice) may be inappropriate for a network layer specification?

Also, Teco had mentioned in an earlier email he was concerned that "a bit table
with packets received with offsets to a sequence number base (as often used
in IPsec replay detection code) is not usable" ... I am not sure if that comment was limited to the fragmentation issue that was being discussed or with regard to SMF DPD in general?  We have used this sort of approach successfully with IPv4 and IPv6 in fairly extensive laboratory and field tests for the past few years (although not with any fragmentation).  However, it is not strictly a a packet bit mask, a timer is used to detect/prune stale packet flows as well, and there is a strategy involved to allow for the bitmask to provide a sort of "sliding window"


At 8:58:02 AM -0700 4/27/07, Charles E. Perkins wrote:

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.


--
Brian
__________________________________
Brian Adamson
<mailto:adamson@itd.nrl.navy.mil>
--============_-1033998631==_ma============-- --===============0945350904== 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 --===============0945350904==-- From manet-bounces@ietf.org Wed May 02 14:10: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 1HjJH4-0006OF-6i; Wed, 02 May 2007 14:09:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjJH2-0006Nz-RU for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 14:09:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjJH2-0006Np-Gg; Wed, 02 May 2007 14:09:56 -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 1HjJH0-0007Mn-Uc; Wed, 02 May 2007 14:09:56 -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 l42I9XVr032742; Wed, 2 May 2007 21:09:51 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 21:09:45 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 13:09:43 -0500 Received: from [10.162.76.0] ([10.162.76.0]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 13:09:42 -0500 Message-ID: <4638D3E0.4010106@nokia.com> Date: Wed, 02 May 2007 11:09:36 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Brian Adamson Subject: Re: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 May 2007 18:09:43.0012 (UTC) FILETIME=[0EFBA240:01C78CE5] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: manet@ietf.org, 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 Hello Brian, I have some 'C' code that I have adapted from other sources, and if you like I can send it to you. Of course you have to promise not to be too disappointed if you find bugs, and please send any improvements back to me so I can reincorporate it into the code I have. It isn't very much, and at least half of it was grabbed from existing code on the net (including RFC 1321, which excuses me from any wrongdoing about the formatting and stylistic issues). Ian suggested that there was agreement that the hashing was effective, and asked whether the other features of the DPD header were sufficient to warrant its use (in favor of hashing). I do _not_ suggest that applications take any responsibility for generating unique hash codes. To summarize, I prefer if we make hashing "good enough", and then use the DPD header for the rare cases where the hash function fails to distinguish different flooded packets. Used in this way, the DPD header could be a lot simpler. Regards, Charlie P. ext Brian Adamson wrote: > Charlie, Teco > > Do either you have implementations of hash or packet lookup approaches > that we could try or incorporate into our "nrlsmf" implementation so > we can look at the performance/computation complexity/space trade-offs > more? > > I am concerned that complexity/space needed for these approaches may > be prohibitive for some applications (and I am curious about the > performance of the hash to not have false duplicates) compared to our > current approach. But I am not opposed to allowing for both > approaches to be specified or options if appropriate. > > The other issue is that imposing a requirement on applications to > generate unique packet payloads (while probably generally good > practice) may be inappropriate for a network layer specification? > > Also, Teco had mentioned in an earlier email he was concerned that "a > bit table > with packets received with offsets to a sequence number base (as often > used > in IPsec replay detection code) is not usable" ... I am not sure if > that comment was limited to the fragmentation issue that was being > discussed or with regard to SMF DPD in general? We have used this > sort of approach successfully with IPv4 and IPv6 in fairly extensive > laboratory and field tests for the past few years (although not with > any fragmentation). However, it is not strictly a a packet bit mask, > a timer is used to detect/prune stale packet flows as well, and there > is a strategy involved to allow for the bitmask to provide a sort of > "sliding window" > _______________________________________________ > Manet-dt mailing list > Manet-dt@ietf.org > https://www1.ietf.org/mailman/listinfo/manet-dt > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 02 15:50: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 1HjKq9-0007j6-Io; Wed, 02 May 2007 15:50:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjKpv-0007ee-LX for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpv-0007e6-2W; Wed, 02 May 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjKpu-0003AO-LM; Wed, 02 May 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 8459426EB2; Wed, 2 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HjKpu-0005ik-Dv; Wed, 02 May 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: Wed, 02 May 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-dymo-09.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 : Dynamic MANET On-demand (DYMO) Routing Author(s) : C. Perkins, I. Chakeres Filename : draft-ietf-manet-dymo-09.txt Pages : 32 Date : 2007-5-2 The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile nodes in wireless, multihop networks. It offers adaptation to changing network topology and determines unicast routes between nodes within the network in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-09.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-dymo-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-dymo-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-2110020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-dymo-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-dymo-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-2110020.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 Wed May 02 16:24: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 1HjLNC-000802-VD; Wed, 02 May 2007 16:24:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjLNB-0007u4-Ia for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 16:24:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjLNB-0007sm-2t for manet@ietf.org; Wed, 02 May 2007 16:24:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpQ-0007Zw-Ap for manet@ietf.org; Wed, 02 May 2007 15:49:32 -0400 Received: from bay0-omc1-s35.bay0.hotmail.com ([65.54.246.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjKpP-00034M-1y for manet@ietf.org; Wed, 02 May 2007 15:49:32 -0400 Received: from hotmail.com ([64.4.38.37]) by bay0-omc1-s35.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 2 May 2007 12:49:30 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 2 May 2007 12:49:30 -0700 Message-ID: Received: from 64.4.38.200 by by116fd.bay116.hotmail.msn.com with HTTP; Wed, 02 May 2007 19:49:26 GMT X-Originating-IP: [84.36.157.154] X-Originating-Email: [seiko131@hotmail.com] X-Sender: seiko131@hotmail.com From: "Amr Hussein" To: manet@ietf.org Bcc: Date: Wed, 02 May 2007 19:49:26 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 May 2007 19:49:30.0047 (UTC) FILETIME=[FF88ACF0:01C78CF2] X-Spam-Score: 2.1 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-TMDA-Confirmed: Wed, 02 May 2007 16:24:25 -0400 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: , Errors-To: manet-bounces@ietf.org Hi, I would like to ask if anyone has the source code or any information for cluster based routing in glomosim. Please if you have anything that is useful reply. Thanks in advance. Best Regards Amr Ismail _________________________________________________________________ MSN is giving away a trip to Vegas to see Elton John.  Enter to win today. http://msnconcertcontest.com?icid-nceltontagline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 02 16:44: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 1HjLgJ-00006C-4P; Wed, 02 May 2007 16:44:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjLgH-00005x-I0 for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 16:44:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjLgH-00005o-8H; Wed, 02 May 2007 16:44:09 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjLgG-0004MN-V2; Wed, 02 May 2007 16:44: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 l42Ki6KQ014809; Wed, 2 May 2007 16:44:06 -0400 (EDT) Received: from [132.250.92.151] ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007050216440504187 ; Wed, 02 May 2007 16:44:05 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4638D3E0.4010106@nokia.com> References: <4638D3E0.4010106@nokia.com> Date: Wed, 2 May 2007 16:44:04 -0400 To: "Charles E. Perkins" From: Brian Adamson Subject: Re: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: manet@ietf.org, 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 Charlie, Whatever 'C' code you have we might be able to work with in some way. Better yet if you had a full-up forwarding engine we could use ... But we can do a little work here and I'm not afraid of bugs (I do a nice job of cultivating my own herd of those), etc. I just would like to compare the space/complexity needed with each approach. Wr2 to a simpler SMF DPD option, it's hard to do much simpler for IPv6 because of the multiple of 8 octets sizing that IPv6 option headers require ... yes, _some_ savings might be garnered under certain conditions when other options were also present, but the current SMF DPD options adds the minimum possible to an IPv6 its the only option added. At 11:09 AM -0700 5/2/07, Charles E. Perkins wrote: >Hello Brian, > >I have some 'C' code that I have adapted >from other sources, and if you like I can >send it to you. Of course you have to >promise not to be too disappointed if you >find bugs, and please send any improvements >back to me so I can reincorporate it into >the code I have. It isn't very much, and >at least half of it was grabbed from existing >code on the net (including RFC 1321, which >excuses me from any wrongdoing about the >formatting and stylistic issues). > >Ian suggested that there was agreement >that the hashing was effective, and asked >whether the other features of the DPD >header were sufficient to warrant its use >(in favor of hashing). > >I do _not_ suggest that applications take >any responsibility for generating unique >hash codes. To summarize, I prefer if we >make hashing "good enough", and then use >the DPD header for the rare cases where >the hash function fails to distinguish different >flooded packets. Used in this way, the >DPD header could be a lot simpler. > >Regards, >Charlie P. > > >ext Brian Adamson wrote: >>Charlie, Teco >> >>Do either you have implementations of hash or packet lookup >>approaches that we could try or incorporate into our "nrlsmf" >>implementation so we can look at the performance/computation >>complexity/space trade-offs more? >> >>I am concerned that complexity/space needed for these approaches >>may be prohibitive for some applications (and I am curious about >>the performance of the hash to not have false duplicates) compared >>to our current approach. But I am not opposed to allowing for both >>approaches to be specified or options if appropriate. >> >>The other issue is that imposing a requirement on applications to >>generate unique packet payloads (while probably generally good >>practice) may be inappropriate for a network layer specification? >> >>Also, Teco had mentioned in an earlier email he was concerned that >>"a bit table >>with packets received with offsets to a sequence number base (as often used >>in IPsec replay detection code) is not usable" ... I am not sure if >>that comment was limited to the fragmentation issue that was being >>discussed or with regard to SMF DPD in general? We have used this >>sort of approach successfully with IPv4 and IPv6 in fairly >>extensive laboratory and field tests for the past few years >>(although not with any fragmentation). However, it is not strictly >>a a packet bit mask, a timer is used to detect/prune stale packet >>flows as well, and there is a strategy involved to allow for the >>bitmask to provide a sort of "sliding window" >>_______________________________________________ >>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 Wed May 02 17:03: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 1HjLys-0006LD-DX; Wed, 02 May 2007 17:03:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjLyq-0006Ky-TH for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 17:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjLyq-0006Kp-Jm; Wed, 02 May 2007 17:03:20 -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 1HjLyp-0001py-50; Wed, 02 May 2007 17:03:20 -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 l42L2xW8013394; Thu, 3 May 2007 00:03:16 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 00:03:04 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 16:02:54 -0500 Received: from [10.162.86.30] ([10.162.86.30]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 16:02:53 -0500 Message-ID: <4638FC77.3080806@nokia.com> Date: Wed, 02 May 2007 14:02:47 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Brian Adamson Subject: Re: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID References: <4638D3E0.4010106@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 May 2007 21:02:54.0378 (UTC) FILETIME=[40B840A0:01C78CFD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: manet@ietf.org, 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 Hello Brian, The option could be simpler, because its only purpose would be to distinguish different flooded packets. Since any node adding this option would use the same hash to find if there had been a collision recently, there would be no need for the Tagger ID. I reckon that the data field for the option might only have to be one byte, but of course there is all the glue. Regards, Charlie P. ext Brian Adamson wrote: > Wr2 to a simpler SMF DPD option, it's hard to do much simpler for IPv6 > because of the multiple of 8 octets sizing that IPv6 option headers > require ... yes, _some_ savings might be garnered under certain > conditions when other options were also present, but the current SMF > DPD options adds the minimum possible to an IPv6 its the only option > added. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 02 17:08: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 1HjM46-0001RC-SR; Wed, 02 May 2007 17:08:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjM44-0001QB-T1 for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 17:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjM44-0001Pk-JC; Wed, 02 May 2007 17:08:44 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjM43-00051i-BL; Wed, 02 May 2007 17:08:44 -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 l42L8hOB016208; Wed, 2 May 2007 17:08:43 -0400 (EDT) Received: from [132.250.92.151] ([132.250.92.151]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007050217084204317 ; Wed, 02 May 2007 17:08:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4638FC77.3080806@nokia.com> References: <4638D3E0.4010106@nokia.com> <4638FC77.3080806@nokia.com> Date: Wed, 2 May 2007 17:08:40 -0400 To: "Charles E. Perkins" From: Brian Adamson Subject: Re: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: manet@ietf.org, 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 That was my point. The "glue" to get an IPv6 option header added makes the difference of whether the SMF DPD option data field is one byte or three bytes (the suggested format that supports the TaggerId concept) almost inconsequential since in many cases this will likely be the only option added ... But all the trade-offs need to go into the decision bucket. At 2:02 PM -0700 5/2/07, Charles E. Perkins wrote: >Hello Brian, > >The option could be simpler, because its only purpose would >be to distinguish different flooded packets. Since any node >adding this option would use the same hash to find if there >had been a collision recently, there would be no need for the >Tagger ID. I reckon that the data field for the option might >only have to be one byte, but of course there is all the glue. > >Regards, >Charlie P. > > > > >ext Brian Adamson wrote: >>Wr2 to a simpler SMF DPD option, it's hard to do much simpler for >>IPv6 because of the multiple of 8 octets sizing that IPv6 option >>headers require ... yes, _some_ savings might be garnered under >>certain conditions when other options were also present, but the >>current SMF DPD options adds the minimum possible to an IPv6 its >>the only option added. -- Brian __________________________________ Brian Adamson _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 02 18:43: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 1HjNXo-0003V6-AI; Wed, 02 May 2007 18:43:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjNXm-0003UT-CE for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 18:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjNXm-0003UL-2W; Wed, 02 May 2007 18:43:30 -0400 Received: from mga09.intel.com ([134.134.136.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjNXl-0008LQ-JD; Wed, 02 May 2007 18:43:30 -0400 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 02 May 2007 15:43:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.14,482,1170662400"; d="txt'208?scan'208,208";a="82901782" Received: from fmsmsxpoc001.fm.intel.com (HELO fmsmsxpoc001.amr.corp.intel.com) ([132.233.49.22]) by fmsmga002.fm.intel.com with ESMTP; 02 May 2007 15:43:27 -0700 Received: from fmsmsx334.amr.corp.intel.com (132.233.42.1) by fmsmsxpoc001.amr.corp.intel.com (132.233.49.22) with Microsoft SMTP Server id 8.0.685.24; Wed, 2 May 2007 15:17:28 -0700 Received: from fmsmsx413.amr.corp.intel.com ([10.19.19.5]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 15:04:40 -0700 Received: from mail pickup service by fmsmsx413.amr.corp.intel.com with Microsoft SMTPSVC; Wed, 2 May 2007 15:04:37 -0700 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmsx413.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 12:52:46 -0700 Received: from orsmsx335.jf.intel.com ([10.22.226.40]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 12:52:43 -0700 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 May 2007 12:52:42 -0700 Received: from watsevs01.gcinc.com (HELO orsmga101.jf.intel.com) ([64.162.136.13]) by orsmga001-1.jf.intel.com with ESMTP; 02 May 2007 12:52:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAECJOEacmhCRk2dsb2JhbACBZI00ewIBAQcIBgcGHQ X-IronPort-AV: E=Sophos;i="4.14,482,1170662400"; d="txt'208?scan'208,208";a="161187547" Received: from stiedprmman1.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by mga02.intel.com with ESMTP; 02 May 2007 12:52:35 -0700 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKqA-0007jT-MR; Wed, 02 May 2007 15:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpv-0007e6-2W; Wed, 02 May 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjKpu-0003AO-LM; Wed, 02 May 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 8459426EB2; Wed, 2 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HjKpu-0005ik-Dv; Wed, 02 May 2007 15:50:02 -0400 Content-Type: multipart/mixed; boundary="NextPart" MIME-Version: 1.0 To: i-d-announce@ietf.org From: Message-ID: Date: Wed, 2 May 2007 15:50:02 -0400 X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-OriginalArrivalTime: 02 May 2007 19:52:42.0848 (UTC) FILETIME=[7273C600:01C78CF3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-dymo-09.txt X-BeenThere: manet@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart Content-Type: text/plain 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 : Dynamic MANET On-demand (DYMO) Routing Author(s) : C. Perkins, I. Chakeres Filename : draft-ietf-manet-dymo-09.txt Pages : 32 Date : 2007-5-2 The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile nodes in wireless, multihop networks. It offers adaptation to changing network topology and determines unicast routes between nodes within the network in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-09.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-dymo-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-dymo-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: multipart/alternative; boundary="OtherAccess" --OtherAccess Content-Type: message/external-body; access-type=mail-server; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-2110020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-dymo-09.txt --OtherAccess Content-Type: message/external-body; name="draft-ietf-manet-dymo-09.txt"; site=ftp.ietf.org; access-type=anon-ftp; directory=internet-drafts Content-Type: text/plain Content-ID: <2007-5-2110020.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Wed May 02 23:44: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 1HjSEw-00059G-Hx; Wed, 02 May 2007 23:44:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjSEv-00059A-Fs for manet-confirm+ok@megatron.ietf.org; Wed, 02 May 2007 23:44:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjSEv-000592-6N for manet@ietf.org; Wed, 02 May 2007 23:44:21 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjSEu-0003MM-UO for manet@ietf.org; Wed, 02 May 2007 23:44:21 -0400 Received: by an-out-0708.google.com with SMTP id d30so405046and for ; Wed, 02 May 2007 20:44: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:mime-version:content-type; b=jQo+6pfRRg/rVvkhdgnRB2JBvnVwMB1tS0fMUe8y7loURRkxQ8mkNQMX4G3fcorF0rmX77wrLvlulMaxV2tuvIQMCXWWZ0szgs3fsxmtf3kwALJjcmZtNlk3Gnouvxqr/XtTc8DZvLNcCyHOOcDFhzfaoTf9RFBqeU/NL0kGOLw= 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=Zx0PTseKIhVDYyISYuI3M4Nr7Pm67tZnnds9SDqk9Bp3/alEDR4erjwg2/UhNtjWWmY35Sowr/sbJAv9Ebnh/ouTvksb5qNFibu17lnYeh4MuwXc4WmeV+FRC5E2f9WufFP8l/zR2uQj5vpM+dOHbeaOHz9d9gTRwg6eGYozODo= Received: by 10.100.202.13 with SMTP id z13mr1179010anf.1178163860601; Wed, 02 May 2007 20:44:20 -0700 (PDT) Received: by 10.100.48.16 with HTTP; Wed, 2 May 2007 20:44:20 -0700 (PDT) Message-ID: <786b4cb30705022044t21e9506aweb710e98b495f0cf@mail.gmail.com> Date: Thu, 3 May 2007 11:44:20 +0800 From: xr.wang To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [manet] aodv-uu -- how to play as a gateway? 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="===============1509972671==" Errors-To: manet-bounces@ietf.org --===============1509972671== Content-Type: multipart/alternative; boundary="----=_Part_24320_31081562.1178163860525" ------=_Part_24320_31081562.1178163860525 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, aodv-uu-0.9.3 works ok in pure ad-hoc network. The aodv-uu source file is compiled with -DCONFIG_GATEWAY option. and the README shows that aodv-uu support internet gateway. But how to make a node as a gateway? ---------- ---------------- -------------- | LAN | <---> eth0<-| Gateway |->eth1 <---> | MANET | ---------- ---------------- -------------- IP distribution: LAN: 192.168.1.x Gateway: eth0 with IP 192.168.1.1, eth1 with IP 192.168.2.1 MANET: 192.168.2.x as to the gateway node, I run the following step: $ /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE $ route add default dev eth1 $ aodvd -w But the node in MANET(e.g 192.168.2.2) ping the node in LAN(e.g 192.168.1.2) failed! message shows "connect: Network is unreachable!" any advise will be appreciated! Regards xr.wang ------=_Part_24320_31081562.1178163860525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
aodv-uu-0.9.3 works ok in pure ad-hoc network.
The aodv-uu source file is compiled with -DCONFIG_GATEWAY option.
and the README shows that aodv-uu support internet gateway.
But how to make a node as a gateway?
 
----------                  ----------------                  --------------
| LAN | <---> eth0<-| Gateway |->eth1 <---> | MANET |
----------                  ----------------                   --------------
 
IP distribution:
LAN: 192.168.1.x
Gateway: eth0 with IP 192.168.1.1,  eth1 with IP 192.168.2.1
MANET: 192.168.2.x
 
as to the gateway node, I run the following step:
$ /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
$ route add default dev eth1
$ aodvd -w
 
But the node in MANET(e.g 192.168.2.2) ping the node in LAN(e.g 192.168.1.2) failed!
message shows "connect: Network is unreachable!"
 
any advise will be appreciated!
 
Regards
xr.wang
 
------=_Part_24320_31081562.1178163860525-- --===============1509972671== 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 --===============1509972671==-- From manet-bounces@ietf.org Thu May 03 01:40: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 1HjU3W-0003b2-QD; Thu, 03 May 2007 01:40:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjU3U-0003Ws-GB for manet-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 01:40:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjU3T-0003Qi-DN for manet@ietf.org; Thu, 03 May 2007 01:40:39 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjU3S-0006zd-39 for manet@ietf.org; Thu, 03 May 2007 01:40:39 -0400 Received: by wr-out-0506.google.com with SMTP id 71so407948wri for ; Wed, 02 May 2007 22:40:37 -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=ZDi97J8znjWspaV1jC3XN8lRpuTBTNlcxLWv1qEbpZpcjbU2/m5JuIb58pQNdE2LxyeqAzv5uDeV4+yYuhaNmh7S8U+poWd4m3gq9IAJwX+fIiujtdApg9vjJD7A3uacmJsGEXYOFBz1/MuW9FtSmnOSdaifxzHgraUb82nNvlc= 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=OoEKUWMFE2F+qu29DFVPttIWI8F+zAhImuC6YxsF5pfQgUWwQLKhhWs2qy5PtS3vGB+H/MTMtHvJupC+wyFpefVor5WKpt8fDt5ctzRD8q5jxWCreUD/jEh3Su1p51XyKFc10oO/Ym7yhtMaYUrsREwQCEqCi3a2D8+6t8ceNH0= Received: by 10.78.149.15 with SMTP id w15mr640513hud.1178170837203; Wed, 02 May 2007 22:40:37 -0700 (PDT) Received: by 10.78.18.18 with HTTP; Wed, 2 May 2007 22:40:37 -0700 (PDT) Message-ID: <374005f30705022240r6539eed8q2767b273cc745367@mail.gmail.com> Date: Thu, 3 May 2007 11:10:37 +0530 From: "Ian Chakeres" To: "xr. wang" Subject: Re: [manet] aodv-uu -- how to play as a gateway? In-Reply-To: <786b4cb30705022044t21e9506aweb710e98b495f0cf@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: <786b4cb30705022044t21e9506aweb710e98b495f0cf@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 You might be better off emailing the aodvimpl mailing list for this AODV-UU specific question. https://lists.sourceforge.net/lists/listinfo/aodvimpl-public Ian Chakeres On 5/3/07, xr. wang wrote: > Hi, > > aodv-uu-0.9.3 works ok in pure ad-hoc network. > > The aodv-uu source file is compiled with -DCONFIG_GATEWAY option. > and the README shows that aodv-uu support internet gateway. > But how to make a node as a gateway? > > ---------- ---------------- > -------------- > | LAN | <---> eth0<-| Gateway |->eth1 <---> | MANET | > ---------- ---------------- > -------------- > > IP distribution: > LAN: 192.168.1.x > Gateway: eth0 with IP 192.168.1.1, eth1 with IP 192.168.2.1 > MANET: 192.168.2.x > > as to the gateway node, I run the following step: > $ /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > $ route add default dev eth1 > $ aodvd -w > > But the node in MANET(e.g 192.168.2.2) ping the node in LAN(e.g 192.168.1.2) > failed! > message shows "connect: Network is unreachable!" > > any advise will be appreciated! > > Regards > xr.wang > > _______________________________________________ > manet mailing 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 May 03 04:10: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 1HjWNs-0006pK-CR; Thu, 03 May 2007 04:09:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjWNq-0006pF-JG for manet-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 04:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjWNq-0006op-97 for manet@ietf.org; Thu, 03 May 2007 04:09:50 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjWNp-0003zo-Uz for manet@ietf.org; Thu, 03 May 2007 04:09:50 -0400 Received: by wr-out-0506.google.com with SMTP id 71so437631wri for ; Thu, 03 May 2007 01:09:44 -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=gyUaAOBg33vKh/H5eUZYXFuYlf38pA0hv0VTI0hSXBzJJvX+zIIoPCc+Vp3jIfl2uEwtavTXT7fPzDbaQ/5ImhZ/nZdgy9mqj+MOARf/Ha6avD8icN4ZTlujUH+OVXB+gWTbq/WX8pupNurMpHQ/2X+47MSVjn0g1SzFgrQQ+Vs= 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=dmI58RcNS+wFa/ki44ItsVx/1fbKpoHji1vXX/Q77v4tCUV2aR+tIPVE3wsgG3HRtSTQLdJKJJQIj6FE/n96xxWUBlyh8VZUPcclt9b7p5nAtImmnMzDlRXKv63PQI1Dv50zkWcKzVfnc+3TMddIpRW86D9Z4nn/d4eRnaCyVwA= Received: by 10.78.81.20 with SMTP id e20mr698215hub.1178179783661; Thu, 03 May 2007 01:09:43 -0700 (PDT) Received: by 10.78.18.18 with HTTP; Thu, 3 May 2007 01:09:43 -0700 (PDT) Message-ID: <374005f30705030109r6e3791b7n4b3e80342c201d52@mail.gmail.com> Date: Thu, 3 May 2007 13:39:43 +0530 From: "Ian Chakeres" To: "Charles E. Perkins" Subject: Re: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID In-Reply-To: <4638D3E0.4010106@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4638D3E0.4010106@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: manet@ietf.org, 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 Clarifying comment. On 5/2/07, Charles E. Perkins wrote: > > Hello Brian, > > I have some 'C' code that I have adapted > from other sources, and if you like I can > send it to you. Of course you have to > promise not to be too disappointed if you > find bugs, and please send any improvements > back to me so I can reincorporate it into > the code I have. It isn't very much, and > at least half of it was grabbed from existing > code on the net (including RFC 1321, which > excuses me from any wrongdoing about the > formatting and stylistic issues). > > Ian suggested that there was agreement > that the hashing was effective, and asked > whether the other features of the DPD > header were sufficient to warrant its use > (in favor of hashing). My statement about hashing was that given different inputs to a hashing algorithm, you get different outputs with high probability. I am not convinced that hashing is the correct approach we should adopt for DPD. > I do _not_ suggest that applications take > any responsibility for generating unique > hash codes. To summarize, I prefer if we > make hashing "good enough", and then use > the DPD header for the rare cases where > the hash function fails to distinguish different > flooded packets. Used in this way, the > DPD header could be a lot simpler. > > Regards, > Charlie P. > > > ext Brian Adamson wrote: > > Charlie, Teco > > > > Do either you have implementations of hash or packet lookup approaches > > that we could try or incorporate into our "nrlsmf" implementation so > > we can look at the performance/computation complexity/space trade-offs > > more? > > > > I am concerned that complexity/space needed for these approaches may > > be prohibitive for some applications (and I am curious about the > > performance of the hash to not have false duplicates) compared to our > > current approach. But I am not opposed to allowing for both > > approaches to be specified or options if appropriate. > > > > The other issue is that imposing a requirement on applications to > > generate unique packet payloads (while probably generally good > > practice) may be inappropriate for a network layer specification? > > > > Also, Teco had mentioned in an earlier email he was concerned that "a > > bit table > > with packets received with offsets to a sequence number base (as often > > used > > in IPsec replay detection code) is not usable" ... I am not sure if > > that comment was limited to the fragmentation issue that was being > > discussed or with regard to SMF DPD in general? We have used this > > sort of approach successfully with IPv4 and IPv6 in fairly extensive > > laboratory and field tests for the past few years (although not with > > any fragmentation). However, it is not strictly a a packet bit mask, > > a timer is used to detect/prune stale packet flows as well, and there > > is a strategy involved to allow for the bitmask to provide a sort of > > "sliding window" > > _______________________________________________ > > Manet-dt mailing list > > Manet-dt@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet-dt > > > > > > _______________________________________________ > Manet-dt mailing list > Manet-dt@ietf.org > https://www1.ietf.org/mailman/listinfo/manet-dt > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu May 03 10:12: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 1Hjc2E-0002tO-Vz; Thu, 03 May 2007 10:11:54 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hjc2D-0002tJ-B2 for manet-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 10:11:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjc2D-0002tB-1X for manet@ietf.org; Thu, 03 May 2007 10:11:53 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjc2B-0001lZ-PT for manet@ietf.org; Thu, 03 May 2007 10:11:53 -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 l43EBVj5015897 for ; Thu, 3 May 2007 10:11:49 -0400 (EDT) Received: (from chiron [132.250.93.53]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007050310114806696 for ; Thu, 03 May 2007 10:11:48 -0400 From: "Jeff Weston" To: References: Subject: Re: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID Date: Thu, 3 May 2007 10:09:42 -0400 Message-ID: <018801c78d8c$b246a2e0$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: AceM/mGTimnCxLWbQEigngUy7TbiowAioPGw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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-dt] Re: [manet] Need for DPD header (SMF document > discussion) - ValidReason for Tagger ID > To summarize, I prefer if we > make hashing "good enough", and then use > the DPD header for the rare cases where > the hash function fails to distinguish different > flooded packets. Charlie, I am curious as to how you are going to determine whether the hash funtion fails or not, given that different forwarder nodes will often have a different hash history than the sender... Even if you assume that all nodes are equal and store the same amount of history information, there are numerous reasons that nodes may have a different hash history. Assuming a sort of FIFO queue of hashes, if there is a packet collision (extremely common in standard 802.11 multicast), then some forwarding nodes will have one older hash than the sender node. If some (but not all) packets have a low TTL, this can produce the same effect to a much larger degree. The problem becomes more pronounced if you decide to conserve memory and not keep separate queues for each source/destination tuple. I still contend that exactly duplicate IPv6 packets are not all that uncommon, depending on your application (video, anything that uses keepalives). It's even more common if you do not hash the entire packet, as many XML-formatted messages may be the same for the first number of bytes, for instance. I can really forsee hashing causing many applications to fail in a MANET. All it takes is the right data rate and the right keepalive rate. If they happen to match up to "one keepalive almost every time we roll through our history", the application will fail at random. -Jeff Weston _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu May 03 10:15: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 1Hjc5M-0003z6-H6; Thu, 03 May 2007 10:15:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hjc5L-0003yw-Cg for manet-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 10:15:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjc5L-0003yo-2o for manet@ietf.org; Thu, 03 May 2007 10:15:07 -0400 Received: from web8323.mail.in.yahoo.com ([202.43.219.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hjc5J-0002eQ-6S for manet@ietf.org; Thu, 03 May 2007 10:15:07 -0400 Received: (qmail 62891 invoked by uid 60001); 3 May 2007 14:15:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=eASlv2vahbqyHPjBU6lDLCz71xL3+ZvY8sXA3o5RhOXi9W45r/NwPe+oxz7bnIN8Bc+R5JSV3lw1yCiPcqUpzufroxmGwmHS9STPgwzuAvSDxjMggX3Rag3vpaE1K59e88atfh0W9auQ8rJKW+MSBwG8CwOC67UthPj+v0PZvuk=; X-YMail-OSG: Sq1VEEwVM1n2MOiJp8s0N.p_QnTn_ClXqVb1ZJ_iPCUsM2b0Hg1Lr8so0bP.EsxsRn5FPIftgBLnxIZurLGHdqP7AQhuTdPMwp8fM66fYLXeMGUhf.tPbG98EPIKFw-- Received: from [59.92.41.88] by web8323.mail.in.yahoo.com via HTTP; Thu, 03 May 2007 07:15:03 PDT Date: Thu, 3 May 2007 07:15:03 -0700 (PDT) From: akila padmanabhan To: manet@ietf.org MIME-Version: 1.0 Message-ID: <498008.61419.qm@web8323.mail.in.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [manet] delete my address from your group 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="===============1494765938==" Errors-To: manet-bounces@ietf.org --===============1494765938== Content-Type: multipart/alternative; boundary="0-920614213-1178201703=:61419" Content-Transfer-Encoding: 8bit --0-920614213-1178201703=:61419 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos. --0-920614213-1178201703=:61419 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

 

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos. --0-920614213-1178201703=:61419-- --===============1494765938== 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 --===============1494765938==-- From manet-bounces@ietf.org Thu May 03 16: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 1Hji7A-0001Gy-T1; Thu, 03 May 2007 16:41:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hji78-0001Gf-NO for manet-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 16:41:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hji78-0001GW-DU for manet@ietf.org; Thu, 03 May 2007 16:41:22 -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 1Hji76-0006Eh-V9 for manet@ietf.org; Thu, 03 May 2007 16:41:22 -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 l43KexLT023200; Thu, 3 May 2007 23:41:18 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 23:41:18 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 15:40:51 -0500 Received: from [172.18.141.150] ([172.18.141.150]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 May 2007 15:40:51 -0500 Message-ID: <463A48D0.3020006@nokia.com> Date: Thu, 03 May 2007 13:40:48 -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-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID References: <018801c78d8c$b246a2e0$355dfa84@chiron> In-Reply-To: <018801c78d8c$b246a2e0$355dfa84@chiron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2007 20:40:51.0406 (UTC) FILETIME=[56947EE0:01C78DC3] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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: > > >> To summarize, I prefer if we >> make hashing "good enough", and then use >> the DPD header for the rare cases where >> the hash function fails to distinguish different >> flooded packets. >> > > Charlie, > > I am curious as to how you are going to determine whether the hash funtion fails or not, given that different forwarder nodes will > often have a different hash history than the sender... Each flooded packet has to be compared against other flooded packets from the same sender. I think this much is common to most approaches, but of course we could design something different. > Even if you assume that all nodes are equal and store the same amount of > history information, there are numerous reasons that nodes may have a different hash history. Assuming a sort of FIFO queue of > hashes, if there is a packet collision (extremely common in standard 802.11 multicast), then some forwarding nodes will have one > older hash than the sender node. If some (but not all) packets have a low TTL, this can produce the same effect to a much larger > degree. The problem becomes more pronounced if you decide to conserve memory and not keep separate queues for each > source/destination tuple. > All that matters is that the source ensures that every packet hashes to a different value. If the packet does not already produce a different hash, then the source "SHOULD" add a DPD header (or something). > I still contend that exactly duplicate IPv6 packets are not all that uncommon, depending on your application (video, anything that > uses keepalives). It's even more common if you do not hash the entire packet, as many XML-formatted messages may be the same for > the first number of bytes, for instance. > Well, if they are exactly duplicate, how can you tell if they are duplicated (and needing to be suppressed) vs. duplicated (and not needing to be suppressed)? > I can really forsee hashing causing many applications to fail in a MANET. All it takes is the right data rate and the right > keepalive rate. If they happen to match up to "one keepalive almost every time we roll through our history", the application will > fail at random. > Do you still think so, given my responses above? Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu May 03 22:25: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 1HjnUO-0002ZT-PU; Thu, 03 May 2007 22:25:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjnUM-0002ZO-Ml for manet-confirm+ok@megatron.ietf.org; Thu, 03 May 2007 22:25:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjnUM-0002ZG-Bf for manet@ietf.org; Thu, 03 May 2007 22:25:42 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjnUM-0003hS-3E for manet@ietf.org; Thu, 03 May 2007 22:25:42 -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 l442PYKa016542; Thu, 3 May 2007 22:25:39 -0400 (EDT) Received: (from morpheus [132.250.217.225]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007050322253809591 ; Thu, 03 May 2007 22:25:38 -0400 From: "Jeff Weston" To: "'Charles E. Perkins'" References: <018801c78d8c$b246a2e0$355dfa84@chiron> <463A48D0.3020006@nokia.com> Subject: RE: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID Date: Thu, 3 May 2007 22:27:33 -0400 Message-ID: <000001c78df3$c7fdd920$6601a8c0@morpheus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <463A48D0.3020006@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceNw2oBoqTrlRHpTTGfso4LZAa+JAALed8g X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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, Comments inline. > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: Thursday, May 03, 2007 4:41 PM > To: ext Jeff Weston > Cc: manet@ietf.org > Subject: Re: [Manet-dt] Re: [manet] Need for DPD header (SMF > document discussion) - ValidReason for Tagger ID > > Hello Jeff, > > ext Jeff Weston wrote: > > > > > >> To summarize, I prefer if we > >> make hashing "good enough", and then use the DPD header > for the rare > >> cases where the hash function fails to distinguish > different flooded > >> packets. > >> > > > > Charlie, > > > > I am curious as to how you are going to determine whether the hash > > funtion fails or not, given that different forwarder nodes > will often have a different hash history than the sender... > Each flooded packet has to be compared against other flooded > packets from the same sender. I think this much is common to > most approaches, but of course we could design something different. > > Even if you assume that all nodes are equal and store the same > > amount of history information, there are numerous reasons > that nodes > > may have a different hash history. Assuming a sort of FIFO > queue of > > hashes, if there is a packet collision (extremely common in > standard > > 802.11 multicast), then some forwarding nodes will have one > older hash > > than the sender node. If some (but not all) packets have a > low TTL, this can produce the same effect to a much larger > degree. The problem becomes more pronounced if you decide to > conserve memory and not keep separate queues for each > source/destination tuple. > > > All that matters is that the source ensures that every packet > hashes to a different value. If the packet does not already > produce a different hash, then the source "SHOULD" add a DPD > header (or something). Right. But my point is that this is not a trivial thing to when forwarding nodes have different histories. While the source/tagger may not see a new packet as having a conflicting hash, that doesn't automatically imply that the forwarders will also see no conflicting hash. Since they will have a different history of hashes to compare against, they may well drop packets as duplicates, when they are, in fact, not duplicates. > > I still contend that exactly duplicate IPv6 packets are not > all that > > uncommon, depending on your application (video, anything that uses > > keepalives). It's even more common if you do not hash the > entire packet, as many XML-formatted messages may be the same > for the first number of bytes, for instance. > > > Well, if they are exactly duplicate, how can you tell if they > are duplicated (and needing to be suppressed) vs. duplicated > (and not needing to be suppressed)? With the DPD option, you mark them with a new header. A node can mark the packets that it sources, as well as those packets flooded into the MANET by a gateway/"tagger"... This is relatively trivial, and NRL's SMF code already does this. This isn't as easy to do with hashing, because you are not marking each packet, but instead, comparing its hash to a limited, non-predictable history of hashes. The problem is again that this history does not match the history at all forwarded nodes, so some forwarders may (incorrectly) drop the packet as being a duplicate. I do not see a way to avoid this problem. > > I can really forsee hashing causing many applications to fail in a > > MANET. All it takes is the right data rate and the right keepalive > > rate. If they happen to match up to "one keepalive almost > every time we roll through our history", the application will > fail at random. > > > Do you still think so, given my responses above? Yes. -Jeff _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 04 02:02: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 1Hjqri-0006LK-Mx; Fri, 04 May 2007 02:02:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hjqrh-0006Cs-5y for manet-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 02:02:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjqrg-0006As-PO for manet@ietf.org; Fri, 04 May 2007 02:02:00 -0400 Received: from ik-out-1112.google.com ([66.249.90.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjqrf-0001se-AC for manet@ietf.org; Fri, 04 May 2007 02:02:00 -0400 Received: by ik-out-1112.google.com with SMTP id b35so734177ika for ; Thu, 03 May 2007 23:01: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cbmDil/hlALyXWfKz7fC1ZOlq+WN3dL7tYXcXPopcbSm00ylJOm16HZ5Vq7bghUYMfAirPUC9evsETm+IYr1s0rMYkTIyN05NaRkhDTX9Z7Lg6gl36ItBXo9IwOW1tmPX+GsD0cNkYF+ALUxo8iRFGs3SRatwpwYpcdJdHBkEmI= 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:content-transfer-encoding:content-disposition:references; b=TASMgOUGmbxHrVERNM9lm0xtVCvxgXXTX/Nj6gSzdJ8eqbi1V/qBmE9vuX38vRLMUh7px3rLnEQ7VdNI+6deAaT6qZKn6+kn6Ky1+GSLsYkjl2/eNugSlEyk0cflRisxv8W+zMLGyJ8PUhHtAGQcjUb9rZKRAUmqlT12nNa72M8= Received: by 10.78.138.14 with SMTP id l14mr1290730hud.1178258518307; Thu, 03 May 2007 23:01:58 -0700 (PDT) Received: by 10.78.18.18 with HTTP; Thu, 3 May 2007 23:01:58 -0700 (PDT) Message-ID: <374005f30705032301r329ef9a4m2e93144a01f77ae9@mail.gmail.com> Date: Fri, 4 May 2007 11:31:58 +0530 From: "Ian Chakeres" To: manet Subject: Re: [manet] I-D ACTION:draft-ietf-manet-dymo-09.txt 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: 4b800b1eab964a31702fa68f1ff0e955 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 you can see from this notice, we've submitted a revised DYMO ID. I'd like to thank everyone one for their excellent comments, and I'd like to encourage people to please review the newest revision. Thank you, Ian Chakeres On 5/3/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 : Dynamic MANET On-demand (DYMO) Routing > Author(s) : C. Perkins, I. Chakeres > Filename : draft-ietf-manet-dymo-09.txt > Pages : 32 > Date : 2007-5-2 > > The Dynamic MANET On-demand (DYMO) routing protocol is intended for > use by mobile nodes in wireless, multihop networks. It offers > adaptation to changing network topology and determines unicast routes > between nodes within the network in an on-demand fashion. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-09.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-dymo-09.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-manet-dymo-09.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > manet mailing 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 May 04 05:39: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 1HjuG3-0004lL-0F; Fri, 04 May 2007 05:39:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HjuG1-0004lG-7u for manet-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 05:39:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjuG0-0004l7-Ud for manet@ietf.org; Fri, 04 May 2007 05:39:20 -0400 Received: from mail153.messagelabs.com ([216.82.253.51]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HjuG0-0004Nn-Jv for manet@ietf.org; Fri, 04 May 2007 05:39:20 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-153.messagelabs.com!1178271559!9054266!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23083 invoked from network); 4 May 2007 09:39:19 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-153.messagelabs.com with SMTP; 4 May 2007 09:39:19 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l449dJDp001165; Fri, 4 May 2007 02:39:19 -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 l449dI8d022556; Fri, 4 May 2007 04:39:18 -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 l449dG0Q022504; Fri, 4 May 2007 04:39:17 -0500 (CDT) Message-ID: <463AFF3E.3040004@gmail.com> Date: Fri, 04 May 2007 11:39:10 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) 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> <4631FB64.5040002@gmail.com> <0BA3D954-3A13-4450-9C92-D3DB0B168130@gmail.com> <4634DC13.2050204@gmail.com> <374005f30705012210v85243c3kbd01cb61a55b9d10@mail.gmail.com> <4639A8FF.9000809@gmail.com> <374005f30705030334y152069aeuef8dc749a48d5cc9@mail.gmail.com> <4639D203.9020406@gmail.com> <374005f30705032248vc653240m1ff5ea2cec8fe371@mail.gmail.com> <463AF37F.7040909@gmail.com> <374005f30705040212q43f05a95j4d0dd8433a60a4c0@mail.gmail.com> In-Reply-To: <374005f30705040212q43f05a95j4d0dd8433a60a4c0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000738-1, 03/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 [MANET: this private discussion Ian and I had is with respect to the MANET IANA needs document. I'm looking at why the necessity of site-local multicast address for IPv6 MANET protocols. I've noticed no other routing protocol uses ff05 site scope multicast addresses, at least not by the specs - so it would be strange for MANET to use it. I've run into the idea of the probable need for a new scope, probably a "MANET scope" ff06. Any thoughts you may have on this, thanks.] Ian Chakeres wrote: > > >> >> It's not what I asked. I'm afraid no IPv6 routing protocol uses >> site-local ff05::x multicast addresses. It would be strange for >> MANET routing protocols to use it. Don't you agree? > > MANET's are more heterogeneous and distributed, than other networks > with traditional routing protocols. I'm afraid most MANETs that have been tested are very homogeneous in terms of the type of link layer. At least compared to the fixed networks. > I think there will be a need to coordinate with MANET routers that > are not link-local. I agree with that - MANET routers are often not on the same link. But that doesn't necessarily make them need multicast addresses with site-local scope. > Given existing routing protocols more fully synchronized attributes, > I don't think they have as much need for a site-local multicast > address. Right, but I don't see why the less synchronized attributes in a MANET protocol will need a site-local multicast address scope. I agree it needs a multicast address with larger scope than just link, but why _site_ scope; especially when the concept of "site" is compromised by the depreciation of site-local addresses fec0. OSPF has this notion of "area" that is semantically close to a "site", yet it doesn't use a site-scope multicast address (neither does RIPng). BGP has "realm" and still not using site-scoped multicast addresses. IANA and rfc4291 reserved the site-scoped ff05::2 "All Routers Address" but I think no routing protocol actually uses it. Do I miss something. 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 May 04 07:04: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 1Hjva7-0007mY-7j; Fri, 04 May 2007 07:04:11 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hjva6-0007mT-5h for manet-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 07:04:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjva5-0007mL-SP for manet@ietf.org; Fri, 04 May 2007 07:04:09 -0400 Received: from wx-out-0506.google.com ([66.249.82.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjva4-0006lV-H6 for manet@ietf.org; Fri, 04 May 2007 07:04:09 -0400 Received: by wx-out-0506.google.com with SMTP id h31so759265wxd for ; Fri, 04 May 2007 04:04: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=snNMStqaNCPtvEsGV/1HaYKxjAtpgoPMBrs0r0DRZD2FQqTUT00KF8/loRasGtehS2d/ggSvnjYC4W7rKExcHaJEvk3OOBOvVG2feoVk0tZgC72YfH4zBYli6ScTRZ7rRBcFKKsGMo/uOASdhU0jDjrNYjaTSb0yj+OMLimPULk= 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=IXgGDKY7HgQNHpjtPpAgEkqmtgb8W5WaF1bFPB35Wti8FRGV6V3KgJhmGGJpq7V10jLwYDUoBrTKm+DCkLKiXlw0iNL6+jqrizEaObkiGFNtogp4t0CXqggH3NkADJjwUpOxG2ihdv9bwgB3p/vXSqoPykKYaEubAjyRg7lsiVE= Received: by 10.78.156.6 with SMTP id d6mr1469285hue.1178276647154; Fri, 04 May 2007 04:04:07 -0700 (PDT) Received: by 10.78.18.18 with HTTP; Fri, 4 May 2007 04:04:07 -0700 (PDT) Message-ID: <374005f30705040404v59ec2185qd2035b5175cf281@mail.gmail.com> Date: Fri, 4 May 2007 16:34:07 +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: <463AFF3E.3040004@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> <4634DC13.2050204@gmail.com> <374005f30705012210v85243c3kbd01cb61a55b9d10@mail.gmail.com> <4639A8FF.9000809@gmail.com> <374005f30705030334y152069aeuef8dc749a48d5cc9@mail.gmail.com> <4639D203.9020406@gmail.com> <374005f30705032248vc653240m1ff5ea2cec8fe371@mail.gmail.com> <463AF37F.7040909@gmail.com> <374005f30705040212q43f05a95j4d0dd8433a60a4c0@mail.gmail.com> <463AFF3E.3040004@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 5/4/07, Alexandru Petrescu wrote: > [MANET: this private discussion Ian and I had is with respect > to the MANET IANA needs document. I'm looking at why the necessity > of site-local multicast address for IPv6 MANET protocols. I've noticed > no other routing protocol uses ff05 site scope multicast addresses, at > least not by the specs - so it would be strange for MANET to use it. > I've run into the idea of the probable need for a new scope, probably a > "MANET scope" ff06. > Right, but I don't see why the less synchronized attributes in a MANET > protocol will need a site-local multicast address scope. I agree it > needs a multicast address with larger scope than just link, but why > _site_ scope; especially when the concept of "site" is compromised by > the depreciation of site-local addresses fec0. >From my understanding, site-local is the next larger scope than link-local. I don't know how we might define a scope that is smaller than site but larger than link. I think the boundary between them is tight (1 hop vs. 1 or more hops). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 04 07:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjw2l-0008FC-0Q; Fri, 04 May 2007 07:33:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hjw2j-0008Ew-3L for manet-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 07:33:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjw2i-0008Eo-Q0 for manet@ietf.org; Fri, 04 May 2007 07:33:44 -0400 Received: from pilot.jhuapl.edu ([128.244.198.200] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjw2g-0002qu-HZ for manet@ietf.org; Fri, 04 May 2007 07:33:44 -0400 Received: from ([128.244.206.105]) by pilot.jhuapl.edu with ESMTP id 5502123.30641595; Fri, 04 May 2007 07:33:20 -0400 Message-ID: <463B1A01.4030001@innovationslab.net> Date: Fri, 04 May 2007 07:33:21 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.10 (Macintosh/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> <4634DC13.2050204@gmail.com> <374005f30705012210v85243c3kbd01cb61a55b9d10@mail.gmail.com> <4639A8FF.9000809@gmail.com> <374005f30705030334y152069aeuef8dc749a48d5cc9@mail.gmail.com> <4639D203.9020406@gmail.com> <374005f30705032248vc653240m1ff5ea2cec8fe371@mail.gmail.com> <463AF37F.7040909@gmail.com> <374005f30705040212q43f05a95j4d0dd8433a60a4c0@mail.gmail.com> <463AFF3E.3040004@gmail.com> <374005f30705040404v59ec2185qd2035b5175cf281@mail.gmail.com> In-Reply-To: <374005f30705040404v59ec2185qd2035b5175cf281@mail.gmail.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 5/4/07, Alexandru Petrescu wrote: >> [MANET: this private discussion Ian and I had is with respect >> to the MANET IANA needs document. I'm looking at why the necessity >> of site-local multicast address for IPv6 MANET protocols. I've noticed >> no other routing protocol uses ff05 site scope multicast addresses, at >> least not by the specs - so it would be strange for MANET to use it. >> I've run into the idea of the probable need for a new scope, probably a >> "MANET scope" ff06. > > > >> Right, but I don't see why the less synchronized attributes in a MANET >> protocol will need a site-local multicast address scope. I agree it >> needs a multicast address with larger scope than just link, but why >> _site_ scope; especially when the concept of "site" is compromised by >> the depreciation of site-local addresses fec0. > >> From my understanding, site-local is the next larger scope than > link-local. I don't know how we might define a scope that is smaller > than site but larger than link. I think the boundary between them is > tight (1 hop vs. 1 or more hops). Not exactly. Scope 4 can be used as well (e.g. "Admin Scope"). Take a look at RFC 4007 (http://tools.ietf.org/html/rfc4007) for some of the technical discussions on the multicast scoping issues. As for the issue itself, until I see a multicast routing protocol (or unicast for that matter) that uses something other than link-local or global addresses for exchanging information I don't see the benefit of reserving a multicast address. Regards, Brian _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 04 10:51: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 1Hjz7z-0007PC-LZ; Fri, 04 May 2007 10:51:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hjz7y-0007Oz-4G for manet-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 10:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjz7x-0007Or-Qr for manet@ietf.org; Fri, 04 May 2007 10:51:21 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjz7w-0005DT-Q9 for manet@ietf.org; Fri, 04 May 2007 10:51:21 -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 l44EpHkn009152; Fri, 4 May 2007 10:51:17 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007050410511711250 ; Fri, 04 May 2007 10:51:17 -0400 From: "Joe Macker" To: "'Brian Haberman'" , "'Ian Chakeres'" References: <374005f30704170225v2e2fa3bfn96615121315f3496@mail.gmail.com> <4634DC13.2050204@gmail.com> <374005f30705012210v85243c3kbd01cb61a55b9d10@mail.gmail.com> <4639A8FF.9000809@gmail.com> <374005f30705030334y152069aeuef8dc749a48d5cc9@mail.gmail.com> <4639D203.9020406@gmail.com> <374005f30705032248vc653240m1ff5ea2cec8fe371@mail.gmail.com> <463AF37F.7040909@gmail.com> <374005f30705040212q43f05a95j4d0dd8433a60a4c0@mail.gmail.com> <463AFF3E.3040004@gmail.com><374005f30705040404v59ec2185qd2035b5175cf281@mail.gmail.com> <463B1A01.4030001@innovationslab.net> Subject: RE: [manet] I-D ACTION:draft-ietf-manet-iana-01.txt = WG Last Call Date: Fri, 4 May 2007 10:51:14 -0400 Message-ID: <003601c78e5b$a9e1e3b0$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: <463B1A01.4030001@innovationslab.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceOQCMG+i21Z/C7TJ6MtVzrMBbqugAFROnw X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 >>> From my understanding, site-local is the next larger scope than >> link-local. I don't know how we might define a scope that is smaller >> than site but larger than link. I think the boundary between them is >> tight (1 hop vs. 1 or more hops). > >Not exactly. Scope 4 can be used as well (e.g. "Admin Scope"). > >Take a look at RFC 4007 (http://tools.ietf.org/html/rfc4007) >for some of the technical discussions on the multicast scoping issues. > >As for the issue itself, until I see a multicast routing >protocol (or unicast for that matter) that uses something >other than link-local or global addresses for exchanging >information I don't see the benefit of reserving a multicast address. > Brian: Most of the design interest I have seen for MANET site-scoping has come not come from routing control plane usage (link-local seems fine to me) but rather implementors wanting to apply SMF for some autconfiguration or discovery protocol (outside of the routing control plane) within a topological zone (e.g., autoconf). There was some concern from previous ADs that we support an approach to keep "site-intended" SMF application data from leaking out when the application is MANET topological zone/site. There are other ways to accomplish this. We could debate whether an assignmnet is needed at this time since global address forwarding is supported and PIM gatewaying has been done. Use cases might come from the autoconf WG. There is certainly still an evolving area and there is a little bit of pre-app definition going on. I believe there is is no dependency related to the present routing protocol designs in this regard just to be clear. Ian I am not sure if you define a use case for DYMO. There was some site-scoping language put in SMF because of ADs and others concerns but the multicast applications that would use this are yet to be defined (although some related proposals have shown up in the autoconf community). I believe SMF site-boundary routing functionality will be useful but perhaps it is redundant with standard practice definitions... >Regards, >Brian > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 04 17:15: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 1Hk57b-0006F0-Ob; Fri, 04 May 2007 17:15:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hk57a-0006Ev-1M for manet-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 17:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk57Z-0006En-O0 for manet@ietf.org; Fri, 04 May 2007 17:15: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 1Hk57Z-0001E7-9q for manet@ietf.org; Fri, 04 May 2007 17:15:21 -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 l44LFDmS003432; Sat, 5 May 2007 00:15:19 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 May 2007 00:15:18 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 16:15:15 -0500 Received: from [10.162.77.247] ([10.162.77.247]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 May 2007 16:15:13 -0500 Message-ID: <463BA25B.5040107@nokia.com> Date: Fri, 04 May 2007 14:15:07 -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-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID References: <018801c78d8c$b246a2e0$355dfa84@chiron> <463A48D0.3020006@nokia.com> <000001c78df3$c7fdd920$6601a8c0@morpheus> In-Reply-To: <000001c78df3$c7fdd920$6601a8c0@morpheus> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2007 21:15:14.0322 (UTC) FILETIME=[4E963F20:01C78E91] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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, Continuing the discussion... ext Jeff Weston wrote: > > ... my point is that this is not a trivial thing to when forwarding > nodes have different histories. While the source/tagger may not see a new > packet as having a conflicting hash, that doesn't automatically imply that > the forwarders will also see no conflicting hash. Since they will have a > different history of hashes to compare against, they may well drop packets > as duplicates, when they are, in fact, not duplicates. > The source would be in charge of disambiguating packets. For sources that do not obey, the taggers can put in DPD headers if there is danger of a problem. For heavy flows, clearly the intended receiver is not worried about energy and so it won't bother anyone much if there is more overhead. For energy constrained systems, it is much more of a bother and so the DPD header should be avoided if it is not needed -- which would be most of the time I reckon. >> Well, if they are exactly duplicate, how can you tell if they >> are duplicated (and needing to be suppressed) vs. duplicated >> (and not needing to be suppressed)? >> > > With the DPD option, you mark them with a new header. A node can mark the > packets that it sources, as well as those packets flooded into the MANET by > a gateway/"tagger"... This is relatively trivial, and NRL's SMF code > already does this. > Yes, the source should do this for packets that would otherwise be identical. This is a subcase of the point about having the same hash result (rare except for identical packets, but possible). My point was that the taggers cannot disambiguate identical packets (!). Isn't this obvious? In the scenario of unfortunate applications that insist in emitting identical packets for IPv6 without any RTP or other nice wrapper, if the source does not put in the distinguishing data at the network layer, the taggers are likely to pessimistically assume they have to tag all identical packets. Ick. > This isn't as easy to do with hashing, because you are not marking each > packet, but instead, comparing its hash to a limited, non-predictable > history of hashes. The problem is again that this history does not match > the history at all forwarded nodes, so some forwarders may (incorrectly) > drop the packet as being a duplicate. I do not see a way to avoid this > problem. > (?) But the source can do the tagging when needed. Why doesn't this solve the problem, for the case you mention when the hash does not disambiguate? > >>> I can really forsee hashing causing many applications to fail in a >>> MANET. >> Do you still think so, given my responses above? >> Now, do you still think so?? Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat May 05 07:24: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 1HkINX-0005LT-N6; Sat, 05 May 2007 07:24:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HkINW-0005LN-E1 for manet-confirm+ok@megatron.ietf.org; Sat, 05 May 2007 07:24:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkINW-0005LF-4a for manet@ietf.org; Sat, 05 May 2007 07:24:42 -0400 Received: from cronos.ocn.ne.jp ([222.146.51.136] helo=smtp.cronos.ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkINU-0005rY-H8 for manet@ietf.org; Sat, 05 May 2007 07:24:42 -0400 Received: from Diamond (theia.cs.tsukuba.ac.jp [130.158.81.84]) by smtp.cronos.ocn.ne.jp (Postfix) with ESMTP id B94A62781 for ; Sat, 5 May 2007 20:24:38 +0900 (JST) From: "Jie Li" To: Date: Sat, 5 May 2007 20:24:34 +0900 Message-ID: <006c01c78f07$f55a3020$0201a8c0@Diamond> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcePB/UeJUm7mWuyQViiZ0U/NO8cSQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.7 (+) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [manet] CALL FOR PARTICIPATION-B O D Y N E T S 2 0 0 7 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] Early registration is scheduled by May 15th. *************** B O D Y N E T S 2 0 0 7 **************** 2nd International Conference on Body Area Networks 11-13 June, 2007, Florence (Italy) http://www.bodynets.org Jointly sponsored by: - Create-Net - ICST - AICT "Networks and Telecommunication systems" Group In-technical cooperation with: - ACM SIGCHI - The European Association for Signal and Image Processing (EURASIP) ------------------------------------------------------------- CALL FOR PARTICIPATION With recent advances in Wireless Sensor Networks (WSNs), their practical applications in general sensing and monitoring are rapidly broadening. Although originally conceived for wide area environment or process monitoring, WSNs are increasingly being used in human computer interaction, brain computer interaction, gaming, and interactive digital arts, as well as in healthcare and patient monitoring. Despite the recent technological developments in sensing, embedded electronics, and sensor networking, several challenging issues need to be addressed. In particular, technological scaling, wireless communication and networking, sensor data processing and presentation are key aspects that need to be investigated in an integrated fashion for enabling visionary applications in the above areas of WSN. The aim of this conference is to bring researchers in WSN to address the technical and application issues related to Body Area Sensor Networks. CONFERENCE PROGRAM The conference program includes: $B!&(B8 Technical sessions (detailed description on www.bodynets.org). The topics include: o BSN and context awareness. o BSN and Human Computer Interaction o BSN applications, test-bed and performance evaluation o BSN wireless communication and networking protocols $B!&(BSeveral invited papers by leading professionals and researchers in the field. $B!&(BA keynote speech from Joseph Paradiso, Director of the Responsive Environments Group at Media Lab, Boston, USA entitled: 'From the Ball Field to the Dance Hall - A Decade of Body Sensor Networks in Medicine, Sports, Entertainment, and the Arts' CONFERENCE LOCATION The conference will be held in Florence, at the $BA$(Bonvitto della Calza$B!&(B located in the ancient centre of the town, from the 11th to the 13th of June 2007. REGISTRATION Early registration deadline is May 15th, 2007. Reduced registration fees are available for students and members of ACM. ORGANIZING COMMITTEE ------------------------------------------------------------ Romano Fantacci (General Chair), University of Florence , Italy David Tacconi (Vice-Chair), Create-Net, Italy Guang-Zhong Yang (TPC chair), Imperial College of London, UK Hsiao-Hwa Chen (TPC chair), NSYSU, Taiwan Prithwish Basu (TPC chair), BBN Technologies, USA Francesco Chiti (Local Arrangement Chair), University of Florence , Italy Jie Li (Publicity Chair), University of Tsukuba, Japan Yang Yang (Publicity Chair), University College of London, UK Sinem Coleri Ergen (Publicity Chair), Pirelli/Telecom Italia WSN Lab,Berkeley, US Giada Mennuti (Sponsorships Chair), University of Florence , Italy Thomas Watteyne (Web Chair), INRIA / France Telecom, France Karen Decker (Financial Chair), ICST, US Zita Rozsa (Conference Coordinator), ICST, Europe STEERING COMMITTEE -------------------------------------------------------- Imrich Chlamtac (Chair), Create-Net, Univ. Trento, Italy _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun May 06 11:21:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkiYQ-0000YF-EG; Sun, 06 May 2007 11:21:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HkiYP-0000Y7-9J for manet-confirm+ok@megatron.ietf.org; Sun, 06 May 2007 11:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkiYO-0000Xz-Vy; Sun, 06 May 2007 11:21:40 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HkiYM-000585-Ud; Sun, 06 May 2007 11:21:40 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4b463dfa1b; Sun, 06 May 2007 23:32:38 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4a463901fb; Thr, 03 May 2007 04:06:04 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Thr, 03 May 2007 04:06:04 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKqB-0007jT-8k; Wed, 02 May 2007 15:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjKpv-0007e6-2W; Wed, 02 May 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjKpu-0003AO-LM; Wed, 02 May 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 8459426EB2; Wed, 2 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HjKpu-0005ik-Dv; Wed, 02 May 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: Wed, 02 May 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-dymo-09.txt X-BeenThere: manet@ietf.org Reply-To: internet-drafts@ietf.org 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 : Dynamic MANET On-demand (DYMO) Routing Author(s) : C. Perkins, I. Chakeres Filename : draft-ietf-manet-dymo-09.txt Pages : 32 Date : 2007-5-2 The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile nodes in wireless, multihop networks. It offers adaptation to changing network topology and determines unicast routes between nodes within the network in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-09.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-dymo-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-dymo-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-5-2110020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-dymo-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-dymo-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-2110020.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Mon May 07 04:47: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 1HkysY-0004nb-JG; Mon, 07 May 2007 04:47:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HkysW-0004nM-Hz for manet-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 04:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkysW-0004nE-8G for manet@ietf.org; Mon, 07 May 2007 04:47:32 -0400 Received: from web32211.mail.mud.yahoo.com ([68.142.207.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HkysT-0004Jp-KQ for manet@ietf.org; Mon, 07 May 2007 04:47:32 -0400 Received: (qmail 50509 invoked by uid 60001); 7 May 2007 08:47:29 -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=Hv8eq4FBOqPN2hJHatnrSycCFqpdXRjzV/i5ufO4DoKnKRT1ZVm4x/hnbjTyUFQeLsOJu3vnY72FP12qzlg3aqIXO1vQXW1Lf/XLxCE/QLPlqjQ3xXixqE+JBNS9FmWZKLPXpCIL84P7pIWSz2fiAi5S8kaiJCj70Vd3fI+MSMo=; X-YMail-OSG: 6NvJ7JoVM1nAttx5LGIqQtqibTF9OniBglsA5RQWAGi7iAdIzeLuIACmRP0EZRmbw.LuulIZS.QvIt.XlOxAWJqUpNXcaV3GTHW6VyF__pj0bZqCNN0- Received: from [202.54.91.205] by web32211.mail.mud.yahoo.com via HTTP; Mon, 07 May 2007 09:47:29 BST Date: Mon, 7 May 2007 09:47:29 +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: <75279.50149.qm@web32211.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Subject: [manet] Anybody has solution for Classfier::no slot{} problem 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 implementing a new VANET protocol in ns2. My configuration in TCL scripts is to establish connectivity between base-station and mobile nodes(using VANET protocol). TCL script i executed as follows: global opt set val(chan) Channel/WirelessChannel ;# channel type set val(prop) Propagation/FreeSpace ;# radio-propagation model set val(ant) Antenna/OmniAntenna ;# antenna type set val(ll) LL ;# link layer type set val(ifq) Queue/DropTail/PriQueue ;# interface queue type set val(ifqlen) 50 ;# max packet in ifq set val(netif) Phy/WirelessPhy ;# network interface type set val(mac) Mac/802_11 ;# MAC type set val(rp) DumbAgent ;# routing (none) set opt(x) 1000 set opt(y) 1000 set opt(nn) 2 set num_base_stations 1 set opt(sc) "/home/Shiva/Desktop/scenario2.tcl" set opt(tracefile) sumo.tr set opt(namfile) sumo set opt(stop) 10 proc finish {} { global ns_ fd1 global ns_ fd2 global ns_ tracefd global opt $ns_ flush-trace close $fd1 close $fd2 close tracefd exec nam $opt(namfile).nam & } set ns_ [new Simulator] $ns_ node-config -AdderessType hierarchical AddrParams set domain_num_ 2 lappend cluster_num 1 1 AddrParams set cluster_num_ $cluster_num lappend eilastlevel 1 1 2 AddrParams set nodes_num_ $eilastlevel set tracefd [open test.tr w] set vanetfd [new Trace/Generic] $tracefd attach $vanetfd set fd1 [open $opt(tracefile) w] $ns_ trace-all $fd1 set fd2 [open $opt(namfile).nam w] $ns_ namtrace-all-wireless $fd2 $opt(x) $opt(y) set topo [new Topography] ;# create the topology $topo load_flatgrid $opt(x) $opt(y) create-god [expr num_base_stations + $opt(nn)] set temp {0.0.0 0.0.1} for {set i 0} {$i < $opt(nn)} {incr i} { set W($i) [$node [lindex $temp $i]] } $ns_ node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -channel [new $val(chan)] \ -topoInstance $topo \ -wiredRouting ON \ -agentTrace ON \ -routerTrace OFF \ -macTrace OFF \ -movementTrace OFF set temp {1.0.0 1.0.1 1.0.2} set BS(0) [$node $temp 0] $BS(0) random-motion 0 $BS(0) set X_ 1.000000 $BS(0) set Y_ 2.000000 $BS(0) set Z_ 0.000000 $ns_ node-config -wiredRouting OFF for {set i 0} {$i < $opt(nn)} {incr i} { set node($i) [$ns_ node [lindex $temp expr[$i+1]]] $node base-station [AddrParams addr2id[$BS(0) node-addr]] set p($i) new [Agent/vanetNEW [lindex $temp expr[$i+1]]] $ns_ attach-agent $node $p($i) $p($i) log-target $vanetfd } source $opt(sc) for {set i 0} {$i < opt(nn)} {incr i} $ns_ at 0.0 "$p($i) start" } $ns_ run when I execute above script it gives followign error message: Classifier:: no slot{} //default tcl/lib/ns-lib.tcl 0 mask 0 offset _05 classifier/port etc... Hope I receive some solutions to this mail. Thanks -Shivamurti. ___________________________________________________________ Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today http://uk.rd.yahoo.com/evt=44106/*http://uk.docs.yahoo.com/mail/winter07.html _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 07 09:33: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 1Hl3LW-0000KE-7F; Mon, 07 May 2007 09:33:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hl3LS-0000H7-Sn for manet-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 09:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl3LS-0000FW-Cx for manet@ietf.org; Mon, 07 May 2007 09:33:42 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl3HY-0000IC-Np for manet@ietf.org; Mon, 07 May 2007 09:29:41 -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 l47DTeBd011658; Mon, 7 May 2007 09:29:40 -0400 (EDT) Received: (from chiron [132.250.93.53]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007050709293919254 ; Mon, 07 May 2007 09:29:39 -0400 From: "Jeff Weston" To: "'Charles E. Perkins'" References: <018801c78d8c$b246a2e0$355dfa84@chiron> <463A48D0.3020006@nokia.com> <000001c78df3$c7fdd920$6601a8c0@morpheus> <463BA25B.5040107@nokia.com> Subject: RE: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID Date: Mon, 7 May 2007 09:27:30 -0400 Message-ID: <01d201c790ab$76d757a0$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: AceOkVTzj9ImZb5OQB6uOrlw5TnEAACF++Sw In-Reply-To: <463BA25B.5040107@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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. > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: Friday, May 04, 2007 5:15 PM > To: ext Jeff Weston > Cc: manet@ietf.org > Subject: Re: [Manet-dt] Re: [manet] Need for DPD header (SMF > document discussion) - ValidReason for Tagger ID > > > Hello Jeff, > > Continuing the discussion... > > ext Jeff Weston wrote: > > > > ... my point is that this is not a trivial thing to when > forwarding > > nodes have different histories. While the source/tagger > may not see a > > new packet as having a conflicting hash, that doesn't automatically > > imply that the forwarders will also see no conflicting hash. Since > > they will have a different history of hashes to compare > against, they > > may well drop packets as duplicates, when they are, in > fact, not duplicates. > > > The source would be in charge of disambiguating packets. Precisely, and my whole point was that with hashing, there is an inherent problem, in which duplicate-hashed packets will sometimes be dropped due to forwarders having a different history than the source/tagger. Do you agree? > For sources that do not obey, the taggers can put in DPD > headers if there is danger of a problem. For heavy flows, > clearly the intended receiver is not worried about energy and > so it won't bother anyone much if there is more overhead. > For energy constrained systems, it is much more of a bother > and so the DPD header should be avoided if it is not needed > -- which would be most of the time I reckon. Are you suggesting that the tagger/source keep track of the data rate it's sending, and add the DPD option if the data rate is too large? That sounds much more complicated than necessary to me... > > > >> Well, if they are exactly duplicate, how can you tell if they are > >> duplicated (and needing to be suppressed) vs. duplicated (and not > >> needing to be suppressed)? > >> > > > > With the DPD option, you mark them with a new header. A > node can mark > > the packets that it sources, as well as those packets > flooded into the > > MANET by a gateway/"tagger"... This is relatively trivial, > and NRL's > > SMF code already does this. > > > Yes, the source should do this for packets that would > otherwise be identical. This is a subcase of the point about > having the same hash result (rare except for identical > packets, but possible). > > My point was that the taggers cannot disambiguate identical > packets (!). Isn't this obvious? In the scenario of > unfortunate applications that insist in emitting identical > packets for IPv6 without any RTP or other nice wrapper, if I thought the point of this whole debate was to save a few bytes on the air ... Why are we forcing applications running on a MANET to use a wrapper, or to timestamp their keepalives, thereby negating any energy savings in the first place? > the source does not put in the distinguishing data at the > network layer, the taggers are likely to pessimistically > assume they have to tag all identical packets. > > Ick. > > This isn't as easy to do with hashing, because you are not marking > > each packet, but instead, comparing its hash to a limited, > > non-predictable history of hashes. The problem is again that this > > history does not match the history at all forwarded nodes, so some > > forwarders may (incorrectly) drop the packet as being a > duplicate. I > > do not see a way to avoid this problem. > > > (?) But the source can do the tagging when needed. Why > doesn't this solve the problem, for the case you mention when > the hash does not disambiguate? My whole point is that the source doesn't always know when tagging is needed! Different forwarders will have different hash histories, period (due to various reasons previously mentioned). Do you agree? So unless all forwarders are feeding back information on their histories to the source somehow, the source has absolutely no way of knowing when tagging is definitely unnecessary, correct? > > > >>> I can really forsee hashing causing many applications to > fail in a > >>> MANET. > >> Do you still think so, given my responses above? > >> > Now, do you still think so?? > > Regards, > Charlie P. > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 07 11:06: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 1Hl4n5-0000JK-Ja; Mon, 07 May 2007 11:06:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hl4n1-0000In-FB for manet-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 11:06:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl4n1-0000If-5Z for manet@ietf.org; Mon, 07 May 2007 11:06: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 1Hl4n0-0004kJ-Ei for manet@ietf.org; Mon, 07 May 2007 11:06:15 -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 l47F61TZ004463; Mon, 7 May 2007 18:06:12 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 18:05:58 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 10:05:45 -0500 Received: from [10.162.27.48] ([10.162.27.48]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 10:05:43 -0500 Message-ID: <463F4042.90909@nokia.com> Date: Mon, 07 May 2007 08:05:38 -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-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID References: <018801c78d8c$b246a2e0$355dfa84@chiron> <463A48D0.3020006@nokia.com> <000001c78df3$c7fdd920$6601a8c0@morpheus> <463BA25B.5040107@nokia.com> <01d201c790ab$76d757a0$355dfa84@chiron> In-Reply-To: <01d201c790ab$76d757a0$355dfa84@chiron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2007 15:05:44.0365 (UTC) FILETIME=[2F8085D0:01C790B9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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, From your answers, it seems that there is still something I am not making clear, even though it seems clear bordering on obvious to me. To restate: - Source is in charge of making packets distinguishable by way of a hash function. - Every node suppressing duplicates uses the same hash function. Thus, if the source ensures that packets are distinguished, no other node (regardless of history) will have a problem with this. - For sources that do not obey this, a very very rare problem exists for packets that are not exact duplicates. These sources are MANET-unaware sources, otherwise they would do the right thing. - To solve the problem when the source does not distinguish, it has been proposed to use "taggers" (hashing or not). - I believe you have claimed that some IPv6 packet streams in your experience produce multiple identical packets that are not supposed to be considered duplicates -- and, hence not suppressed. - To distinguish these packets, the proposal is to tag _every_ IPv6 flooded packet _ever_ sent in the ad hoc network? Externally sourced or not? This is a very severe and onerous requirement to solve a problem I have never seen and only the word of the tagger proponents to support its existence. It would be a burden for _every_ ad hoc network ever built from this specification. Continuing... - In order to distinguish such packets, hashing would require insertion of a header. We can discuss more about this header, but before doing so I think it should be clear that this is only to solve a problem that is almost astronomically rare, and only for IPv6 packets. - For this astronomically rare problem, for MANET-unaware sources that do not already make the packets distinct, I agree that taggers could put in a header. - As an even rarer occurrence within the already rare problem, it is possible that for multiple MANET-unaware sources, taggers might fail to have enough history to ensure unique hash results for every instance of "duplicated but different" packets that are somehow not supposed to be suppressed. That is the context in which I see our current discussion is being carried out. There must be some part of the bedrock context that you do not agree with, otherwise the conclusion seems inescapable that we should use hashing. Can you point out where our assumptions are diverging? Given the above, I have made some answers inline below. ext Jeff Weston wrote: > Comments inline. > > >> >> >> The source would be in charge of disambiguating packets. >> > > Precisely, and my whole point was that with hashing, there is an inherent problem, in which duplicate-hashed packets will sometimes > be dropped due to forwarders having a different history than the source/tagger. Do you agree? > You must be referring to the case where the source does not actually do what it is supposed to do. Right? > > > Are you suggesting that the tagger/source keep track of the data rate it's sending, and add the DPD option if the data rate is too > large? That sounds much more complicated than necessary to me... > It is no more complicated than any other rate-controlled operation. > >> >> Yes, the source should do this for packets that would >> otherwise be identical. This is a subcase of the point about >> having the same hash result (rare except for identical >> packets, but possible). >> >> My point was that the taggers cannot disambiguate identical >> packets (!). Isn't this obvious? In the scenario of >> unfortunate applications that insist in emitting identical >> packets for IPv6 without any RTP or other nice wrapper, if >> > > I thought the point of this whole debate was to save a few bytes on the air ... Why are we forcing applications running on a MANET > to use a wrapper, or to timestamp their keepalives, thereby negating any energy savings in the first place? > First, these are not applications running purely on the MANET, or else they would already have the DPD header inserted from the source and no tagger would ever have any work to do. Unless I misunderstand you, this is only for cases where a data stream is coming from outside the MANET and the external source does not know it is running a MANET application. >> (?) But the source can do the tagging when needed. Why >> doesn't this solve the problem, for the case you mention when >> the hash does not disambiguate? >> > > My whole point is that the source doesn't always know when tagging is needed! No, the source would _always_ know exactly when the packets have to be distinguished. It is sourcing them! It knows that any node checking for duplicates will use exactly the same hash function and so will get the same answer per packet. > Different forwarders will have different hash > histories, period (due to various reasons previously mentioned). Do you agree? I agree that for external, MANET-unaware hosts that are using specific kinds of applications that I have never ever seen, a problem could exist for a kind of data stream that I have never ever seen. > So unless all forwarders are feeding back > information on their histories to the source somehow, the source has absolutely no way of knowing when tagging is definitely > unnecessary, correct? > No. The source would always emit packets that can easily be distinguished. Unless it were external and MANET-unaware. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 07 12:05: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 1Hl5if-00040I-Im; Mon, 07 May 2007 12:05:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hl5ie-0003sB-1l for manet-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 12:05:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl5id-0003qC-MH for manet@ietf.org; Mon, 07 May 2007 12:05:47 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl5ic-0003w0-Ec for manet@ietf.org; Mon, 07 May 2007 12:05:47 -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 l47G5iEM018956; Mon, 7 May 2007 12:05:46 -0400 (EDT) Received: (from chiron [132.250.93.53]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007050712054520150 ; Mon, 07 May 2007 12:05:45 -0400 From: "Jeff Weston" To: "'Charles E. Perkins'" References: <018801c78d8c$b246a2e0$355dfa84@chiron> <463A48D0.3020006@nokia.com> <000001c78df3$c7fdd920$6601a8c0@morpheus> <463BA25B.5040107@nokia.com> <01d201c790ab$76d757a0$355dfa84@chiron> <463F4042.90909@nokia.com> Subject: RE: [Manet-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID Date: Mon, 7 May 2007 12:03:37 -0400 Message-ID: <01d701c790c1$45bf47c0$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: AceQuUOMd9W9MXGHQs+JICuadAvojwAAIXBA In-Reply-To: <463F4042.90909@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 > - Source is in charge of making packets > distinguishable by way of a hash function. > - Every node suppressing duplicates uses the > same hash function. Thus, if the source > ensures that packets are distinguished, no > other node (regardless of history) will have > a problem with this. This is the part where I'm having the problem. I guess I'm thinking about this from an implementation perspective... -In order for a source to ensure that the packets are distinguishable via a hash, it must store a history of hashes to compare against. -In order for the program to work for any length of time, the source must have some sort of limited queue of hashes, as it cannot store an infinite number of them. -Therefore, the source cannot ensure that a given packet will not have a hash conflict with ANY packet it has sent; the source can only ensure that there will be no conflict with any hash within its limited history. -Thus, whether the source's limited history matches up with (or at least includes all of) its forwarders' limited history, IS important. I had assumed this would most likely be implemented as a memory-based FIFO queue (always store X hashes from each source), which would introduce a problem in which forwarders (having a similarly limited history) would have a history of hashes (from not receiving some packets due to collisions, limited TTL packets, etc.) that the source had already purged from memory, and was therefore unable to compare against. This was the issue I was trying to get you to see (particularly since duplicate IPv6 packets are not uncommon with some applications). I suppose it's possible that you could have a sort of time-based FIFO queue (store all hashes for the last X seconds from each source), rather than a simple memory-based FIFO. This would effectively avoid the history mismatch problem (assuming all nodes agree on the number of seconds), but it forces you to keep more state (e.g. a timestamp w/ each hash), and would likely lead to high memory usage with fast data flows. -Jeff _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 07 12:25: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 1Hl61o-0006YG-RR; Mon, 07 May 2007 12:25:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hl61n-0006YB-DI for manet-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 12:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl61n-0006Y3-3r for manet@ietf.org; Mon, 07 May 2007 12:25:35 -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 1Hl61l-0006vI-Jq for manet@ietf.org; Mon, 07 May 2007 12:25:35 -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 l47GPUA3009431; Mon, 7 May 2007 19:25:31 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 19:25:26 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 11:25:23 -0500 Received: from [10.162.27.48] ([10.162.27.48]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 11:25:22 -0500 Message-ID: <463F52ED.5060502@nokia.com> Date: Mon, 07 May 2007 09:25:17 -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-dt] Re: [manet] Need for DPD header (SMF document discussion) - ValidReason for Tagger ID References: <018801c78d8c$b246a2e0$355dfa84@chiron> <463A48D0.3020006@nokia.com> <000001c78df3$c7fdd920$6601a8c0@morpheus> <463BA25B.5040107@nokia.com> <01d201c790ab$76d757a0$355dfa84@chiron> <463F4042.90909@nokia.com> <01d701c790c1$45bf47c0$355dfa84@chiron> In-Reply-To: <01d701c790c1$45bf47c0$355dfa84@chiron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 May 2007 16:25:22.0770 (UTC) FILETIME=[4FA74320:01C790C4] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: >> - Source is in charge of making packets >> distinguishable by way of a hash function. >> - Every node suppressing duplicates uses the >> same hash function. Thus, if the source >> ensures that packets are distinguished, no >> other node (regardless of history) will have >> a problem with this. >> > > This is the part where I'm having the problem. I guess I'm thinking about this from an implementation perspective... > That is also how I am thinking about the problem. > -In order for a source to ensure that the packets are distinguishable via a hash, it must store a history of hashes to compare > against. > Check. > -In order for the program to work for any length of time, the source must have some sort of limited queue of hashes, as it cannot > store an infinite number of them. > Check. > -Therefore, the source cannot ensure that a given packet will not have a hash conflict with ANY packet it has sent; the source can > only ensure that there will be no conflict with any hash within its limited history. > Check. > -Thus, whether the source's limited history matches up with (or at least includes all of) its forwarders' limited history, IS > important. > Check. > I had assumed this would most likely be implemented as a memory-based FIFO queue (always store X hashes from each source), which > would introduce a problem in which forwarders (having a similarly limited history) would have a history of hashes (from not > receiving some packets due to collisions, limited TTL packets, etc.) that the source had already purged from memory, and was > therefore unable to compare against. If the source produces enough packets to swamp its queue, within the time during which we want to consider packets to be live in the network, then the source can add the new header. > This was the issue I was trying to get you to see (particularly since duplicate IPv6 packets > are not uncommon with some applications). > This is the issue that has been explained to me repeatedly and over and over again, iteratively, and etc. :-) > I suppose it's possible that you could have a sort of time-based FIFO queue (store all hashes for the last X seconds from each > source), rather than a simple memory-based FIFO. This would effectively avoid the history mismatch problem (assuming all nodes > agree on the number of seconds), but it forces you to keep more state (e.g. a timestamp w/ each hash), and would likely lead to high > memory usage with fast data flows. > I think this tradeoff can be made without a huge expense, and that we can compare the energy utilization of the two schemes. All schemes proposed so far are per source, right? Regarding the timestamp, I can design a scheme for that using only a few bits. There is no need to store a full microsecond-accurate timestamp per entry. Plus, the timestamp would not be needed at all for well behaved sources. Maybe the DPD header should include a bit describing whether the source is well behaved (meaning, MANET-aware and rate-limiting). For such sources, bookkeeping would be minimized. Regards, Charlie P. PS (trivia contest): What is the only word in the English language with three consecutive pairs of double letters? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue May 08 10: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 1HlQbO-00064d-H4; Tue, 08 May 2007 10:23:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HlQbM-00064Y-H5 for manet-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 10:23:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlQbM-00064Q-7Z for manet@ietf.org; Tue, 08 May 2007 10:23:40 -0400 Received: from wx-out-0506.google.com ([66.249.82.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlQbJ-0006Oy-Ns for manet@ietf.org; Tue, 08 May 2007 10:23:40 -0400 Received: by wx-out-0506.google.com with SMTP id h31so1839764wxd for ; Tue, 08 May 2007 07:23:37 -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=lay5HqwvJIokZckWB7xxsa2xB0h2Q3PqqFA+qzxZyM4sFAAZRrz6Aq38TeELYrse4ns7WN/pVWmtRctpeac9uiIuG+22xCVkiGCbRSbhdfttjGG2IgXm/41CbCj6JQNQay0FpUHbUpaCMXWml7fYTBHEhihdfpWgtAW0Ny6z7gk= 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=OdZXwfnOKONUIf9PZeG77FD9c8Q8Llu6vpfAsEAD6zWGGNB7kLys8afL1NNAjP4X2g2C8ImpsZUvWFwrj0RxwIm6ePoje6T+/zojdhck2OEtKgNssqXa+TT6BH8SdDchjAyJqSTXRg7cthqpcY1ZCeQ9vQ4GHMmJi3JMC84omlc= Received: by 10.90.70.10 with SMTP id s10mr6207798aga.1178634217175; Tue, 08 May 2007 07:23:37 -0700 (PDT) Received: by 10.90.117.19 with HTTP; Tue, 8 May 2007 07:23:37 -0700 (PDT) Message-ID: Date: Tue, 8 May 2007 10:23:37 -0400 From: "Jinhua Guo" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Subject: [manet] CFP: IEEE MHWMN'07 -- Deadline: May 15 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="===============1247408566==" Errors-To: manet-bounces@ietf.org --===============1247408566== Content-Type: multipart/alternative; boundary="----=_Part_23855_13591834.1178634217127" ------=_Part_23855_13591834.1178634217127 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--- ***** Third 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_23855_13591834.1178634217127 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---

***** Third 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_23855_13591834.1178634217127-- --===============1247408566== 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 --===============1247408566==-- From manet-bounces@ietf.org Tue May 08 19:29: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 1HlZ7Y-0008VB-KM; Tue, 08 May 2007 19:29:28 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HlZ7X-0008V5-1G for manet-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 19:29:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZ7W-0008Uv-Nk for manet@ietf.org; Tue, 08 May 2007 19:29:26 -0400 Received: from mail.ece.gatech.edu ([143.215.151.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlZ7U-0003n4-92 for manet@ietf.org; Tue, 08 May 2007 19:29:26 -0400 Received: from gc556bwnlap07 (c-24-131-45-131.hsd1.ga.comcast.net [24.131.45.131]) (authenticated bits=0) by mail.ece.gatech.edu (8.14.0/8.13.7) with ESMTP id l48NSB2l005532 for ; Tue, 8 May 2007 19:28:15 -0400 (EDT) From: "Dario Pompili" To: Date: Tue, 8 May 2007 19:28:54 -0400 Message-ID: <014701c791c8$aa2dbf40$6601a8c0@ece.gatech.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceRyEA2Tdi7dmaWSKaEjQcFLRKwoQAAAnagAAAT7mA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-PMX-Version: 5.3.1.294258, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.5.8.160545 X-PerlMx-Spam: Gauge=XXII, Probability=22%, Report='RELAY_IN_PBL_10 2.5, RDNS_BROADBAND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, RELAY_IN_PBL 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RDNS_BROADBAND_4 0, __RDNS_POOLED_10 0, __SANE_MSGID 0, __USER_AGENT_MS_GENERIC 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Subject: [manet] CFP: The Second ACM International Workshop on UnderWater Networks (WUWNet 2007) - Submission deadline (EXTENDED): May 18, 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 [We apologize in advance if you receive multiple copies of this CFP] __________________________________________________________________________ __________________________________________________________________________ The Second ACM International Workshop on UnderWater Networks (WUWNet 2007) http://wuwnet07.engr.uconn.edu/ In conjunction with ACM MobiCom 2007 September 14, 2007 Montreal, Quebec, Canada Sponsored by ACM SIGMOBILE __________________________________________________________________________ __________________________________________________________________________ Overview & Scope **************** The oceans cover 71% of the earth's surface and represent one of the least explored frontiers, yet the oceans are integral to climate regulation, nutrient production, oil retrieval and transportation. As such, there is significant interest in monitoring aquatic environments for scientific, environmental, commercial, safety, and military reasons. While there is a need for highly precise, real-time, fine grained spatio-temporal sampling of the ocean environment, current methods such as remote telemetry and sequential local sensing cannot satisfy current needs, let alone future needs. The notion of an underwater network is relatively new due to the lack of maturity of underwater acoustic communication. However, networks are critical in order to achieve the monitoring goals noted above. The physical challenges of acoustic underwater communication and the complexity of diverse aquatic environments require us to completely re-think how a network should be deployed in underwater environments. Challenges to be overcome by underwater acoustic modem and network designers include: severely limited range-dependent bandwidth and attenuation, extensive time-varying multi-path propagation, and low speed of sound propagation in water resulting in long propagation delays. Moreover, a unique feature of underwater networks is that nodes can passively move due to water currents and dispersion. All the above distinct features of underwater networks yield grand challenges for every level of the network protocol suite. The goal of the proposed workshop is to bring together researchers and practitioners in areas relevant to underwater networks. Thus, many layers of the "stack" from the physical layer to the application layer will be represented. The objective is to serve as a forum for presenting state of the art research, exchanging ideas and experiences, and facilitating interaction and collaboration. The workshop will span one day, including presentations of technical papers, keynote speeches, a panel session and a poster/demo session. Submissions for technical papers should describe original research, not published or currently under review for other workshops, conferences, or journals. Topics include, but are not limited to: - Network architecture design - Efficient acoustic communications - Cooperative underwater communications - Medium access control - Routing and forwarding - Reliable data transfer - Security and robustness - Data storage and management - Power and resource management - Localization and synchronization - Data fusion, dissemination, tracking - Network modeling and simulations - Network planning and deployment - New techniques for aquatic applications - New applications for underwater networks - Testbed and systems: real-world experiences and lessons Submission Guidelines ********************* All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 8 pages for full papers (4 pages for short papers), and must follow ACM single-space, double-column format, 10 pt. Submitted papers will be judged based on their quality and novelty through a rigorous review process. All accepted papers will appear in the workshop proceedings. Detailed instructions for paper submission will be posted on the workshop website. Important Dates *************** Submission deadline (EXTENDED): May 18, 2007 Acceptance notification: June 16, 2007 Camera-ready version due: June 30, 2007 Workshop date: September 14, 2007 Organizing Committee ******************** General Co-Chairs: Ian F. Akyildiz (Georgia Institute of Technology) David Hung-Chang Du (University of Minnesota/NSF) Technical Program Co-Chairs: Robert H. Headrick (Office of Naval Research) Michele Zorzi (University of Padova, Italy) WUWNet Steering Committee: Ian F. Akyildiz (Georgia Institute of Technology) Jun-Hong Cui (University of Connecticut, Chair) David Hung-Chang Du (University of Minnesota/NSF) Kevin Fall (Intel Research, Berkeley) John Heidemann (University of Southern California/ISI) Urbashi Mitra (University of Southern California) Milica Stojanovic (Massachusetts Institute of Technology) Publicity Co-Chairs: Qilian Liang (University of Texas at Arlington) Dario Pompili (Georgia Institute of Technology) Work-In-Progress Poster Co-Chairs: Volkan Rodoplu (University of California at Santa Barbara) Wei Ye (University of Southern California/ISI) Demo Co-Chairs: Payman Arabshahi (University of Washington) Geoffrey Xie (Naval Postgrad School) Finance Chair: Shengli Zhou (University of Connecticut) Technical Program Committee (incomplete) **************************************** Jun-Hong Cui (University of Connecticut) Kevin Fall (Intel Research, Berkeley) Joo Pedro Gomes (Instituto Superior Tecnico, Portugal) Al Harris (University of Illinois at Urbana-Champaign) Brian Levine (University of Massachusetts) Urbashi Mitra (University of Southern California) James Preisig (Woods Hole Oceanographic Institution (WHOI)) Robert Qiu (Tennessee Technological University) Volkan Rodoplu (University of California, Santa Barbara) Sumit Roy (University of Washington) Winston Seah (Institute for Infocomm Research, Singapore) Milica Stojanovic (Massachusetts Institute of Technology) Yang Xiao (University of Alabama) Wei Ye (University of Southern California/ISI) ********************************************* Dario Pompili, Ph.D. Broadband & Wireless Networking Laboratory School of Electrical & Computer Engineering Georgia Institute of Technology, Atlanta, GA Email: dario@ece.gatech.edu http://users.ece.gatech.edu/dario/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue May 08 21:07: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 1Hladt-000672-P7; Tue, 08 May 2007 21:06:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hlads-00066x-JT for manet-confirm+ok@megatron.ietf.org; Tue, 08 May 2007 21:06:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlads-00066p-9n for manet@ietf.org; Tue, 08 May 2007 21:06:56 -0400 Received: from a2s13.a2hosting.com ([69.39.88.160]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hladr-0008Ap-UW for manet@ietf.org; Tue, 08 May 2007 21:06:56 -0400 Received: from a2s13.a2hosting.com ([69.39.88.160] helo=[127.0.0.1]) by a2s13.a2hosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Hladq-00020h-7H for manet@ietf.org; Tue, 08 May 2007 21:06:54 -0400 Message-ID: <46411EA5.2070105@acm.org> Date: Tue, 08 May 2007 17:06:45 -0800 From: Ken Laberteaux User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: manet@ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: multipart/mixed; boundary="------------020800080405070302090507" X-A2hosting-MailScanner-Information: Please contact the ISP for more information X-A2hosting-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-A2hosting-MailScanner-SpamCheck: X-A2hosting-MailScanner-From: klaberte@acm.org X-Spam-Status: No X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a2s13.a2hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - acm.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [manet] Reminder: VANET 2007 Submissions due May 14 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 is a multi-part message in MIME format. --------------020800080405070302090507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --------------020800080405070302090507 Content-Type: text/plain; name="VANET-2007-CFP.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="VANET-2007-CFP.txt" ANNOUNCEMENT and CALL FOR PAPERS VANET 2007 The Fourth ACM International Workshop on Vehicular Ad Hoc Networks In conjunction with ACM MobiCom 2007 September 10, 2007 Montréal, QC, Canada Sponsored by ACM SIGMOBILE http://www.sigmobile.org/workshops/vanet2007/ Important Dates: Paper Submission Deadline: May 14, 2007, 11:59 p.m. GMT Notification of Acceptance: June 18, 2007 Camera-Ready Deadline: July 16, 2007 The goal of this workshop is to present and discuss recent advances in the development of wireless vehicular ad hoc networking (VANET) technologies. Based on short- to medium-range communication systems (vehicle-to-vehicle and vehicle-to-roadside), vehicular ad hoc networks will enable vehicular safety applications (including collision and other safety warnings) as well as non-safety applications (like real-time traffic congestion and routing information, high-speed tolling, mobile infotainment, and many others). The creation of high-performance, highly reliable, highly scalable, and secure VANET technologies presents an extraordinary challenge for the wireless research community. A high degree of communication reliability is needed under unfavorable conditions. Clearly, the specificity of vehicular ad hoc networks in terms of mobility behavior and applications scenarios and requirements makes VANET research an exciting and demanding application- and purpose-driven sub-discipline of wireless networking. Following the successes of VANET 2004 held in Philadelphia, VANET 2005 held in Cologne, Germany, and VANET 2006 in Los Angeles, CA, the Fourth ACM International Workshop on Vehicular Ad Hoc Networks (VANET) will be held in Montréal, QC, Canada September 14, 2007, in conjunction with MobiCom 2007. Authors are invited to submit papers presenting new research related to the theory or practice of vehicular ad hoc networks (VANET). 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: - Safety and non-safety applications - Roadside-to-vehicle and vehicle-to-vehicle communication - Communication protocol design - Channel modeling - Modulation and coding - Power control and scalability issues - Multi-channel organization and operation - Security issues and countermeasures - Privacy issues - Network management - Simulation frameworks & real-world testbeds VANET present a highly active field of research, development, standardization and field trials. Throughout the world, there are many national/international projects in government, industry, and academia devoted to VANET. These include the consortia like Vehicle Safety Consortium (US), Car-2-Car Communication Consortium (Europe) and Advanced Safety Vehicle Program (Japan), standardization efforts like IEEE 802.11p (WAVE), and field trials like the large-scale Vehicle Infrastructure Integration Program (VII) in the US. Submission Instructions All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 10 pages (single- or double-column), in font no smaller than 11 points, and must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Submitted papers will be judged based on their quality through a double-blind review process, where the identities of the authors are withheld from the reviewers. Detailed instructions for paper submission will be posted on the VANET 2007 web page at: http://www.sigmobile.org/workshops/vanet2007/. General Co-Chairs: Wieland Holfelder, DaimlerChrysler REDNA Paolo Santi, Italian Natl. Research Council Technical Program Co-Chairs: Yih-Chun Hu, University of Illinois at Urbana-Champaign Jean-Pierre Hubaux, EPFL Web Chair: Ken Laberteaux, Toyota Technical Center Technical Program Committee (partial list): Victor Bahl, Microsoft Research Fan Bai, General Motors Levente Buttyan, Budapest University of Technology and Economics Tracy Camp, Colorado School of Mines Eylem Ekici, Ohio State University Tamer ElBatt, San Diego Research Center Andreas Festag, NEC Europe Ltd Hannes Hartenstein, University of Karlsruhe Wieland Holfelder, DaimlerChrysler REDNA Yih-Chun Hu, University of Illinois at Urbana-Champaign Jean-Pierre Hubaux, EPFL Markus Jakobsson, Indiana University Daniel Jiang, DaimlerChrysler REDNA Frank Kargl, Ulm University Timo Kosch, BMW Ken Laberteaux, Toyota Technical Center Martin Mauve, Heinrich Heine University Düsseldorf Christof Paar, Ruhr-University Bochum Panos Papadimitratos, EPFL Adrian Perrig, Carnegie Mellon University Maxim Raya, EPFL Paolo Santi, CNR Rajeev Shorey, General Motors Research Pravin Varaiya, University of California at Berkeley --------------020800080405070302090507 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 --------------020800080405070302090507-- From manet-bounces@ietf.org Wed May 09 16:32: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 1Hlspb-0004I4-5p; Wed, 09 May 2007 16:32:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HlspZ-0004Hz-QC for manet-confirm+ok@megatron.ietf.org; Wed, 09 May 2007 16:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlspZ-0004Hr-Gi for manet@ietf.org; Wed, 09 May 2007 16:32:13 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlspY-0004rr-AC for manet@ietf.org; Wed, 09 May 2007 16:32: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 l49KW9ZE014884 for ; Wed, 9 May 2007 16:32:10 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007050916320931919 for ; Wed, 09 May 2007 16:32:09 -0400 From: "Joe Macker" To: "'manet'" Date: Wed, 9 May 2007 16:32:06 -0400 Message-ID: <001d01c79279$1c83db50$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: AceSeRxstGJVzAAsTNKxgDLaz0Nmqg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [manet] SMF ID Way Forward 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 Since we have lively debates on hashing vs. explicit DPDs here is the way forward we have come up with. ------------------------ Here is my proposal for a way forward. The proposal is to include direct hashing support and design discussion. We have ideas for short header options to support this as well. I think we can make an upgrade to SMF to support a hashing DPD approach and move to EXP submission consideration within a few months. I want it to be clear I WANT to update the specification to support hashing more directly (it reads very vague right now) even thought this slows things down I am ok with that because it makes sense. Also, although it presently supports hashing in concept the language in the spec is overly negative in this regard. We should remove this and also have a method to support it more directly. At the same time, we plan to preserve explicit DPD specification and operation. Nothing wrong with that for EXP in my opinion. ------------------------ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu May 10 10:50: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 1Hm9y9-0007yM-Mo; Thu, 10 May 2007 10:50:13 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hm9y4-0007qn-6T for manet-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 10:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm9y3-0007od-2n; Thu, 10 May 2007 10:50:07 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm9xz-0006ig-MI; Thu, 10 May 2007 10:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 1FC8E329FA; Thu, 10 May 2007 14:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hm9xy-0002iU-14; Thu, 10 May 2007 10: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: Thu, 10 May 2007 10: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-02.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-02.txt Pages : 7 Date : 2007-5-10 This document enumerates IANA assignments for use by MANET WG protocols. 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-02.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-02.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-02.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-5-10095346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-iana-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-iana-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-10095346.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 Thu May 10 19: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 1HmINz-0006j3-2L; Thu, 10 May 2007 19:49:27 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HmINy-0006iy-8Q for manet-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 19:49:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmINx-0006iq-V1 for manet@ietf.org; Thu, 10 May 2007 19:49:25 -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 1HmINx-0002wx-5Y for manet@ietf.org; Thu, 10 May 2007 19:49:25 -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 l4ANnBoq003778; Fri, 11 May 2007 02:49:20 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 02:48:19 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 18:48:17 -0500 Received: from [10.162.75.160] ([10.162.75.160]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 18:48:16 -0500 Message-ID: <4643AF39.9080106@nokia.com> Date: Thu, 10 May 2007 16:48:09 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Thomas Heide clausen , chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2007 23:48:16.0699 (UTC) FILETIME=[AE3048B0:01C7935D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: Manet Subject: [manet] Comments about draft-ietf-manet-packetbb-04 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, Herewith, some comments on the PacketBB document. I didn't go through the appendices yet, sigh... ================================================ Somewhere, the document should explain why the "bb". > o A message header format containing *all* necessary information to > allow a node to make forwarding decisions without inspecting and > processing the message body. Message header information permits > single- and multi-hop message diffusion. Should clarify this only affects packets with TTL > 1. The statement is also incorrect if it is interpreted to mean that the node's present state cannot be used in the forwarding decision. > The specification has been explicitly designed with the following > properties in mind: One of the design goals ought to be compact header size, in general -- not just for address representations. > Parsing logic - the regular expression specification facilitates > generic, protocol independent, parsing logic. If, by putting this first, it is elevated to prime importance, then I think the design goals have the wrong priority. It should be a goal, but considerably less important than efficiency of representation or actual processing. Parsing is a smaller part. > ... Full backward compatibility can be > maintained. Backward compatibility to what? > Packet - the top level entity in this specification. Packets are > transmitted over a single logical hop and are not forwarded. A > packet contains zero or more messages, and may contain a packet > header. When do we need to transmit a packet with zero messages? > Address - an address of the same length as the source IP address in > the IP datagram carrying the packet. I don't see the point of making the definition this way. People reading the spec are likely to have encountered IP addresses before, and would be familiar with the concept of a network-layer address. Plus, I can imagine mixed-mode systems where IPv6 and IPv4 nodes share routing responsibilities, even though we are not designing those systems today. > The specification is designed specifically with IP (IPv4/IPv6) in > mind. All addresses within a control message are assumed to be of > the same size, deduced from IP. In the case of mixed IPv6 and IPv4 > addresses, IPv4 addresses are carried in IPv6 as specified in [2]. The first sentence I like. The second restriction is chancy, as I just mentioned. The third restriction could lead to ambiguities, I think... > ........ transport mechanism (unicast, multicast) I never heard these called "transport mechanisms" before. Aren't they really different modes of network addressability? > .......... it will employ. What is "it"? The "protocol"? Does it mean that the document specifies features that may be prohibited for use by some protocols designed according to the specification? Just checking! > = {*}? > {*}* > > where is defined in Section 5.2, and is defined > in Section 5.4. The packet is parsed until all octets are used. The last sentence imposes an unnecessary restriction. Some packets should be dropped before parsing is complete. And, what if the packet is unparseable? > bit 0 (pnoseqnum): if cleared ('0'), then the packet header > contains a . If set ('1'), then the packet > header does not include a . > > bit 1 (ptlv): if cleared ('0'), then the packet header does not > include a TLV block. If set ('1'), then the packet header > includes a TLV block. It is curious, and less than desireable, that the senses of these two flags are inverted relative to each other. However, it is not incorrect -- except insofar as it makes people more likely to make mistakes from strained memory. > is an 8 bit field, specifying the type of message. A > type with all bits cleared ('0') MUST NOT be used. You can just say that type 0 (zero) is RESERVED. > is a 16 bit field, specifying the size of the , > counted in octets. This would be a possible use of another bit in the msg-semantics field, which would say whether or not the msg-size were 8 or 16 bits. It is to be hoped that most kinds packetbb messages would be usually be less than 256 bytes long, so it would be nice if the specification supported that case. > is an 8 bit field, which contains the maximum number of > logical hops a message should be further transmitted. > > is an 8 bit field, which contains the number of logical > hops a message has traveled. I can well imagine protocol messages which would not need both of these fields. >
is defined by: > > = > > ? > ? > ? > ? > * This construction assumes that most address information will be transmitted in blocks of aggregated addresses. As we have discussed many times in the past, the value of the given scheme is questionable if most addresses are really singletons from an effectively flat address space. This is the case for the overwhelming majority of times in my experience. One way around this would be to have two kinds of
s: one, as given above, and another trivial one just consisting of the unadorned and unpartitioned address. I thought about developing a simple expression for the overhead, depending on the expected number of addresses that can be aggregated, but it is really just an exercise. However, for the case of unaggregated IPv4 addresses, the overhead from the address block mechanism as given, is 50%. That can make a difference. In many cases, the number of addresses in the message (disregarding extensions) is fixed by the message type, enabling a very compact representation overall. How about if we put another bit into the which would enable the simple
variant? Aside from this case which is the majority case in my experience, I think the given format seems to work well for addresses that can be aggregated. However, it is to be noted that, for instance, AODV handles address aggregation by another mechanism entirely. > mid-length is a variable, which MUST be non-negative, defined by: Is there some field here which is signed? What does this mean? > is a 16 bit field I hope most s will be shorter than 256 bytes, so this could be considered overkill. I am constantly reminded that our results show over and over again that extra bytes really correlate well with reduced protocol performance, so I look for ways to make savings especially in crucial systemic protocol elements such as this. If there is a where the fields add up to more than 256 (wow!) wouldn't it be better to just define a "continuation" for that case? Or, did I misinterpret, and is intended to include the length of ? In that case, my comments still apply, but I would prefer having a way to determine whether or not the was of the long or the short variety, perhaps based on the type. > Two or more TLVs of the same type associated with the same address > block MUST NOT both cover any address. I do not understand the reasoning behind this constraint. What if TLVs specify link characteristics, and we want to know more than one characteristic about some links (i.e., some pairs of addresses)? > Packet headers and messages can be padded to ensure 32 bit alignment Packet headers and messages MAY be padded to ensure 32 bit alignment > Message type 0 MUST NOT be allocated because a zero-octet signifies a > packet header and zero-octets are used for padding. Message types 1 > to 4 are reserved because they are used by OLSR [4], which uses a > compatible packet/message header format. I don't think IANA cares what type 0 signifies. Why not just make it RESERVED? It would be better to put into the OLSR document a part of the IANA considerations to reserve the four message types, and delete the discussion in the PacketBB document. Why isn't Table 7 close to the paragraph about address blocks? >8. Security Considerations > > Messages are designed to be carriers of protocol information and MAY, I don't think MAY is supposed to be used this way. > ............... Since count> and are the only fields that may be modified when > such a message is forwarded, this signature can be calculated based Really? What about current estimates of cost, stability, delay, ...? Or, is this discussion only valid "If forwarded messages are unchanged by this protocol," ? Furthermore, I reckon "end-to-end security MAY be implemented" in many ways. Again, this seems to be a wrong use of "MAY". Also, "Hop-by-hop packet level security MAY be implemented" could, presumably, be implemented using IPsec. Or am I missing something...? ================================================ Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu May 10 23:33: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 1HmLsL-0003uN-1N; Thu, 10 May 2007 23:33:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HmLsJ-0003uI-LV for manet-confirm+ok@megatron.ietf.org; Thu, 10 May 2007 23:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmLsJ-0003uA-C4 for manet@ietf.org; Thu, 10 May 2007 23:32:59 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmLsI-00043J-0B for manet@ietf.org; Thu, 10 May 2007 23:32:59 -0400 Received: by ug-out-1314.google.com with SMTP id 72so575155ugd for ; Thu, 10 May 2007 20:32: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:content-transfer-encoding:content-disposition; b=iLORrx7WhE5DUVU9UU2yg0eweA5g1Yo0QUqYfJgMGkVGUXYWHDbp0aavnvHuFpTXrRvt7dBdgfabCFyidSJVvA5gtygz/VFJVBqInKpaHRtozXC0sw/++zmHQlKX/gRP/mSQ+T0+KIWlZt+XLBl74IsOzyU7HX87en2eKZrddkM= 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=f13rJyqjf+RZhCh15lMpHH8rANcVCBKUmytRykerkDcvOH1oSSTlLNWSxOU7yPDFKfoxSHjOaKgZllV5+ovoPSocEjiWK6E6x4J7iUqIxmjYNPykC0L7uF+SaiF6eDolKEDLxklE2KJZh9+36zQEC2LO780qWUTU/Syh6+IgILs= Received: by 10.78.183.15 with SMTP id g15mr617448huf.1178854377080; Thu, 10 May 2007 20:32:57 -0700 (PDT) Received: by 10.78.18.18 with HTTP; Thu, 10 May 2007 20:32:57 -0700 (PDT) Message-ID: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> Date: Fri, 11 May 2007 09:02:57 +0530 From: "Ian Chakeres" To: manet@ietf.org Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-02.txt & WGLC 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: d185fa790257f526fedfd5d01ed9c976 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 to review this new revision. I'm also reissuing WGLC. Here is a summary of the main changes: The draft has been revised to state clearly that a well-known UDP port, LL multicast addresses, and SL multicast addresses are required by the MANET WG. I tried to remove any text specifying operational requirements/advice related to these well-known values, as this type of discussion belongs in the protocol specifications. I choose to leave the site-local multicast addresses. This topic has been discussed several times on the list and I believe there is consensus that we should allocate these (IPv4/IPv6) addresses. Please sent any questions/comments to the list. Ian Chakeres On 5/10/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-02.txt > Pages : 7 > Date : 2007-5-10 > > This document enumerates IANA assignments for use by MANET WG > protocols. 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-02.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-02.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-02.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 Fri May 11 04:53: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 1HmQrv-0004tk-EQ; Fri, 11 May 2007 04:52:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HmQrt-0004tY-Ce for manet-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 04:52:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmQrq-0004qr-3E for manet@ietf.org; Fri, 11 May 2007 04:52:50 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmQrp-0004Lf-Lj for manet@ietf.org; Fri, 11 May 2007 04:52:50 -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 l4B8qmHb023695 for ; Fri, 11 May 2007 09:52:48 +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 l4B8qlr2032040 for ; Fri, 11 May 2007 09:52:47 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 11 May 2007 09:52:47 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Fri, 11 May 2007 09:50:03 +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 Date: Fri, 11 May 2007 09:49:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments about draft-ietf-manet-packetbb-04 Thread-Index: AceTXdjNa5G6mxbZSu2dUR5uO3zm2QAR051g From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" , "Thomas Heide clausen" , X-OriginalArrivalTime: 11 May 2007 08:50:04.0121 (UTC) FILETIME=[5E1F3C90:01C793A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Manet Subject: [manet] RE: Comments about draft-ietf-manet-packetbb-04 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 Some comments on a few of Charlie's comments. > When do we need to transmit a packet with zero messages? If someone wants to send just a packet TLV. I don't have a use for it right now, but it's trivial to permit and harmless. > You can just say that type 0 (zero) is RESERVED. No. RESERVED suggests it could be used sometime in the future. Using type zero breaks the format - it leads to parsing ambiguity. So we want to make it absolutely clear it is not used, cannot be used, will never be used in the future, MUST NOT be used. > However, for the case of unaggregated > IPv4 addresses, the overhead from the address block > mechanism as given, is 50%. If you are creating address blocks each with one address in them. Why would you do that? If efficiency is your goal, don't do that. Make one address block with a single one-off 2 octet overhead for all addresses. > Or, did I misinterpret, and is intended > to include the length of ? is the total length of all TLVs in the block, not just a single TLV. That includes all types, semantics, indices, lengths and values. Each individual TLV has a semantics bit to indicate if it has a 0, 8 or 16 bit value length. But there's no point having a TLV block semantics octet as that costs the octet you are trying to save. > Packet headers and messages MAY be padded to ensure 32 bit alignment Good catch. Thanks. Ditto in security considerations I think (I haven't checked). > It would be better to put into the OLSR document a part > of the IANA considerations to reserve the four message > types, and delete the discussion in the PacketBB document. I don't agree. With regard to the rest of Charlie's comments, they include some changes to substance, rather than wording which could be done. (But aren't the only things that could be done - some going in the opposite direction.) I don't agree with them, not because they have no merit but because I (and, recognising reality, the company that pays me) have as highest priority getting this published as soon as possible, and with minimal changes. I've said before, there are tradeoffs here and we've made some. Are they perfect? I'm not claiming that, but rather that "the best is the enemy of the good" (which Googling tells me is Voltaire). Although in many cases I'd argue against them being best too. ******************************************************************** 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 Fri May 11 06:29: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 1HmSNa-0006yF-Qo; Fri, 11 May 2007 06:29:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HmSNY-0006tZ-VL for manet-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 06:29:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmSNY-0006tR-Ln for manet@ietf.org; Fri, 11 May 2007 06:29:40 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmSNX-00027M-VU for manet@ietf.org; Fri, 11 May 2007 06:29:40 -0400 Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp7-g19.free.fr (Postfix) with ESMTP id BEC7E18302; Fri, 11 May 2007 12:29:38 +0200 (CEST) Message-ID: <46444592.6080605@gmail.com> Date: Fri, 11 May 2007 12:29:38 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: site-scoped IPv6 multicast address (was: [manet] I-D ACTION:draft-ietf-manet-iana-02.txt & WGLC) References: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> In-Reply-To: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-2, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 Ian Chakeres wrote: > I'd like to ask people to review this new revision. I'm also > reissuing WGLC. > > Here is a summary of the main changes: > > The draft has been revised to state clearly that a well-known UDP > port, LL multicast addresses, and SL multicast addresses are required > by the MANET WG. > > I tried to remove any text specifying operational requirements/advice > related to these well-known values, as this type of discussion > belongs in the protocol specifications. > > I choose to leave the site-local multicast addresses. This topic has > been discussed several times on the list and I believe there is > consensus that we should allocate these (IPv4/IPv6) addresses. What exactly is the need of a MANET protocol for a _site-local_ IPv6 multicast address? How is that need different from existing routing protocols (I'm asking because no existing routing protocol uses a _site-local_ IPv6 multicast address). Why can't a MANET routing protocol use an IPv6 multicast address with a scope non-permanently assigned (like ff15) or with Internet scope (like ff0e). In my oppinion a MANET routing protocol has no special needs for _site-local_ multicast addresses (although it may need IPv6 multicast addresses with larger than link). Because the definition of a 'site' is very vague in the static (non-MANET) world and has no meaning in a MANET environment. Alex > > Please sent any questions/comments to the list. Ian Chakeres > > On 5/10/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-02.txt Pages : 7 >> Date : 2007-5-10 >> >> This document enumerates IANA assignments for use by MANET WG >> protocols. 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-02.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-02.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-02.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 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 11 07:10: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 1HmT14-00089x-5r; Fri, 11 May 2007 07:10:30 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HmT12-00089s-Fo for manet-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 07:10:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmT12-00089k-6I for manet@ietf.org; Fri, 11 May 2007 07:10:28 -0400 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmT10-0007iK-Pk for manet@ietf.org; Fri, 11 May 2007 07:10:28 -0400 Received: by wr-out-0506.google.com with SMTP id 71so944550wri for ; Fri, 11 May 2007 04:10: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=KnspXq7njMNtpaQaaw1SQXhPvWnRdnQJeGxorJ8kGIAHC05UhfzLMbuMduDFRYwtX0XY5E7PozGXswoAC4HZ+SI3hX9FwwKkdz49TliZQb2cz81gpHa0iOk+qdZ4vrh1nYyHaGki8zHNjVUJhx9OuYMw1Q8UNhFr54OixJwWlgs= 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=l6+BzqBJCpgz2ZRzrnRaWn5HyZY5EBDj/x8cIXf1ZGo/NYPBPptv56gaqCebjzsINXw/PwXmYtJMSbocC1j8j52u9h/3+QkACl724LlJMh9F9a4B3D2DsXa3m/YtgYxsNVYgqCw9PC6v/raNLaRkXuhfgMsWfgnLk98SD8HEY/g= Received: by 10.78.97.7 with SMTP id u7mr760762hub.1178881825548; Fri, 11 May 2007 04:10:25 -0700 (PDT) Received: by 10.78.33.14 with HTTP; Fri, 11 May 2007 04:10:25 -0700 (PDT) Message-ID: <374005f30705110410n285728adge4166f82c6888889@mail.gmail.com> Date: Fri, 11 May 2007 16:40:25 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: site-scoped IPv6 multicast address (was: [manet] I-D ACTION:draft-ietf-manet-iana-02.txt & WGLC) In-Reply-To: <46444592.6080605@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> <46444592.6080605@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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 is agreement that we need a well-known multicast address with a scope larger than link. I believe that site scoping is the closest match with the expressed need. Using a non scoped address could cause leakage of manet routing packets into the greater Internet. I would not mind switching the text from site-scope to variable scope (assignment at all scopes). Do you think this would be better fit? There are a large list of protocols & assignments for variable scoping. http://www.iana.org/assignments/ipv6-multicast-addresses This scoping assignment includes "DVMRP on MOSPF", a multicast routing protocol. Ian Chakeres On 5/11/07, Alexandru Petrescu wrote: > Ian Chakeres wrote: > > I'd like to ask people to review this new revision. I'm also > > reissuing WGLC. > > > > Here is a summary of the main changes: > > > > The draft has been revised to state clearly that a well-known UDP > > port, LL multicast addresses, and SL multicast addresses are required > > by the MANET WG. > > > > I tried to remove any text specifying operational requirements/advice > > related to these well-known values, as this type of discussion > > belongs in the protocol specifications. > > > > I choose to leave the site-local multicast addresses. This topic has > > been discussed several times on the list and I believe there is > > consensus that we should allocate these (IPv4/IPv6) addresses. > > What exactly is the need of a MANET protocol for a _site-local_ IPv6 > multicast address? How is that need different from existing routing > protocols (I'm asking because no existing routing protocol uses a > _site-local_ IPv6 multicast address). > > Why can't a MANET routing protocol use an IPv6 multicast address with a > scope non-permanently assigned (like ff15) or with Internet scope (like > ff0e). > > In my oppinion a MANET routing protocol has no special needs for > _site-local_ multicast addresses (although it may need IPv6 multicast > addresses with larger than link). Because the definition of a 'site' is > very vague in the static (non-MANET) world and has no meaning in a MANET > environment. > > Alex > > > > > Please sent any questions/comments to the list. Ian Chakeres > > > > On 5/10/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-02.txt Pages : 7 > >> Date : 2007-5-10 > >> > >> This document enumerates IANA assignments for use by MANET WG > >> protocols. 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-02.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-02.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-02.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 > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 11 08:51: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 1HmUb9-00067D-4P; Fri, 11 May 2007 08:51:51 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HmUb7-000674-SY for manet-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 08:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUb7-00066v-Iy for manet@ietf.org; Fri, 11 May 2007 08:51:49 -0400 Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmUb6-0005JR-4E for manet@ietf.org; Fri, 11 May 2007 08:51:49 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id 5502121.28988166; Fri, 11 May 2007 08:51:26 -0400 Message-ID: <464466CE.40003@innovationslab.net> Date: Fri, 11 May 2007 08:51:26 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ian Chakeres References: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> <46444592.6080605@gmail.com> <374005f30705110410n285728adge4166f82c6888889@mail.gmail.com> In-Reply-To: <374005f30705110410n285728adge4166f82c6888889@mail.gmail.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Alexandru Petrescu , manet@ietf.org Subject: [manet] Re: site-scoped IPv6 multicast address 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 First off, I have to echo Alex's concern. Can someone enumerate what the need is for the "greater than link-local" multicast address? Secondly, referencing the DVMRP-over-MOSPF variable scope multicast address doesn't make much sense. That functionality was added to the default list of reserved multicast addresses "just in case". As far as I know no one who still uses DVMRP over MOSPF. Regards, Brian Ian Chakeres wrote: > There is agreement that we need a well-known multicast address with a > scope larger than link. > > I believe that site scoping is the closest match with the expressed need. > > Using a non scoped address could cause leakage of manet routing > packets into the greater Internet. > > I would not mind switching the text from site-scope to variable scope > (assignment at all scopes). Do you think this would be better fit? > > There are a large list of protocols & assignments for variable > scoping. http://www.iana.org/assignments/ipv6-multicast-addresses > > This scoping assignment includes "DVMRP on MOSPF", a multicast routing > protocol. > > Ian Chakeres > > On 5/11/07, Alexandru Petrescu wrote: >> Ian Chakeres wrote: >> > I'd like to ask people to review this new revision. I'm also >> > reissuing WGLC. >> > >> > Here is a summary of the main changes: >> > >> > The draft has been revised to state clearly that a well-known UDP >> > port, LL multicast addresses, and SL multicast addresses are required >> > by the MANET WG. >> > >> > I tried to remove any text specifying operational requirements/advice >> > related to these well-known values, as this type of discussion >> > belongs in the protocol specifications. >> > >> > I choose to leave the site-local multicast addresses. This topic has >> > been discussed several times on the list and I believe there is >> > consensus that we should allocate these (IPv4/IPv6) addresses. >> >> What exactly is the need of a MANET protocol for a _site-local_ IPv6 >> multicast address? How is that need different from existing routing >> protocols (I'm asking because no existing routing protocol uses a >> _site-local_ IPv6 multicast address). >> >> Why can't a MANET routing protocol use an IPv6 multicast address with a >> scope non-permanently assigned (like ff15) or with Internet scope (like >> ff0e). >> >> In my oppinion a MANET routing protocol has no special needs for >> _site-local_ multicast addresses (although it may need IPv6 multicast >> addresses with larger than link). Because the definition of a 'site' is >> very vague in the static (non-MANET) world and has no meaning in a MANET >> environment. >> >> Alex >> >> > >> > Please sent any questions/comments to the list. Ian Chakeres >> > >> > On 5/10/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-02.txt Pages : 7 >> >> Date : 2007-5-10 >> >> >> >> This document enumerates IANA assignments for use by MANET WG >> >> protocols. 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-02.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-02.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-02.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 >> > >> >> > > > _______________________________________________ > manet mailing 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 May 11 12:07: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 1HmXe2-0005f3-VR; Fri, 11 May 2007 12:07:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HmXe1-0005d3-NX for manet-confirm+ok@megatron.ietf.org; Fri, 11 May 2007 12:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXe1-0005cu-Ds for manet@ietf.org; Fri, 11 May 2007 12:07:01 -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 1HmXe0-0000ot-T3 for manet@ietf.org; Fri, 11 May 2007 12:07:01 -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 l4BG6u0l001957; Fri, 11 May 2007 19:06:56 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 19:06:41 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 11:06:37 -0500 Received: from [10.162.70.221] ([10.162.70.221]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 11:06:36 -0500 Message-ID: <46449482.1010207@nokia.com> Date: Fri, 11 May 2007 09:06:26 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ext Dearlove, Christopher (UK)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2007 16:06:36.0658 (UTC) FILETIME=[5A173520:01C793E6] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Thomas Heide clausen , Manet Subject: [manet] Re: Comments about draft-ietf-manet-packetbb-04 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: > >> You can just say that type 0 (zero) is RESERVED. >> > > No. RESERVED suggests it could be used sometime in the future. > Using type zero breaks the format - it leads to parsing > ambiguity. So we want to make it absolutely clear it is not > used, cannot be used, will never be used in the future, > MUST NOT be used. > RESERVED does not have the connotation you suggest. It would probably be better to put this discussion in the IANA considerations. Presumably anyone familiar enough with PacketBB to serve as an advisor for future allocations would recognize the basic fact. > >> However, for the case of unaggregated >> IPv4 addresses, the overhead from the address block >> mechanism as given, is 50%. >> > > If you are creating address blocks each with one address > in them. Why would you do that? If efficiency is your > goal, don't do that. Make one address block with a single > one-off 2 octet overhead for all addresses. > A lot of ad hoc networks will be either partially or completely populated by nodes with previously assigned addresses. They get together, they work, they break apart. Like ad hoc networks do. Your perspective seems to assume the existence of a centralized address allocation agency, either online or offline by preassignment. That is very worrisome to me. > >> Or, did I misinterpret, and is intended >> to include the length of ? >> > > is the total length of all TLVs in the > block, not just a single TLV. That includes all types, > semantics, indices, lengths and values. > > Each individual TLV has a semantics bit to indicate if > it has a 0, 8 or 16 bit value length. But there's no > point having a TLV block semantics octet as that costs > the octet you are trying to save. > No, it does not have to be that way. I think I already suggested a way to do it without adding any more bytes... But if need be I can repeat it. > > > >> It would be better to put into the OLSR document a part >> of the IANA considerations to reserve the four message >> types, and delete the discussion in the PacketBB document. >> > > I don't agree. > Well, that doesn't seem to explain anything. This document should not have any normative dependencies on OLSR whatsoever, and I don't really see any necessity for any informative references either except for historians. > With regard to the rest of Charlie's comments, they include some > changes to substance, rather than wording which could be done. > (But aren't the only things that could be done - some going in > the opposite direction.) I don't agree with them, not because > they have no merit but because I (and, recognising reality, the > company that pays me) have as highest priority getting this > published as soon as possible, and with minimal changes. I've > said before, there are tradeoffs here and we've made some. Are > they perfect? I'm not claiming that, but rather that "the best > is the enemy of the good" (which Googling tells me is Voltaire). > Although in many cases I'd argue against them being best too. > I have been saying some of these things for many, many months, both at IETFs and in e-mails. The request has been made for comments many times and I have finally responded at some length, as a formal process step. Your logic would seem to validate the acceptance of almost anything. I do not claim that PacketBB is terrible, but this is the time to make improvements. The suggestions I have made for the substance are, if you look objectively, quite minor indeed, but can offer real performance improvements and real flexibility for future protocol designers. I reckon the changes could be made in two weeks. I doubt that Voltaire would disagree with my attempt to make these suggestions. Furthermore, the sense of that quotation rather supports my argument. The point of the quote is exactly that when things are thought to be the "best", there seems to be no opportunity for improvement. How could one improve on the "best"? We seem to be in agreement that the document is not the "best" in absolute terms, but your claim is that it is the "best" we can expect in terms of some hypothetical time window for making it available. Oh how I wish we could have rammed through Mobile IPv6 with the same logic offered in the your quoted paragraph. In that case, the suggestions were not even remotely targeted towards performance improvements, sigh... Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat May 12 03:13: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 1Hmlmn-0006C6-8s; Sat, 12 May 2007 03:13:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hmlml-0006By-HH for manet-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 03:12:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmlml-0006Bq-3z for manet@ietf.org; Sat, 12 May 2007 03:12:59 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmlmj-0003qf-HS for manet@ietf.org; Sat, 12 May 2007 03:12:59 -0400 Received: by ug-out-1314.google.com with SMTP id 72so753107ugd for ; Sat, 12 May 2007 00:12: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mNi3VYaKbPqxTsgWAtEAmuLlrCheZWAgOFJC0tyN4w/YmX8jnBav/bgSDH6lNcoQBLxq8VTDxjhZrW0Ph6aspkvR5zLoUGXI4mM77bsQGPWeom8X6DOmQIDe6Z5HdibtxAnrV0qe9g5oaPHrTLOQNn/zesTvZc98erSLqF06ug4= 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=D1kuL61Q+JzifpnMUCc5v/zRX72dkcvTE0Nq+R7ksztXcHgbRyB9jNCzkAmxh+11aDo3AqhgIANe3jfxZ6oe3E0HJ0IpmEUYX025YgkfB/mp8h6Tyfp+NmClf2tDKZ1nU9rJRezey4UDF/ZtzY7/fYRY8vWUx3bDo7kbU0x1OKk= Received: by 10.78.156.6 with SMTP id d6mr1095576hue.1178953976297; Sat, 12 May 2007 00:12:56 -0700 (PDT) Received: by 10.78.33.14 with HTTP; Sat, 12 May 2007 00:12:56 -0700 (PDT) Message-ID: <374005f30705120012x1633750dyd40ef801b5b3d5c2@mail.gmail.com> Date: Sat, 12 May 2007 12:42:56 +0530 From: "Ian Chakeres" To: "Brian Haberman" In-Reply-To: <464466CE.40003@innovationslab.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> <46444592.6080605@gmail.com> <374005f30705110410n285728adge4166f82c6888889@mail.gmail.com> <464466CE.40003@innovationslab.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: Alexandru Petrescu , manet@ietf.org Subject: [manet] Re: site-scoped IPv6 multicast address 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 (and a bunch of other people) have expressed that there is a clear desire to have a site scoped (larger than link actually) multicast address for MANET routers. The purpose of this address would be to allow greater than link scoped packets between MANET routers. I cannot enumerate everyone's thoughts, but the use-cases are be wide and varied. It could be used for MANET router discovery, MANET Border Router communication/coordination, Autoconf assistance protocols, dissemination of multicast group information to assist SMF/multicast/nhdp, plus lots of other potential uses. Another use case could be to assist in securing certain messages (that don't require hop-by-hop modification) in an end-to-end fashion over multiple hops. Perhaps, it will not be used - but I think it is better to reserve it now - than to wait and see. Ian Chakeres On 5/11/07, Brian Haberman wrote: > First off, I have to echo Alex's concern. Can someone enumerate what > the need is for the "greater than link-local" multicast address? > > Secondly, referencing the DVMRP-over-MOSPF variable scope multicast > address doesn't make much sense. That functionality was added to the > default list of reserved multicast addresses "just in case". As far as > I know no one who still uses DVMRP over MOSPF. > > Regards, > Brian > > Ian Chakeres wrote: > > There is agreement that we need a well-known multicast address with a > > scope larger than link. > > > > I believe that site scoping is the closest match with the expressed need. > > > > Using a non scoped address could cause leakage of manet routing > > packets into the greater Internet. > > > > I would not mind switching the text from site-scope to variable scope > > (assignment at all scopes). Do you think this would be better fit? > > > > There are a large list of protocols & assignments for variable > > scoping. http://www.iana.org/assignments/ipv6-multicast-addresses > > > > This scoping assignment includes "DVMRP on MOSPF", a multicast routing > > protocol. > > > > Ian Chakeres > > > > On 5/11/07, Alexandru Petrescu wrote: > >> Ian Chakeres wrote: > >> > I'd like to ask people to review this new revision. I'm also > >> > reissuing WGLC. > >> > > >> > Here is a summary of the main changes: > >> > > >> > The draft has been revised to state clearly that a well-known UDP > >> > port, LL multicast addresses, and SL multicast addresses are required > >> > by the MANET WG. > >> > > >> > I tried to remove any text specifying operational requirements/advice > >> > related to these well-known values, as this type of discussion > >> > belongs in the protocol specifications. > >> > > >> > I choose to leave the site-local multicast addresses. This topic has > >> > been discussed several times on the list and I believe there is > >> > consensus that we should allocate these (IPv4/IPv6) addresses. > >> > >> What exactly is the need of a MANET protocol for a _site-local_ IPv6 > >> multicast address? How is that need different from existing routing > >> protocols (I'm asking because no existing routing protocol uses a > >> _site-local_ IPv6 multicast address). > >> > >> Why can't a MANET routing protocol use an IPv6 multicast address with a > >> scope non-permanently assigned (like ff15) or with Internet scope (like > >> ff0e). > >> > >> In my oppinion a MANET routing protocol has no special needs for > >> _site-local_ multicast addresses (although it may need IPv6 multicast > >> addresses with larger than link). Because the definition of a 'site' is > >> very vague in the static (non-MANET) world and has no meaning in a MANET > >> environment. > >> > >> Alex > >> > >> > > >> > Please sent any questions/comments to the list. Ian Chakeres > >> > > >> > On 5/10/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-02.txt Pages : 7 > >> >> Date : 2007-5-10 > >> >> > >> >> This document enumerates IANA assignments for use by MANET WG > >> >> protocols. 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-02.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-02.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-02.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 > >> > > >> > >> > > > > > > _______________________________________________ > > manet mailing 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 Sat May 12 04:39:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmn8e-00039S-0q; Sat, 12 May 2007 04:39:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hmn8c-00039N-G7 for manet-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 04:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hmn8b-00039F-Go for manet@ietf.org; Sat, 12 May 2007 04:39:37 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hmn8Z-0003Yw-TY for manet@ietf.org; Sat, 12 May 2007 04:39:37 -0400 Received: by ug-out-1314.google.com with SMTP id 72so760042ugd for ; Sat, 12 May 2007 01:39: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=IlWJLywM01ZVeZI6HmwhG72zeFxtr6GIf2QKENHz4ZIsalt48++yrOupyEFy/1lVHuHzMS7YA+2QEqNVqA5A1GalbiWLBWX0JhuhAfbYl44XAXbmOuDVvtdqq9jo17Crp/nE2WP/0PX8ZEYVy4ADGHy5ufQWrHaUMj63e9OxY9Q= 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=g2fBm2NTJ6P8yoz+PCojgyLFYmDGPBu9KS0HMwgk9kAJEy9YyWi7gAzhOSmiuWrE0q2ip8in3T1SPOXAlf8xun4D7Lx7GE4szOQzetrEHmGELcZlwhBAVk5cSAoesnZVtFSxHwhB87MVdxx5+7RDx5YfPKdGLSVS+2W9KmWebh8= Received: by 10.78.183.15 with SMTP id g15mr1094708huf.1178959174825; Sat, 12 May 2007 01:39:34 -0700 (PDT) Received: by 10.82.150.8 with HTTP; Sat, 12 May 2007 01:39:34 -0700 (PDT) Message-ID: Date: Sat, 12 May 2007 04:39:34 -0400 From: "Marshall Eubanks" To: "Ian Chakeres" Subject: Re: [manet] Re: site-scoped IPv6 multicast address In-Reply-To: <374005f30705120012x1633750dyd40ef801b5b3d5c2@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: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> <46444592.6080605@gmail.com> <374005f30705110410n285728adge4166f82c6888889@mail.gmail.com> <464466CE.40003@innovationslab.net> <374005f30705120012x1633750dyd40ef801b5b3d5c2@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: manet@ietf.org, 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 On 5/12/07, Ian Chakeres wrote: > I (and a bunch of other people) have expressed that there is a clear > desire to have a site scoped (larger than link actually) multicast > address for MANET routers. The purpose of this address would be to > allow greater than link scoped packets between MANET routers. > > I cannot enumerate everyone's thoughts, but the use-cases are be wide > and varied. It could be used for MANET router discovery, MANET Border > Router communication/coordination, Autoconf assistance protocols, > dissemination of multicast group information to assist > SMF/multicast/nhdp, plus lots of other potential uses. Another use > case could be to assist in securing certain messages (that don't > require hop-by-hop modification) in an end-to-end fashion over > multiple hops. > Are any of these use cases expressed in RFCs or I-Ds (and, if so, which ones) ? Regards Marshall > Perhaps, it will not be used - but I think it is better to reserve it > now - than to wait and see. > > Ian Chakeres > > On 5/11/07, Brian Haberman wrote: > > First off, I have to echo Alex's concern. Can someone enumerate what > > the need is for the "greater than link-local" multicast address? > > > > Secondly, referencing the DVMRP-over-MOSPF variable scope multicast > > address doesn't make much sense. That functionality was added to the > > default list of reserved multicast addresses "just in case". As far as > > I know no one who still uses DVMRP over MOSPF. > > > > Regards, > > Brian > > > > Ian Chakeres wrote: > > > There is agreement that we need a well-known multicast address with a > > > scope larger than link. > > > > > > I believe that site scoping is the closest match with the expressed need. > > > > > > Using a non scoped address could cause leakage of manet routing > > > packets into the greater Internet. > > > > > > I would not mind switching the text from site-scope to variable scope > > > (assignment at all scopes). Do you think this would be better fit? > > > > > > There are a large list of protocols & assignments for variable > > > scoping. http://www.iana.org/assignments/ipv6-multicast-addresses > > > > > > This scoping assignment includes "DVMRP on MOSPF", a multicast routing > > > protocol. > > > > > > Ian Chakeres > > > > > > On 5/11/07, Alexandru Petrescu wrote: > > >> Ian Chakeres wrote: > > >> > I'd like to ask people to review this new revision. I'm also > > >> > reissuing WGLC. > > >> > > > >> > Here is a summary of the main changes: > > >> > > > >> > The draft has been revised to state clearly that a well-known UDP > > >> > port, LL multicast addresses, and SL multicast addresses are required > > >> > by the MANET WG. > > >> > > > >> > I tried to remove any text specifying operational requirements/advice > > >> > related to these well-known values, as this type of discussion > > >> > belongs in the protocol specifications. > > >> > > > >> > I choose to leave the site-local multicast addresses. This topic has > > >> > been discussed several times on the list and I believe there is > > >> > consensus that we should allocate these (IPv4/IPv6) addresses. > > >> > > >> What exactly is the need of a MANET protocol for a _site-local_ IPv6 > > >> multicast address? How is that need different from existing routing > > >> protocols (I'm asking because no existing routing protocol uses a > > >> _site-local_ IPv6 multicast address). > > >> > > >> Why can't a MANET routing protocol use an IPv6 multicast address with a > > >> scope non-permanently assigned (like ff15) or with Internet scope (like > > >> ff0e). > > >> > > >> In my oppinion a MANET routing protocol has no special needs for > > >> _site-local_ multicast addresses (although it may need IPv6 multicast > > >> addresses with larger than link). Because the definition of a 'site' is > > >> very vague in the static (non-MANET) world and has no meaning in a MANET > > >> environment. > > >> > > >> Alex > > >> > > >> > > > >> > Please sent any questions/comments to the list. Ian Chakeres > > >> > > > >> > On 5/10/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-02.txt Pages : 7 > > >> >> Date : 2007-5-10 > > >> >> > > >> >> This document enumerates IANA assignments for use by MANET WG > > >> >> protocols. 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-02.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-02.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-02.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 > > >> > > > >> > > >> > > > > > > > > > _______________________________________________ > > > manet mailing 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 Sat May 12 11:52: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 1HmttG-0000L2-5O; Sat, 12 May 2007 11:52:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HmttD-0000Kp-P1 for manet-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 11:52:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmttD-0000Kg-FN for manet@ietf.org; Sat, 12 May 2007 11:52:11 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HmttB-0003R6-Uk for manet@ietf.org; Sat, 12 May 2007 11:52:11 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1178985128!20241503!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 29924 invoked from network); 12 May 2007 15:52:09 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-12.tower-119.messagelabs.com with SMTP; 12 May 2007 15:52:09 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l4CFq8dA007493; Sat, 12 May 2007 08:52:08 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l4CFq7lT018599; Sat, 12 May 2007 10:52:08 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-50.corp.mot.com [10.169.4.50]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l4CFpwsh018573; Sat, 12 May 2007 10:52:01 -0500 (CDT) Message-ID: <4645E29D.8090808@gmail.com> Date: Sat, 12 May 2007 17:51:57 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres References: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> <46444592.6080605@gmail.com> <374005f30705110410n285728adge4166f82c6888889@mail.gmail.com> <464466CE.40003@innovationslab.net> <374005f30705120012x1633750dyd40ef801b5b3d5c2@mail.gmail.com> In-Reply-To: <374005f30705120012x1633750dyd40ef801b5b3d5c2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-3, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: manet@ietf.org, Alexandru Petrescu Subject: [manet] Re: site-scoped IPv6 multicast address 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 (and a bunch of other people) have expressed that there is a clear > desire to have a site scoped (larger than link actually) multicast > address for MANET routers. A 'site' scope is not the only scope larger than link. > I cannot enumerate everyone's thoughts, but the use-cases are be wide > and varied. It could be used for MANET router discovery, I think we should be careful with terminology. I think MANET router discovery should include first and foremost ND router discovery (and that is link-local). Which MANET protocol _discovers_ other routers (not on same link)? I thought they're hardcoded in config files. > MANET Border Router communication/coordination, Autoconf assistance > protocols, dissemination of multicast group information to assist > SMF/multicast/nhdp, plus lots of other potential uses. I think these are words that sound good, with potentially very stimulating intelligent ideas; but I am afraid (afraid to say something wrong), that there are no specs for these behaviours. > Another use case could be to assist in securing certain messages > (that don't require hop-by-hop modification) in an end-to-end fashion > over multiple hops. Ian, this surely goes into IRTF discussion. Securing multicast communication - and mobility or manet - is cleary something not agreed to work on currently as standards track. There is a little activity at IETF to secure group/multicast communication and that doesn't include mobility. There are however large activities in IRTF about securing mobile multicast communications at least in mobopts RG and recently a new list dealing with that. In this context, I am wondering why do you cite in the MANET Working Group "securing certain messages" together with a "site-scoped multicast address". > Perhaps, it will not be used - but I think it is better to reserve it > now - than to wait and see. A risk I'd like to mention - reserve now for we don't know what - and when we know what we'll reserve another one. Alex > > Ian Chakeres > > On 5/11/07, Brian Haberman wrote: >> First off, I have to echo Alex's concern. Can someone enumerate >> what the need is for the "greater than link-local" multicast >> address? >> >> Secondly, referencing the DVMRP-over-MOSPF variable scope multicast >> address doesn't make much sense. That functionality was added to >> the default list of reserved multicast addresses "just in case". >> As far as I know no one who still uses DVMRP over MOSPF. >> >> Regards, Brian >> >> Ian Chakeres wrote: >>> There is agreement that we need a well-known multicast address >>> with a scope larger than link. >>> >>> I believe that site scoping is the closest match with the >>> expressed >> need. >>> >>> Using a non scoped address could cause leakage of manet routing >>> packets into the greater Internet. >>> >>> I would not mind switching the text from site-scope to variable >>> scope (assignment at all scopes). Do you think this would be >>> better fit? >>> >>> There are a large list of protocols & assignments for variable >>> scoping. http://www.iana.org/assignments/ipv6-multicast-addresses >>> >>> >>> >>> >>> This scoping assignment includes "DVMRP on MOSPF", a multicast >>> routing protocol. >>> >>> Ian Chakeres >>> >>> On 5/11/07, Alexandru Petrescu >>> wrote: >>>> Ian Chakeres wrote: >>>>> I'd like to ask people to review this new revision. I'm also >>>>> reissuing WGLC. >>>>> >>>>> Here is a summary of the main changes: >>>>> >>>>> The draft has been revised to state clearly that a well-known >>>>> UDP port, LL multicast addresses, and SL multicast addresses >>>>> are >> required >>>>> by the MANET WG. >>>>> >>>>> I tried to remove any text specifying operational >> requirements/advice >>>>> related to these well-known values, as this type of >>>>> discussion belongs in the protocol specifications. >>>>> >>>>> I choose to leave the site-local multicast addresses. This >>>>> topic has been discussed several times on the list and I >>>>> believe there is consensus that we should allocate these >>>>> (IPv4/IPv6) addresses. >>>> >>>> What exactly is the need of a MANET protocol for a _site-local_ >>>> IPv6 multicast address? How is that need different from >>>> existing routing protocols (I'm asking because no existing >>>> routing protocol uses a _site-local_ IPv6 multicast address). >>>> >>>> Why can't a MANET routing protocol use an IPv6 multicast >>>> address >> with a >>>> scope non-permanently assigned (like ff15) or with Internet >>>> scope >> (like >>>> ff0e). >>>> >>>> In my oppinion a MANET routing protocol has no special needs >>>> for _site-local_ multicast addresses (although it may need IPv6 >>>> multicast addresses with larger than link). Because the >>>> definition of a >> 'site' is >>>> very vague in the static (non-MANET) world and has no meaning >>>> in a >> MANET >>>> environment. >>>> >>>> Alex >>>> >>>>> >>>>> Please sent any questions/comments to the list. Ian Chakeres >>>>> >>>>> On 5/10/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-02.txt >>>>>> Pages : 7 Date : 2007-5-10 >>>>>> >>>>>> This document enumerates IANA assignments for use by MANET >>>>>> WG protocols. 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-02.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-02.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-02.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 >>>>> >>>> >>>> >>> >>> >>> _______________________________________________ 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 May 12 11:55: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 1Hmtwa-00019R-OW; Sat, 12 May 2007 11:55:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HmtwY-000198-Hn for manet-confirm+ok@megatron.ietf.org; Sat, 12 May 2007 11:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmtwY-00018x-7w for manet@ietf.org; Sat, 12 May 2007 11:55:38 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HmtwW-0004IC-Vn for manet@ietf.org; Sat, 12 May 2007 11:55:38 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1178985336!21109349!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4390 invoked from network); 12 May 2007 15:55:36 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-119.messagelabs.com with SMTP; 12 May 2007 15:55:36 -0000 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4CFtZxB006357; Sat, 12 May 2007 08:55:36 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l4CFtYOm019226; Sat, 12 May 2007 10:55:35 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-50.corp.mot.com [10.169.4.50]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l4CFtVTA019217; Sat, 12 May 2007 10:55:33 -0500 (CDT) Message-ID: <4645E372.9020408@gmail.com> Date: Sat, 12 May 2007 17:55:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres References: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> <46444592.6080605@gmail.com> <374005f30705110410n285728adge4166f82c6888889@mail.gmail.com> In-Reply-To: <374005f30705110410n285728adge4166f82c6888889@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000739-3, 11/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Alexandru Petrescu , manet@ietf.org Subject: [manet] Re: site-scoped IPv6 multicast address 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: > There is agreement that we need a well-known multicast address with a > scope larger than link. > > I believe that site scoping is the closest match with the expressed > need. > > Using a non scoped address could cause leakage of manet routing > packets into the greater Internet. > > I would not mind switching the text from site-scope to variable scope > (assignment at all scopes). Do you think this would be better fit? I think that could be a good idea, but without knowing which are the uses of all these addresses it sounds like address waste. I think another way would be to wait that the need for this address is more clear. Yet another way is to request definition of a new scope. If I were to choose right now between all these possible ways forward I'd say to wait that the need is clear. > There are a large list of protocols & assignments for variable > scoping. http://www.iana.org/assignments/ipv6-multicast-addresses > > This scoping assignment includes "DVMRP on MOSPF", a multicast > routing protocol. I don't think we have any common idea about a MANET multicast routing protocol right now, such as to require a multicast address for it. Or I don't. 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 May 14 01:09: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 1HnSnv-0007sg-UX; Mon, 14 May 2007 01:09:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HnSnu-0007pe-Ac for manet-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 01:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnSnt-0007oF-TG for manet@ietf.org; Mon, 14 May 2007 01:09:01 -0400 Received: from ik-out-1112.google.com ([66.249.90.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnSnt-0006Dg-FG for manet@ietf.org; Mon, 14 May 2007 01:09:01 -0400 Received: by ik-out-1112.google.com with SMTP id c29so969768ika for ; Sun, 13 May 2007 22:09: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=LYDcnTf1hE/2i8RUyXwn8irm9xY5A+JBjH5VgzkvSbgGhy2VwqtOA+wQJ++g4+DWzkWRDjLl4Llv3Ql8j3vN7qwmDPsyNahHV6ASdaN2NlZTjFkq7K0/jFf2k0yUBu4cIwbthSyFk0H9rEDpeuk9byIgaR9ahmtbKAfq8QIGJBY= 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=NM9QDmIBm/TlHq0uiTnD09O/1hqGIf4P4nDPwVhK/URBJV0buCZVkgboZW5QQX3aXZ1KfvqH74RBovzW4NH8ANfFlfvA5pyk3w14HCG0EBXW+fY2mVMBB8JiQghQUy3rwJwSBBrH9er7X2jrBSV+MgsHbJcDQO64JhDaObUaSzA= Received: by 10.82.100.1 with SMTP id x1mr794802bub.1179119340460; Sun, 13 May 2007 22:09:00 -0700 (PDT) Received: by 10.82.176.18 with HTTP; Sun, 13 May 2007 22:09:00 -0700 (PDT) Message-ID: Date: Mon, 14 May 2007 01:09:00 -0400 From: "Dwarkanath Radhakrishnan" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [manet] [GloMoSim] error LNK2001: unresolved external symbol 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="===============0854934354==" Errors-To: manet-bounces@ietf.org --===============0854934354== Content-Type: multipart/alternative; boundary="----=_Part_53557_22871767.1179119340421" ------=_Part_53557_22871767.1179119340421 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all users, I am a graduate student and I am doing research in the area of ad -hoc networks. I downloaded GloMoSim to assist in simulation. I wrote a new mac protocol and added the .pc, .h and .pi files .I then tried to compile GloMoSim in WIN xp. Next the following errors happened in the process of compilation: >call pcc -Zi -Ox -I..\include\ -I..\radio\ -clock longlong -o ..\bin\radio_r ange ..\radio\radiorange.pc temp.lib tmp-3968.c tmp-3968-0.c radiorange.init.c temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceInit temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceLayer temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceNetwor kLayerHasPacketToSend temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceReceiv ePacketFromRadio temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceReceiv eRadioStatusChangeNotification temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceFinali ze ..\bin\radio_range.exe : fatal error LNK1120: 6 unresolved externals Failed linking '..\bin\radio_range' Can you please help me resolve this error or give me some suggestions? Any replies will be greatly appreciated. Thanks and have a nice day Regards Dwarak ------=_Part_53557_22871767.1179119340421 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear all users,
 I am a graduate student and I am doing research in the area of  ad -hoc networks.  I downloaded GloMoSim to assist in simulation.  I wrote a new mac protocol and added the .pc, .h and .pi files .I then  tried to compile GloMoSim in WIN xp. Next the following errors happened in the process of compilation:
 
 
>call pcc -Zi -Ox    -I..\include\ -I..\radio\ -clock longlong -o ..\bin\radio_r
ange ..\radio\radiorange.pc temp.lib
tmp-3968.c
tmp-3968-0.c
radiorange.init.c
temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceInit
temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceLayer
temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceNetwor
kLayerHasPacketToSend
temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceReceiv
ePacketFromRadio
temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceReceiv
eRadioStatusChangeNotification
temp.lib(mac.obj) : error LNK2001: unresolved external symbol _MacAllianceFinali
ze
..\bin\radio_range.exe : fatal error LNK1120: 6 unresolved externals
Failed linking '..\bin\radio_range'
 
Can you please help me resolve this error or give me some suggestions? Any replies will be greatly appreciated.
 

Thanks and have a nice day
 
Regards
Dwarak

 
 
------=_Part_53557_22871767.1179119340421-- --===============0854934354== 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 --===============0854934354==-- From manet-bounces@ietf.org Mon May 14 04:34: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 1HnW0r-0005W0-VL; Mon, 14 May 2007 04:34:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HnW0q-0005U2-3C for manet-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 04:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnW0p-0005Rg-5H for manet@ietf.org; Mon, 14 May 2007 04:34:35 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnW0n-00086b-PA for manet@ietf.org; Mon, 14 May 2007 04:34:35 -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 l4E8YEjE016103 for ; Mon, 14 May 2007 09:34:15 +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 l4E8YEwd019577 for ; Mon, 14 May 2007 09:34:14 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 14 May 2007 09:34:06 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 May 2007 09:33:44 +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 Date: Mon, 14 May 2007 09:33:22 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments about draft-ietf-manet-packetbb-04 Thread-Index: AceT5mmSUs37JBvbRHqdYBetL0Qk1QCGqLGg From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" X-OriginalArrivalTime: 14 May 2007 08:33:44.0886 (UTC) FILETIME=[95B11560:01C79602] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Thomas Heide clausen , Manet Subject: [manet] RE: Comments about draft-ietf-manet-packetbb-04 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 lot of ad hoc networks will be either partially or completely > populated by nodes with previously assigned addresses. > They get together, they work, they break apart. Like > ad hoc networks do. >=20 > Your perspective seems to assume the existence of a > centralized address allocation agency, either online or > offline by preassignment. That is very worrisome to me. You have quite misread my comments, which didn't discuss address allocation at all - in fact actually discussed the case you are considering. You can have entirely unrelated addresses, with no address compression possible. You can still put them in a single address block. That will be 2 octets overhead - not 50%, which would be 2 per address, and would only happen if you put them in separate address blocks. So don't do that. > Well, that doesn't seem to explain anything. This document > should not have any normative dependencies on OLSR > whatsoever, and I don't really see any necessity for any > informative references either except for historians. It's not informative, it's normative. It allows some options using OLSRv1 that would otherwise fail. (A valid OLSRv2 message with a zero semantics octet is a valid OLSR message.) > I do not > claim that PacketBB is terrible, but this is the time to make > improvements. I do not claim packetbb is perfect, but now is the time to publish. > I reckon the changes could be made in two weeks. You don't have code to re-write and re-test. And I know from experience two weeks is too short an estimate even apart from that. Furthermore other interested parties (quite independent of me) want to go in the opposite direction - simplification at the expense of flexibility and efficiency. I think we have a reasonable compromise. ******************************************************************** 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 May 14 07:27: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 1HnYiT-0006DO-WB; Mon, 14 May 2007 07:27:50 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HnYiS-0006DJ-V7 for manet-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 07:27:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HnYiS-0006DB-Le for manet@ietf.org; Mon, 14 May 2007 07:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnYeD-0001fY-Qw for manet@ietf.org; Mon, 14 May 2007 07:23:25 -0400 Received: from faui45.informatik.uni-erlangen.de ([131.188.34.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnYeC-0002w9-H5 for manet@ietf.org; Mon, 14 May 2007 07:23:25 -0400 Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTP id 180884D10 for ; Mon, 14 May 2007 13:23:24 +0200 (MEST) Received: from [131.188.37.96] (faui7m16 [131.188.37.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id ECE41B0038 for ; Mon, 14 May 2007 13:23:23 +0200 (CEST) Message-ID: <464846EA.1080803@informatik.uni-erlangen.de> Date: Mon, 14 May 2007 13:24:26 +0200 From: Christoph Sommer User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-TMDA-Confirmed: Mon, 14 May 2007 07:27:48 -0400 Subject: [manet] Bug with DYMO not incrementing OwnSeqNum and nodes throwing packets away 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 list, We have built a model of DYMO for use in OMNeT++ and came across a weird issue: Intermediate hops throw away RREP packets that were requested to refresh timed-out routes. In the draft revision we used to build the model, nodes are not yet allowed to send RREPs on behalf of a sink, but it seems like the problem should also present with the current revision. This is what happens in our simulation: 1.) node sends RREQ, receives RREP and stores current OwnSeqNum of sink 2.) route to sink times out (invalid, but not yet deleted) 3.) node sends RREQ, includes current OwnSeqNum of sink 4.) sink recognizes that the included SeqNum in RREQ equals OwnSeqNum, sends back RREP without incrementing OwnSeqNum 5.) (intermediate) node judges usefulness of RREP packet, recognizes SeqNum stayed the same, hop count did not get better and throws RREP away. 6.) node retries RREQ and steps 3--5 repeat Where did our implementation go wrong? Maybe a (destination or intermediate) node should not take expired-but-not-yet-deleted route entries into account when judging a RREP's usefulness? The current draft does not seem to require this. Simulations with NIST-DYMO run fine, probably because a node increments its OwnSeqNum with every RREP it sends, regardless of the expected SeqNum included in a DYMO packet. It seems like DYMOUM, on the other hand, should run into the same problem, so I am bit confused. Kind regards, Christoph Sommer _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 14 07: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 1HnZ89-0005nP-AL; Mon, 14 May 2007 07:54:21 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HnZ87-0005jZ-Oc for manet-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 07:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZ87-0005jR-Ey for manet@ietf.org; Mon, 14 May 2007 07:54:19 -0400 Received: from ik-out-1112.google.com ([66.249.90.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZ87-0003P7-0l for manet@ietf.org; Mon, 14 May 2007 07:54:19 -0400 Received: by ik-out-1112.google.com with SMTP id c29so1026045ika for ; Mon, 14 May 2007 04:54:18 -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=ZTjLGr1xKapU6jQla0dS+TKwisF7gZ/+zzDEam4d84Na0lsvsUpxmvp+FzukVuWs1LcSBc0MoHdN1XHxL5khIZlrLTBVczcOteIcZNfes56x642JCrHhSWgV/k5sBDgub0Ieu/v748ERoYZ+iTG+PsSpvrThBMJfP0z5CinUr3Q= 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=AxtHQYNAtMhywL13mEPmsoWpw9K8NueGtVNjY+ex1t1pzvV4aVtu5j5vOOVBUPR0nVfbj/uKBziOQxQKEkZyXXjUd2mruScoJItvPErPjnWcZI7xm9TzhV5S1smP5AvPQRVKI/+GRfgsTYOqRmeLB83EGgJF4N1EBL0TtKlfvJY= Received: by 10.78.157.19 with SMTP id f19mr2284494hue.1179143657880; Mon, 14 May 2007 04:54:17 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Mon, 14 May 2007 04:54:17 -0700 (PDT) Message-ID: <374005f30705140454u494afd94j16b46e0c3ef2ff60@mail.gmail.com> Date: Mon, 14 May 2007 17:24:17 +0530 From: "Ian Chakeres" To: "Christoph Sommer" Subject: Re: [manet] Bug with DYMO not incrementing OwnSeqNum and nodes throwing packets away In-Reply-To: <464846EA.1080803@informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <464846EA.1080803@informatik.uni-erlangen.de> 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 I think there might be a few issues here. If the destination does not increment its OwnSeqNum, the RREP might be discarded. This fact is clearly called out in the draft in Section 5.3.2 in paragraph 3. That said, I suspect one problem with the implementation is in the route discovery proceedure. See Section 5.3.1 paragraph 3. After failing to determine a route several times, the originator should not include the SeqNum information for the target. In this case when the RREQ reaches the target, the target will be required to increment its sequence number and the RREP will then reach the originator. Another issue in the implementation appears to be determining the usefulness of routing information. In the above scenario, since the new information has equal sequence number, equal hopcount, and is being carried in a RREP - the information should be accepted as superior. Please see Section 5.2.1. Ian Chakeres On 5/14/07, Christoph Sommer wrote: > Hello list, > > We have built a model of DYMO for use in OMNeT++ and came across a weird > issue: > > Intermediate hops throw away RREP packets that were requested to refresh > timed-out routes. > > In the draft revision we used to build the model, nodes are not yet > allowed to send RREPs on behalf of a sink, but it seems like the problem > should also present with the current revision. This is what happens in > our simulation: > > 1.) node sends RREQ, receives RREP and stores current OwnSeqNum of sink > > 2.) route to sink times out (invalid, but not yet deleted) > > 3.) node sends RREQ, includes current OwnSeqNum of sink > > 4.) sink recognizes that the included SeqNum in RREQ equals OwnSeqNum, > sends back RREP without incrementing OwnSeqNum > > 5.) (intermediate) node judges usefulness of RREP packet, recognizes > SeqNum stayed the same, hop count did not get better and throws RREP away. > > 6.) node retries RREQ and steps 3--5 repeat > > > Where did our implementation go wrong? Maybe a (destination or > intermediate) node should not take expired-but-not-yet-deleted route > entries into account when judging a RREP's usefulness? The current draft > does not seem to require this. > > Simulations with NIST-DYMO run fine, probably because a node increments > its OwnSeqNum with every RREP it sends, regardless of the expected > SeqNum included in a DYMO packet. It seems like DYMOUM, on the other > hand, should run into the same problem, so I am bit confused. > > > Kind regards, > > Christoph Sommer > > > > > > _______________________________________________ > manet mailing 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 May 14 13:05: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 1Hndzc-0006Mq-1k; Mon, 14 May 2007 13:05:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hndza-0006Mk-7e for manet-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 13:05:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndzZ-0006Mc-UE for manet@ietf.org; Mon, 14 May 2007 13:05:49 -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 1HndzZ-0006aU-FJ for manet@ietf.org; Mon, 14 May 2007 13:05:49 -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 l4EH5HsX024862; Mon, 14 May 2007 20:05:35 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 20:04:59 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 12:04:57 -0500 Received: from [10.162.65.167] ([10.162.65.167]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 12:04:56 -0500 Message-ID: <464896B2.9090309@nokia.com> Date: Mon, 14 May 2007 10:04:50 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "ext Dearlove, Christopher (UK)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2007 17:04:57.0262 (UTC) FILETIME=[FFDA3CE0:01C79649] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Thomas Heide clausen , Manet Subject: [manet] Re: Comments about draft-ietf-manet-packetbb-04 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 Christopher, More comments below... ext Dearlove, Christopher (UK) wrote: >> A lot of ad hoc networks will be either partially or completely >> populated by nodes with previously assigned addresses. >> They get together, they work, they break apart. Like >> ad hoc networks do. >> >> Your perspective seems to assume the existence of a >> centralized address allocation agency, either online or >> offline by preassignment. That is very worrisome to me. >> > > You have quite misread my comments, which didn't discuss > address allocation at all - in fact actually discussed the > case you are considering. You can have entirely unrelated > addresses, with no address compression possible. Good -- yes I did know this was possible. I am glad that your comments were not made from the context that I had inferred. > You can > still put them in a single address block. That will be 2 > octets overhead - not 50%, which would be 2 per address, > and would only happen if you put them in separate address > blocks. So don't do that. > Whether or not multiple addresses are collected is dictated by the meaning of the message, not the desire for a person to save space according to a parseable bucket of message fields. I agree that when you can collect multiple addresses, the more you can get the less percentage overhead will be incurred for the whole collection. > >> Well, that doesn't seem to explain anything. This document >> should not have any normative dependencies on OLSR >> whatsoever, and I don't really see any necessity for any >> informative references either except for historians. >> > > It's not informative, it's normative. It allows some options > using OLSRv1 that would otherwise fail. (A valid OLSRv2 message > with a zero semantics octet is a valid OLSR message.) > I am not following this logic. Why should PacketBB depend on OLSR? All the basic message structure should be defined in PacketBB, and OLSR should make a normative reference on PacketBB in order to utilize the structures defined there. What am I missing? What would fail? Is there more text that needs to be pulled from OLSR and put into PacketBB? > > > >> I reckon the changes could be made in two weeks. >> > > You don't have code to re-write and re-test. And I know > from experience two weeks is too short an estimate even > apart from that. Furthermore other interested parties > (quite independent of me) want to go in the opposite > direction - simplification at the expense of flexibility > and efficiency. I think we have a reasonable compromise. > The document can be revised in a way that does not disable existing code, except that existing code blocks would need to be encapsulated by some minor bit testing. Furthermore, it is not enforced that we require interoperability testing before progressing the document. I really think you are exaggerating the difficulty for including the changes I have suggested. These sorts of techniques have been used so many times in the past that there is little doubt they would work. Do you contend that no changes are possible unless (a) you have tested the new code, and (b) the voices of discussion that you hear but are not on the mailing list approve? Regards, Charlie P., _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 14 13:33: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 1HneQa-0004L1-4n; Mon, 14 May 2007 13:33:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HneQY-0004Kr-Ku for manet-confirm+ok@megatron.ietf.org; Mon, 14 May 2007 13:33:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HneQY-0004Kj-BD for manet@ietf.org; Mon, 14 May 2007 13:33:42 -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 1HneQV-0005su-IQ for manet@ietf.org; Mon, 14 May 2007 13:33:42 -0400 Received: (eyou send program); Tue, 15 May 2007 01:33:29 +0800 Message-ID: <379164009.14677@ustc.edu.cn> Received: from 211.86.146.106 by email.ustc.edu.cn with HTTP; Tue, 15 May 2007 01:33:29 +0800 X-WebMAIL-MUA: [211.86.146.106] From: "RuiZhe Wu" To: manet@ietf.org Date: Tue, 15 May 2007 01:33:29 +0800 X-Priority: 3 Content-Type: text/plain X-Spam-Score: 1.2 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [manet] Multicast Energy saving in WSN 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 Consider this problem: A sensor note can know specific minimum energy request in its connection with specific note. Only using more than this request energy, the edge is connected. Moreover, a sensor note also can control its sending power. In this situation, we want to find a min multicast energy consumption backbone. Min Steiner Tree is not the min energy consumption tree, even the edge weight is the min energy request. Because in wireless network, any sending message is broadcasted to neighbors. The energy consumption is shared by its neighbors. I want to find a proper mathematic model to solve it. It looks like the Min Connected Dominating Set Problem. However,MCDS find the minimum of Connected Dominating Set.In this problem. we want to find the minimum total energy consumption that can make the backbone is connected. I don't know any previous model or papers about this. Can someone gives me some hints? _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue May 15 04:39: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 1HnsYm-0003lj-Q3; Tue, 15 May 2007 04:39:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HnsYk-0003le-NA for manet-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 04:39:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnsYk-0003lW-0q for manet@ietf.org; Tue, 15 May 2007 04:39:06 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnsYi-0006sR-Id for manet@ietf.org; Tue, 15 May 2007 04:39:06 -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 l4F8d2ho025223 for ; Tue, 15 May 2007 09:39:02 +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 l4F8d2pp008133 for ; Tue, 15 May 2007 09:39:02 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 15 May 2007 09:39:01 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 May 2007 09:37:37 +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: Comments about draft-ietf-manet-packetbb-04 Date: Tue, 15 May 2007 09:35:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: Comments about draft-ietf-manet-packetbb-04 Thread-Index: AceWSi4vJDld+p0xTDiwzQJ9RXzcgwAfqFZg From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" X-OriginalArrivalTime: 15 May 2007 08:37:37.0402 (UTC) FILETIME=[4AB1F5A0:01C796CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Thomas Heide clausen , 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 > Whether or not multiple addresses are collected is dictated by > the meaning of the message, not the desire for a person to save > space according to a parseable bucket of message fields. You should design your protocol using packetbb to use it efficiently. There are generally several solutions to each problem. For example if you want to separate addresses into groups then one way is to put them in separate address blocks. Another way uses address TLVs. There are doubtless others. >I am not following this logic. Why should PacketBB depend on >OLSR? All the basic message structure should be defined in >PacketBB, and OLSR should make a normative reference on >PacketBB in order to utilize the structures defined there. >What am I missing? What would fail? Is there more text >that needs to be pulled from OLSR and put into PacketBB? OLSR, i.e. OLSRv1, not OLSRv2. It's hardly possible to change the former. > The document can be revised in a way that does not > disable existing code, except that existing code blocks > would need to be encapsulated by some minor bit testing. If you change the document, you change the code. You are talking about adding options, so that's adding options to the code. (I'm referring to mine - at least one of my co-authors also has code.) > Do you contend that no changes are possible unless > (a) you have tested the new code, and > (b) the voices of discussion that you hear but are not on the mailing list approve? Changes are always possible. But not necessarily desirable. My position is that there are pressures in various directions, and where we are is the best balance of those pressures based on proposals I've seen. As for (a) - yes, there may not be an interoperability requirement, but I want some running code, and (b) yes, all discussion should be on the list - but this list has been pretty much useless over most of my time with the IETF, it's really only been the last few months that it's approached being a more usual IETF list. People have got in the habit of bypassing it, and I can't make them post here. Actually they tend to communicate directly with Thomas rather than me. ******************************************************************** 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 May 15 05:16: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 1Hnt8c-0007U4-MP; Tue, 15 May 2007 05:16:10 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hnt8b-0007QM-07 for manet-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 05:16:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnt8a-0007OR-Lk for manet@ietf.org; Tue, 15 May 2007 05:16:08 -0400 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnt8Z-00084l-Q5 for manet@ietf.org; Tue, 15 May 2007 05:16:08 -0400 Received: by wr-out-0506.google.com with SMTP id 71so1971401wri for ; Tue, 15 May 2007 02:16: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EMP82n2o1rmLpx/lh4xjD/6+LKLjNvnzaCszrw3BE2Gj4PnCWs0rITkLnOFyhkRet80mq4TONSfqXEK4voNJgGmlX5rinDv8i63jSpxLPcGh9NWluTMxtwKW64yzv2+LfJ1EsZRsa2RHFDmjDUjdsIIIRfD7wnbE43X7J1wTas4= 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=KIOpuFPM7HWRGKtFgqhUIy+4bNkObGhNGla5x3xNKRSeEQfr/qLPB2619pWssYtjgvt0uag85ISFGKW0T3aknBHikvEFGms6UnGaDaaoBu5Ulu2f/aPMwohMszfxRoHebRwkDCPPC9xy94kA9iEU7i6p6FBXGVGboYkqwqDdcSk= Received: by 10.78.200.20 with SMTP id x20mr2557963huf.1179220566719; Tue, 15 May 2007 02:16:06 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Tue, 15 May 2007 02:16:06 -0700 (PDT) Message-ID: <374005f30705150216j2a62bd93p5cb3c8ef3f90b2aa@mail.gmail.com> Date: Tue, 15 May 2007 14:46:06 +0530 From: "Ian Chakeres" To: "Thomas Heide clausen" , chris.dearlove@baesystems.com, "Justin Dean (work)" Subject: Re: [manet] Comments about draft-ietf-manet-packetbb-04 In-Reply-To: <4643AF39.9080106@nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4643AF39.9080106@nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac 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 PacketBB authors, A lot of Charlie's comments appear to be minor. I assume you'll happily integrate them. Regarding the "larger" changes Charlie has suggested, can you please breakout the various items into separate threads? Then we can tackle them one-by-one. Ian On 5/11/07, Charles E. Perkins wrote: > > Hello folks, > > Herewith, some comments on the PacketBB document. > I didn't go through the appendices yet, sigh... > > ================================================ > > Somewhere, the document should explain why the "bb". > > > o A message header format containing *all* necessary information to > > allow a node to make forwarding decisions without inspecting and > > processing the message body. Message header information permits > > single- and multi-hop message diffusion. > > Should clarify this only affects packets with TTL > 1. > The statement is also incorrect if it is interpreted to mean > that the node's present state cannot be used in the forwarding > decision. > > > The specification has been explicitly designed with the following > > properties in mind: > > One of the design goals ought to be compact header size, > in general -- not just for address representations. > > > Parsing logic - the regular expression specification facilitates > > generic, protocol independent, parsing logic. > > If, by putting this first, it is elevated to prime importance, > then I think the design goals have the wrong priority. It should > be a goal, but considerably less important than efficiency > of representation or actual processing. Parsing is a smaller > part. > > > ... Full backward compatibility can be > > maintained. > > Backward compatibility to what? > > > Packet - the top level entity in this specification. Packets are > > transmitted over a single logical hop and are not forwarded. A > > packet contains zero or more messages, and may contain a packet > > header. > > When do we need to transmit a packet with zero messages? > > > Address - an address of the same length as the source IP address in > > the IP datagram carrying the packet. > > I don't see the point of making the definition this way. > People reading the spec are likely to have encountered > IP addresses before, and would be familiar with the concept > of a network-layer address. Plus, I can imagine mixed-mode > systems where IPv6 and IPv4 nodes share routing responsibilities, > even though we are not designing those systems today. > > > The specification is designed specifically with IP (IPv4/IPv6) in > > mind. All addresses within a control message are assumed to be of > > the same size, deduced from IP. In the case of mixed IPv6 and IPv4 > > addresses, IPv4 addresses are carried in IPv6 as specified in [2]. > > The first sentence I like. The second restriction is chancy, as > I just mentioned. The third restriction could lead to ambiguities, > I think... > > > ........ transport mechanism (unicast, multicast) > > I never heard these called "transport mechanisms" before. > Aren't they really different modes of network addressability? > > > .......... it will employ. > > What is "it"? The "protocol"? Does it mean that the > document specifies features that may be prohibited for > use by some protocols designed according to the specification? > > Just checking! > > > = {*}? > > {*}* > > > > where is defined in Section 5.2, and is defined > > in Section 5.4. The packet is parsed until all octets are used. > > The last sentence imposes an unnecessary restriction. > Some packets should be dropped before parsing is complete. > And, what if the packet is unparseable? > > > bit 0 (pnoseqnum): if cleared ('0'), then the packet header > > contains a . If set ('1'), then the packet > > header does not include a . > > > > bit 1 (ptlv): if cleared ('0'), then the packet header does not > > include a TLV block. If set ('1'), then the packet header > > includes a TLV block. > > It is curious, and less than desireable, that the senses > of these two flags are inverted relative to each other. > However, it is not incorrect -- except insofar as it makes > people more likely to make mistakes from strained memory. > > > is an 8 bit field, specifying the type of message. A > > type with all bits cleared ('0') MUST NOT be used. > > You can just say that type 0 (zero) is RESERVED. > > > is a 16 bit field, specifying the size of the , > > counted in octets. > > This would be a possible use of another bit in the msg-semantics > field, which would say whether or not the msg-size were 8 or 16 bits. > It is to be hoped that most kinds packetbb messages would be usually > be less than 256 bytes long, so it would be nice if the specification > supported that case. > > > is an 8 bit field, which contains the maximum number of > > logical hops a message should be further transmitted. > > > > is an 8 bit field, which contains the number of logical > > hops a message has traveled. > > I can well imagine protocol messages which would not need > both of these fields. > > >
is defined by: > > > > = > > > > ? > > ? > > ? > > ? > > * > > This construction assumes that most address information > will be transmitted in blocks of aggregated addresses. > As we have discussed many times in the past, the value > of the given scheme is questionable if most addresses > are really singletons from an effectively flat address > space. This is the case for the overwhelming majority > of times in my experience. > > One way around this would be to have two kinds of >
s: one, as given above, and another > trivial one just consisting of the unadorned and > unpartitioned address. > > I thought about developing a simple expression for > the overhead, depending on the expected number of > addresses that can be aggregated, but it is really > just an exercise. However, for the case of unaggregated > IPv4 addresses, the overhead from the address block > mechanism as given, is 50%. That can make a difference. > In many cases, the number of addresses in the message > (disregarding extensions) is fixed by the message > type, enabling a very compact representation overall. > > How about if we put another bit into the > which would enable the simple
variant? > > Aside from this case which is the majority case in > my experience, I think the given format seems to > work well for addresses that can be aggregated. > However, it is to be noted that, for instance, AODV > handles address aggregation by another mechanism > entirely. > > > mid-length is a variable, which MUST be non-negative, defined by: > > Is there some field here which is signed? > What does this mean? > > > > is a 16 bit field > > I hope most s will be shorter than 256 bytes, so this > could be considered overkill. I am constantly reminded > that our results show over and over again that extra > bytes really correlate well with reduced protocol > performance, so I look for ways to make savings especially > in crucial systemic protocol elements such as this. > If there is a where the fields add up to more > than 256 (wow!) wouldn't it be better to just define > a "continuation" for that case? > > Or, did I misinterpret, and is intended > to include the length of ? > > In that case, my comments still apply, but I would > prefer having a way to determine whether or not the > was of the long or the short variety, perhaps > based on the type. > > > Two or more TLVs of the same type associated with the same address > > block MUST NOT both cover any address. > > I do not understand the reasoning behind this constraint. > What if TLVs specify link characteristics, and we want > to know more than one characteristic about some links > (i.e., some pairs of addresses)? > > > Packet headers and messages can be padded to ensure 32 bit alignment > > Packet headers and messages MAY be padded to ensure 32 bit alignment > > > Message type 0 MUST NOT be allocated because a zero-octet signifies a > > packet header and zero-octets are used for padding. Message types 1 > > to 4 are reserved because they are used by OLSR [4], which uses a > > compatible packet/message header format. > > I don't think IANA cares what type 0 signifies. Why not just > make it RESERVED? > > It would be better to put into the OLSR document a part > of the IANA considerations to reserve the four message > types, and delete the discussion in the PacketBB document. > > Why isn't Table 7 close to the paragraph about address blocks? > > >8. Security Considerations > > > > Messages are designed to be carriers of protocol information and MAY, > > I don't think MAY is supposed to be used this way. > > > ............... Since > count> and are the only fields that may be modified when > > such a message is forwarded, this signature can be calculated based > > Really? What about current estimates of cost, stability, delay, ...? > > Or, is this discussion only valid > "If forwarded messages are unchanged by this protocol," ? > > Furthermore, I reckon "end-to-end security MAY be implemented" > in many ways. Again, this seems to be a wrong use of "MAY". > Also, "Hop-by-hop packet level security MAY be implemented" > could, presumably, be implemented using IPsec. Or am I missing > something...? > > ================================================ > > 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 May 15 10:58: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 1HnyUA-00072A-U1; Tue, 15 May 2007 10:58:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HnyU9-0006uk-ID for manet-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 10:58:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnyU9-0006rN-5R for manet@ietf.org; Tue, 15 May 2007 10:58:45 -0400 Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnyU7-0003Af-NN for manet@ietf.org; Tue, 15 May 2007 10:58:45 -0400 Received: from ([128.244.206.105]) by piper.jhuapl.edu with ESMTP id 5502121.29323637; Tue, 15 May 2007 10:58:23 -0400 Message-ID: <4649CA8F.6080800@innovationslab.net> Date: Tue, 15 May 2007 10:58:23 -0400 From: Brian Haberman User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ian Chakeres References: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> <46444592.6080605@gmail.com> <374005f30705110410n285728adge4166f82c6888889@mail.gmail.com> <464466CE.40003@innovationslab.net> <374005f30705120012x1633750dyd40ef801b5b3d5c2@mail.gmail.com> In-Reply-To: <374005f30705120012x1633750dyd40ef801b5b3d5c2@mail.gmail.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: Alexandru Petrescu , manet@ietf.org Subject: [manet] Re: site-scoped IPv6 multicast address 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 argue that reserving a multicast address "just in case" is a bad idea. These potential functions, when defined in an I-D, can make the IANA request themselves based on their stated needs. Regards, Brian Ian Chakeres wrote: > I (and a bunch of other people) have expressed that there is a clear > desire to have a site scoped (larger than link actually) multicast > address for MANET routers. The purpose of this address would be to > allow greater than link scoped packets between MANET routers. > > I cannot enumerate everyone's thoughts, but the use-cases are be wide > and varied. It could be used for MANET router discovery, MANET Border > Router communication/coordination, Autoconf assistance protocols, > dissemination of multicast group information to assist > SMF/multicast/nhdp, plus lots of other potential uses. Another use > case could be to assist in securing certain messages (that don't > require hop-by-hop modification) in an end-to-end fashion over > multiple hops. > > Perhaps, it will not be used - but I think it is better to reserve it > now - than to wait and see. > > Ian Chakeres > > On 5/11/07, Brian Haberman wrote: >> First off, I have to echo Alex's concern. Can someone enumerate what >> the need is for the "greater than link-local" multicast address? >> >> Secondly, referencing the DVMRP-over-MOSPF variable scope multicast >> address doesn't make much sense. That functionality was added to the >> default list of reserved multicast addresses "just in case". As far as >> I know no one who still uses DVMRP over MOSPF. >> >> Regards, >> Brian >> >> Ian Chakeres wrote: >> > There is agreement that we need a well-known multicast address with a >> > scope larger than link. >> > >> > I believe that site scoping is the closest match with the expressed >> need. >> > >> > Using a non scoped address could cause leakage of manet routing >> > packets into the greater Internet. >> > >> > I would not mind switching the text from site-scope to variable scope >> > (assignment at all scopes). Do you think this would be better fit? >> > >> > There are a large list of protocols & assignments for variable >> > scoping. http://www.iana.org/assignments/ipv6-multicast-addresses >> > >> > This scoping assignment includes "DVMRP on MOSPF", a multicast routing >> > protocol. >> > >> > Ian Chakeres >> > >> > On 5/11/07, Alexandru Petrescu wrote: >> >> Ian Chakeres wrote: >> >> > I'd like to ask people to review this new revision. I'm also >> >> > reissuing WGLC. >> >> > >> >> > Here is a summary of the main changes: >> >> > >> >> > The draft has been revised to state clearly that a well-known UDP >> >> > port, LL multicast addresses, and SL multicast addresses are >> required >> >> > by the MANET WG. >> >> > >> >> > I tried to remove any text specifying operational >> requirements/advice >> >> > related to these well-known values, as this type of discussion >> >> > belongs in the protocol specifications. >> >> > >> >> > I choose to leave the site-local multicast addresses. This topic has >> >> > been discussed several times on the list and I believe there is >> >> > consensus that we should allocate these (IPv4/IPv6) addresses. >> >> >> >> What exactly is the need of a MANET protocol for a _site-local_ IPv6 >> >> multicast address? How is that need different from existing routing >> >> protocols (I'm asking because no existing routing protocol uses a >> >> _site-local_ IPv6 multicast address). >> >> >> >> Why can't a MANET routing protocol use an IPv6 multicast address >> with a >> >> scope non-permanently assigned (like ff15) or with Internet scope >> (like >> >> ff0e). >> >> >> >> In my oppinion a MANET routing protocol has no special needs for >> >> _site-local_ multicast addresses (although it may need IPv6 multicast >> >> addresses with larger than link). Because the definition of a >> 'site' is >> >> very vague in the static (non-MANET) world and has no meaning in a >> MANET >> >> environment. >> >> >> >> Alex >> >> >> >> > >> >> > Please sent any questions/comments to the list. Ian Chakeres >> >> > >> >> > On 5/10/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-02.txt Pages : 7 >> >> >> Date : 2007-5-10 >> >> >> >> >> >> This document enumerates IANA assignments for use by MANET WG >> >> >> protocols. 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-02.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-02.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-02.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 >> >> > >> >> >> >> >> > >> > >> > _______________________________________________ >> > manet mailing 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 May 15 11:43: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 1HnzBT-0001jB-UN; Tue, 15 May 2007 11:43:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HnzBS-0001j5-Dt for manet-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 11:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnzBS-0001ix-49 for manet@ietf.org; Tue, 15 May 2007 11:43:30 -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 1HnzBQ-0004Wv-Bb for manet@ietf.org; Tue, 15 May 2007 11:43:29 -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 l4FFhGAl008545; Tue, 15 May 2007 18:43:24 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 18:43:23 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 10:42:53 -0500 Received: from [10.162.64.182] ([10.162.64.182]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 10:42:52 -0500 Message-ID: <4649D4F5.6020004@nokia.com> Date: Tue, 15 May 2007 08:42:45 -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] Re: Comments about draft-ietf-manet-packetbb-04 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2007 15:42:52.0978 (UTC) FILETIME=[B329E120:01C79707] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Thomas Heide clausen , 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 Chris, ext Dearlove, Christopher (UK) wrote: >> Whether or not multiple addresses are collected is dictated by >> the meaning of the message, not the desire for a person to save >> space according to a parseable bucket of message fields. >> > > You should design your protocol using packetbb to use it > efficiently. There are generally several solutions to > each problem. For example if you want to separate addresses > into groups then one way is to put them in separate address > blocks. Another way uses address TLVs. There are doubtless > others. > All of my suggestions have been made with the goal of being able to use PacketBB efficiently. I had presumed that one would like to have addresses collected together in an address TLV to have some relationship to each other. Your suggestion seems to encourage people to put as many addresses as can be done into the same TLV in order to make use of the PacketBB as efficiently as possible. It does not have to be that way! My proposal for an alternate form of address representation is not all that hard to do -- a lot easier, in fact, than spending this much time looking for reasons not to do it. > >> I am not following this logic. Why should PacketBB depend on >> OLSR? All the basic message structure should be defined in >> PacketBB, and OLSR should make a normative reference on >> PacketBB in order to utilize the structures defined there. >> What am I missing? What would fail? Is there more text >> that needs to be pulled from OLSR and put into PacketBB? >> > > OLSR, i.e. OLSRv1, not OLSRv2. It's hardly possible to change > the former. > Nor was such an un-RFC-like thing suggested. The main reference to OLSR provides guidance to IANA to avoid allocating message types 1-4. Of course, OLSRv1 implementors won't be able to consult the IANA PacketBB table solely on the information provided in the OLSRv1 spec. So it seems more informative than normative to me. > >> Do you contend that no changes are possible unless >> (a) you have tested the new code, and >> (b) the voices of discussion that you hear but are not >> > on the mailing list approve? > > Changes are always possible. But not necessarily desirable. > My position is that there are pressures in various directions, > and where we are is the best balance of those pressures based > on proposals I've seen. > Didn't you say the best was the enemy of the good? > As for (a) - yes, there may not be an interoperability > requirement, but I want some running code, Yes. Running code is an asset. However, it is not the determining factor, as you well know. I am sure you have seen similar arguments before in other working groups. > and (b) yes, > all discussion should be on the list - but this list > has been pretty much useless over most of my time with > the IETF, it's really only been the last few months that > it's approached being a more usual IETF list. I'm on a lot of IETF lists, and there does not seem to be only one style or flavor of lists. But I hardly thought that the MANET mailing list was dysfunctional. I can skim past and disregard irrelevant messages as well as anyone else. > People > have got in the habit of bypassing it, and I can't make > them post here. Actually they tend to communicate directly > with Thomas rather than me. > I just cannot endorse a condemnation of the mailing list as justification for avoiding even the discussion of my proposals for improvement. > > ******************************************************************** > 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. > ******************************************************************** > > I guess you really didn't mean this. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue May 15 11:55: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 1HnzMx-0007yI-Lg; Tue, 15 May 2007 11:55:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HnzMw-0007yD-Rn for manet-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 11:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnzMw-0007y5-I0 for manet@ietf.org; Tue, 15 May 2007 11:55:22 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnzMv-0007I7-5c for manet@ietf.org; Tue, 15 May 2007 11:55:22 -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 l4FFtJKe028994 for ; Tue, 15 May 2007 16:55:19 +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 l4FFtJlp016050 for ; Tue, 15 May 2007 16:55:19 +0100 Received: from glkms0002.GREENLNK.NET ([10.15.184.2]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 15 May 2007 16:55:18 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0002.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Tue, 15 May 2007 16:55:18 +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: Comments about draft-ietf-manet-packetbb-04 Date: Tue, 15 May 2007 16:55:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: Comments about draft-ietf-manet-packetbb-04 Thread-Index: AceXCCS+fYKp8H1wS4SZBQRPNYCOvwAAAuew From: "Dearlove, Christopher \(UK\)" To: "Charles E. Perkins" X-OriginalArrivalTime: 15 May 2007 15:55:18.0303 (UTC) FILETIME=[6F6972F0:01C79709] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Thomas Heide clausen , 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 just cannot endorse a condemnation of the mailing list > as justification for avoiding even the discussion of my > proposals for improvement. I'm only going to comment on this. Again, not my point. My point was that the list was disfunctional (just look back in the archive a bit) and hence people got out of the habit of posting to it. I'm not supporting this - it made my life difficult when I first joined in this. But I think it is an explanation of how people have come to treat the list. Ian's been making good steps to improve matters, and things have picked up. But habits take longer to change. ******************************************************************** 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 May 15 12:34: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 1Hnzyi-000726-K5; Tue, 15 May 2007 12:34:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hnzyg-000721-Lo for manet-confirm+ok@megatron.ietf.org; Tue, 15 May 2007 12:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnzyg-00071t-C5 for manet@ietf.org; Tue, 15 May 2007 12:34:22 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnzye-0007Pc-Uz for manet@ietf.org; Tue, 15 May 2007 12:34:22 -0400 Received: from [128.93.62.246] (dhcp-rocq-246.inria.fr [128.93.62.246]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4FGYKQq032210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 May 2007 18:34:20 +0200 Message-ID: <4649E10A.5040007@inria.fr> Date: Tue, 15 May 2007 18:34:18 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "'manet'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 4649E10C.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [manet] DYMO RREQ flooding and super-flooding 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 see in DYMO spec (5.3.4) that a RREQ message can be retransmitted several times by a node if it receives copies on shorter routes. This reminds me the paper we did about this kind of super-flooding. Comparative Study of Routing Protocols for Mobile Ad Hoc Networks T. Clausen, P. Jacquet et L. Viennot Med-hoc-Net, 2002 http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz It gives the shortest path to OrigNode in hop count, but the number of retransmissions may be important and exceed the network size (can be quadratic in the network size per RREQ). I wonder if one could also add other metrics than simply hop count. For example RREQ could seek the path with average shortest delay by adding the last hop average link delay to the current weight carried by the RREQ. The RREQ would carry a bit indicating that average shortest delay is activated). Or the RREQ could look to the largest bandwidth route (in this case one take the minimum of the last hop bandwidth with the weight carried by the RREQ. Other metrics are possible (variance, etc). Best regards, Philippe _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 00:27: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 1HoB6q-0002Tr-CK; Wed, 16 May 2007 00:27:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoB6o-0002Tk-RG for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 00:27:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoB6o-0002Tc-HH for manet@ietf.org; Wed, 16 May 2007 00:27:30 -0400 Received: from ik-out-1112.google.com ([66.249.90.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoB6n-0005Eu-5j for manet@ietf.org; Wed, 16 May 2007 00:27:30 -0400 Received: by ik-out-1112.google.com with SMTP id c29so35050ika for ; Tue, 15 May 2007 21:27:28 -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=Rt+b4364pmWWqrMPEL8VYDYXM2ZNOqO/NkBrdy/PtSJbn96wTkEwDqJkUmVKvy1sxg7de8HJ5KM5FQ7WieZyiRaOfbuGdLr1D51aZPbAkC5q5exBEEZao8JHiQBbGNQYOJZxKddC+5JeqmzEVxV4y0q72Hpo9tKQrp6S0vs0ibc= 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=p5kSA/IHgFiU2O1CsykI0UzHi56FDioYZcsUQUo3Pb570RZRbYjg2HQ4JapTWULZZj4SotSBq6xYU12RPhn7z4HwUpGqbpPnvZfzeExTT871gqG8NHf3iE5xacVcm3TUnT2fbq9GiOz00MawpcEw6ji11jgHj3hWrE0ID9yZZw0= Received: by 10.67.116.3 with SMTP id t3mr6405501ugm.1179289648475; Tue, 15 May 2007 21:27:28 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Tue, 15 May 2007 21:27:28 -0700 (PDT) Message-ID: <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> Date: Wed, 16 May 2007 09:57:28 +0530 From: "Ian Chakeres" To: "Philippe Jacquet" Subject: Re: [manet] DYMO RREQ flooding and super-flooding In-Reply-To: <4649E10A.5040007@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4649E10A.5040007@inria.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 had done some work on using different metrics by introducing delay during route discovery to influence route selection. Here is the paper info: Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent Influence of Path Selection in Heterogeneous Ad hoc Networks." Proceedings of the 15th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), Barcelona, Spain, September 2004. For the base spec we are not including any complex metrics, but instead rely on DV & hopcount (if included) or other techniques that work under these assumptions (like the paper above). I think some additional TLVs and new functionality to enable DYMO to support more complex metrics would be interesting. Ian On 5/15/07, Philippe Jacquet wrote: > Hello, folks, > > I see in DYMO spec (5.3.4) that a RREQ message can be retransmitted > several times by a node if it receives copies on shorter routes. > > This reminds me the paper we did about this kind of super-flooding. > > Comparative Study of Routing Protocols for Mobile Ad Hoc Networks > T. Clausen, P. Jacquet et L. Viennot > Med-hoc-Net, 2002 > > > http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz > > It gives the shortest path to OrigNode in hop count, but the number of > retransmissions may be important and exceed the network size (can be > quadratic in the network size per RREQ). > > I wonder if one could also add other metrics than simply hop count. For > example RREQ could seek the path with average shortest delay by adding > the last hop average link delay to the current weight carried by the > RREQ. The RREQ would carry a bit indicating that average shortest delay > is activated). Or the RREQ could look to the largest bandwidth route (in > this case one take the minimum of the last hop bandwidth with the weight > carried by the RREQ. > > Other metrics are possible (variance, etc). > > 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 May 16 02:46: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 1HoDGo-0002fV-PO; Wed, 16 May 2007 02:45:58 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoDGn-0002fQ-Hq for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 02:45:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoDGn-0002fI-8F for manet@ietf.org; Wed, 16 May 2007 02:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoDFf-0001cG-6z for manet@ietf.org; Wed, 16 May 2007 02:44:47 -0400 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoDFe-0003NS-10 for manet@ietf.org; Wed, 16 May 2007 02:44:47 -0400 Received: by wx-out-0506.google.com with SMTP id h31so83942wxd for ; Tue, 15 May 2007 23:44: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; b=FyeesPRFZztnXPxZoWtGz5W2B6HyKBsenc/K4p51P9CnoVJPf9+F+lNBGgSqhkVqL/HZaHf23NywMPGEnI06T4WThOWTT/Dc8kGR/axnlyNnQeSJITDbq3zBl6hpBfS0qFmrxfl1Hul3OnWUn+1yR/naxc9vIlsk1bNbi4cL2GQ= 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=owVXoV9kve9rL5+ab9W7AMgD4Ca0BE2oS/+sczLQbjzGgE2e/MM0dWrKgnYh/UTVAf0Krc1yQPX08sNTq/sg6f7omRhv/xqj2es2ihY0ibCS1BaLfoITLwZ9c4Ek3uXZSS8FyyjFNCItmI43+AL5p3YYry9Sw96xF2fGERMJJAA= Received: by 10.70.59.9 with SMTP id h9mr13066428wxa.1179297885807; Tue, 15 May 2007 23:44:45 -0700 (PDT) Received: by 10.70.37.3 with HTTP; Tue, 15 May 2007 23:44:45 -0700 (PDT) Message-ID: Date: Wed, 16 May 2007 08:44:45 +0200 From: "Eder Miguel" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-TMDA-Confirmed: Wed, 16 May 2007 02:45:57 -0400 Subject: [manet] M-Grid Mobility Model 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="===============1044037340==" Errors-To: manet-bounces@ietf.org --===============1044037340== Content-Type: multipart/alternative; boundary="----=_Part_7108_5598134.1179297885763" ------=_Part_7108_5598134.1179297885763 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I'm working on a modification of AODV and I'd like to simulate some urban scenarios. I've read about M-GRID mobility model but I haven't found it. Does anyone know where to find this mobility model? Thanks in advance. Eder. ------=_Part_7108_5598134.1179297885763 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I'm working on a modification of AODV and I'd like to simulate some urban scenarios. I've read about M-GRID mobility model but I haven't found it. Does anyone know where to find this mobility model?

Thanks in advance.

Eder.
------=_Part_7108_5598134.1179297885763-- --===============1044037340== 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 --===============1044037340==-- From manet-bounces@ietf.org Wed May 16 04:32: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 1HoEvv-00069m-Lo; Wed, 16 May 2007 04:32:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoEvt-00069d-Ne for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 04:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoEvt-00069V-CE for manet@ietf.org; Wed, 16 May 2007 04:32:29 -0400 Received: from mail.di.uniroma1.it ([151.100.17.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoEvr-0006lO-Ei for manet@ietf.org; Wed, 16 May 2007 04:32:29 -0400 Received: from [151.100.17.90] (unknown [151.100.17.90]) by mail.di.uniroma1.it (Postfix) with ESMTP id 1FF2B1BD651 for ; Wed, 16 May 2007 10:15:34 +0200 (CEST) Message-ID: <464AC195.7080704@di.uniroma1.it> Date: Wed, 16 May 2007 10:32:21 +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 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Subject: [manet] ACM HealthNet 2007 - MobiSys Workshop: 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 We apologize in advance if you receive multiple copies of this CFP. ------------------------------------------------------------ ************************************************************ CALL FOR PARTICIPATION ACM HealthNet 2007 ********** EARLY REGISTRATION DEADLINE EXTENDED ********** to MAY 18, 2007 Please, check http://healthnet07.cs.uiuc.edu/ for venue and registration information ************************************************************ The 1st International Workshop on Systems and Networking Support for Healthcare and Assisted Living Environments Sponsored by ACM SIGMOBILE in conjunction with ACM MobiSys 2007 =20 Corporate sponsors: Microsoft (gold), IBM (silver) Jointly organized by * The University of Illinois at Urbana Champaign, US, and * Universit=E0 di Roma "La Sapienza," Italy ************************************************************ You are cordially invited to join us in San Juan, Puerto Rico, on June 11, 2007 for participating to ACM HealthNet 2007. The workshop is devoted to presenting and discussing novel findings and approaches for healthcare systems and networks. ****************** WORKSHOP FEATURES ******************* * 13 full papers * * 7 research posters * ************************************************************ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 PROGRAM =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Session 1: Access and Security * Rendezvous-based access control for medical records in the pre-hospital environment Feike Dillema (Universitetet i Troms=D8, NO); Simone Lupetti (Universitetet i Troms, NO) * Addressing Security in Medical Sensor Networks Kriangsiri Malasri (University of Memphis, US); Lan Wang (University of Memphis, US) * Context-aware Access to Public Shared Devices David Jea (University of California, Los Angeles, US); Ian Yap (University of California, Los Angeles, US); Mani Srivastava (University of California, Los Angeles, US) Session 2: Network Architectures and Support * Investigating Network Architectures for Body Sensor Networks Anirudh Natarajan (National University of Singapore, SG); Mehul Motani (National University of Singapore, SG); Buddhika De Silva (University of Singapore, SG); Kok Kiong Yap (Stanford University, US); Kee Chaing Chua (National University of Singapore, SG) * H-MAC, Heartbeat Driven Medium Access Control for Body Sensor Networks Huaming Li (Michigan Technological University, US) * Towards Highly-Available WSNs for Assisted Living Safwan Al-Omari (Wayne State Univeristy, US); Weisong Shi (Wayne State University, US) * Energy-Efficient Multi-hop Medical Sensor Networking Antonio Ruzzelli (University College Dublin, IE); Raja Jurdak (University College Dublin, IE); Gregory O'Hare (University College Dublin, IE); Peter van der Stok (Philips Research Laboratories, NL) Session 3: System Design * Participatory User Centered Design Techniques for a Large Scale Ad-Hoc Health Information System Tia Gao (John Hopkins University Applied Physics Lab, US); Tammara Massey (UCLA, US); Leo Selavo (University of Virginia, US); Matt Welsh (Harvard University, US); Majid Sarrafzadeh (UCLA, US) * Investigating and Supporting Health Management Practices of Individuals with Diabetes Lena Mamykina (Siemens Corporate Research, Inc., US); Elizabeth Mynatt (Georgia Institute of Technology, USA, US) * MACCS: An Industrial Study of Hands-Free Wireless Communications for Mobile Healthcare Workers Michael Sammon (Avaya Labs Research, US); Lynne Brotman (Avaya Labs Research, US); Ed Peebles (Avaya Labs Research, US); Dor=EFe Seligmann (Avaya Labs Research, US) Session 4: Research Posters * A Feature Combination Approach for the Detection of Early Morning Bathroom Activities with Wireless Sensors Nuri Ince (University of Minnesota, US); Cheol-Hong Min (University of Minnesota, US); Ahmed Tewfik (University of Minnesota, US) * A Resource Optimized Physical Movement Monitoring Scheme for Environmental and on-Body Sensor Networks Antti Vehkaoja (Tampere University of Technology, FI); Sameer Iyengar (UC Berkeley, US); Mari Zakrzewski (Tampere University of Technology, FI); Roozbeh Jafari (University of California, Berkeley, US); Ruzena Bajcsy (University of California, US); Steve Glaser (University of California at Berkeley, US); Jukka Lekkala (Tampere University of Technology, FI); Shankar Sastry (UC Berkeley, US)/ * Accelerometer-Based Human Abnormal Movement Detection in Wireless Sensor Networks Timothy Burchfield (University of Texas at Dallas, US); Subbarayan Venkatesan (University of Texas at Dallas, US) * An Integrated Wireless Sensing and Mobile Processing Architecture for Assisted Living and Healthcare Applications Serhan Dagtas (University of Arkansas at Little Rock, US) * Automatic Administration of the Get Up and Go Test Dounia Berrada (Georgia Institute of Technology, US); Mario Romero (Georgia Institute of Technology, US); Gregory Abowd (Georgia Institute of Technology, US); Marion Blount (IBM Research, US); John Davis (IBM, US) * Health-OS: A Positioning Paper Nuria Oliver (Microsoft Research, Redmond, US); Darko Kirovski (Microsoft Research, US); Desney Tan (Microsoft Research, US); Mike Sinclair (Microsoft Research, US) * Meditrina: Addressing the System-level Challenges to Ambient Assisted Living Albert Harris III (University of Illinois at Urbana-Champaign, US= ); Rob Kooper (UIUC, US); Robin Kravets (University of Illinois at Urbana-Champaign, US); Gaia Maselli (University of Rome "La Sapienza," IT); Chiara Petrioli (University of Rome "La Sapienza," IT) Session 5: Data and Event Management * Universal Real-Time Navigational Assistance (URNA): An Urban Bluetooth Beacon for the Blind Shawn Bohonos (UCSC, US); Alexander Lee (UCSC, US); Amir Malik (UCSC, US); Chung Thai (UCSC, US); Roberto Manduchi (University of California Santa Cruz, US) * Algorithm to Automatically Detect Abnormally Long Periods of Inactivity in a Home Paul Cuddihy (GE Global Research, US); Jenny Weisenberg (GE Global Research, US); Catherine Graichen (GE Global Research, US); Meena Ganesh (General Electric Company, US) * A Time-and-Value Centric Provenance Model and Architecture for Medical Event Streams Archan Misra (IBM TJ Watson Research Center, US); John Davis (IBM, US); Marion Blount (IBM Research, US); Daby Sow (IBM Watson, US); Min Wang (IBM Research, US) --=20 Gaia Maselli, Postdoc HealthNet 2007 Publicity Chair Computer Science Dept. Rome University "La Sapienza" Via Salaria 113, 00198 Rome Italy _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 04:50: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 1HoFDN-0008Ak-Fr; Wed, 16 May 2007 04:50:33 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoFDL-00089o-Jl for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 04:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoFDL-00087Z-6u for manet@ietf.org; Wed, 16 May 2007 04:50:31 -0400 Received: from mail.gdatech.co.in ([202.144.30.226] helo=gdatech.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoFDJ-0003ql-NN for manet@ietf.org; Wed, 16 May 2007 04:50:31 -0400 Received: from [192.168.0.2] (localhost.localdomain [127.0.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id C9D1B8780D1 for ; Wed, 16 May 2007 01:50:25 -0700 (PDT) X-Propel-Return-Path: Received: from gdatech.co.in ([192.168.0.3]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.0.6841-branch_6613 $Rev: 6586 $) id gP3jr75g8Op0; Wed, 16 May 2007 01:50:25 -0700 Received: from mail.gdatech.co.in (unknown [192.168.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id 8FF898780C8 for ; Wed, 16 May 2007 01:50:25 -0700 (PDT) Received: (qmail 30429 invoked by uid 89); 16 May 2007 09:00:24 -0000 Received: from unknown (HELO ?192.168.3.90?) (b.nagarajan@192.168.3.90) by 0 with SMTP; 16 May 2007 09:00:24 -0000 Message-ID: <464AC5D5.3010306@gdatech.co.in> Date: Wed, 16 May 2007 14:20:29 +0530 From: nagarajan 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-Propel-ID: gP3jr75g8Op0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [manet] Diff b/w Wireless Mesh Networks and MANETs 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 new to this wireless domain. I like to know the functional difference between Wireless mesh networks and MANETs. I appreciate your support to kick off my process. Thanks and regards, Nagarajan _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 05:14: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 1HoFaJ-0006J0-G3; Wed, 16 May 2007 05:14:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoFaI-0006Iu-9N for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 05:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoFaH-0006Im-V5 for manet@ietf.org; Wed, 16 May 2007 05:14:13 -0400 Received: from lneuilly-152-22-94-45.w193-251.abo.wanadoo.fr ([193.251.40.45] helo=ngk.cbtrob.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoFaG-0003DO-JE for manet@ietf.org; Wed, 16 May 2007 05:14:13 -0400 Received: from k800-cat.cbtrob.net ([192.168.1.26]) by ngk.cbtrob.net with esmtp (Exim 4.63) (envelope-from ) id 1HoFeR-00056U-VO; Wed, 16 May 2007 11:18:39 +0200 Message-ID: <464ACB80.6040404@n0rg.org> Date: Wed, 16 May 2007 11:14:40 +0200 From: Laurent Dehoey User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: nagarajan References: <464AC5D5.3010306@gdatech.co.in> In-Reply-To: <464AC5D5.3010306@gdatech.co.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 192.168.1.26 X-SA-Exim-Rcpt-To: b.nagarajan@gdatech.co.in, manet@ietf.org, L+@n0rg.org X-SA-Exim-Mail-From: manet2@n0rg.org X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on ngk.cbtrob.net X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.7-deb Subject: Re: [manet] Diff b/w Wireless Mesh Networks and MANETs X-SA-Exim-Version: 4.2.1 (built Tue, 09 Jan 2007 17:23:22 +0000) X-SA-Exim-Scanned: Yes (on ngk.cbtrob.net) X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Hi Nagarajan the difference can be considered "subtle" and found with the help of the letter "M" in MANET one can imagine mesh networks as a fix wireless backbone where clients of the backbone moves along that static backbone as opposed to MANETs where the moving clients *are* the wireless backbone. ...this is a blurred "frontier" : when all the nodes of a manet are static,.. well.. don't we have a mesh network ? HTH Laurent nagarajan wrote: > Hi all, > > I am new to this wireless domain. I like to know the functional > difference between Wireless mesh networks and MANETs. I appreciate > your support to kick off my process. > > Thanks and regards, > Nagarajan > > > _______________________________________________ > manet mailing 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 May 16 05:29: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 1HoFom-00055G-9j; Wed, 16 May 2007 05:29:12 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoFok-000553-JK for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 05:29:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoFok-00054v-9E for manet@ietf.org; Wed, 16 May 2007 05:29:10 -0400 Received: from mail.gdatech.co.in ([202.144.30.226] helo=gdatech.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoFoj-0006yQ-O8 for manet@ietf.org; Wed, 16 May 2007 05:29:10 -0400 Received: from [192.168.0.2] (localhost.localdomain [127.0.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id D2849878064 for ; Wed, 16 May 2007 02:29:07 -0700 (PDT) X-Propel-Return-Path: Received: from gdatech.co.in ([192.168.0.3]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.0.6841-branch_6613 $Rev: 6586 $) id gP3jr75g9t71; Wed, 16 May 2007 02:29:07 -0700 Received: from mail.gdatech.co.in (unknown [192.168.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id 7D0CE87806E for ; Wed, 16 May 2007 02:29:07 -0700 (PDT) Received: (qmail 10051 invoked by uid 89); 16 May 2007 09:39:06 -0000 Received: from unknown (HELO ?192.168.3.90?) (b.nagarajan@192.168.3.90) by 0 with SMTP; 16 May 2007 09:39:06 -0000 Message-ID: <464ACEE7.1060906@gdatech.co.in> Date: Wed, 16 May 2007 14:59:11 +0530 From: nagarajan User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Laurent Dehoey Subject: Re: [manet] Diff b/w Wireless Mesh Networks and MANETs References: <464AC5D5.3010306@gdatech.co.in> <464ACB80.6040404@n0rg.org> In-Reply-To: <464ACB80.6040404@n0rg.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Propel-ID: gP3jr75g9t71 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Hi Laurent, I am very much clear with your explanation. Wireless mesh networks are static in network topology and architecture whereas the MANETs need not be static in network topology and architecture. I would also like to know the routing protocols recommended for MANETs like AODV, OLSR etc suits with Wireless Mesh Networks. Looking forward your reply Thanks and regards, Nagarajan Laurent Dehoey wrote: > Hi Nagarajan > > the difference can be considered "subtle" and found with the help of > the letter "M" in MANET > > one can imagine mesh networks as a fix wireless backbone where clients > of the backbone moves along that static backbone as opposed to MANETs > where the moving clients *are* the wireless backbone. > > ...this is a blurred "frontier" : when all the nodes of a manet are > static,.. well.. don't we have a mesh network ? > > HTH > Laurent > > nagarajan wrote: >> Hi all, >> >> I am new to this wireless domain. I like to know the functional >> difference between Wireless mesh networks and MANETs. I appreciate >> your support to kick off my process. >> >> Thanks and regards, >> Nagarajan >> >> >> _______________________________________________ >> manet mailing 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 May 16 05:41: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 1HoG12-00055e-Ip; Wed, 16 May 2007 05:41:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoG10-00055U-Ab for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 05:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoG10-00055L-0a for manet@ietf.org; Wed, 16 May 2007 05:41:50 -0400 Received: from smtp03.bis.na.blackberry.com ([216.9.248.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoG0y-0001gI-Oq for manet@ietf.org; Wed, 16 May 2007 05:41:49 -0400 Message-ID: <814726457-1179308504-cardhu_blackberry.rim.net-2113627483-@bxe032-cell01.bisx.prod.on.blackberry> References: <464AC5D5.3010306@gdatech.co.in> <464ACB80.6040404@n0rg.org> <464ACEE7.1060906@gdatech.co.in> In-Reply-To: <464ACEE7.1060906@gdatech.co.in> Sensitivity: Normal Importance: Normal To: "nagarajan" , "Laurent Dehoey" Subject: Re: [manet] Diff b/w Wireless Mesh Networks and MANETs From: "=?UTF-8?B?Q2hyaXN0aWFuIEt1aHR6?=" Date: Wed, 16 May 2007 09:40:14 +0000 MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: christian@kuhtz.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1183903520==" Errors-To: manet-bounces@ietf.org --===============1183903520== Content-Transfer-Encoding: base64 Content-type: text/plain DQpMaWtld2lzZSwgd2lyZWxlc3MgbWVzaCBuZXR3b3JrcyBjYW4gYWxzbyBoYXZlIG1vYmlsZSBj b21wb25lbnRzIHRvIHRoZW0sIHdoZXJlIHBvcnRpb25zIG9mIHRoZSBtZXNoIGFyZSBwbGFjZWQg b24gdmVoaWNsZXMgZXRjLg0KDQpCZXN0IFJlZ2FyZHMsDQpDaHJpc3RpYW4gDQoNCiAgDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuYWdhcmFqYW4gPGIubmFnYXJhamFuQGdk YXRlY2guY28uaW4+DQpEYXRlOiBXZWQsIDE2IE1heSAyMDA3IDE0OjU5OjExIA0KVG86TGF1cmVu dCBEZWhvZXkgPG1hbmV0MkBuMHJnLm9yZz4NCkNjOm1hbmV0IDxtYW5ldEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbbWFuZXRdIERpZmYgYi93IFdpcmVsZXNzIE1lc2ggTmV0d29ya3MgYW5kIE1B TkVUcw0KDQogICAgSGkgTGF1cmVudCwNCg0KICAgICAgICAgICAgICAgICAgIEkgYW0gdmVyeSBt dWNoIGNsZWFyIHdpdGggeW91ciBleHBsYW5hdGlvbi4gV2lyZWxlc3MgDQptZXNoIG5ldHdvcmtz IGFyZSBzdGF0aWMgaW4gbmV0d29yayB0b3BvbG9neSBhbmQgYXJjaGl0ZWN0dXJlIHdoZXJlYXMg DQp0aGUgTUFORVRzIG5lZWQgbm90IGJlIHN0YXRpYyBpbiBuZXR3b3JrIHRvcG9sb2d5IGFuZCBh cmNoaXRlY3R1cmUuDQoNCiAgICAgICAgICAgICAgICBJIHdvdWxkIGFsc28gbGlrZSB0byBrbm93 IHRoZSByb3V0aW5nIHByb3RvY29scyANCnJlY29tbWVuZGVkIGZvciBNQU5FVHMgbGlrZSBBT0RW LCBPTFNSIGV0YyBzdWl0cyB3aXRoIFdpcmVsZXNzIE1lc2ggDQpOZXR3b3Jrcy4NCg0KICAgIExv b2tpbmcgZm9yd2FyZCB5b3VyIHJlcGx5DQoNClRoYW5rcyBhbmQgcmVnYXJkcywNCk5hZ2FyYWph bg0KDQpMYXVyZW50IERlaG9leSB3cm90ZToNCj4gSGkgTmFnYXJhamFuDQo+DQo+IHRoZSBkaWZm ZXJlbmNlIGNhbiBiZSBjb25zaWRlcmVkICJzdWJ0bGUiIGFuZCBmb3VuZCB3aXRoIHRoZSBoZWxw IG9mIA0KPiB0aGUgbGV0dGVyICJNIiBpbiBNQU5FVA0KPg0KPiBvbmUgY2FuIGltYWdpbmUgbWVz aCBuZXR3b3JrcyBhcyBhIGZpeCB3aXJlbGVzcyBiYWNrYm9uZSB3aGVyZSBjbGllbnRzIA0KPiBv ZiB0aGUgYmFja2JvbmUgbW92ZXMgYWxvbmcgdGhhdCBzdGF0aWMgYmFja2JvbmUgYXMgb3Bwb3Nl ZCB0byBNQU5FVHMgDQo+IHdoZXJlIHRoZSBtb3ZpbmcgY2xpZW50cyAqYXJlKiB0aGUgd2lyZWxl c3MgYmFja2JvbmUuDQo+DQo+IC4uLnRoaXMgaXMgYSBibHVycmVkICJmcm9udGllciIgOiB3aGVu IGFsbCB0aGUgbm9kZXMgb2YgYSBtYW5ldCBhcmUgDQo+IHN0YXRpYywuLiB3ZWxsLi4gZG9uJ3Qg d2UgaGF2ZSBhIG1lc2ggbmV0d29yayA/DQo+DQo+IEhUSA0KPiBMYXVyZW50DQo+DQo+IG5hZ2Fy YWphbiB3cm90ZToNCj4+IEhpIGFsbCwNCj4+DQo+PiAgICAgICBJIGFtIG5ldyB0byB0aGlzIHdp cmVsZXNzIGRvbWFpbi4gSSBsaWtlIHRvIGtub3cgdGhlIGZ1bmN0aW9uYWwgDQo+PiBkaWZmZXJl bmNlIGJldHdlZW4gV2lyZWxlc3MgbWVzaCBuZXR3b3JrcyBhbmQgTUFORVRzLiBJIGFwcHJlY2lh dGUgDQo+PiB5b3VyIHN1cHBvcnQgdG8ga2ljayBvZmYgbXkgcHJvY2Vzcy4NCj4+DQo+PiBUaGFu a3MgYW5kIHJlZ2FyZHMsDQo+PiBOYWdhcmFqYW4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG1hbmV0IG1haWxpbmcgbGlzdA0K Pj4gbWFuZXRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21hbmV0DQo+Pg0KPj4NCj4NCj4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg== --===============1183903520== 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 --===============1183903520==-- From manet-bounces@ietf.org Wed May 16 05:47: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 1HoG6E-0000fW-Mw; Wed, 16 May 2007 05:47:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoG6D-0000fR-Vw for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 05:47:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoG6D-0000fJ-Lj for manet@ietf.org; Wed, 16 May 2007 05:47:13 -0400 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoG6B-0002oe-E3 for manet@ietf.org; Wed, 16 May 2007 05:47:13 -0400 Received: by an-out-0708.google.com with SMTP id c34so26192anc for ; Wed, 16 May 2007 02:47:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Bck6u26ZsTwDYiS+5RYWvko7zwKQJLKm5mRTMwVPHzcUv0kd45lI3HrhdafS8pH0l4K7pIrwfrLKbmy5zI/rjJPjAtWM2fXz3B1nrbOG5S9ETFMrnaAHeXEqMuAQgQDE0Tj+VEzHyI8UYarx8aXUqumtzh9xBYwHsnMSF6TlNMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=St5wnF55WzVpD7CNEhV6rm4zojfEKkiQDCgUGGVPVacUo+vc3GSh5UG/fwQ48uWOGQnvVURM8SqzKMOi5P2Yvj2WQd27POZIcQ0gHZYTsxNfA1FAo0yXDSgHHeGVvtJ/eKzfcV3dPNYhfafCGGrc1gJDJffWxkwnSVYgdnxSZD0= Received: by 10.100.240.19 with SMTP id n19mr5935501anh.1179308830198; Wed, 16 May 2007 02:47:10 -0700 (PDT) Received: by 10.100.174.2 with HTTP; Wed, 16 May 2007 02:47:09 -0700 (PDT) Message-ID: <957d36030705160247u2f406edcp6136295c1d9f913d@mail.gmail.com> Date: Wed, 16 May 2007 10:47:09 +0100 From: "Siva Sivavakeesar" To: manet@ietf.org 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: ea4ac80f790299f943f0a53be7e1a21a Subject: [manet] Mobile Ad hoc Network (MANET) - Testbed Experiments with Mobility 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 there, I am sure that one of you should be able to help me out. I have been involved with Mobile Ad hoc Network (MANET) testbed experiments, in which I am supposed to develop my own routing protocol and compare its performance with that of another well known protocol called AODV. My testbed consists of 6 nodes in total and runs Fedora Core 5. I am using Intel Pro Wireless (IPW) 2200BG pci WiFi card and downloaded the necessary source for the driver and ieee802.11. Given that mobility needs to be incorporated, for a meaningful fair comparison, it should be ensured that in each test run the nodes take the same trajectories. In order to facilitate this, the APE testbed (http://apetestbed.sourceforge.net/) has a new mobility metric for real world tests called "virtual mobility" (vM) that provides movement instructions to test-participants during the actual testruns. I wish to incorporate the same functionality in my experiments whereby users are given movement instructions during each test run. I learnt that each node needs to log in details pertaining to each received frame such as RSSI and SNR for this purpose. I modified my driver code to gather this low-level information. My question now is how to make use of such information to build my own "Virtual Mobility" model that helps users take exact movement patterns during each test run. Thanks in advance for taking your invaluable time to answer my question. Best Regards, Siva Dr Siva Sivavakeesar _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 07:47: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 1HoHyi-0003vI-GI; Wed, 16 May 2007 07:47:36 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoHyh-0003v8-0t for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 07:47:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoHyg-0003uz-Mw; Wed, 16 May 2007 07:47:34 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoHyf-0001hh-7y; Wed, 16 May 2007 07:47:34 -0400 Received: from [192.168.112.191] (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4GBlVNW022323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 May 2007 13:47:31 +0200 Message-ID: <464AEF53.7020506@inria.fr> Date: Wed, 16 May 2007 13:47:31 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] DYMO RREQ flooding and super-flooding References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> In-Reply-To: <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at concorde with ID 464AEF53.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id l4GBlVNW022323 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 Ian, I don't understand how the method you described in your paper for=20 AODV can be applied for DYMO. Assume you delay the RREQ retransmission on the two-hop route because=20 the routers have low willingness, so that it is transmitted after the=20 three hops route. Anyhow the two-hop RREQ will be relayed since it has a=20 smaller hop-count and the shortest route will be in fact selected. Or am=20 I wrong? Philippe Ian Chakeres a =E9crit : > I had done some work on using different metrics by introducing delay > during route discovery to influence route selection. >=20 > Here is the paper info: >=20 > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent Influence > of Path Selection in Heterogeneous Ad hoc Networks." Proceedings of > the 15th IEEE International Symposium on Personal, Indoor and Mobile > Radio Communications (PIMRC), Barcelona, Spain, September 2004. >=20 > For the base spec we are not including any complex metrics, but > instead rely on DV & hopcount (if included) or other techniques that > work under these assumptions (like the paper above). >=20 > I think some additional TLVs and new functionality to enable DYMO to > support more complex metrics would be interesting. >=20 > Ian >=20 > On 5/15/07, Philippe Jacquet wrote: >> Hello, folks, >> >> I see in DYMO spec (5.3.4) that a RREQ message can be retransmitted >> several times by a node if it receives copies on shorter routes. >> >> This reminds me the paper we did about this kind of super-flooding. >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc Networks >> T. Clausen, P. Jacquet et L. Viennot >> Med-hoc-Net, 2002 >> >> >> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz >> >> It gives the shortest path to OrigNode in hop count, but the number of >> retransmissions may be important and exceed the network size (can be >> quadratic in the network size per RREQ). >> >> I wonder if one could also add other metrics than simply hop count. Fo= r >> example RREQ could seek the path with average shortest delay by adding >> the last hop average link delay to the current weight carried by the >> RREQ. The RREQ would carry a bit indicating that average shortest dela= y >> is activated). Or the RREQ could look to the largest bandwidth route (= in >> this case one take the minimum of the last hop bandwidth with the weig= ht >> carried by the RREQ. >> >> Other metrics are possible (variance, etc). >> >> Best regards, >> Philippe >> >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 08:02: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 1HoICv-00057R-DD; Wed, 16 May 2007 08:02:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoICt-00057D-6Q for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 08:02:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoICs-000572-Rn for manet@ietf.org; Wed, 16 May 2007 08:02:14 -0400 Received: from hu-out-0506.google.com ([72.14.214.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HoICq-00082u-8E for manet@ietf.org; Wed, 16 May 2007 08:02:14 -0400 Received: by hu-out-0506.google.com with SMTP id 38so259huc for ; Wed, 16 May 2007 05:01: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=krmHRpO0Dkb7tLS/pZJ5nbT9CMb8reWOwnmqGl7IM4+/wyReP7k7ZGvqzeZe3R8stv+9AFC7BRb1ZryobUGgEkUAokdPbew/dvornIWPBavUxXh2jFV2JxDbPcSU50s6qvioMWthQ55L4skROpUe08zpNL3kdB1/VmLqGvqzzY8= 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=cxUO5kU+v04xwwo07wZMJpNCpIiKkvGtME4LuZkfr5p/Gfw05uwsc9inpfLnm26vLyEKwdtMiuye1ynvla0gD8Uu0WGGl2XJ1GEonGiEaqD9Kw57eiKuo11HZwnI4TFWmp5+pzfviwFni5jJRjvOjf9TIygYZQCaUVGmOncUw+g= Received: by 10.78.162.4 with SMTP id k4mr2815981hue.1179316899244; Wed, 16 May 2007 05:01:39 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Wed, 16 May 2007 05:01:38 -0700 (PDT) Message-ID: <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> Date: Wed, 16 May 2007 17:31:38 +0530 From: "Ian Chakeres" To: "Philippe Jacquet" Subject: Re: [manet] DYMO RREQ flooding and super-flooding In-Reply-To: <464AEF53.7020506@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 don't include hop count information, it will not be used in the decision making. If you were interested in using "fasted RREQ" path, you would not include the hop count information. Ian On 5/16/07, Philippe Jacquet wrote: > Ian, I don't understand how the method you described in your paper for > AODV can be applied for DYMO. > > Assume you delay the RREQ retransmission on the two-hop route because > the routers have low willingness, so that it is transmitted after the > three hops route. Anyhow the two-hop RREQ will be relayed since it has a > smaller hop-count and the shortest route will be in fact selected. Or am > I wrong? > > Philippe > > Ian Chakeres a =E9crit : > > I had done some work on using different metrics by introducing delay > > during route discovery to influence route selection. > > > > Here is the paper info: > > > > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent Influence > > of Path Selection in Heterogeneous Ad hoc Networks." Proceedings of > > the 15th IEEE International Symposium on Personal, Indoor and Mobile > > Radio Communications (PIMRC), Barcelona, Spain, September 2004. > > > > For the base spec we are not including any complex metrics, but > > instead rely on DV & hopcount (if included) or other techniques that > > work under these assumptions (like the paper above). > > > > I think some additional TLVs and new functionality to enable DYMO to > > support more complex metrics would be interesting. > > > > Ian > > > > On 5/15/07, Philippe Jacquet wrote: > >> Hello, folks, > >> > >> I see in DYMO spec (5.3.4) that a RREQ message can be retransmitted > >> several times by a node if it receives copies on shorter routes. > >> > >> This reminds me the paper we did about this kind of super-flooding. > >> > >> Comparative Study of Routing Protocols for Mobile Ad Hoc Networks > >> T. Clausen, P. Jacquet et L. Viennot > >> Med-hoc-Net, 2002 > >> > >> > >> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz > >> > >> It gives the shortest path to OrigNode in hop count, but the number of > >> retransmissions may be important and exceed the network size (can be > >> quadratic in the network size per RREQ). > >> > >> I wonder if one could also add other metrics than simply hop count. Fo= r > >> example RREQ could seek the path with average shortest delay by adding > >> the last hop average link delay to the current weight carried by the > >> RREQ. The RREQ would carry a bit indicating that average shortest dela= y > >> is activated). Or the RREQ could look to the largest bandwidth route (= in > >> this case one take the minimum of the last hop bandwidth with the weig= ht > >> carried by the RREQ. > >> > >> Other metrics are possible (variance, etc). > >> > >> 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 > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 09:04: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 1HoJAe-0002dY-HU; Wed, 16 May 2007 09:04:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoJAc-0002Vs-Aj for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 09:03:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJAc-0002Ve-0w; Wed, 16 May 2007 09:03:58 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoJAa-000056-HR; Wed, 16 May 2007 09:03:58 -0400 Received: from [192.168.112.191] (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4GD3s6L012182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 May 2007 15:03:55 +0200 Message-ID: <464B013A.6070601@inria.fr> Date: Wed, 16 May 2007 15:03:54 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] DYMO RREQ flooding and super-flooding References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> In-Reply-To: <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at concorde with ID 464B013B.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 concorde.inria.fr id l4GD3s6L012182 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 I didn't know that you could disable hop counter, I thought=20 MsgHdr.HopCnt was mandatory in RREQ message. In case you use super-flooding, should you put a limit in the number of=20 retransmissions per node in order to avoid a flooding explosion? Philippe Ian Chakeres a =E9crit : > If you don't include hop count information, it will not be used in the > decision making. >=20 > If you were interested in using "fasted RREQ" path, you would not > include the hop count information. >=20 > Ian >=20 > On 5/16/07, Philippe Jacquet wrote: >> Ian, I don't understand how the method you described in your paper for >> AODV can be applied for DYMO. >> >> Assume you delay the RREQ retransmission on the two-hop route because >> the routers have low willingness, so that it is transmitted after the >> three hops route. Anyhow the two-hop RREQ will be relayed since it has= a >> smaller hop-count and the shortest route will be in fact selected. Or = am >> I wrong? >> >> Philippe >> >> Ian Chakeres a =E9crit : >> > I had done some work on using different metrics by introducing delay >> > during route discovery to influence route selection. >> > >> > Here is the paper info: >> > >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent Influen= ce >> > of Path Selection in Heterogeneous Ad hoc Networks." Proceedings of >> > the 15th IEEE International Symposium on Personal, Indoor and Mobile >> > Radio Communications (PIMRC), Barcelona, Spain, September 2004. >> > >> > For the base spec we are not including any complex metrics, but >> > instead rely on DV & hopcount (if included) or other techniques that >> > work under these assumptions (like the paper above). >> > >> > I think some additional TLVs and new functionality to enable DYMO to >> > support more complex metrics would be interesting. >> > >> > Ian >> > >> > On 5/15/07, Philippe Jacquet wrote: >> >> Hello, folks, >> >> >> >> I see in DYMO spec (5.3.4) that a RREQ message can be retransmitted >> >> several times by a node if it receives copies on shorter routes. >> >> >> >> This reminds me the paper we did about this kind of super-flooding. >> >> >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc Networks >> >> T. Clausen, P. Jacquet et L. Viennot >> >> Med-hoc-Net, 2002 >> >> >> >> >> >> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz >> >> >> >> It gives the shortest path to OrigNode in hop count, but the number= of >> >> retransmissions may be important and exceed the network size (can b= e >> >> quadratic in the network size per RREQ). >> >> >> >> I wonder if one could also add other metrics than simply hop count.= =20 >> For >> >> example RREQ could seek the path with average shortest delay by add= ing >> >> the last hop average link delay to the current weight carried by th= e >> >> RREQ. The RREQ would carry a bit indicating that average shortest=20 >> delay >> >> is activated). Or the RREQ could look to the largest bandwidth=20 >> route (in >> >> this case one take the minimum of the last hop bandwidth with the=20 >> weight >> >> carried by the RREQ. >> >> >> >> Other metrics are possible (variance, etc). >> >> >> >> 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 >> > >> > >> >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 09:36: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 1HoJfz-00088H-RI; Wed, 16 May 2007 09:36:23 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoJfx-00080a-Qv for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 09:36:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJfx-0007zE-Gq for manet@ietf.org; Wed, 16 May 2007 09:36:21 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoJfw-0003Wz-4r for manet@ietf.org; Wed, 16 May 2007 09:36:21 -0400 Received: by an-out-0708.google.com with SMTP id c34so47348anc for ; Wed, 16 May 2007 06:36: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=avQlIrFQuT8aPm7TFKUNCwkQ/12h9jrIgvMaz2q3ijj2NhviXVp+MP6V7kCpurtxWBYAkRHIl7dzkpS/nplJAmRRk1c2OYHL9+RTS4VfrRvpV6itoETV3DzpoHBQljriGskAVQFWiYJBfQO9fMoORODG+r+xJWRDPTC96tJfR4k= 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=pIB0moYWMRjusyBJExtNuCQiiGloT2iDYh2M3hH+HFfLT69gZT1+LW8vwCPxOYpIK6WsEHkdP78O5WMwakZ2QMfaZbpddRmBg9DxCe/P6B1JJIm7/BpsrIntgIV+BUmLw2FjrDIJQ/ON+sKqdskVZjgk2C6TXnZaNj4yRmuGxek= Received: by 10.78.147.6 with SMTP id u6mr50736hud.1179322575223; Wed, 16 May 2007 06:36:15 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Wed, 16 May 2007 06:36:15 -0700 (PDT) Message-ID: <374005f30705160636p69ae55e8ya6ab9bbcf499c04a@mail.gmail.com> Date: Wed, 16 May 2007 19:06:15 +0530 From: "Ian Chakeres" To: "Philippe Jacquet" Subject: Re: [manet] DYMO RREQ flooding and super-flooding In-Reply-To: <464B013A.6070601@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> <464B013A.6070601@inria.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 MsgHdr.HopCount is not used in reference to routing information in DYMO. Node.HopCount (in an address block TLV) is optional. I have not read about super-flooding, but DYMO's method for determining the quality of routing information should be sufficient to avoid excess flooding. Ian On 5/16/07, Philippe Jacquet wrote: > I didn't know that you could disable hop counter, I thought > MsgHdr.HopCnt was mandatory in RREQ message. > > In case you use super-flooding, should you put a limit in the number of > retransmissions per node in order to avoid a flooding explosion? > > Philippe > > > > Ian Chakeres a =E9crit : > > If you don't include hop count information, it will not be used in the > > decision making. > > > > If you were interested in using "fasted RREQ" path, you would not > > include the hop count information. > > > > Ian > > > > On 5/16/07, Philippe Jacquet wrote: > >> Ian, I don't understand how the method you described in your paper for > >> AODV can be applied for DYMO. > >> > >> Assume you delay the RREQ retransmission on the two-hop route because > >> the routers have low willingness, so that it is transmitted after the > >> three hops route. Anyhow the two-hop RREQ will be relayed since it has= a > >> smaller hop-count and the shortest route will be in fact selected. Or = am > >> I wrong? > >> > >> Philippe > >> > >> Ian Chakeres a =E9crit : > >> > I had done some work on using different metrics by introducing delay > >> > during route discovery to influence route selection. > >> > > >> > Here is the paper info: > >> > > >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent Influen= ce > >> > of Path Selection in Heterogeneous Ad hoc Networks." Proceedings of > >> > the 15th IEEE International Symposium on Personal, Indoor and Mobile > >> > Radio Communications (PIMRC), Barcelona, Spain, September 2004. > >> > > >> > For the base spec we are not including any complex metrics, but > >> > instead rely on DV & hopcount (if included) or other techniques that > >> > work under these assumptions (like the paper above). > >> > > >> > I think some additional TLVs and new functionality to enable DYMO to > >> > support more complex metrics would be interesting. > >> > > >> > Ian > >> > > >> > On 5/15/07, Philippe Jacquet wrote: > >> >> Hello, folks, > >> >> > >> >> I see in DYMO spec (5.3.4) that a RREQ message can be retransmitted > >> >> several times by a node if it receives copies on shorter routes. > >> >> > >> >> This reminds me the paper we did about this kind of super-flooding. > >> >> > >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc Networks > >> >> T. Clausen, P. Jacquet et L. Viennot > >> >> Med-hoc-Net, 2002 > >> >> > >> >> > >> >> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz > >> >> > >> >> It gives the shortest path to OrigNode in hop count, but the number= of > >> >> retransmissions may be important and exceed the network size (can b= e > >> >> quadratic in the network size per RREQ). > >> >> > >> >> I wonder if one could also add other metrics than simply hop count. > >> For > >> >> example RREQ could seek the path with average shortest delay by add= ing > >> >> the last hop average link delay to the current weight carried by th= e > >> >> RREQ. The RREQ would carry a bit indicating that average shortest > >> delay > >> >> is activated). Or the RREQ could look to the largest bandwidth > >> route (in > >> >> this case one take the minimum of the last hop bandwidth with the > >> weight > >> >> carried by the RREQ. > >> >> > >> >> Other metrics are possible (variance, etc). > >> >> > >> >> 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 > >> > > >> > > >> > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 10:11: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 1HoKDN-0004Zz-UG; Wed, 16 May 2007 10:10:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoKDM-0004Td-Fp for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 10:10:52 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoKDM-0004S5-3A for manet@ietf.org; Wed, 16 May 2007 10:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoJb9-0005Zi-FI for manet@ietf.org; Wed, 16 May 2007 09:31:23 -0400 Received: from web59307.mail.re1.yahoo.com ([66.196.101.48]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HoJb8-0000zq-89 for manet@ietf.org; Wed, 16 May 2007 09:31:23 -0400 Received: (qmail 99825 invoked by uid 60001); 16 May 2007 13:31:22 -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=B7SoxcvQupKnmvpGffYP7XKkg+chuJVQ5NtbGKXC7dSklWCvZRrZ8PCF51PsMa6RpSYbrHV2Z8FPYVh/1/zwa6MA+csoEHKNEDobDezZ4FWFexY+sgOQ/TvPb7KS8utxSrM1JPmn6vUMOH49sQHs5CfDnb0otjNKAZ7S9OFxZdE=; X-YMail-OSG: 4P.ZWj4VM1lUzEyoBv6n.cIHVx8EicgY1jQ6JAVE4DanaBiZeN8FhmmOkUPRVqJqLc7zPwmYv0l36IBlVpY.KyOe6gHB2WhaUE8InphZr9hZWT_YzzqH8c7TgiOR6pA- Received: from [146.124.141.250] by web59307.mail.re1.yahoo.com via HTTP; Wed, 16 May 2007 06:31:22 PDT Date: Wed, 16 May 2007 06:31:22 -0700 (PDT) From: Sophia FP To: manet@ietf.org MIME-Version: 1.0 Message-ID: <146681.97042.qm@web59307.mail.re1.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-TMDA-Confirmed: Wed, 16 May 2007 10:10:52 -0400 Subject: [manet] hierarchical routing and switching clusters 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="===============1430837620==" Errors-To: manet-bounces@ietf.org --===============1430837620== Content-Type: multipart/alternative; boundary="0-1442362005-1179322282=:97042" Content-Transfer-Encoding: 8bit --0-1442362005-1179322282=:97042 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I am interested in a hierarchical routing protocol for MANETS. Nodes should be statically partitioned in mobile backbone nodes and simple mobile nodes. Simple mobile nodes can be communicating together through multiple hops, and at the same time form clusters around mobile backbone nodes, to utilize extra resources through backbone. The characteristic I have difficulty finding in already proposed schemes is the possibility that simple mobile nodes can switch clusters. Do you know if there already exists a solution for this problem or if this seems to you like an interesting issue to do research on? Thank you very much in advance --------------------------------- Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. --0-1442362005-1179322282=:97042 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
I am interested in a hierarchical routing protocol for MANETS.
Nodes should be statically partitioned in mobile backbone nodes and simple mobile nodes. Simple mobile nodes can be communicating together through multiple hops, and at the same time form clusters around mobile backbone nodes, to utilize extra resources through backbone. The characteristic I have difficulty finding in already proposed schemes is the possibility that simple mobile nodes can switch clusters.

Do you know if there already exists a solution for this problem or if this seems to  you like an interesting issue to do research on?

Thank you very much in advance

Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta. --0-1442362005-1179322282=:97042-- --===============1430837620== 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 --===============1430837620==-- From manet-bounces@ietf.org Wed May 16 10:59: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 1HoKyZ-0004Qz-PY; Wed, 16 May 2007 10:59:39 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoKyX-0004Qc-Se for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 10:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoKyX-0004QU-J2 for manet@ietf.org; Wed, 16 May 2007 10:59:37 -0400 Received: from smtp-3.smtp.ucla.edu ([169.232.48.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoKyV-0000n4-S5 for manet@ietf.org; Wed, 16 May 2007 10:59:37 -0400 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-3.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l4GExYvH012383; Wed, 16 May 2007 07:59:34 -0700 Received: from IRUBIN001.ee.ucla.edu (cpe-76-167-129-225.socal.res.rr.com [76.167.129.225]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l4GExWGD006306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 May 2007 07:59:32 -0700 Message-Id: <6.2.0.14.2.20070516074226.065911d0@mail.ucla.edu> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 16 May 2007 07:59:26 -0700 To: Sophia FP , manet@ietf.org From: Izhak Rubin Subject: Re: [manet] hierarchical routing and switching clusters In-Reply-To: <146681.97042.qm@web59307.mail.re1.yahoo.com> References: <146681.97042.qm@web59307.mail.re1.yahoo.com> Mime-Version: 1.0 X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.48.136 X-Spam-Score: 1.5 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: rubin@ee.ucla.edu 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="===============0242880592==" Errors-To: manet-bounces@ietf.org --===============0242880592== Content-Type: text/html; charset="us-ascii"
Hi:

Over the last several years, we have been developing the Mobile Backbone Network (MBN) architecture for mobile ad hoc wireless networks.  Our developments include:

1.  Topology synthesis algorithms for synthesizing dynamically in a distributed and highly scalable manner a mobile backbone.  The backbone is connected and highly robust.  Mobile nodes associate with a selected backbone node.  Higher local connectivity is maintained.  The algorithms are distributed and consider only a certain class of nodes (Backbone Capable Nodes, BCNs, and NOT Regular Nodes, RNs) as candidates for acting as BNs (Backbone Nodes), and is thus very different from many clustering and CDS (connected dominated set) construction algorithms.  We have also introduced such algorithms for systems in which BCNs may employ multiple radio modules.  References:  please see my papers with Laura Ju in conference proceedings and journals. 

2.  MBN based QoS routing algorithms (MBNR), using congestion and flow admission control (MBNR-FC) to ensure QoS behavior; also distance aware version (MBNR-FC/DA), under which shorter range flows use global multi hop routes, while longer distance flows discover routes through the backbone network; an optimal distance threshold is calculated analytically and /or dynamically through status monitoring.  Also we have developed MBNR-PS schemes that are power saving (energy aware) oriented, which keep backbone nodes awake while turning on other nodes on demand.  References:  please see my papers with Xiaolong Huang in conference proceedings and journals.  Please see also our extensive performance comparisons with flat hierarchy operations.

3.  MBN based multicating schemes, which employ the mobile backbone to multicast messages.  They have been compared with flat hierarchy schemes such as ODMRP.  Please see my papers with Jeffrey Tan.

4.  Robust routing mechanisms that ensure the selection of routes that are robust under mobility to ensure a high probability of completing a transactions.  See my papers with Runhe Zhang.

Under our routing schemes, mobile nodes re-associate with a selected backbone node whose beacons (periodically issued hello messages) they hear. 

Best regards,

Izhak

Professor Izhak Rubin
Electrical Engineering Department
UCLA
rubin@ee.ucla.edu




At 06:31 AM 5/16/2007, Sophia FP wrote:

I am interested in a hierarchical routing protocol for MANETS.
Nodes should be statically partitioned in mobile backbone nodes and simple mobile nodes. Simple mobile nodes can be communicating together through multiple hops, and at the same time form clusters around mobile backbone nodes, to utilize extra resources through backbone. The characteristic I have difficulty finding in already proposed schemes is the possibility that simple mobile nodes can switch clusters.

Do you know if there already exists a solution for this problem or if this seems to  you like an interesting issue to do research on?

Thank you very much in advance


Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet
--===============0242880592== 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 --===============0242880592==-- From manet-bounces@ietf.org Wed May 16 11:57: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 1HoLsC-0007SD-3T; Wed, 16 May 2007 11:57:08 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoLsA-0007S8-14 for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 11:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLs9-0007S0-NV for manet@ietf.org; Wed, 16 May 2007 11:57:05 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoLs8-0006xr-H0 for manet@ietf.org; Wed, 16 May 2007 11:57:05 -0400 Received: by an-out-0708.google.com with SMTP id c34so63286anc for ; Wed, 16 May 2007 08:57:04 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=jubiuUc31oQPIXhexZvkFr8phpyEJIjRCwUtGO4uXbU1D11h8JswleagQZg4mGsgO1iPkfxUyGJp7rT+7bj47QPfxWzPBbZqwsX2gARx6mCvVjK1Q4OpmkuQ8PeqNS2f4rrj0CL23bSPYAiKdP9qyMX3tRE+hJNmbNN+et+ayRs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NkBB2oGVnfijZy0EPZkIxY5SXn2BSp5TqmtT1jCoCzk02OMgD1HoZIfsIHxmtjM1VZSqKSeJaBfeQSsV38515YJtc1i2fW4C37QoG2zpV1W/erOGes5A6rrYeaDjck1FZmKjSc92PIOo+/x0KwvpUxXnQeRjhxo509XVArIrYTQ= Received: by 10.100.106.5 with SMTP id e5mr6256338anc.1179331023737; Wed, 16 May 2007 08:57:03 -0700 (PDT) Received: by 10.100.174.2 with HTTP; Wed, 16 May 2007 08:57:03 -0700 (PDT) Message-ID: <957d36030705160857xb89b893uc4c48e5288228dda@mail.gmail.com> Date: Wed, 16 May 2007 16:57:03 +0100 From: "Siva Sivavakeesar" To: manet@ietf.org 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: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [manet] APEView Functionality of APE Testbed 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 there, I am wondering whether somebody can shed me some light on how the "APEView" functionality of APE testbed is implemented. I have been involved with MANET testbed experiments, where I need to make sure that in successive test runs participating nodes take the same trajectories. This is important because I am comparing the performances of two high-level routing protocols. As far as I understood, the APEview makes use of some log files (e.g., RSSI measurement) to provide movement instructions to test-participants during the actual testruns. My question is whether this signal quality information is logged in real-time and it is mearely this information being used for navigating purposes. In othere words, what information is used to provide such movement instructions to the users ? Please shed some light as much as possible. Thanks in advance for taking your invaluable time to answer my question. Best Regards, Dr. Siva _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 13:53: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 1HoNgy-0004Tp-IR; Wed, 16 May 2007 13:53:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoNgw-0004Tj-FZ for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 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 1HoNgw-0004Tb-5t for manet@ietf.org; Wed, 16 May 2007 13:53:38 -0400 Received: from mail.di.uniroma1.it ([151.100.17.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoNgu-0000VV-Or for manet@ietf.org; Wed, 16 May 2007 13:53:38 -0400 Received: from wmail.di.uniroma1.it (venere.di.uniroma1.it [151.100.17.6]) by mail.di.uniroma1.it (Postfix) with ESMTP id 981141BD655; Wed, 16 May 2007 19:36:40 +0200 (CEST) Received: from petrioli2.dsi.uniroma1.it ([151.100.17.135]) (SquirrelMail authenticated user petrioli); by wmail.di.uniroma1.it with HTTP; Wed, 16 May 2007 19:54:54 +0200 (CEST) Message-ID: <1559.151.100.17.135.1179338094.squirrel@151.100.17.135> In-Reply-To: <146681.97042.qm@web59307.mail.re1.yahoo.com> References: <146681.97042.qm@web59307.mail.re1.yahoo.com> Date: Wed, 16 May 2007 19:54:54 +0200 (CEST) Subject: Re: [manet] hierarchical routing and switching clusters From: petrioli@di.uniroma1.it To: "Sophia FP" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) 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 Hi Sophia we have done work on performance comparison among leading algorithms for hierarchical organization -S. Basagni, M. Mastrogiovanni, A. Panconesi, C. Petrioli Localized Protocols for Ad Hoc Clustering and Backbone Formation: A Performance Comparison. IEEE Transaction on Parallel and Distributed Systems, special issue on Localized communication and topology protocols for ad hoc networks, May 2006. Our evaluation is based on ns2 simulations. The framework is available fo= r the community to use at http://reti.dsi.uniroma1.it/eng/mastrogiovanni/software/index.php It includes the implementation of several among the best clustering protocols. Best Regards, Chiara Petrioli > > I am interested in a hierarchical routing protocol for MANETS. > Nodes should be statically partitioned in mobile backbone nodes and sim= ple > mobile nodes. Simple mobile nodes can be communicating together through > multiple hops, and at the same time form clusters around mobile backbon= e > nodes, to utilize extra resources through backbone. The characteristic = I > have difficulty finding in already proposed schemes is the possibility > that simple mobile nodes can switch clusters. > > Do you know if there already exists a solution for this problem or if t= his > seems to you like an interesting issue to do research on? > > Thank you very much in advance > > > > --------------------------------- > Sucker-punch spam with award-winning protection. > Try the free Yahoo! Mail > Beta._______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > --=20 Dr. Chiara Petrioli, PhD Associate Professor Computer Science Department Rome University "La Sapienza" Via Salaria 113 -00198 Roma Italy E-mail: petrioli@di.uniroma1.it _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 16 20:16: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 1HoTfO-0004Eo-Pk; Wed, 16 May 2007 20:16:26 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoTfM-0004Ej-QT for manet-confirm+ok@megatron.ietf.org; Wed, 16 May 2007 20:16:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoTfM-0004Eb-GZ for manet@ietf.org; Wed, 16 May 2007 20:16:24 -0400 Received: from lennier.cc.vt.edu ([198.82.162.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoTfM-00062T-7v for manet@ietf.org; Wed, 16 May 2007 20:16:24 -0400 Received: from vivi.cc.vt.edu (IDENT:mirapoint@evil-vivi.cc.vt.edu [10.1.1.12]) by lennier.cc.vt.edu (8.12.11.20060308/8.12.11) with ESMTP id l4H0GKFR027678; Wed, 16 May 2007 20:16:20 -0400 Received: from blade08.cc.vt.edu (imp.cc.vt.edu [198.82.161.55]) by vivi.cc.vt.edu (MOS 3.8.2-GA) with ESMTP id HMP02507; Wed, 16 May 2007 20:16:19 -0400 (EDT) Received: from blade08.cc.vt.edu (blade08.cc.vt.edu [127.0.0.1]) by blade08.cc.vt.edu (8.13.1/8.13.1) with ESMTP id l4H0GJsf032149; Wed, 16 May 2007 20:16:19 -0400 Received: (from apache@localhost) by blade08.cc.vt.edu (8.13.1/8.13.1/Submit) id l4H0GGfD032148; Wed, 16 May 2007 20:16:16 -0400 Received: from c-69-143-56-167.hsd1.va.comcast.net (c-69-143-56-167.hsd1.va.comcast.net [69.143.56.167]) by webmail.vt.edu (IMP) with HTTP; Wed, 16 May 2007 20:16:16 -0400 Message-ID: <1179360976.464b9ed00a5aa@webmail.vt.edu> Date: Wed, 16 May 2007 20:16:16 -0400 From: mdemissi@vt.edu To: christian@kuhtz.com Subject: Re: [manet] Diff b/w Wireless Mesh Networks and MANETs References: <464AC5D5.3010306@gdatech.co.in> <464ACB80.6040404@n0rg.org> <464ACEE7.1060906@gdatech.co.in> <814726457-1179308504-cardhu_blackberry.rim.net-2113627483-@bxe032-cell01.bisx.prod.on.blackberry> In-Reply-To: <814726457-1179308504-cardhu_blackberry.rim.net-2113627483-@bxe032-cell01.bisx.prod.on.blackberry> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Quoting Christian Kuhtz : > > Likewise, wireless mesh networks can also have mobile components to them, > where portions of the mesh are placed on vehicles etc. > > Best Regards, > Christian > > > > -----Original Message----- > From: nagarajan > Date: Wed, 16 May 2007 14:59:11 > To:Laurent Dehoey > Cc:manet > Subject: Re: [manet] Diff b/w Wireless Mesh Networks and MANETs > > Hi Laurent, > > I am very much clear with your explanation. Wireless > mesh networks are static in network topology and architecture whereas > the MANETs need not be static in network topology and architecture. > > I would also like to know the routing protocols > recommended for MANETs like AODV, OLSR etc suits with Wireless Mesh > Networks. > > Looking forward your reply > > Thanks and regards, > Nagarajan > > Laurent Dehoey wrote: > > Hi Nagarajan > > > > the difference can be considered "subtle" and found with the help of > > the letter "M" in MANET > > > > one can imagine mesh networks as a fix wireless backbone where clients > > of the backbone moves along that static backbone as opposed to MANETs > > where the moving clients *are* the wireless backbone. > > > > ...this is a blurred "frontier" : when all the nodes of a manet are > > static,.. well.. don't we have a mesh network ? > > > > HTH > > Laurent > > > > nagarajan wrote: > >> Hi all, > >> > >> I am new to this wireless domain. I like to know the functional > >> difference between Wireless mesh networks and MANETs. I appreciate > >> your support to kick off my process. > >> > >> Thanks and regards, > >> Nagarajan > >> > >> > >> _______________________________________________ > >> manet mailing 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 Thu May 17 09:06: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 1HofgQ-0000Ys-Uj; Thu, 17 May 2007 09:06:18 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoZiK-0002px-Le for manet-confirm+ok@megatron.ietf.org; Thu, 17 May 2007 02:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZiK-0002pm-A9 for manet@ietf.org; Thu, 17 May 2007 02:43:52 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoZiI-0005DV-Te for manet@ietf.org; Thu, 17 May 2007 02:43:52 -0400 Received: from 210-170-097-082.jp.fiberbit.net ([210.170.97.82] helo=[172.30.241.138]) by outbound.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HoZiI-000OH0-6X; Thu, 17 May 2007 02:43:50 -0400 X-MHO-User: U2FsdGVkX198GrjcO9pwGPEWTotADgR6 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 210.170.97.82 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19AoZdd/E9Fkgb9PCQhBAYR In-Reply-To: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> References: <374005f30705102032k119ff9e9u7d562820d6b3e8a4@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FAFD0DE-BEB8-4687-9BC0-FAE727913F87@polytechnique.fr> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-02.txt & WGLC Date: Thu, 17 May 2007 08:43:49 +0200 To: Ian Chakeres X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 X-Mailman-Approved-At: Thu, 17 May 2007 09:06:17 -0400 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 Just for the record, I voice my support for the IANA document as-is, and I believe that it should go forward. I see the allocations for ports and addresses (scopes) as appropriate for what we need currently in the routing protocols, as well as the design of the SMF framework. Thomas On May 11, 2007, at 5:32 AM, Ian Chakeres wrote: > I'd like to ask people to review this new revision. I'm also > reissuing WGLC. > > Here is a summary of the main changes: > > The draft has been revised to state clearly that a well-known UDP > port, LL multicast addresses, and SL multicast addresses are required > by the MANET WG. > > I tried to remove any text specifying operational requirements/advice > related to these well-known values, as this type of discussion belongs > in the protocol specifications. > > I choose to leave the site-local multicast addresses. This topic has > been discussed several times on the list and I believe there is > consensus that we should allocate these (IPv4/IPv6) addresses. > > Please sent any questions/comments to the list. > Ian Chakeres > > On 5/10/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-02.txt >> Pages : 7 >> Date : 2007-5-10 >> >> This document enumerates IANA assignments for use by MANET WG >> protocols. 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-02.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-02.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-02.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 > -- Thomas Clausen Thomas.Clausen@polytechnique.fr http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ http://www.lix.polytechnique.fr/hipercom/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 18 04:18: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 1Hoxf4-0001Ex-6N; Fri, 18 May 2007 04:18:06 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hoxf1-0001Ep-KI for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 04:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoxf0-0001Eh-UR for manet@ietf.org; Fri, 18 May 2007 04:18:02 -0400 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoxez-0003ZK-Jv for manet@ietf.org; Fri, 18 May 2007 04:18:02 -0400 Received: by an-out-0708.google.com with SMTP id c34so241701anc for ; Fri, 18 May 2007 01:18:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hhUvnql9TFCljehlxlRlC6/862F2XMj7EPT3FuxZGJkxb/TjIp9gnEIQSm5P8yiCoVDN3E5nr6ZZSt1MZQ8Zw2iuYlVprENVNOEe+R6sKignHItSjAg45OuWbH//DPyElNRXxZugo8ZYWU4bUngDT9Se9JCP+zaZ7hQaxrrl8sM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=tiWu9KpRUqFFrzMHshzeuLVXIxndBcIJiwnaI9DOG61JcYMPacucgnvIZrxYLhMDBcRiXLc2b6Yblec250wnJY8GXdx32tX5VlP+5dEzVDHadqql3HYimMfIOS+FmsMBcVCCKDU/8zHilj/133P5qvwX0Vbkb3/iM+qErZfSek8= Received: by 10.100.153.17 with SMTP id a17mr922824ane.1179476281116; Fri, 18 May 2007 01:18:01 -0700 (PDT) Received: by 10.100.174.2 with HTTP; Fri, 18 May 2007 01:18:01 -0700 (PDT) Message-ID: <957d36030705180118m21dbfce8i81455a1729eb512d@mail.gmail.com> Date: Fri, 18 May 2007 09:18:01 +0100 From: "Siva Sivavakeesar" To: manet@ietf.org 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: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [manet] MANET Testbed Experiments 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 there, I am sure that someone out there is able to help me out. Has anyone carried out MANET experiments, where the objective is to compare two high-level (for instance, 2 two routing protocols) protocols while the nodes move around ? Under such circumstances, for a meaningful fair comparison of two different protocols, in each test run the nodes should take the exact mobility pattern (trajectories). This is to make sure that every environmental settings are equal, although the radio channel may be time-variant - which we don't have any control. Given this the requirement, has anyone developed anything where this uncertainty with regard to mobility is taken care of - i.e., the system enables the users carrying the nodes to take exact movement patters in each test run ? If so, have you ever used GPS mechanism to correctly determine the geographical location (i.e., positioning information) OR else used signal strength measurements to determine the relative position with respect to a known location. Please share your experience with us, as I have similar requirments to satisfy. Thanks in advance for taking your invaluable time to answer my question. Best Regards, Dr. Siva _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 18 04:57: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 1HoyGh-0005v7-DD; Fri, 18 May 2007 04:56:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HoyGg-0005v0-7k for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 04:56:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoyGf-0005uq-RV for manet@ietf.org; Fri, 18 May 2007 04:56:57 -0400 Received: from smtp15.wxs.nl ([195.121.247.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoyGf-0007f7-H9 for manet@ietf.org; Fri, 18 May 2007 04:56:57 -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 <0JI800NZJBIW3M@smtp15.wxs.nl> for manet@ietf.org; Fri, 18 May 2007 10:56:56 +0200 (CEST) Date: Fri, 18 May 2007 10:57:57 +0200 From: Teco Boot To: 'manet' Message-id: <000001c7992a$ad46c140$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: AceZKqDHv/ixMT0nR2GEHEdEtJJvmQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [manet] some thoughts on 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 All SMF and DPD fans, here some thoughts on DPD. As DPD using hashing is to be supported more directly, we could re-evaluate some issues: -> We have to specify sent packets over a MANET are unique. Choices are _SHOULD be unique_ or _MUST be unique_. We also have a choice on uniqueness on the whole packet or the starting N octets. Hashing over a shorter string would save CPU. I prefer lowering overhead, e.g. specifying the first 256 octets should guarantee uniqueness. -> The hashing algorithm for IPv6 can be reused for IPv4. This provides support for fragmented packets and RFC791 compliant packets (ID unique for srce, dest and proto). I highly prefer RFC791-compliance. It takes some time to adjust the SMF draft text, and some more time to adjust code. But let's do it correctly. (don't forget blanking TTL before hashing;-) -> I think IPv6 packets are NOT unique by nature. Typical examples for duplicates are keep-alive and retransmits. Sending a sequence number, ID or retransmit counter could be useful, but this is not mandatory. Or am I missing something? So making IPv6 packets unique could require marking. Is using the RFC2460 fragment option considered before? Aren't existing facilities preferred over new mechanisms? Using this option would implement the same mechanism for IPv4 and IPv6. IPv6 ID field is 32 bits and it should guarantee uniqueness, otherwise an update of RFC2460 is needed. Some disadvantages: fragments with Fragment Offset on zero and M-flag on zero are a little bit strange, and defragmentation code is touched. Also hashing should be performed over a longer string, as (long) hop-by-hop options, destination options and routing headers come in front of the fragment header. Taggers inserting a fragment option are not in line with RFC2460, but I don't foresee problems. -> I think DPD has a high level of acceptance by MANET unicast protocol implementators, as it highly reduces negative effects in case of a routing loop. This is another reason for careful specification of the mechanism. I even think it should be part of the chartered WG work on defining a STD unicast MANET protocol. My 3 cents, Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 18 07:09: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 1Hp0Ki-0001Kc-U2; Fri, 18 May 2007 07:09:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hp0Kh-0001H8-4D for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 07:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp0Kg-0001GB-Pj for manet@ietf.org; Fri, 18 May 2007 07:09:14 -0400 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp0Kf-0001p8-Gb for manet@ietf.org; Fri, 18 May 2007 07:09:14 -0400 Received: by wr-out-0506.google.com with SMTP id 71so919087wri for ; Fri, 18 May 2007 04:09:13 -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=RynFGCEI31LblNww0t3Kj5yjB1OkFfX6iAH8Zxo08X7wvnb+ITNofNMRKMOmlmGllMizqM5PRPvglWsNFLqLupkeZaSABtnWXfNX1TpxiIdEvvU+Ua1Q4kLgl5lrnOKJIYGrrIhgq/K6RbtCB4ZPowCkra05x1J9xeE8Yvc4E9I= 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=RvGA3MNRZwLA/fJgBCSFKFvyZ2YBiWAFFmx6DNevaWzTw+MWqZlBQmz7NAd9GmlrDdnZgtSc/8uc4yXwMnLUw15ke+xBiDK+PE4OmyXYX00bvk43eayztLGa1Pi1STgZN4SoeurxVlbAVtUWmjcrQFI3Cbo/ab7m/1W1x1i77Fg= Received: by 10.78.159.7 with SMTP id h7mr403810hue.1179486552532; Fri, 18 May 2007 04:09:12 -0700 (PDT) Received: by 10.78.48.10 with HTTP; Fri, 18 May 2007 04:09:12 -0700 (PDT) Message-ID: Date: Fri, 18 May 2007 13:09:12 +0200 From: "Henrik Lundgren" To: "Siva Sivavakeesar" Subject: Re: [manet] APEView Functionality of APE Testbed In-Reply-To: <957d36030705160857xb89b893uc4c48e5288228dda@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: <957d36030705160857xb89b893uc4c48e5288228dda@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Siva, The APEview tool can display node/link information and position nodes relative to each other based on the information you feed into it. It can be done to replay testruns in terms of the information you choose to provide to the tool. It can also be used in real-time as long as you have implemented the means to provide the information to the tool in real-time, for example, through a backhaul network. However, the positioning of nodes in the APEview tool is not used to drive movement instructions. Instead this movement choreography is typicially based on pre-determined (carefully designed, timed, and rehearsed) to provide the highest level of repeatability possible. This movement choreography is provided in a separate global configuration file in which the movement including timing is provided for each node. hope this helps, -- Henrik On 5/16/07, Siva Sivavakeesar wrote: > Hello there, > > I am wondering whether somebody can shed me some light on how the > "APEView" functionality of APE testbed is implemented. I have been > involved with MANET testbed experiments, where I need to make sure > that in successive test runs participating nodes take the same > trajectories. This is important because I am comparing the > performances of two high-level routing protocols. > > As far as I understood, the APEview makes use of some log files (e.g., > RSSI measurement) to provide movement instructions to > test-participants during the actual testruns. My question is whether > this signal quality information is logged in real-time and it is > mearely this information being used for navigating purposes. In othere > words, what information is used to provide such movement instructions > to the users ? Please shed some light as much as possible. > > Thanks in advance for taking your invaluable time to answer my question. > > Best Regards, > > Dr. Siva > > > _______________________________________________ > manet mailing 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 May 18 07:30: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 1Hp0em-0007qz-0A; Fri, 18 May 2007 07:30:00 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hp0ek-0007qd-CL for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 07:29:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp0ek-0007qV-14 for manet@ietf.org; Fri, 18 May 2007 07:29:58 -0400 Received: from wx-out-0506.google.com ([66.249.82.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp0ei-0008S2-Ov for manet@ietf.org; Fri, 18 May 2007 07:29:58 -0400 Received: by wx-out-0506.google.com with SMTP id h31so917023wxd for ; Fri, 18 May 2007 04:29: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=raeyiX4epXNg1cNw3VrZhof26QnNAVeHfpcNTwmhn0YvDdagZHUwSjUXUiwtxxcDrE3BmtLscuZmlch69bxyxKxDtFq9QuyUvJ6TQzI5yE8bLD17b7wRut+94pP5L2Pg/e52d2YSTCiU8cnaVWFoNBYiVb/E6UFx0wmIlcQDYfg= 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=N02QmjXCfNqVuBI1Skicj4ca4+5vZzl9q3YSH0T138MpEFXCqetzkTnOL17jCxngaJMceAqxxHoCGJ1P2Jc8XA8BQsy0lLR4mYP3j8I+V0WqnyCtt65wRCNAmLRPZEpBMzG/9vEc1Cx0hO4pCcWLJRNBeNl6L6vK7Lk+GxGN6mE= Received: by 10.78.170.6 with SMTP id s6mr409198hue.1179487795852; Fri, 18 May 2007 04:29:55 -0700 (PDT) Received: by 10.78.48.10 with HTTP; Fri, 18 May 2007 04:29:55 -0700 (PDT) Message-ID: Date: Fri, 18 May 2007 13:29:55 +0200 From: "Henrik Lundgren" To: "Siva Sivavakeesar" Subject: Re: [manet] MANET Testbed Experiments In-Reply-To: <957d36030705180118m21dbfce8i81455a1729eb512d@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: <957d36030705180118m21dbfce8i81455a1729eb512d@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Siva, See my recent reply to one of your other emails concerning APEview for a comment about how movement choreography is implemented in the APE testbed tool. In addition, to ensure the exact movement pattern of nodes, I strongly recommend that you implement means to investigate the radio environment characterstics between testruns. My former colleagues at Uppsala University have extensively conducted mobile experiments and investigated issues related to node movement, repeatability, etc. for fair evaluation and comparison. -- Henrik On 5/18/07, Siva Sivavakeesar wrote: > Hello there, > > I am sure that someone out there is able to help me out. Has anyone > carried out MANET experiments, where the objective is to compare two > high-level (for instance, 2 two routing protocols) protocols while the > nodes move around ? Under such circumstances, for a meaningful fair > comparison of two different protocols, in each test run the nodes > should take the exact mobility pattern (trajectories). This is to make > sure that every environmental settings are equal, although the radio > channel may be time-variant - which we don't have any control. Given > this the requirement, has anyone developed anything where this > uncertainty with regard to mobility is taken care of - i.e., the > system enables the users carrying the nodes to take exact movement > patters in each test run ? If so, have you ever used GPS mechanism to > correctly determine the geographical location (i.e., positioning > information) OR else used signal strength measurements to determine > the relative position with respect to a known location. > > Please share your experience with us, as I have similar requirments to satisfy. > > Thanks in advance for taking your invaluable time to answer my question. > > Best Regards, > > Dr. Siva > > > _______________________________________________ > manet mailing 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 May 18 07:31: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 1Hp0gZ-0002FO-V1; Fri, 18 May 2007 07:31:51 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hp0gY-0002B3-Go for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 07:31:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp0gY-00028v-63 for manet@ietf.org; Fri, 18 May 2007 07:31:50 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp0gW-0000FQ-Rx for manet@ietf.org; Fri, 18 May 2007 07:31:50 -0400 Received: by an-out-0708.google.com with SMTP id c34so259545anc for ; Fri, 18 May 2007 04:31:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.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=Ddnl6ABMXLZSZecbg8XKpjFOU8sIaRkbvUcPD+KsBs4HNJqhB1efoPSkizO/SunCuy73rXeiVkXtDYzHrUZDulRFIct7nx0XW6NQ2IUAPKcyzrJeiF7ETiYADM3FFt39l9GLHqWkZxumcdyK3jIdSeEn2jOpYuvNZJBiFt3rV2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=Y3pqL3FvQGfahImU8jHLoJFGdal2C3k5iwH3mS4qNn4hpLVnMyvGVMikaXNe5voiiUs66Q4agZTngrAfwDxE+IhPxLCwO0dWyjV5sSoF1XDinVVBvWKl/4po2fOD0xLBUi2qO6M++hQ7agMExneg+wdMVQB7cb97wB699+0S/XQ= Received: by 10.100.120.5 with SMTP id s5mr997901anc.1179487908554; Fri, 18 May 2007 04:31:48 -0700 (PDT) Received: by 10.100.174.2 with HTTP; Fri, 18 May 2007 04:31:48 -0700 (PDT) Message-ID: <957d36030705180431l2bf10ee6j288005640882323a@mail.gmail.com> Date: Fri, 18 May 2007 12:31:48 +0100 From: "Siva Sivavakeesar" To: "Henrik Lundgren" Subject: Re: [manet] APEView Functionality of APE Testbed 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: <957d36030705160857xb89b893uc4c48e5288228dda@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Henrik, Thanks - this is exactly what I wanted. From your mail, I can now understand that the virtual-mobility functionality does not make use of any data being logged in real-time to give instructions about future movements. Initially, I was suspecting how can SNR information be used to give such movement instructions. Despite this, this is what, however, one of your README files (ape-testbed.tex) says: "APE introduce a new mobility metric for real world tests called ``virtual mobility'' (vM), which is based on SNR changes in links between nodes. SNR is mapped to a ``virtual distance'', then vM is calculated as the changes in ``virtual distance'' between two consecutive time intervals. vM is mainly used for two purposes: one is to estimate the degree of similarity between two testruns (in a mobility and movement sense, but also in a connectivity sense, since vM is dependent on inter-node connectivity), and to provide a way to evaluate how it affects other metrics, for example packet loss". I am sure that VM is different from APEview - the latter being responsible for displaying the instantaneous topological configurations of nodes during each test run. Hence, it is reasonable to expect that for the APEview to work, it needs to rely on SNR data being logged in real-time. On the other hand, as far as I understood from reading the APE documents, I have the impression that it is the VM functionality that gives the users the movement instructions. If it the case, it should not rely on any SNR inofmration - but the previous paragraph says that it makes use of SNR - is this correct ? If you have time, please clarify my ambiquity. Thanks in advance for taking your invaluable time to answer my questions. Best Regards, Siva On 5/18/07, Henrik Lundgren wrote: > Siva, > > The APEview tool can display node/link information and position > nodes relative to each other based on the information you feed into it. > It can be done to replay testruns in terms of the information you > choose to provide to the tool. It can also be used in real-time as long > as you have implemented the means to provide the information to > the tool in real-time, for example, through a backhaul network. > > However, the positioning of nodes in the APEview tool is not used > to drive movement instructions. Instead this movement choreography > is typicially based on pre-determined (carefully designed, timed, and > rehearsed) to provide the highest level of repeatability possible. > This movement choreography is provided in a separate global configuration > file in which the movement including timing is provided for each node. > > hope this helps, > > -- Henrik > > > On 5/16/07, Siva Sivavakeesar wrote: > > Hello there, > > > > I am wondering whether somebody can shed me some light on how the > > "APEView" functionality of APE testbed is implemented. I have been > > involved with MANET testbed experiments, where I need to make sure > > that in successive test runs participating nodes take the same > > trajectories. This is important because I am comparing the > > performances of two high-level routing protocols. > > > > As far as I understood, the APEview makes use of some log files (e.g., > > RSSI measurement) to provide movement instructions to > > test-participants during the actual testruns. My question is whether > > this signal quality information is logged in real-time and it is > > mearely this information being used for navigating purposes. In othere > > words, what information is used to provide such movement instructions > > to the users ? Please shed some light as much as possible. > > > > Thanks in advance for taking your invaluable time to answer my question. > > > > Best Regards, > > > > Dr. Siva > > > > > > _______________________________________________ > > manet mailing 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 May 18 11:37: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 1Hp4Vi-0007ov-2s; Fri, 18 May 2007 11:36:54 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hp4Vh-0007oq-Ad for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 11:36:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4Vh-0007oi-0u for manet@ietf.org; Fri, 18 May 2007 11:36:53 -0400 Received: from mail139.messagelabs.com ([85.158.137.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hp4Ve-0007mZ-Ix for manet@ietf.org; Fri, 18 May 2007 11:36:53 -0400 X-VirusChecked: Checked X-Env-Sender: Ronald.intVelt@tno.nl X-Msg-Ref: server-7.tower-139.messagelabs.com!1179502609!4583801!1 X-StarScan-Version: 5.5.10.7.1; banners=tno.nl,-,- X-Originating-IP: [134.221.2.2] Received: (qmail 13344 invoked from network); 18 May 2007 15:36:49 -0000 Received: from zeus.tno.nl (HELO zeus.tno.nl) (134.221.2.2) by server-7.tower-139.messagelabs.com with SMTP; 18 May 2007 15:36:49 -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 l4IFanx17775 for ; Fri, 18 May 2007 17:36:49 +0200 (MEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [manet] some thoughts on DPD Date: Fri, 18 May 2007 17:36:48 +0200 Message-ID: <7877C5C0B5CC894AB26113CF06CF88637BDEBC@ms-dt01thalia.tsn.tno.nl> In-Reply-To: <000001c7992a$ad46c140$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] some thoughts on DPD Thread-Index: AceZKqDHv/ixMT0nR2GEHEdEtJJvmQAMuSmA From: "Velt, R. \(Ronald\) in 't" To: "manet" X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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,=20all, >=20-----Original=20Message----- >=20From:=20Teco=20Boot=20[mailto:teco@inf-net.nl]=20 >=20Sent:=20vrijdag=2018=20mei=202007=2010:58 >=20To:=20'manet' >=20Subject:=20[manet]=20some=20thoughts=20on=20DPD >=20 >=20All=20SMF=20and=20DPD=20fans,=20here=20some=20thoughts=20on=20DPD. >=20 >=20As=20DPD=20using=20hashing=20is=20to=20be=20supported=20more=20directl= y,=20we=20 >=20could=20re-evaluate=20some=20issues: >=20 >=20->=20We=20have=20to=20specify=20sent=20packets=20over=20a=20MANET=20ar= e=20unique.=20 >=20Choices=20are >=20_SHOULD=20be=20unique_=20or=20_MUST=20be=20unique_.=20We=20also=20have= =20a=20choice=20 >=20on=20uniqueness=20on=20the=20whole=20packet=20or=20the=20starting=20N=20= octets.=20 >=20Hashing=20over=20a=20shorter=20string=20would=20save=20CPU.=20I=20pref= er=20 >=20lowering=20overhead,=20e.g.=20specifying=20the=20first=20256=20octets=20= >=20should=20guarantee=20uniqueness. >=20 >=20->=20The=20hashing=20algorithm=20for=20IPv6=20can=20be=20reused=20for=20= IPv4.=20 >=20This=20provides >=20support=20for=20fragmented=20packets=20and=20RFC791=20compliant=20pack= ets=20 >=20(ID=20unique=20for=20srce,=20dest=20and=20proto).=20I=20highly=20prefe= r=20 >=20RFC791-compliance.=20It=20takes=20some=20time=20to=20adjust=20the=20SM= F=20draft=20 >=20text,=20and=20some=20more=20time=20to=20adjust=20code.=20But=20let's=20= do=20it=20 >=20correctly.=20(don't=20forget=20blanking=20TTL=20before=20hashing;-) _And_=20the=20Header=20Checksum... _And_=20the=20TOS-byte=20/=20DS=20field=20or=20TC=20field=20(IPv6),=20I=20= guess.=20A=20duplicate packet,=20having=20taken=20a=20different=20route=20than=20the=20original,=20= may=20have=20been remarked,=20while=20the=20original=20was=20left=20untouched=20or=20vice=20= versa.=20One=20copy may=20have=20had=20the=20ECN=20CE=20codepoint=20set,=20while=20the=20other= =20has=20not. >=20 >=20->=20I=20think=20IPv6=20packets=20are=20NOT=20unique=20by=20nature.=20= Typical=20examples=20for (=20=3D=3D=3D=3D=3D8<---=20snip=20--->8=3D=3D=3D=3D=3D) Regards, Ronald 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 Fri May 18 11:46: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 1Hp4fG-00064V-1j; Fri, 18 May 2007 11:46:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hp4fE-00064Q-G8 for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 11:46:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp4fE-00064I-6T for manet@ietf.org; Fri, 18 May 2007 11:46:44 -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 1Hp4fD-0001C7-OK for manet@ietf.org; Fri, 18 May 2007 11:46:44 -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 l4IFkJ1D015883; Fri, 18 May 2007 18:46:41 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 18:46:32 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:46:17 -0500 Received: from [10.162.94.151] ([10.162.94.151]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 10:46:16 -0500 Message-ID: <464DCA42.2000105@nokia.com> Date: Fri, 18 May 2007 08:46:10 -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] some thoughts on DPD References: <000001c7992a$ad46c140$0202a8c0@Teco> In-Reply-To: <000001c7992a$ad46c140$0202a8c0@Teco> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2007 15:46:16.0921 (UTC) FILETIME=[ABF65C90:01C79963] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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, A few comments below... ext Teco Boot wrote: > > -> We have to specify sent packets over a MANET are unique. Choices are > _SHOULD be unique_ or _MUST be unique_. We also have a choice on uniqueness > on the whole packet or the starting N octets. Hashing over a shorter string > would save CPU. I prefer lowering overhead, e.g. specifying the first 256 > octets should guarantee uniqueness. > I thought that the problem was not in the manet, but in packets arriving at a gateway for retransmission into the manet. I agree that we ought to specify uniqueness for all packets generated within the manet. > -> The hashing algorithm for IPv6 can be reused for IPv4. This provides > support for fragmented packets and RFC791 compliant packets (ID unique for > srce, dest and proto). I highly prefer RFC791-compliance. It takes some time > to adjust the SMF draft text, and some more time to adjust code. But let's > do it correctly. (don't forget blanking TTL before hashing;-) > For IPv4, I thought we had some consensus that the ip_id field was good enough to verify uniqueness (per source). What do you think? > -> I think IPv6 packets are NOT unique by nature. Typical examples for > duplicates are keep-alive and retransmits. Sending a sequence number, ID or > retransmit counter could be useful, but this is not mandatory. Or am I > missing something? > Retransmissions are less common for broadcasts and multicasts, though... right? > -> I think DPD has a high level of acceptance by MANET unicast protocol > implementators, as it highly reduces negative effects in case of a routing > loop. This is another reason for careful specification of the mechanism. I > even think it should be part of the chartered WG work on defining a STD > unicast MANET protocol. > Isn't it already chartered, essentially as a required part of SMF? Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 18 12:29: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 1Hp5Kj-0006Br-R8; Fri, 18 May 2007 12:29:37 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hp5Kj-0006Bm-29 for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 12:29:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp5Ki-0006Be-Of for manet@ietf.org; Fri, 18 May 2007 12:29:36 -0400 Received: from neptune.azu.com ([67.15.54.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hp5Kf-00021O-0N for manet@ietf.org; Fri, 18 May 2007 12:29:36 -0400 Received: (qmail 24766 invoked by uid 89); 19 May 2007 01:29:24 +0900 Received: from unknown (HELO IBM-T42) (59.143.41.119) by 0 with SMTP; 19 May 2007 01:29:24 +0900 Date: Sat, 19 May 2007 01:29:31 +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: e1b0e72ff1bbd457ceef31828f216a86 Message-Id: Subject: [manet] CFP: P2P Computing and Autonomous Agents 2007 @ WI-IAT'07 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 We apologize in advance if you receive multiple copies of this CFP. _______________________________________________________________ CALL FOR CONTRIBUATIONS The Second IEEE International Workshop On Peer-to-Peer Computing and Autonomous Agents P2PAA 2007 http://www.kfupm.edu.sa/~helmy/P2PAA2007_WI.html (In conjunction with the International IEEE WI/IAT WI-IAT'07) http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html SILICON VALLEY, November 2-5 2007, USA Autonomous agents and Peer-to-Peer (P2P) computing are attracting enormous attention world wide. In P2P systems a very large number of autonomous computing nodes (the peers) pool together their resources and rely on each other for data and services. The main aim of the P2P Computing and Autonomous Agents Workshop is addressing the needs for autonomous agents that support self-organization of highly autonomous peers, load balance, routing, etc. The Workshop seeks papers describing significant research contributions to the field of P2P and Autonomous agents. Paper submissions are invited on Autonomous Agents techniques for P2P computing, Services in P2P and autonomous agent systems and Grid computing solutions based on autonomous agents and P2P paradigms. Areas of interest include, but are not limited to: ?Autonomous agents and query languages for P2P systems ?Data placement and query answering in P2P systems ?Transaction management for P2P systems ?Autonomous peers and Semantic Web ?Self-organization and emergent behavior in P2P systems ?P2P information retrieval architectures ?Resource allocation in P2P systems ?Coordination, robustness and adaptability in P2P systems. ?Autonomic Services in P2P systems ?P2P Grid Computing ?Services in P2P systems ?Knowledge Discovery and P2P Data Mining Agents ?P2P oriented information systems ?Security issues in P2P networks _______________________________________________________________ Important Dates Electronic submission of full papers: June 20, 2007 Notification of paper acceptance: August 2, 2007 Camera-ready of accepted papers: August 17, 2007 Workshops: November 2-5, 2007 _______________________________________________________________ Submissions Papers in P2P and autonomous agents related areas are solicited. All submitted papers will be reviewed on the basis of technical quality, relevance, significance, and clarity. Note that P2PAA'07 will accept ONLY on-line submissions, containing PDF versions. Paper submissions should be limited to a maximum of 4 pages in the IEEE 2-column format; extra payment is only available for one more extra page. Submitted papers will be reviewed by the Program Committee members. Please use the Submission Form on the P2PAA'07 website to submit your paper. Accepted papers will be published in the workshop proceedings by the IEEE Computer Society Press. _______________________________________________________________ General Inquires For more detailed and updated information, please refer to: http://www.ccse.kfupm.edu.sa/~helmy/P2PAA2007_WI.html For further information, please contact: the Chairs at [helmy@kfupm.edu.sa or ragab@mori.cs.titech.ac.jp] _______________________________________________________________ General Chair Tarek Helmy (KFUPM, Saudi Arabia) Co-Chair Khaled Ragab (Tokyo U., Japan) International Program Committee Makoto Amamiya (Kyushu University, Japan) Jeffery Bradshaw (IHMC USA) Tsunenori Mine (Kyushu University, Japan) Laurence T. Yang (St. Francis Xavier University, Canada) Aly Fahmy (Cairo University, Egypt) Khaled Shaalan (British University, UAE) Yasser Kotb (JAIST Inst.) Rabee Refat (KFUPM, Saudi Arabia) Moataz Ahmed (LEROS, USA) M.R.K. Krishna Rao (KFUPM, Saudi Arabia) Farag Ezidin (KFUPM, Saudi Arabia) Salaheldin Adam (KFUPM, Saudi Arabia) Mohamed Marghny (Assuit University) Tarek El-Tobely (Tanta University, Egypt) Omer Karem (Ain Shames University, Egypt) Kenji Kaneda (Tokyo University, Japan) R. Kowalczyk (Swinburne University, Australia) G. Alghamdi (KFUPM, Saudi Arabia) Satoshi Amamiya (Kyushu University, Japan) Iyad Rahwan (British University, UAE) Sameh El-Ansary (Swedish Institute, Sweden) Aboul Ella Hassanien (Kuwait University) Ibrahim Imam (AAST, Egypt) Mohamed Marghny (Assuit University, Egypt) Jianhua Ma (Hosei University, Japan) Mohamed Alnaser (KFUPM, Saudi Arabia) _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 18 15:50: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 1Hp8Sq-0005by-Ts; Fri, 18 May 2007 15:50:13 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hp8Sh-0005NN-7F for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8Sg-0005N2-ND; Fri, 18 May 2007 15:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8Sg-0006zZ-EA; Fri, 18 May 2007 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 65F66329EF; Fri, 18 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hp8Sg-0000RG-AK; Fri, 18 May 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, 18 May 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-iana-03.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-03.txt Pages : 6 Date : 2007-5-18 This document enumerates IANA allocations for use by MANET WG protocols. Specifically, a UDP port and two link-local multicast group addresses (IPv4 & IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-03.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-03.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-03.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-5-18115320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-iana-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-iana-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-18115320.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 May 18 17: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 1HpAB9-00049Q-Vq; Fri, 18 May 2007 17:40:04 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HpAB8-00049E-JK for manet-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 17:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpAB8-000496-9c; Fri, 18 May 2007 17:40:02 -0400 Received: from cl-433.ham-01.de.sixxs.net ([2001:6f8:900:1b0::2] helo=mx.dd19.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpAB5-00076R-Tk; Fri, 18 May 2007 17:40:02 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mx.dd19.de (Postfix) with ESMTP id 6292B6164; Fri, 18 May 2007 23:39:57 +0200 (CEST) Message-ID: <464E1D27.2010002@dd19.de> Date: Fri, 18 May 2007 23:39:51 +0200 From: Alexander Morlang User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Teco Boot Subject: Re: [manet] RE: WPF syndrome and MONAMI6 References: <004901c75f6a$0566e530$0202a8c0@Teco> In-Reply-To: <004901c75f6a$0566e530$0202a8c0@Teco> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nemo@ietf.org, 'Alexandru Petrescu' , manet@ietf.org, manemo@mobileip.jp, 'Monami6 WG' 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 Boot schrieb: > Alexandru wrote: >> Doesn't OSPF provide metrics in its LSAs (Link State Advertisements) >> that can help a router select the best metric at it sees fit? I think >> it does. > > [Teco] > OLSRv2 is still using hop count. Additions to OLSR could enhance that. > > OSPF, including OSPF MANET is using cost based metric. For network types P2P > and P2MP a metric can be set for each neighbor. OSPF MANET-interface is > P2MP. Example in draft-chandra-ospf-manet-ext-04 (section 3.1.2.1 Router > LSAs) shows selective metrics, this would be a solution for WPF. > draft-ogier-manet-ospf-extension-08.txt is similar. > > The question is how to update the metric dynamicly, this requires an L2 API. > Or count missed hellos / LSA retransmits etc. Counting missing hello packets works, it is called "lq-extension" and is implemented in the olsr.org implementation. http://www.olsr.org/docs/README-Link-Quality.html It is used for community wireless networks with up to 650 nodes. > > The question is adopting this mechanism by oyther MANET protocols, for > example by TD and use RA-TIO path metric instead of hop count? > And do we need rules for actual metric values set? > > > > > _______________________________________________ > manet mailing 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 May 21 05:13: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 1Hq3x4-0006zh-HH; Mon, 21 May 2007 05:13:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hq3x2-0006zD-Lo for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 05:13:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq3x2-0006z4-8e for manet@ietf.org; Mon, 21 May 2007 05:13:12 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq3x1-0002Xk-Vd for manet@ietf.org; Mon, 21 May 2007 05:13:12 -0400 Received: by wx-out-0506.google.com with SMTP id s7so240997wxc for ; Mon, 21 May 2007 02:13:11 -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=YqThSMyTAlK3bV/D8FO+HNKCaX8BBrcsHS/x0SPdGtFRtfbGAzOCmuGhB63x1O2Krki4wQLhNypiR5VzUw/V/BwznMjWUl1eLWykX2Sy5arEBRhQDJpoJ6GXcDFAMDAfc2B+K+WlF2wey76cXc9dQfZRzmdtDB+3clOXHlnDhxw= 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=anB/XzOa4/rKmNYA5wBtPT0NLt8Po9lPbSa49NKTEPdMl8fvcSy9jLEIck+MnUxOlTKuK7yrfSShIOExwfs7pYBKGq1yYbjzRrp7zgT44eOm9AvCJU0BK102mkkCfPOinF+QWOEosev5y7A416BpM+xd9S05zwgTrje8bsiWcc8= Received: by 10.78.132.2 with SMTP id f2mr1038558hud.1179738790630; Mon, 21 May 2007 02:13:10 -0700 (PDT) Received: by 10.78.33.14 with HTTP; Mon, 21 May 2007 02:13:10 -0700 (PDT) Message-ID: <374005f30705210213h67f9c469o7a2b3b7f3de9458e@mail.gmail.com> Date: Mon, 21 May 2007 14:43:10 +0530 From: "Ian Chakeres" To: manet Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-03.txt = WGLC 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: 41c17b4b16d1eedaa8395c26e9a251c4 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've update the IANA ID. Site-local multicast addresses allocations have been removed. I'd like to reissue the WGLC. Please contact me or email the list with any remaining concerns. Ian Chakeres On 5/19/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-03.txt > Pages : 6 > Date : 2007-5-18 > > This document enumerates IANA allocations for use by MANET WG > protocols. Specifically, a UDP port and two link-local multicast > group addresses (IPv4 & IPv6). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-03.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-03.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-03.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 Mon May 21 05:19: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 1Hq43D-00022b-Kz; Mon, 21 May 2007 05:19:35 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hq43C-00022W-Ab for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 05:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq43C-00022O-0T for manet@ietf.org; Mon, 21 May 2007 05:19:34 -0400 Received: from mail.gdatech.co.in ([202.144.30.226] helo=gdatech.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq43A-00042i-GW for manet@ietf.org; Mon, 21 May 2007 05:19:33 -0400 Received: from [192.168.0.2] (localhost.localdomain [127.0.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id F3EF58780D7 for ; Mon, 21 May 2007 02:19:30 -0700 (PDT) X-Propel-Return-Path: Received: from gdatech.co.in ([192.168.0.3]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.0.6841-branch_6613 $Rev: 6586 $) id gP3jr75l9ju1; Mon, 21 May 2007 02:19:30 -0700 Received: from mail.gdatech.co.in (unknown [192.168.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id AF41A8780B7 for ; Mon, 21 May 2007 02:19:30 -0700 (PDT) Received: (qmail 25663 invoked by uid 89); 21 May 2007 09:29:42 -0000 Received: from unknown (HELO ?192.168.3.90?) (b.nagarajan@192.168.3.90) by 0 with SMTP; 21 May 2007 09:29:42 -0000 Message-ID: <46516429.6010602@gdatech.co.in> Date: Mon, 21 May 2007 14:49:37 +0530 From: nagarajan User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: manet X-Propel-ID: gP3jr75l9ju1 X-Spam-Score: 1.2 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [manet] Routing protocols for Wireless Mesh 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: , Content-Type: multipart/mixed; boundary="===============0132813967==" Errors-To: manet-bounces@ietf.org --===============0132813967== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

       Can the following protocols

  • Ad-hoc On Demand Distance Vector Routing protocol - AODV
  • Optimized Link State Routing protocol - OLSR
       be used for Wireless Mesh Networks??

Thanks and Regards,
Nagarajan
--===============0132813967== 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 --===============0132813967==-- From manet-bounces@ietf.org Mon May 21 05:22: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 1Hq45X-00031R-Ic; Mon, 21 May 2007 05:21:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hq45V-00031E-Nh for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 05:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq45V-000316-Du for manet@ietf.org; Mon, 21 May 2007 05:21:57 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hq45T-0004js-OB for manet@ietf.org; Mon, 21 May 2007 05:21:57 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-5.tower-128.messagelabs.com!1179739314!758010!1 X-StarScan-Version: 5.5.10.7.1; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 31634 invoked from network); 21 May 2007 09:21:54 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-5.tower-128.messagelabs.com with SMTP; 21 May 2007 09:21:54 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l4L9Lsd2018965; Mon, 21 May 2007 02:21:54 -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 l4L9LsmM016927; Mon, 21 May 2007 04:21:54 -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 l4L9LqoN016913; Mon, 21 May 2007 04:21:53 -0500 (CDT) Message-ID: <465164B0.2010101@gmail.com> Date: Mon, 21 May 2007 11:21:52 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-03.txt = WGLC References: <374005f30705210213h67f9c469o7a2b3b7f3de9458e@mail.gmail.com> In-Reply-To: <374005f30705210213h67f9c469o7a2b3b7f3de9458e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000741-4, 18/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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've update the IANA ID. Site-local multicast addresses allocations > have been removed. > > I'd like to reissue the WGLC. Please contact me or email the list with > any remaining concerns. Thanks, I've read it when it was issued. I'm basically fine with its current form. Two nits in the References section: it's useful to tag the URL in the References section with the date it was actually browsed; saying "http://http://" is probably an error in the formatting tool(?). Alex > > Ian Chakeres > > On 5/19/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-03.txt >> Pages : 6 >> Date : 2007-5-18 >> >> This document enumerates IANA allocations for use by MANET WG >> protocols. Specifically, a UDP port and two link-local multicast >> group addresses (IPv4 & IPv6). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-03.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-03.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-03.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 > ______________________________________________________________________ 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 May 21 05:26: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 1Hq49f-0007sj-TL; Mon, 21 May 2007 05:26:15 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hq49e-0007sY-6n for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 05:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq49d-0007sO-Lv for manet@ietf.org; Mon, 21 May 2007 05:26:13 -0400 Received: from thsmsgxrt11p.thalesgroup.com ([192.54.144.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq49c-000677-5X for manet@ietf.org; Mon, 21 May 2007 05:26:13 -0400 Received: from thsmsgirt23p.corp.thales (unknown [10.33.231.7]) by thsmsgxrt11p.thalesgroup.com (Postfix) with ESMTP id 548BC3C037 for ; Mon, 21 May 2007 11:26:11 +0200 (CEST) Received: from [10.33.231.32] (10.33.231.32) by thsmsgirt23p.corp.thales (7.2.055.4) id 4646F76A00126982 for manet@ietf.org; Mon, 21 May 2007 11:26:16 +0200 Received: from (10.33.231.1) by via smtp id 616d_503ee376_077d_11dc_9416_0013725118e7; Mon, 21 May 2007 11:26:11 +0200 (CEST) Received: from msw002.uk.trt.thales (unknown [10.33.5.101]) by thsmsgirt11p.corp.thales (Postfix) with ESMTP id 349783C009 for ; Mon, 21 May 2007 11:26:09 +0200 (CEST) Received: from NTS013.uk.trt.thales (nts013.uk.trt.thales) by msw002.uk.trt.thales (Clearswift SMTPRS 5.2.3) with ESMTP id ; Mon, 21 May 2007 10:26:05 +0100 Received: by nts013.uk.trt.thales with Internet Mail Service (5.5.2656.59) id ; Mon, 21 May 2007 10:26:05 +0100 Message-ID: <51BF576D5A02CC4CB2591F50994FD76601D3AB37@nts013.uk.trt.thales> From: "Tan, Chiang Kang " To: 'nagarajan' Subject: RE: [manet] Routing protocols for Wireless Mesh Networks Date: Mon, 21 May 2007 10:26:05 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Content-Type: multipart/mixed; boundary="===============1078132540==" Errors-To: manet-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1078132540== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79B8A.0E4E12FC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C79B8A.0E4E12FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Nagarajan, I don't suppose there's any reason why these protocols can be not be for wireless mesh networks, if you find them suitable for your use... cheers Chiang -----Original Message----- From: nagarajan [mailto:b.nagarajan@gdatech.co.in] Sent: 21 May 2007 10:20 To: manet Subject: [manet] Routing protocols for Wireless Mesh Networks Hi all, Can the following protocols * Ad-hoc On Demand Distance Vector Routing protocol - AODV * Optimized Link State Routing protocol - OLSR be used for Wireless Mesh Networks?? Thanks and Regards, Nagarajan ******************************************************************************* This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may not be divulged to any third party without the express permission of the originator. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thales Research & Technology (UK) Limited. ******************************************************************************* ------_=_NextPart_001_01C79B8A.0E4E12FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Hi Nagarajan,
    I don't suppose there's any reason why these protocols can be not be for wireless
mesh networks, if you find them suitable for your use...
 
cheers
Chiang
-----Original Message-----
From: nagarajan [mailto:b.nagarajan@gdatech.co.in]
Sent: 21 May 2007 10:20
To: manet
Subject: [manet] Routing protocols for Wireless Mesh Networks

Hi all,

       Can the following protocols

  • Ad-hoc On Demand Distance Vector Routing protocol - AODV
  • Optimized Link State Routing protocol - OLSR
       be used for Wireless Mesh Networks??

Thanks and Regards,
Nagarajan

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

This email and any files transmitted with it are intended solely for the use of

the individual or entity to whom they are addressed and may not be divulged to

any third party without the express permission of the originator. Any views

expressed in this message are those of the individual sender, except where the

sender specifically states them to be the views of Thales Research & Technology

(UK) Limited.

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

 

------_=_NextPart_001_01C79B8A.0E4E12FC-- --===============1078132540== 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 --===============1078132540==-- From manet-bounces@ietf.org Mon May 21 05:33: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 1Hq4H7-00030m-Nd; Mon, 21 May 2007 05:33:57 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hq4H5-00030d-Mt for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 05:33:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq4H5-00030V-D9 for manet@ietf.org; Mon, 21 May 2007 05:33:55 -0400 Received: from ik-out-1112.google.com ([66.249.90.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq4H4-0007bH-Su for manet@ietf.org; Mon, 21 May 2007 05:33:55 -0400 Received: by ik-out-1112.google.com with SMTP id c29so822536ika for ; Mon, 21 May 2007 02:33:54 -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=lsb0LxiyQNXttPY0YuRw76QBUFv8YBYwhQ40eeJdDJqS0je9YqgtNy25sn2HouFEC0KG8fEMklZIUtdSUesvvtlAUKxCWP/WiYcKBBNihBLkTw4W+Zad6DpGqWlgt2R+rT9+VC1OTv70fObgwtg04Mw+l9uaVJeDpYLpdX/rgAE= 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=A3yamUuTU0XOfEWY5y+6AbsQvjSBTWrvwsApOgqBrqz+nJEkoPY7ZpQ8YKIWZNOHu2RfD9JHLfTEMTQCDu1PzTEN49ZFXAJH1VcRl0WXxUw5FY4QQTySKqjvhKQMmVcMvyddqM1ZkYuqkDYvdZ3BeU5/7w17gjfHMJQNCloQQ00= Received: by 10.78.48.16 with SMTP id v16mr1045435huv.1179740034081; Mon, 21 May 2007 02:33:54 -0700 (PDT) Received: by 10.78.48.10 with HTTP; Mon, 21 May 2007 02:33:54 -0700 (PDT) Message-ID: Date: Mon, 21 May 2007 11:33:54 +0200 From: "Henrik Lundgren" To: "Siva Sivavakeesar" Subject: Re: [manet] APEView Functionality of APE Testbed In-Reply-To: <957d36030705180431l2bf10ee6j288005640882323a@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: <957d36030705160857xb89b893uc4c48e5288228dda@mail.gmail.com> <957d36030705180431l2bf10ee6j288005640882323a@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 Dear Siva, see my comments inlined. On 5/18/07, Siva Sivavakeesar wrote: > Henrik, > > Thanks - this is exactly what I wanted. From your mail, I can now > understand that the virtual-mobility functionality does not make use > of any data being logged in real-time to give instructions about > future movements. Initially, I was suspecting how can SNR information > be used to give such movement instructions. Despite this, this is > what, however, one of your README files (ape-testbed.tex) says: No, you have misinterpreted the text. There is nothing that states that SNR is used to give movement instructions. The text very briefly explains what the virtual mobility metric is, and that you can use it when comparing the similarity between testruns (in terms of "virtual" mobility, i.e., snr fluctucations, and connectivity). > "APE introduce a new mobility metric for real world tests called > ``virtual mobility'' (vM), which is based on SNR changes in links > between nodes. SNR is mapped to a ``virtual distance'', then vM is > calculated as the changes in ``virtual distance'' between two > consecutive time intervals. vM is mainly used for two purposes: one is > to estimate the degree of similarity between two testruns (in a > mobility and movement sense, but also in a connectivity sense, since > vM is dependent on inter-node connectivity), and to provide a way to > evaluate how it affects other metrics, for example packet loss". I hope it is clear now :) > I am sure that VM is different from APEview - the latter being > responsible for displaying the instantaneous topological > configurations of nodes during each test run. Hence, it is reasonable vM is a metric, typically used when post-processing a testrun. APEview is a graphical tool that displays node connectivity and the distance between nodes is based on the quality of the links between them (e.g., based on SNR). > to expect that for the APEview to work, it needs to rely on SNR data > being logged in real-time. On the other hand, as far as I understood As I have said in reply to one of your other recent emails, you can use APEview either in real-time or you can use it to replay a scenario based on stored log files. (to run it in real-time you must collect the needed information and send it to APEview in real-time, typically through a backhaul network). > from reading the APE documents, I have the impression that it is the > VM functionality that gives the users the movement instructions. If it > the case, it should not rely on any SNR inofmration - but the previous > paragraph says that it makes use of SNR - is this correct ? If you > have time, please clarify my ambiquity. No, neither vM nor SNR information is used to drive movement instructions! The movement choreography is separate from this. See what I said in my previous email (below): > > Instead this movement choreography > > is typicially based on pre-determined (carefully designed, timed, and > > rehearsed) to provide the highest level of repeatability possible. > > This movement choreography is provided in a separate global configuration > > file in which the movement including timing is provided for each node. I hope it is clear(er) for you now. If not, please download the source code and have a look at the testrun configuration files and this will become clear to you :) I hope this helped, Henrik > > Thanks in advance for taking your invaluable time to answer my questions. > > Best Regards, > > Siva > > On 5/18/07, Henrik Lundgren wrote: > > Siva, > > > > The APEview tool can display node/link information and position > > nodes relative to each other based on the information you feed into it. > > It can be done to replay testruns in terms of the information you > > choose to provide to the tool. It can also be used in real-time as long > > as you have implemented the means to provide the information to > > the tool in real-time, for example, through a backhaul network. > > > > However, the positioning of nodes in the APEview tool is not used > > to drive movement instructions. Instead this movement choreography > > is typicially based on pre-determined (carefully designed, timed, and > > rehearsed) to provide the highest level of repeatability possible. > > This movement choreography is provided in a separate global configuration > > file in which the movement including timing is provided for each node. > > > > hope this helps, > > > > -- Henrik > > > > > > On 5/16/07, Siva Sivavakeesar wrote: > > > Hello there, > > > > > > I am wondering whether somebody can shed me some light on how the > > > "APEView" functionality of APE testbed is implemented. I have been > > > involved with MANET testbed experiments, where I need to make sure > > > that in successive test runs participating nodes take the same > > > trajectories. This is important because I am comparing the > > > performances of two high-level routing protocols. > > > > > > As far as I understood, the APEview makes use of some log files (e.g., > > > RSSI measurement) to provide movement instructions to > > > test-participants during the actual testruns. My question is whether > > > this signal quality information is logged in real-time and it is > > > mearely this information being used for navigating purposes. In othere > > > words, what information is used to provide such movement instructions > > > to the users ? Please shed some light as much as possible. > > > > > > Thanks in advance for taking your invaluable time to answer my question. > > > > > > Best Regards, > > > > > > Dr. Siva > > > > > > > > > _______________________________________________ > > > manet mailing 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 May 21 06: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 1Hq5Ek-0007L0-Mw; Mon, 21 May 2007 06:35:34 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hq5Ei-0007DJ-MM for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 06:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq5Ei-0007DA-Cb for manet@ietf.org; Mon, 21 May 2007 06:35:32 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq5Eh-0004aL-Vu for manet@ietf.org; Mon, 21 May 2007 06:35:32 -0400 Received: by an-out-0708.google.com with SMTP id c34so451758anc for ; Mon, 21 May 2007 03:35:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=googlemail.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=EgYoS/2TMBgyag5w1juSxkCyBrw3N+K6BSJKMuAlOSEB/Xwk+gcQ4dt74IVfUC4zN5jHLVT3erkvhNjO/x9tvtv+clZBeXnDNtYolUxf+j1qpCG8BXVxIZX8ScyiX8B2z9Bqz9VnJOwZJWHXi7gegVYBuNA5q4juAf7cBDwUVRc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.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=Mbjxvw3xx6NOD9poPoZ9xiLDisuqY+liBDgm22ypyWqe3tKzDpVbvWYRepmrM+L0eOuENTCkeVXkudkpCMvGz4uRocGQ+5pf8Gho+YRzPWuSeyEPxyo6bl3ZgSlSfhiHcqN5Em/taPorIyWWOMAS2a2P47bWJedBOnzN1Bc/OEk= Received: by 10.100.200.12 with SMTP id x12mr2839574anf.1179743731667; Mon, 21 May 2007 03:35:31 -0700 (PDT) Received: by 10.100.174.2 with HTTP; Mon, 21 May 2007 03:35:31 -0700 (PDT) Message-ID: <957d36030705210335w66065a34x8a89282cdfd1a872@mail.gmail.com> Date: Mon, 21 May 2007 11:35:31 +0100 From: "Siva Sivavakeesar" To: "Henrik Lundgren" Subject: Re: [manet] APEView Functionality of APE Testbed 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: <957d36030705160857xb89b893uc4c48e5288228dda@mail.gmail.com> <957d36030705180431l2bf10ee6j288005640882323a@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 Henrik, Thanks for making an effort to answer my questions. Cheers Siva On 5/21/07, Henrik Lundgren wrote: > Dear Siva, > > see my comments inlined. > > On 5/18/07, Siva Sivavakeesar wrote: > > Henrik, > > > > Thanks - this is exactly what I wanted. From your mail, I can now > > understand that the virtual-mobility functionality does not make use > > of any data being logged in real-time to give instructions about > > future movements. Initially, I was suspecting how can SNR information > > be used to give such movement instructions. Despite this, this is > > what, however, one of your README files (ape-testbed.tex) says: > > No, you have misinterpreted the text. There is nothing that > states that SNR is used to give movement instructions. The text > very briefly explains what the virtual mobility metric is, and that > you can use it when comparing the similarity between testruns > (in terms of "virtual" mobility, i.e., snr fluctucations, and > connectivity). > > > > "APE introduce a new mobility metric for real world tests called > > ``virtual mobility'' (vM), which is based on SNR changes in links > > between nodes. SNR is mapped to a ``virtual distance'', then vM is > > calculated as the changes in ``virtual distance'' between two > > consecutive time intervals. vM is mainly used for two purposes: one is > > to estimate the degree of similarity between two testruns (in a > > mobility and movement sense, but also in a connectivity sense, since > > vM is dependent on inter-node connectivity), and to provide a way to > > evaluate how it affects other metrics, for example packet loss". > > I hope it is clear now :) > > > > I am sure that VM is different from APEview - the latter being > > responsible for displaying the instantaneous topological > > configurations of nodes during each test run. Hence, it is reasonable > > vM is a metric, typically used when post-processing a testrun. > APEview is a graphical tool that displays node connectivity and the > distance between nodes is based on the quality of the links between > them (e.g., based on SNR). > > > to expect that for the APEview to work, it needs to rely on SNR data > > being logged in real-time. On the other hand, as far as I understood > > As I have said in reply to one of your other recent emails, you can use > APEview either in real-time or you can use it to replay a scenario based > on stored log files. (to run it in real-time you must collect the needed > information and send it to APEview in real-time, typically through a > backhaul network). > > > from reading the APE documents, I have the impression that it is the > > VM functionality that gives the users the movement instructions. If it > > the case, it should not rely on any SNR inofmration - but the previous > > paragraph says that it makes use of SNR - is this correct ? If you > > have time, please clarify my ambiquity. > > No, neither vM nor SNR information is used to drive movement instructions! > The movement choreography is separate from this. See what I said in my > previous email (below): > > > > Instead this movement choreography > > > is typicially based on pre-determined (carefully designed, timed, and > > > rehearsed) to provide the highest level of repeatability possible. > > > This movement choreography is provided in a separate global > configuration > > > file in which the movement including timing is provided for each node. > > > I hope it is clear(er) for you now. If not, please download the source code > and > have a look at the testrun configuration files and this will become > clear to you :) > > I hope this helped, > > Henrik > > > > > > Thanks in advance for taking your invaluable time to answer my questions. > > > > Best Regards, > > > > Siva > > > > On 5/18/07, Henrik Lundgren wrote: > > > Siva, > > > > > > The APEview tool can display node/link information and position > > > nodes relative to each other based on the information you feed into it. > > > It can be done to replay testruns in terms of the information you > > > choose to provide to the tool. It can also be used in real-time as long > > > as you have implemented the means to provide the information to > > > the tool in real-time, for example, through a backhaul network. > > > > > > However, the positioning of nodes in the APEview tool is not used > > > to drive movement instructions. Instead this movement choreography > > > is typicially based on pre-determined (carefully designed, timed, and > > > rehearsed) to provide the highest level of repeatability possible. > > > This movement choreography is provided in a separate global > configuration > > > file in which the movement including timing is provided for each node. > > > > > > hope this helps, > > > > > > -- Henrik > > > > > > > > > On 5/16/07, Siva Sivavakeesar wrote: > > > > Hello there, > > > > > > > > I am wondering whether somebody can shed me some light on how the > > > > "APEView" functionality of APE testbed is implemented. I have been > > > > involved with MANET testbed experiments, where I need to make sure > > > > that in successive test runs participating nodes take the same > > > > trajectories. This is important because I am comparing the > > > > performances of two high-level routing protocols. > > > > > > > > As far as I understood, the APEview makes use of some log files (e.g., > > > > RSSI measurement) to provide movement instructions to > > > > test-participants during the actual testruns. My question is whether > > > > this signal quality information is logged in real-time and it is > > > > mearely this information being used for navigating purposes. In othere > > > > words, what information is used to provide such movement instructions > > > > to the users ? Please shed some light as much as possible. > > > > > > > > Thanks in advance for taking your invaluable time to answer my > question. > > > > > > > > Best Regards, > > > > > > > > Dr. Siva > > > > > > > > > > > > _______________________________________________ > > > > manet mailing 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 May 21 07:42: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 1Hq6HY-00088V-Q3; Mon, 21 May 2007 07:42:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hq6HQ-00085q-Qz for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 07:42:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq6HQ-00081u-A3 for manet@ietf.org; Mon, 21 May 2007 07:42:24 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq6HO-0003m0-Ft for manet@ietf.org; Mon, 21 May 2007 07:42:24 -0400 Received: (qmail 21283 invoked from network); 21 May 2007 13:42:20 +0200 Received: from unknown (HELO Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 21 May 2007 13:42:19 +0200 From: "Teco_Boot" To: "'Charles E. Perkins'" Subject: RE: [manet] some thoughts on DPD Date: Mon, 21 May 2007 13:43:09 +0200 Message-ID: <005401c79b9d$46d08570$be00800a@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <464DCA42.2000105@nokia.com> Thread-Index: AceZY7yyL9s4G5O1RNGri2FuGcj0cgCKYeug X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Perkins wrote: >>>> Specification for uniqueness: > I thought that the problem was not in the manet, but in packets > arriving at a gateway for retransmission into the manet. I agree > that we ought to specify uniqueness for all packets generated > within the manet. [Teco] I think it is better to specify it for both cases, e.g. end-to-end and on MANET ingress boxes (taggers). I think a need for changing packets in the network should be prevented. >>>> DPD for IPv4: > For IPv4, I thought we had some consensus that the ip_id field was > good enough to verify uniqueness (per source). What do you think? [Teco] I think RFC791 shall take precedence over new ideas. So ip_id shall be unique for srce, dest, proto and fragment offset as already specified in RFC791. Why deviate from RFC791 when it is not needed? >>>> IPv6 keep-alive and retransmits: > Retransmissions are less common for broadcasts and multicasts, though... > right? [Teco] I agree it is less common. But I think we have to support it. PGM RDATA/NAK/NCF are examples (RFC3208). I didn't doublecheck for duplicates, we can ask someone if needed. NORM (RFC3940) has sequence numbers, so no problems there. >>>> DPD for unicast MANET protocol: > Isn't it already chartered, essentially as a required part of SMF? [Teco] I am not aware of any activity making DPD part of a standards track RFC. I suggest reusing SMF DPD mechanism for unicast forwarding. We could discuss this at next IETF and decide it will be part of our chartered work. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 21 07:52: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 1Hq6Qw-00057f-0A; Mon, 21 May 2007 07:52:14 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hq6Qs-00057W-QG for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 07:52:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq6Qr-00057N-Tk for manet@ietf.org; Mon, 21 May 2007 07:52:10 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq6Qq-0007WB-Gt for manet@ietf.org; Mon, 21 May 2007 07:52:09 -0400 Received: (qmail 26395 invoked from network); 21 May 2007 13:52:07 +0200 Received: from unknown (HELO Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 21 May 2007 13:52:06 +0200 From: "Teco_Boot" To: "'Velt, R. \(Ronald\) in 't'" Subject: RE: [manet] some thoughts on DPD Date: Mon, 21 May 2007 13:52:56 +0200 Message-ID: <005601c79b9e$a4ace200$be00800a@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7877C5C0B5CC894AB26113CF06CF88637BDEBC@ms-dt01thalia.tsn.tno.nl> Thread-Index: AceZKqDHv/ixMT0nR2GEHEdEtJJvmQAMuSmAAJAdoxA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Ronald intVelt wrote: >>>> hashing algorithm: >>>> (don't forget blanking TTL before hashing;-) > _And_ the Header Checksum... > _And_ the TOS-byte / DS field or TC field (IPv6), I guess. A duplicate > packet, having taken a different route than the original, may have been > remarked, while the original was left untouched or vice versa. One copy > may have had the ECN CE codepoint set, while the other has not. [Teco] And we have to evaluate header options, e.g. updated routing headers. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 21 08:36: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 1Hq77z-0000UV-9g; Mon, 21 May 2007 08:36:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hq77u-0000UD-Fz for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 08:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq77t-0000U4-17 for manet@ietf.org; Mon, 21 May 2007 08:36:37 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq77r-0003w0-Ki for manet@ietf.org; Mon, 21 May 2007 08:36:37 -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 l4LCaVSO011603 for ; Mon, 21 May 2007 13:36:31 +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 l4LCaVf2002114 for ; Mon, 21 May 2007 13:36:31 +0100 Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 21 May 2007 13:36:30 +0100 Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Mon, 21 May 2007 13:36:30 +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] some thoughts on DPD Date: Mon, 21 May 2007 13:36:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] some thoughts on DPD Thread-Index: AceZY7yyL9s4G5O1RNGri2FuGcj0cgCKYeugAAVySHA= From: "Dearlove, Christopher \(UK\)" To: "Teco_Boot" , "Charles E. Perkins" X-OriginalArrivalTime: 21 May 2007 12:36:30.0635 (UTC) FILETIME=[A8723FB0:01C79BA4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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]=20 I think RFC791 shall take precedence over new ideas. So ip_id shall be unique for srce, dest, proto and fragment offset as already specified in RFC791. Why deviate from RFC791 when it is not needed? Caveat: This is not an area I'm an expert in. And I may have missed the point of the discussion. But if I have I'm sure I'll learn something from the corrections. My understanding was that more important than either is what already happens in practice - millions of IP stacks are not going to be rewritten for the benefit of MANETs. And here as I understand it, behaviour varies. A Google search on the subject threw up as an early hit http://www.mit.edu/~rbeverly/papers/tcpclass-pam04.pdf which isn't the original source of my understanding, but has some comments about NATs interfering with IP IDs that may be relevant, as well as other interesting material. Final caveat: I've only skimmed it at this time. (In case it helps: my search was "ip id uniqueness" - without the quotes. This was the third hit, and the only one I've looked at.) ******************************************************************** 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 May 21 13:39:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqBrD-0004Se-6s; Mon, 21 May 2007 13:39:43 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HqBrC-0004SX-4b for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 13:39:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqBrB-0004SO-R8 for manet@ietf.org; Mon, 21 May 2007 13:39:41 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqBrA-000423-FQ for manet@ietf.org; Mon, 21 May 2007 13:39:41 -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 l4LHddxT022588; Mon, 21 May 2007 13:39:39 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007052113393818579 ; Mon, 21 May 2007 13:39:38 -0400 From: "Joe Macker" To: "'Ian Chakeres'" , "'manet'" References: <374005f30705210213h67f9c469o7a2b3b7f3de9458e@mail.gmail.com> Subject: RE: [manet] I-D ACTION:draft-ietf-manet-iana-03.txt = WGLC Date: Mon, 21 May 2007 13:39:36 -0400 Message-ID: <00ff01c79bce$ffe2cb50$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: <374005f30705210213h67f9c469o7a2b3b7f3de9458e@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcebiJRXcDVoFAlATRWOgQJcXsmMrwARgPhg X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 concur with removing the site-local multicast allocation section. -joe >-----Original Message----- >From: Ian Chakeres [mailto:ian.chakeres@gmail.com] >Sent: Monday, May 21, 2007 5:13 AM >To: manet >Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-03.txt = WGLC > >I've update the IANA ID. Site-local multicast addresses >allocations have been removed. > >I'd like to reissue the WGLC. Please contact me or email the >list with any remaining concerns. > >Ian Chakeres > >On 5/19/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-03.txt >> Pages : 6 >> Date : 2007-5-18 >> >> This document enumerates IANA allocations for use by MANET WG >> protocols. Specifically, a UDP port and two link-local multicast >> group addresses (IPv4 & IPv6). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-03.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-03.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-03.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 > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 21 14:38: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 1HqCm1-00051c-S2; Mon, 21 May 2007 14:38:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HqCm0-00051X-Ff for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 14:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqCm0-00051P-5s for manet@ietf.org; Mon, 21 May 2007 14:38:24 -0400 Received: from virginia.nps.edu ([205.155.65.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqClz-0007OM-R0 for manet@ietf.org; Mon, 21 May 2007 14:38:24 -0400 Received: from [172.20.58.27] ([172.20.58.27]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 May 2007 11:38:22 -0700 Subject: RE: [manet] Routing protocols for Wireless Mesh Networks From: Rex Buddenberg To: "Tan, Chiang Kang" In-Reply-To: <51BF576D5A02CC4CB2591F50994FD76601D3AB37@nts013.uk.trt.thales> References: <51BF576D5A02CC4CB2591F50994FD76601D3AB37@nts013.uk.trt.thales> Content-Type: text/plain Date: Mon, 21 May 2007 11:36:28 -0700 Message-Id: <1179772588.3106.49.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2007 18:38:22.0915 (UTC) FILETIME=[35F94130:01C79BD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Nagarajan, 'mesh' is a somewhat abused term in this business. But in general, it connotes a layer 2 solution to problems like need to handoff from one base station to another and need to daisy-chain multiple nodes together (usually thought of as a hermaphrodite rig where a node is BS in one segment and SS in another). Most of the mesh solutions we've seen, being at layer 2, are technology-dependent. And the problem with layer 2 solutions appears to be in loop behavior. Loops in LAN protocols result when bridges are connected in such a way that bridge forwarding returns a frame back to it's origin. At layer 2, a loop can result in frames 'ringing' around the network forever. Obviously not a Good Thing. So within layer 2, IEEE 802.1 worked up a spanning tree protocol. It deals with loops by detecting them and inserting logical breaks in the forwarding chain. Turning a graph back into a tree. The problem is that in a lot of situations where we want 'mesh' solutions, we have some very pressing high availability engineering requirements. We also want to introduce lots of alternate routes to account for those that fail at any point in time. In other words, for Ao reasons we want altroutes ... which are loops! Indeed, show me situations where high Ao isn't a trumping requirement. Single-threaded networks are fragile. And single threaded, multiple hop radio networks are reeeealy fragile. So I tend to get suspicious about vendors telling me about their mesh solutions when they tell me they are using spanning tree. ... rig a test to show what happens with loops. A routed solution, which is what you're implying in your question, is working at layer 3. Here we have a set of protocols that have long tolerated and used alternate routes. The obvious example here is that we're not frame-forwarding, but rather datagram forwarding. And each hop results in a decremented TTL value in the datagram header ... eventually a ringing datagram will timeout and self-extinguish. Help? On Mon, 2007-05-21 at 10:26 +0100, Tan, Chiang Kang wrote: > Hi Nagarajan, > I don't suppose there's any reason why these protocols can be not > be for wireless > mesh networks, if you find them suitable for your use... > > cheers > Chiang > -----Original Message----- > From: nagarajan [mailto:b.nagarajan@gdatech.co.in] > Sent: 21 May 2007 10:20 > To: manet > Subject: [manet] Routing protocols for Wireless Mesh Networks > > > Hi all, > > Can the following protocols > > * Ad-hoc On Demand Distance Vector Routing protocol - > AODV > * Optimized Link State Routing protocol - OLSR > be used for Wireless Mesh Networks?? > > Thanks and Regards, > Nagarajan > > ******************************************************************************* > > This email and any files transmitted with it are intended solely for > the use of > > the individual or entity to whom they are addressed and may not be > divulged to > > any third party without the express permission of the originator. Any > views > > expressed in this message are those of the individual sender, except > where the > > sender specifically states them to be the views of Thales Research & > Technology > > (UK) Limited. > > ******************************************************************************* > > > > _______________________________________________ > manet mailing 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 May 22 08:04: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 1HqT6a-0007gA-Iq; Tue, 22 May 2007 08:04:44 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HqEic-00025S-97 for manet-confirm+ok@megatron.ietf.org; Mon, 21 May 2007 16:43:02 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HqEib-00025K-Vq for manet@ietf.org; Mon, 21 May 2007 16:43:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqEhH-0001dV-1H for manet@ietf.org; Mon, 21 May 2007 16:41:39 -0400 Received: from server18.pronicsolutions.com ([66.103.131.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqEhD-0000D9-Fq for manet@ietf.org; Mon, 21 May 2007 16:41:39 -0400 Received: from [24.126.99.124] (helo=HerbRubens) by server18.pronicsolutions.com with esmtpa (Exim 4.66) (envelope-from ) id 1HqEh8-0000EU-52; Mon, 21 May 2007 16:41:30 -0400 From: "Herbert Rubens" To: "'Rex Buddenberg'" , "'Tan, Chiang Kang'" References: <51BF576D5A02CC4CB2591F50994FD76601D3AB37@nts013.uk.trt.thales> <1179772588.3106.49.camel@localhost.localdomain> Subject: RE: [manet] Routing protocols for Wireless Mesh Networks Date: Mon, 21 May 2007 16:41:26 -0400 Organization: Persistent Systems, LLC Message-ID: <002d01c79be8$68a7e4e0$6401a8c0@HerbRubens> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1179772588.3106.49.camel@localhost.localdomain> Thread-Index: Aceb1z73EKRcQsikQWqkWGHieL83CwADVJMg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server18.pronicsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - persistentsystems.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 X-TMDA-Confirmed: Mon, 21 May 2007 16:43:01 -0400 X-Mailman-Approved-At: Tue, 22 May 2007 08:04:40 -0400 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hrubens@persistentsystems.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Rex, It sounds like what you are looking for is a layer 2 routing protocol which is instantaneously loop free. Most link-state protocols do not have this property and are only loop free in their converged steady state (this is true at regardless of whether they operate at layer 2 or layer 3). However, it is possible to design protocols which have this property. The most obvious example of such a protocol would be DSR, since it uses source routing. It wouldn't make sense in the context of DSR to source route a packet into a loop. There are definitely other protocols which provide instantaneous loop freedom; DSR was just the most obvious example. Like you mentioned, the Spanning Tree Protocol can turn a graph into a tree to 'try' and prevent routing loops. The problem is that packets which are routed to destinations which are not the root of the tree probably could have found a better route in the graph as opposed to the tree. If you consider 3 wired switches connected in a loop, the spanning tree protocol will remove one of the links to form a tree. This means that two of the switches can't communicate across their direct wired connection and are forced to hop through the intermediate switch. On a wired network this may or may not be the end of the world, but in a wireless network two hops instead of one 'could' result in losing half (or more) of your bandwidth (depending on the link speeds). In general, running the 'standard' spanning tree protocol to create a mesh is a very bad idea. -Herb -------------------------- Herbert Rubens Persistent Systems, LLC www.PersistentSystems.com -----Original Message----- From: Rex Buddenberg [mailto:budden@nps.navy.mil] Sent: Monday, May 21, 2007 2:36 PM To: Tan, Chiang Kang Cc: manet Subject: RE: [manet] Routing protocols for Wireless Mesh Networks Nagarajan, 'mesh' is a somewhat abused term in this business. But in general, it connotes a layer 2 solution to problems like need to handoff from one base station to another and need to daisy-chain multiple nodes together (usually thought of as a hermaphrodite rig where a node is BS in one segment and SS in another). Most of the mesh solutions we've seen, being at layer 2, are technology-dependent. And the problem with layer 2 solutions appears to be in loop behavior. Loops in LAN protocols result when bridges are connected in such a way that bridge forwarding returns a frame back to it's origin. At layer 2, a loop can result in frames 'ringing' around the network forever. Obviously not a Good Thing. So within layer 2, IEEE 802.1 worked up a spanning tree protocol. It deals with loops by detecting them and inserting logical breaks in the forwarding chain. Turning a graph back into a tree. The problem is that in a lot of situations where we want 'mesh' solutions, we have some very pressing high availability engineering requirements. We also want to introduce lots of alternate routes to account for those that fail at any point in time. In other words, for Ao reasons we want altroutes ... which are loops! Indeed, show me situations where high Ao isn't a trumping requirement. Single-threaded networks are fragile. And single threaded, multiple hop radio networks are reeeealy fragile. So I tend to get suspicious about vendors telling me about their mesh solutions when they tell me they are using spanning tree. ... rig a test to show what happens with loops. A routed solution, which is what you're implying in your question, is working at layer 3. Here we have a set of protocols that have long tolerated and used alternate routes. The obvious example here is that we're not frame-forwarding, but rather datagram forwarding. And each hop results in a decremented TTL value in the datagram header ... eventually a ringing datagram will timeout and self-extinguish. Help? On Mon, 2007-05-21 at 10:26 +0100, Tan, Chiang Kang wrote: > Hi Nagarajan, > I don't suppose there's any reason why these protocols can be not > be for wireless > mesh networks, if you find them suitable for your use... > > cheers > Chiang > -----Original Message----- > From: nagarajan [mailto:b.nagarajan@gdatech.co.in] > Sent: 21 May 2007 10:20 > To: manet > Subject: [manet] Routing protocols for Wireless Mesh Networks > > > Hi all, > > Can the following protocols > > * Ad-hoc On Demand Distance Vector Routing protocol - > AODV > * Optimized Link State Routing protocol - OLSR > be used for Wireless Mesh Networks?? > > Thanks and Regards, > Nagarajan > > **************************************************************************** *** > > This email and any files transmitted with it are intended solely for > the use of > > the individual or entity to whom they are addressed and may not be > divulged to > > any third party without the express permission of the originator. Any > views > > expressed in this message are those of the individual sender, except > where the > > sender specifically states them to be the views of Thales Research & > Technology > > (UK) Limited. > > **************************************************************************** *** > > > > _______________________________________________ > manet mailing 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 May 22 09:36: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 1HqUXZ-0005QU-N0; Tue, 22 May 2007 09:36:41 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HqUXX-0005Mc-HX for manet-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 09:36:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqUXX-0005MU-7s for manet@ietf.org; Tue, 22 May 2007 09:36:39 -0400 Received: from 67-129-173-13.dia.static.qwest.net ([67.129.173.13] helo=alfalfa.fortresstech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqUXW-0006tX-Pq for manet@ietf.org; Tue, 22 May 2007 09:36:39 -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] Routing protocols for Wireless Mesh Networks Date: Tue, 22 May 2007 09:36:37 -0400 Message-ID: <60C9D8B49C2C71459874A1F4F5DEE80702950E6A@alfalfa.fortresstech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Routing protocols for Wireless Mesh Networks Thread-Index: Aceb1z73EKRcQsikQWqkWGHieL83CwADVJMgACP7uSA= References: <51BF576D5A02CC4CB2591F50994FD76601D3AB37@nts013.uk.trt.thales><1179772588.3106.49.camel@localhost.localdomain> <002d01c79be8$68a7e4e0$6401a8c0@HerbRubens> From: "Kenneth Peirce" To: "manet" X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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 FWIW - I know of a large bubble-era metropolitan-scale wireless mesh(fixed) network which attempted to use STP. They tried all sorts of variations on it, and it's performance was never really very good. At first glance STP looks to be a natural fit for a wireless mesh, but the reality of wireless link behavior is "non-synergystic".:) Ken Peirce -----Original Message----- From: Herbert Rubens [mailto:hrubens@persistentsystems.com]=20 Sent: Monday, May 21, 2007 4:41 PM To: 'Rex Buddenberg'; 'Tan, Chiang Kang' Cc: 'manet' Subject: RE: [manet] Routing protocols for Wireless Mesh Networks Rex, It sounds like what you are looking for is a layer 2 routing protocol which is instantaneously loop free. Most link-state protocols do not have this property and are only loop free in their converged steady state (this is true at regardless of whether they operate at layer 2 or layer 3). However, it is possible to design protocols which have this property. The most obvious example of such a protocol would be DSR, since it uses source routing. It wouldn't make sense in the context of DSR to source route a packet into a loop. There are definitely other protocols which provide instantaneous loop freedom; DSR was just the most obvious example. Like you mentioned, the Spanning Tree Protocol can turn a graph into a tree to 'try' and prevent routing loops. The problem is that packets which are routed to destinations which are not the root of the tree probably could have found a better route in the graph as opposed to the tree. If you consider 3 wired switches connected in a loop, the spanning tree protocol will remove one of the links to form a tree. This means that two of the switches can't communicate across their direct wired connection and are forced to hop through the intermediate switch. On a wired network this may or may not be the end of the world, but in a wireless network two hops instead of one 'could' result in losing half (or more) of your bandwidth (depending on the link speeds). In general, running the 'standard' spanning tree protocol to create a mesh is a very bad idea. -Herb -------------------------- Herbert Rubens Persistent Systems, LLC www.PersistentSystems.com -----Original Message----- From: Rex Buddenberg [mailto:budden@nps.navy.mil] Sent: Monday, May 21, 2007 2:36 PM To: Tan, Chiang Kang Cc: manet Subject: RE: [manet] Routing protocols for Wireless Mesh Networks Nagarajan, 'mesh' is a somewhat abused term in this business. But in general, it connotes a layer 2 solution to problems like need to handoff from one base station to another and need to daisy-chain multiple nodes together (usually thought of as a hermaphrodite rig where a node is BS in one segment and SS in another). =20 Most of the mesh solutions we've seen, being at layer 2, are technology-dependent. And the problem with layer 2 solutions appears to be in loop behavior. Loops in LAN protocols result when bridges are connected in such a way that bridge forwarding returns a frame back to it's origin. At layer 2, a loop can result in frames 'ringing' around the network forever. Obviously not a Good Thing. So within layer 2, IEEE 802.1 worked up a spanning tree protocol. It deals with loops by detecting them and inserting logical breaks in the forwarding chain. Turning a graph back into a tree. The problem is that in a lot of situations where we want 'mesh' solutions, we have some very pressing high availability engineering requirements. We also want to introduce lots of alternate routes to account for those that fail at any point in time. In other words, for Ao reasons we want altroutes ... which are loops! =20 Indeed, show me situations where high Ao isn't a trumping requirement. Single-threaded networks are fragile. And single threaded, multiple hop radio networks are reeeealy fragile. =20 =09 So I tend to get suspicious about vendors telling me about their mesh solutions when they tell me they are using spanning tree. ... rig a test to show what happens with loops. A routed solution, which is what you're implying in your question, is working at layer 3. Here we have a set of protocols that have long tolerated and used alternate routes. The obvious example here is that we're not frame-forwarding, but rather datagram forwarding. And each hop results in a decremented TTL value in the datagram header ... eventually a ringing datagram will timeout and self-extinguish. =20 Help? On Mon, 2007-05-21 at 10:26 +0100, Tan, Chiang Kang wrote: > Hi Nagarajan, > I don't suppose there's any reason why these protocols can be not=20 > be for wireless mesh networks, if you find them suitable for your=20 > use... > =20 > cheers > Chiang > -----Original Message----- > From: nagarajan [mailto:b.nagarajan@gdatech.co.in] > Sent: 21 May 2007 10:20 > To: manet > Subject: [manet] Routing protocols for Wireless Mesh Networks > =20 > =20 > Hi all, > =20 > Can the following protocols > =20 > * Ad-hoc On Demand Distance Vector Routing protocol - > AODV > * Optimized Link State Routing protocol - OLSR=20 > be used for Wireless Mesh Networks?? > =20 > Thanks and Regards, > Nagarajan >=20 > ************************************************************************ **** *** >=20 > This email and any files transmitted with it are intended solely for=20 > the use of >=20 > the individual or entity to whom they are addressed and may not be=20 > divulged to >=20 > any third party without the express permission of the originator. Any=20 > views >=20 > expressed in this message are those of the individual sender, except=20 > where the >=20 > sender specifically states them to be the views of Thales Research &=20 > Technology >=20 > (UK) Limited. >=20 > ************************************************************************ **** *** >=20 > =20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing 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 May 22 15:24: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 1HqZyC-0003j2-Fq; Tue, 22 May 2007 15:24:33 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HqZy7-0003ij-TI for manet-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 15:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqZy6-0003iW-Ko; Tue, 22 May 2007 15:24:27 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqZy5-0001Vr-1F; Tue, 22 May 2007 15:24:26 -0400 Received: from [192.168.0.3] (AVelizy-152-1-6-47.w82-120.abo.wanadoo.fr [82.120.5.47]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4MJOKw6023982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 May 2007 21:24:21 +0200 Message-ID: <46534361.4020703@inria.fr> Date: Tue, 22 May 2007 21:24:17 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] DYMO RREQ flooding and super-flooding References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> <464B013A.6070601@inria.fr> <374005f30705160636p69ae55e8ya6ab9bbcf499c04a@mail.gmail.com> In-Reply-To: <374005f30705160636p69ae55e8ya6ab9bbcf499c04a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at discorde with ID 46534364.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 l4MJOKw6023982 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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 I see, I confused with MsgHdr.Hopcount, sorry. Maybe this could be=20 specifed as a remark in the draft. I am not sure that the method specified in the draft will avoid a=20 quadratic flooding. In particular when slow interfaces have longer hauls=20 than fast interfaces. Consider a chain of n nodes, each having two interfaces a fast one=20 covering one hop, and a slow one covering two hops. The route with n-1=20 hops will come first, then the n-2 hops, then the n-3, and finally n/2=20 hops. This would give O(n) RREQ relayed per node. In fact the quadratic bound could explode if the metric has no=20 constraint on discrepancy. In this case it could become exponential or=20 even factorial in worst case. Why not an upper limit on the number of per RREQ per node relaying as a=20 safeguard to flooding explosion? Even if it has the cost that optimal=20 route may not be attainable that way. Philippe Ian Chakeres a =E9crit : > The MsgHdr.HopCount is not used in reference to routing information in > DYMO. Node.HopCount (in an address block TLV) is optional. >=20 > I have not read about super-flooding, but DYMO's method for > determining the quality of routing information should be sufficient to > avoid excess flooding. >=20 > Ian >=20 > On 5/16/07, Philippe Jacquet wrote: >> I didn't know that you could disable hop counter, I thought >> MsgHdr.HopCnt was mandatory in RREQ message. >> >> In case you use super-flooding, should you put a limit in the number o= f >> retransmissions per node in order to avoid a flooding explosion? >> >> Philippe >> >> >> >> Ian Chakeres a =E9crit : >> > If you don't include hop count information, it will not be used in t= he >> > decision making. >> > >> > If you were interested in using "fasted RREQ" path, you would not >> > include the hop count information. >> > >> > Ian >> > >> > On 5/16/07, Philippe Jacquet wrote: >> >> Ian, I don't understand how the method you described in your paper = for >> >> AODV can be applied for DYMO. >> >> >> >> Assume you delay the RREQ retransmission on the two-hop route becau= se >> >> the routers have low willingness, so that it is transmitted after t= he >> >> three hops route. Anyhow the two-hop RREQ will be relayed since it=20 >> has a >> >> smaller hop-count and the shortest route will be in fact selected.=20 >> Or am >> >> I wrong? >> >> >> >> Philippe >> >> >> >> Ian Chakeres a =E9crit : >> >> > I had done some work on using different metrics by introducing de= lay >> >> > during route discovery to influence route selection. >> >> > >> >> > Here is the paper info: >> >> > >> >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent=20 >> Influence >> >> > of Path Selection in Heterogeneous Ad hoc Networks." Proceedings = of >> >> > the 15th IEEE International Symposium on Personal, Indoor and Mob= ile >> >> > Radio Communications (PIMRC), Barcelona, Spain, September 2004. >> >> > >> >> > For the base spec we are not including any complex metrics, but >> >> > instead rely on DV & hopcount (if included) or other techniques t= hat >> >> > work under these assumptions (like the paper above). >> >> > >> >> > I think some additional TLVs and new functionality to enable DYMO= to >> >> > support more complex metrics would be interesting. >> >> > >> >> > Ian >> >> > >> >> > On 5/15/07, Philippe Jacquet wrote: >> >> >> Hello, folks, >> >> >> >> >> >> I see in DYMO spec (5.3.4) that a RREQ message can be retransmit= ted >> >> >> several times by a node if it receives copies on shorter routes. >> >> >> >> >> >> This reminds me the paper we did about this kind of super-floodi= ng. >> >> >> >> >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc Network= s >> >> >> T. Clausen, P. Jacquet et L. Viennot >> >> >> Med-hoc-Net, 2002 >> >> >> >> >> >> >> >> >> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps= .gz >> >> >> >> >> >> It gives the shortest path to OrigNode in hop count, but the=20 >> number of >> >> >> retransmissions may be important and exceed the network size=20 >> (can be >> >> >> quadratic in the network size per RREQ). >> >> >> >> >> >> I wonder if one could also add other metrics than simply hop cou= nt. >> >> For >> >> >> example RREQ could seek the path with average shortest delay by=20 >> adding >> >> >> the last hop average link delay to the current weight carried by= =20 >> the >> >> >> RREQ. The RREQ would carry a bit indicating that average shortes= t >> >> delay >> >> >> is activated). Or the RREQ could look to the largest bandwidth >> >> route (in >> >> >> this case one take the minimum of the last hop bandwidth with th= e >> >> weight >> >> >> carried by the RREQ. >> >> >> >> >> >> Other metrics are possible (variance, etc). >> >> >> >> >> >> 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 >> >> > >> >> > >> >> >> > >> > >> >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue May 22 15:28:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqa2E-0007pQ-2j; Tue, 22 May 2007 15:28:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hqa2A-0007fg-NY for manet-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 15:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqa29-0007Zz-6j for manet@ietf.org; Tue, 22 May 2007 15:28:37 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqa28-0004p3-0K for manet@ietf.org; Tue, 22 May 2007 15:28:37 -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 l4MJSXWu018641 for ; Tue, 22 May 2007 15:28:33 -0400 (EDT) Received: (from SEXTANT [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007052215283324975 for ; Tue, 22 May 2007 15:28:33 -0400 From: "Joe Macker" To: "'manet'" Date: Tue, 22 May 2007 15:28:30 -0400 Message-ID: <019401c79ca7$61491740$165cfa84@SEXTANT> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceXg4w5qxhoBNubQC++JTI+DpJ+tAABbFggAUd9qlA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [manet] FW: MIB template tester 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 Some manet authors may be interested in looking at David's template. -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Wednesday, May 16, 2007 3:13 AM To: Working Group Chairs Cc: David Harrington Subject: FW: MIB template tester David Harrington is working on behalf of the OPS Area on a MIB document template which would help authors of MIB documents to design faster and better documents. If there are any authors in your WGs in initial phases of a new MIB document, please contact David. Thanks and Regards, Dan -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net] Sent: Wednesday, May 16, 2007 9:33 AM To: Romascanu, Dan (Dan) Subject: MIB template tester Hi Dan, Do you know of any WG that is about to start work on a MIB module? I would like to have them test my updated MIB document template. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue May 22 22:36: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 1HqgiV-0006bi-80; Tue, 22 May 2007 22:36:47 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HqgiS-0006ba-Qt for manet-confirm+ok@megatron.ietf.org; Tue, 22 May 2007 22:36:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqgiS-0006bS-E6; Tue, 22 May 2007 22:36:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqgiQ-0000uh-Qk; Tue, 22 May 2007 22:36:44 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 May 2007 04:36:43 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4N2agsK027782; Wed, 23 May 2007 04:36:42 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4N2agDR017577; Wed, 23 May 2007 02:36:42 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 04:36:41 +0200 Received: from [10.43.1.84] ([10.58.48.2]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 04:36:39 +0200 Mime-Version: 1.0 (Apple Message framework v752.2) To: 6lowpan@ietf.org, manet@ietf.org Message-Id: References: From: JP Vasseur Date: Wed, 23 May 2007 04:36:29 +0200 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 23 May 2007 02:36:39.0721 (UTC) FILETIME=[31041990:01C79CE3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=21164; t=1179887802; x=1180751802; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20Next=20step=20for=20RSN=20? |Sender:=20; bh=nszXfkFYBn+gYSCcipPEMd4OOeaEbgDmphSRiJzgT/8=; b=mhSbiuH+8ugURn4Y4+AOlq8nbh8fNHwfrp2ZGJfvXyxxo3nhV/Z12ZBRc24df9pZ1+eLsaaC fmRpiBHGqm8q/uwV0JcoC1ittF9k4uApEfsnJdIlFXIvhar9XwJZuwqD; Authentication-Results: ams-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.3 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: Subject: [manet] Fwd: Next step for RSN ? 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="===============1214464516==" Errors-To: manet-bounces@ietf.org --===============1214464516== Content-Type: multipart/alternative; boundary=Apple-Mail-166--282872936 --Apple-Mail-166--282872936 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed FYI - Feel free to register to RSN and provide feed-back if of interest. Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: May 23, 2007 4:33:31 AM GMT+02:00 > To: rsn@ietf.org > Cc: David Culler > Subject: Next step for RSN ? > > Dear List members, > > Looking at the number of people who registered to this list, there > seems to be a strong interest in designing a Routing solution for > Sensor Networks. David and I had during the last few months a > number of off-line discussions with positive feed-back and support, > it is now a good time to use the Mailing List to gauge whether > there is a consensus on whether to work on this topic. > > David provided an excellent problem statement below. I'd like to > add a few comments and get feed-back from the ML members on whether > we collectively want to work on this item. > > With no doubt, we'll see many other radio networks emerging soon > and sensor networks will soon be made links using various layer1/2 > protocols defined by other SDOs: 802.15.4, Wifi, WiMax but also non > wireless links. Such networks will also comprise sensor nodes with > a wide range of capabilities, which makes the routing fairly unique > in term of requirement. Thus the proposal is to design a IP routing > solution specifically for sensor networks, that would of course be > independent to the L1/L2 protocol in use (it may be desirable to > take into account link layer attributes when calculating a route > but the routing process would not be tied up with the link layer). > > It looks fairly obvious that a network made of N "mesh-under" > routing protocols is very unlikely to satisfy an end to end path > constraint and would be fairly complex to manage and tune. We all > remember the issue of IP routing over ATM PVCs routed by PNNI. > Think of this with N "Mesh-under" routing protocols. That said, > this is not to say that we exclude the use of "mesh-under" > solutions, but we propose to define a IP-based routing protocol. > > What would be a charter proposal ? > > First we would need to spend a good amount of time on the routing > requirements. David and I posted a first revision of a generic > requirement draft (draft-culler-rsn-routing-reqs-00.txt); the next > revision will soon be posted accounting for the comments received > so far. I would propose to continue to list the generic > requirements in this draft and have other application-specific > routing requirements drafts discussed in other IDs: for home > networking, industrial applications, ... Such approach has been > successfully adopted in other WGs. > > The second step would consist of making a survey on the existing > routing protocols and see whether (1) they could be used as such > (2) they should be adapted (for instance, see whether AODV or OLR > or RIP could be made energy efficient, could support some form of > constrained based routing, ...) or (3) we should design a new > generic new protocol. > > Note that we may not be able to satisfy all the requirements, and > this might be perfectly acceptable and should be documented. > Indeed, we all know that Sensor Networks may significantly differ > in term of degree of mobility, link layer reliability/bandwidth, > node constraints, ... A very good outcome of this work might be > that the newly defined/adapted protocol could satisfy the > requirement IDs A, B, D and E but not C. > > So please use this list to provide feed-back on whether you would > support such initiative and if so your contribution is more than > welcome. Note that several people already mentioned some interest > and we do expect to see new IDs posted before Chicago. > > JP and David. > > Begin forwarded message: > >> From: "dculler" >> Date: May 23, 2007 1:24:58 AM GMT+02:00 >> To: >> Subject: [RSN] Interest in the Interplay of "routing" and "meshing" >> Reply-To: dculler@archrock.com >> >> Several of the comments on this list have touched on the issue of >> different kinds of "multihop routing" in the context of sensor >> networks. Is there interest in working on how these forms of >> routing tie together? >> >> To make the question more grounded: Low power radios have >> relatively short range. IEEE 802.15.4 radios are typically 1 mW >> transmit power, vs 100 mW for 802.11, and have typical ranges in >> 10s to 100 m. Generally speaking, the power required to >> communicate a given distance by radio grows polynomially with >> distance. In typical settings it grows like the cube, but it can >> be much worse near the ground or somewhat better with directional >> antennas. The cost to communicate hop-by-hop grows only linearly, >> and it offers the potential to route around obstacles and enhance >> reliability through "receiver diversity". >> >> The question is at what layer(s) in the stack this routing occurs >> and how it relates to IP routing more generally. Most multihop >> protocols in the sensor network research community are effectively >> at layer2 - they form a single "patch" of homogeneous media. >> Logically, they are a subnet, although few of the protocols >> address what happens beyond the "patch" of sensor nodes, other >> than that some of the nodes are "gateways". Current industry >> standards, such as Zigbee, Zwave, and wirelessHART, are also a >> "multihop link", leaving open the question of how nodes within the >> sensor patch communicate with nodes outside. >> >> 6LoWPAN provides a compressed header format for "mesh routing", >> meaning multihop forwarding of packets within the 802.15.4 link. >> Such a link is assumed to be formed by a contiguously connected >> set of 802.15.4 nodes. The presence of such "mesh routing" >> capabilities does not eliminate the need for layer 3 routing. If >> a 15.4 node communicates with a remote node, say an 802.11 node, >> how is routing and forwarding carried out? If two "LoWPAN >> subnets" [sic] happen to be connected by 15.4 nodes, how does 15.4- >> to-15.4 routing occur? The 6LoWPAN header format is, of course, a >> general solution for carrying IP over 802.15.4, so it is able to >> express these other forms of routing, as well. In the extreme >> case, each individual node is an IP link and all routing is done >> at the IP layer. On the other hand, patches of nodes may want to >> function as a logical subnet, even if the wireless multihop >> routing is done at the IP layer. At this point, the concerns >> overlap with those addressed in autoconf (cf., draft-ietf-autoconf- >> manetarch-01). >> >> There is substantial commonality of concerns at the different >> layers of multihop routing, but also differences. It is also >> important to separate the process of forming a routing topology >> from the process of forwarding packets. Both of which are >> distinct (but not entirely independent of) how power management >> (turning on/off the radios) is performed. >> >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn > --Apple-Mail-166--282872936 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 FYI - Feel free to register to = RSN and provide feed-back if of interest.

Thanks.

JP.

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = May 23, 2007 4:33:31 AM GMT+02:00
Cc: David = Culler <dculler@archrock.com>
Subject: Next step for RSN = ?

= Dear List members,

Looking at the number of = people who registered to this list, there seems to be a strong interest = in designing a Routing solution for Sensor Networks. David and I had = during the last few months a number of off-line discussions with = positive feed-back and support, it is now a good time to use the Mailing = List to gauge whether there is a consensus on whether to work on this = topic.

David = provided an excellent problem statement below. I'd like to add a few = comments and get feed-back from the ML members on whether we = collectively want to work on this item.

With no doubt, we'll see many other radio = networks emerging soon and sensor networks will soon be made links using = various layer1/2 protocols defined by other SDOs: 802.15.4, Wifi, WiMax = but also non wireless links. Such networks will also comprise = sensor nodes with a wide range of capabilities, which makes the = routing fairly unique in term of requirement. Thus the proposal is = to design a IP routing solution specifically for sensor networks, that = would of course be independent to the L1/L2 protocol in use (it may be = desirable to take into account link layer attributes when calculating a = route but the routing process would not be tied up with the link = layer).=A0

It looks fairly obvious that a network made = of N "mesh-under" routing protocols is very unlikely to satisfy an end = to end path constraint and would be fairly complex to manage and tune. = We all remember the issue of IP routing over ATM PVCs routed by PNNI. = Think of this with N "Mesh-under" routing protocols. That said, this is = not to say that we exclude the use of "mesh-under" solutions, but we = propose to define a IP-based routing protocol.=A0

What would be a = charter proposal ?

First we would need to = spend a good amount of time on the routing requirements. David and I = posted a first revision of a generic requirement draft = (draft-culler-rsn-routing-reqs-00.txt); the next revision will soon be = posted accounting for the comments received so far. I would propose to = continue to list the generic requirements in this draft and have other = application-specific routing requirements drafts discussed in other IDs: = for home networking, industrial applications, ... Such approach has been = successfully adopted in other WGs.

The second step would = consist of making a survey on the existing routing protocols and see = whether (1) they could be used as such (2) they should be adapted (for = instance, see whether AODV or OLR or RIP could be made energy efficient, = could support some form of constrained based routing, ...) or (3) we = should design a new generic new protocol.=A0

Note that we may not be = able to satisfy all the requirements, and this might be perfectly = acceptable and should be documented. Indeed, we all know that Sensor = Networks may significantly differ in term of degree of mobility, link = layer reliability/bandwidth, node constraints, ... A very good outcome = of this work might be that the newly defined/adapted protocol could = satisfy the requirement IDs A, B, D and E but not C.=A0

So please use this list to = provide feed-back on whether you would support such initiative and if so = your contribution is more than welcome. Note that several people already = mentioned some interest and we do expect to see new IDs posted before = Chicago.

JP and = David.

Begin forwarded message:

From: = "dculler" <dculler@archrock.com>
Date: May 23, 2007 1:24:58 AM = GMT+02:00
Subject: = [RSN] Interest in the Interplay of "routing" and = "meshing"
=

Several of = the comments on this list have touched on the=A0issue of different kinds = of "multihop routing" in the context of sensor networks.=A0 Is there = interest in working on how these=A0forms of routing=A0tie = together?
=A0
To make the = question more grounded:=A0 Low power radios have relatively short = range.=A0 IEEE 802.15.4 radios are typically 1 mW transmit power, vs 100 = mW for 802.11, and have typical ranges in 10s to 100 m.=A0 Generally = speaking, the power required to communicate a given distance by radio = grows polynomially with distance.=A0 In typical settings it grows like = the cube, but it can be much worse near the ground or somewhat better = with directional antennas.=A0=A0The cost to communicate=A0hop-by-hop = grows only linearly, and it offers the potential to route around = obstacles and enhance reliability through "receiver diversity".=A0 =
=A0
The = question is at what layer(s) in the stack this routing occurs and how it = relates to IP routing more generally.=A0 Most multihop protocols in the = sensor network research community are effectively at layer2 - they form = a single "patch" of homogeneous media.=A0 Logically, they are a subnet, = although few of the protocols address what happens beyond the "patch" of = sensor nodes, other than that some of the nodes are "gateways".=A0 = Current industry standards,=A0such as=A0Zigbee, Zwave, and wirelessHART, = are also a "multihop link", leaving open the question of how nodes = within the sensor patch communicate with nodes = outside.
=A0
6LoWPAN = provides a compressed header format for "mesh routing", meaning multihop = forwarding of packets within the 802.15.4 link.=A0 Such a link is = assumed to be formed by a contiguously connected set of 802.15.4 nodes.=A0= The presence of such "mesh routing" capabilities does not eliminate the = need for layer 3 routing.=A0 If a 15.4 node communicates with a remote = node, say an 802.11 node, how is routing and forwarding carried out?=A0 = If two "LoWPAN subnets" [sic] happen to be connected by 15.4 nodes, how = does 15.4-to-15.4 routing occur?=A0 The 6LoWPAN header format is, of = course, a general solution for carrying IP over 802.15.4, so it is able = to express these other forms of routing, as well.=A0 In the extreme = case, each individual node is an IP link and all routing is done at the = IP layer.=A0 On the other hand, patches of nodes may want to function as = a logical subnet, even if the wireless multihop routing is done at the = IP layer.=A0 At this point, the concerns overlap with those addressed in = autoconf (cf., draft-ietf-autoconf-manetarch-01).
=
=A0
There is = substantial commonality of concerns at the different layers of multihop = routing, but also differences.=A0 It is also important to separate the = process of forming a routing topology from the process of forwarding = packets.=A0 Both of which are distinct (but not entirely independent of) = how power management (turning on/off the radios) is = performed.
=A0
=A0
RSN mailing list
=


= --Apple-Mail-166--282872936-- --===============1214464516== 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 --===============1214464516==-- From manet-bounces@ietf.org Wed May 23 00:20: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 1HqiKT-0004WM-FA; Wed, 23 May 2007 00:20:05 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HqiKR-0004W7-VC for manet-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 00:20:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqiKR-0004Vv-Il for manet@ietf.org; Wed, 23 May 2007 00:20:03 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqiKM-000350-Gz for manet@ietf.org; Wed, 23 May 2007 00:20:03 -0400 Received: by ug-out-1314.google.com with SMTP id 72so370854ugd for ; Tue, 22 May 2007 21:19: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=Q5B+6nTIfeRJTcPkkLAGGBFqsopFVbN63q9dbYzt8ZCcyLpywT6GxC4jx2Xwiw+24uIWc4olovWJNxKX0k9h7XyMSEu1jjQMqgWKDup12Rkqwia9N9bJOx/q2BwW493cIeMLFxXk/QjyFT6fHgx70Lnx9Iz6diLOn7eSKmeeDzo= 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=onVd18T2LnJV2O1Eoc5JSrwv2uNFDb2DuXP0ab6fBvCSjY4zE/8uPER7fpeJNCIgGnrzIuxHyWicxRkzntuE0e0po7Xxxralu//ZHZlktrfLbM0TuEvkgcIqXLz0XaqEKElTL0utXcczukQFoBpO5cMWNkajSfDuGFLbW/CpSb4= Received: by 10.78.181.13 with SMTP id d13mr23506huf.1179893997573; Tue, 22 May 2007 21:19:57 -0700 (PDT) Received: by 10.78.53.13 with HTTP; Tue, 22 May 2007 21:19:57 -0700 (PDT) Message-ID: <374005f30705222119q2508118ep7ef85cddf635e4f9@mail.gmail.com> Date: Wed, 23 May 2007 09:49:57 +0530 From: "Ian Chakeres" To: "Philippe Jacquet" Subject: Re: [manet] DYMO RREQ flooding and super-flooding In-Reply-To: <46534361.4020703@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> <464B013A.6070601@inria.fr> <374005f30705160636p69ae55e8ya6ab9bbcf499c04a@mail.gmail.com> <46534361.4020703@inria.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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 Sounds like a good idea, I will add a recommendation in the next DYMO revision that devices SHOULD limit the number of RREQ forwarded. Do you have a suggestion for the default limit that should be forwarded? Ian On 5/23/07, Philippe Jacquet wrote: > I see, I confused with MsgHdr.Hopcount, sorry. Maybe this could be > specifed as a remark in the draft. > > I am not sure that the method specified in the draft will avoid a > quadratic flooding. In particular when slow interfaces have longer hauls > than fast interfaces. > > Consider a chain of n nodes, each having two interfaces a fast one > covering one hop, and a slow one covering two hops. The route with n-1 > hops will come first, then the n-2 hops, then the n-3, and finally n/2 > hops. This would give O(n) RREQ relayed per node. > > In fact the quadratic bound could explode if the metric has no > constraint on discrepancy. In this case it could become exponential or > even factorial in worst case. > > Why not an upper limit on the number of per RREQ per node relaying as a > safeguard to flooding explosion? Even if it has the cost that optimal > route may not be attainable that way. > > Philippe > > Ian Chakeres a =E9crit : > > The MsgHdr.HopCount is not used in reference to routing information in > > DYMO. Node.HopCount (in an address block TLV) is optional. > > > > I have not read about super-flooding, but DYMO's method for > > determining the quality of routing information should be sufficient to > > avoid excess flooding. > > > > Ian > > > > On 5/16/07, Philippe Jacquet wrote: > >> I didn't know that you could disable hop counter, I thought > >> MsgHdr.HopCnt was mandatory in RREQ message. > >> > >> In case you use super-flooding, should you put a limit in the number o= f > >> retransmissions per node in order to avoid a flooding explosion? > >> > >> Philippe > >> > >> > >> > >> Ian Chakeres a =E9crit : > >> > If you don't include hop count information, it will not be used in t= he > >> > decision making. > >> > > >> > If you were interested in using "fasted RREQ" path, you would not > >> > include the hop count information. > >> > > >> > Ian > >> > > >> > On 5/16/07, Philippe Jacquet wrote: > >> >> Ian, I don't understand how the method you described in your paper = for > >> >> AODV can be applied for DYMO. > >> >> > >> >> Assume you delay the RREQ retransmission on the two-hop route becau= se > >> >> the routers have low willingness, so that it is transmitted after t= he > >> >> three hops route. Anyhow the two-hop RREQ will be relayed since it > >> has a > >> >> smaller hop-count and the shortest route will be in fact selected. > >> Or am > >> >> I wrong? > >> >> > >> >> Philippe > >> >> > >> >> Ian Chakeres a =E9crit : > >> >> > I had done some work on using different metrics by introducing de= lay > >> >> > during route discovery to influence route selection. > >> >> > > >> >> > Here is the paper info: > >> >> > > >> >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent > >> Influence > >> >> > of Path Selection in Heterogeneous Ad hoc Networks." Proceedings = of > >> >> > the 15th IEEE International Symposium on Personal, Indoor and Mob= ile > >> >> > Radio Communications (PIMRC), Barcelona, Spain, September 2004. > >> >> > > >> >> > For the base spec we are not including any complex metrics, but > >> >> > instead rely on DV & hopcount (if included) or other techniques t= hat > >> >> > work under these assumptions (like the paper above). > >> >> > > >> >> > I think some additional TLVs and new functionality to enable DYMO= to > >> >> > support more complex metrics would be interesting. > >> >> > > >> >> > Ian > >> >> > > >> >> > On 5/15/07, Philippe Jacquet wrote: > >> >> >> Hello, folks, > >> >> >> > >> >> >> I see in DYMO spec (5.3.4) that a RREQ message can be retransmit= ted > >> >> >> several times by a node if it receives copies on shorter routes. > >> >> >> > >> >> >> This reminds me the paper we did about this kind of super-floodi= ng. > >> >> >> > >> >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc Network= s > >> >> >> T. Clausen, P. Jacquet et L. Viennot > >> >> >> Med-hoc-Net, 2002 > >> >> >> > >> >> >> > >> >> >> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps= .gz > >> >> >> > >> >> >> It gives the shortest path to OrigNode in hop count, but the > >> number of > >> >> >> retransmissions may be important and exceed the network size > >> (can be > >> >> >> quadratic in the network size per RREQ). > >> >> >> > >> >> >> I wonder if one could also add other metrics than simply hop cou= nt. > >> >> For > >> >> >> example RREQ could seek the path with average shortest delay by > >> adding > >> >> >> the last hop average link delay to the current weight carried by > >> the > >> >> >> RREQ. The RREQ would carry a bit indicating that average shortes= t > >> >> delay > >> >> >> is activated). Or the RREQ could look to the largest bandwidth > >> >> route (in > >> >> >> this case one take the minimum of the last hop bandwidth with th= e > >> >> weight > >> >> >> carried by the RREQ. > >> >> >> > >> >> >> Other metrics are possible (variance, etc). > >> >> >> > >> >> >> 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 > >> >> > > >> >> > > >> >> > >> > > >> > > >> > > > > > > _______________________________________________ > > manet mailing 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 May 23 12:14: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 1HqtSr-0005cQ-Kr; Wed, 23 May 2007 12:13:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HqtSq-0005Zb-3S for manet-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 12:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqtSp-0005ZS-Kl; Wed, 23 May 2007 12:13:27 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqtSo-0004k6-W5; Wed, 23 May 2007 12:13:27 -0400 Received: from [128.93.62.246] (dhcp-rocq-246.inria.fr [128.93.62.246]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4NGDPsF008915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 May 2007 18:13:25 +0200 Message-ID: <46546824.9040905@inria.fr> Date: Wed, 23 May 2007 18:13:24 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] DYMO RREQ flooding and super-flooding References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> <464B013A.6070601@inria.fr> <374005f30705160636p69ae55e8ya6ab9bbcf499c04a@mail.gmail.com> <46534361.4020703@inria.fr> <374005f30705222119q2508118ep7ef85cddf635e4f9@mail.gmail.com> In-Reply-To: <374005f30705222119q2508118ep7ef85cddf635e4f9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at discorde with ID 46546825.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 l4NGDPsF008915 X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 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 Hard to see a default number value. To my opinion it should be included=20 in RREQ message and hinted that it should depend on traffic conditions.=20 A short relay number will imply a light flooding but sub-optimal routes.=20 This would be better suited for short lived path or connection. For long=20 lived connection where route sub-optimality may be more costly than a=20 heavy super-flooding, a larger relay number may be more suitable. In general I would be careful when introducing additional default=20 parameters in DYMO since the latter is strongly based on network=20 dynamic. A bad default protocol timing may have great negative impacts. Philippe Ian Chakeres a =E9crit : > Sounds like a good idea, I will add a recommendation in the next DYMO > revision that devices SHOULD limit the number of RREQ forwarded. >=20 > Do you have a suggestion for the default limit that should be forwarded= ? >=20 > Ian >=20 > On 5/23/07, Philippe Jacquet wrote: >> I see, I confused with MsgHdr.Hopcount, sorry. Maybe this could be >> specifed as a remark in the draft. >> >> I am not sure that the method specified in the draft will avoid a >> quadratic flooding. In particular when slow interfaces have longer hau= ls >> than fast interfaces. >> >> Consider a chain of n nodes, each having two interfaces a fast one >> covering one hop, and a slow one covering two hops. The route with n-1 >> hops will come first, then the n-2 hops, then the n-3, and finally n/2 >> hops. This would give O(n) RREQ relayed per node. >> >> In fact the quadratic bound could explode if the metric has no >> constraint on discrepancy. In this case it could become exponential or >> even factorial in worst case. >> >> Why not an upper limit on the number of per RREQ per node relaying as = a >> safeguard to flooding explosion? Even if it has the cost that optimal >> route may not be attainable that way. >> >> Philippe >> >> Ian Chakeres a =E9crit : >> > The MsgHdr.HopCount is not used in reference to routing information = in >> > DYMO. Node.HopCount (in an address block TLV) is optional. >> > >> > I have not read about super-flooding, but DYMO's method for >> > determining the quality of routing information should be sufficient = to >> > avoid excess flooding. >> > >> > Ian >> > >> > On 5/16/07, Philippe Jacquet wrote: >> >> I didn't know that you could disable hop counter, I thought >> >> MsgHdr.HopCnt was mandatory in RREQ message. >> >> >> >> In case you use super-flooding, should you put a limit in the=20 >> number of >> >> retransmissions per node in order to avoid a flooding explosion? >> >> >> >> Philippe >> >> >> >> >> >> >> >> Ian Chakeres a =E9crit : >> >> > If you don't include hop count information, it will not be used=20 >> in the >> >> > decision making. >> >> > >> >> > If you were interested in using "fasted RREQ" path, you would not >> >> > include the hop count information. >> >> > >> >> > Ian >> >> > >> >> > On 5/16/07, Philippe Jacquet wrote: >> >> >> Ian, I don't understand how the method you described in your=20 >> paper for >> >> >> AODV can be applied for DYMO. >> >> >> >> >> >> Assume you delay the RREQ retransmission on the two-hop route=20 >> because >> >> >> the routers have low willingness, so that it is transmitted=20 >> after the >> >> >> three hops route. Anyhow the two-hop RREQ will be relayed since = it >> >> has a >> >> >> smaller hop-count and the shortest route will be in fact selecte= d. >> >> Or am >> >> >> I wrong? >> >> >> >> >> >> Philippe >> >> >> >> >> >> Ian Chakeres a =E9crit : >> >> >> > I had done some work on using different metrics by introducing= =20 >> delay >> >> >> > during route discovery to influence route selection. >> >> >> > >> >> >> > Here is the paper info: >> >> >> > >> >> >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent >> >> Influence >> >> >> > of Path Selection in Heterogeneous Ad hoc Networks."=20 >> Proceedings of >> >> >> > the 15th IEEE International Symposium on Personal, Indoor and=20 >> Mobile >> >> >> > Radio Communications (PIMRC), Barcelona, Spain, September 2004. >> >> >> > >> >> >> > For the base spec we are not including any complex metrics, bu= t >> >> >> > instead rely on DV & hopcount (if included) or other=20 >> techniques that >> >> >> > work under these assumptions (like the paper above). >> >> >> > >> >> >> > I think some additional TLVs and new functionality to enable=20 >> DYMO to >> >> >> > support more complex metrics would be interesting. >> >> >> > >> >> >> > Ian >> >> >> > >> >> >> > On 5/15/07, Philippe Jacquet wrote= : >> >> >> >> Hello, folks, >> >> >> >> >> >> >> >> I see in DYMO spec (5.3.4) that a RREQ message can be=20 >> retransmitted >> >> >> >> several times by a node if it receives copies on shorter rout= es. >> >> >> >> >> >> >> >> This reminds me the paper we did about this kind of=20 >> super-flooding. >> >> >> >> >> >> >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc=20 >> Networks >> >> >> >> T. Clausen, P. Jacquet et L. Viennot >> >> >> >> Med-hoc-Net, 2002 >> >> >> >> >> >> >> >> >> >> >> >>=20 >> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz >> >> >> >> >> >> >> >> It gives the shortest path to OrigNode in hop count, but the >> >> number of >> >> >> >> retransmissions may be important and exceed the network size >> >> (can be >> >> >> >> quadratic in the network size per RREQ). >> >> >> >> >> >> >> >> I wonder if one could also add other metrics than simply hop=20 >> count. >> >> >> For >> >> >> >> example RREQ could seek the path with average shortest delay = by >> >> adding >> >> >> >> the last hop average link delay to the current weight carried= by >> >> the >> >> >> >> RREQ. The RREQ would carry a bit indicating that average=20 >> shortest >> >> >> delay >> >> >> >> is activated). Or the RREQ could look to the largest bandwidt= h >> >> >> route (in >> >> >> >> this case one take the minimum of the last hop bandwidth with= =20 >> the >> >> >> weight >> >> >> >> carried by the RREQ. >> >> >> >> >> >> >> >> Other metrics are possible (variance, etc). >> >> >> >> >> >> >> >> 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 >> >> >> > >> >> >> > >> >> >> >> >> > >> >> > >> >> >> > >> > >> > _______________________________________________ >> > manet mailing list >> > manet@ietf.org >> > https://www1.ietf.org/mailman/listinfo/manet >> > >> > >> >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 23 16:07: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 1Hqx7L-0005r1-JP; Wed, 23 May 2007 16:07:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hqx7K-0005nj-Dz for manet-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 16:07:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqx7J-0005nJ-Uv; Wed, 23 May 2007 16:07:29 -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 1Hqx7H-0005a0-CE; Wed, 23 May 2007 16:07:29 -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 l4NK7K6b025833; Wed, 23 May 2007 23:07:24 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 23:07:22 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 15:07:08 -0500 Received: from [172.18.141.172] ([172.18.141.172]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 15:07:07 -0500 Message-ID: <46549EE5.7070509@nokia.com> Date: Wed, 23 May 2007 13:07:01 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Philippe Jacquet Subject: Re: [Manet-dt] Re: [manet] DYMO RREQ flooding and super-flooding References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> <464B013A.6070601@inria.fr> <374005f30705160636p69ae55e8ya6ab9bbcf499c04a@mail.gmail.com> <46534361.4020703@inria.fr> <374005f30705222119q2508118ep7ef85cddf635e4f9@mail.gmail.com> <46546824.9040905@inria.fr> In-Reply-To: <46546824.9040905@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 23 May 2007 20:07:07.0726 (UTC) FILETIME=[F0A26EE0:01C79D75] X-Nokia-AV: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext13.nokia.com id l4NK7K6b025833 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e 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 Hello Philippe, I have been following along, and have a minor comment about the proposal. In general, I think it is appropriate to maintain default values but to enable modifications based on measurements of current relevant traffic and network conditions. Having a default value saves a great deal of repetition, and so saves a great deal of wasted transmission capacity. The lesson we have been learning in our measurements is that more bytes over the air equals more congestion and always there must be justification for the potentially degraded performance. What would you say about having a default value and a newly defined extension to change it when needed? What happens when variable congestion conditions in different parts of the network suggest different values for the number of RREQs that should be retransmitted? I don't automatically see a problem there, but it could be a tricky point. Regards, Charlie P. ext Philippe Jacquet wrote: > Hard to see a default number value. To my opinion it should be=20 > included in RREQ message and hinted that it should depend on traffic=20 > conditions. A short relay number will imply a light flooding but=20 > sub-optimal routes. This would be better suited for short lived path=20 > or connection. For long lived connection where route sub-optimality=20 > may be more costly than a heavy super-flooding, a larger relay number=20 > may be more suitable. > > In general I would be careful when introducing additional default=20 > parameters in DYMO since the latter is strongly based on network=20 > dynamic. A bad default protocol timing may have great negative impacts. > > Philippe > > > > Ian Chakeres a =E9crit : >> Sounds like a good idea, I will add a recommendation in the next DYMO >> revision that devices SHOULD limit the number of RREQ forwarded. >> >> Do you have a suggestion for the default limit that should be forwarde= d? >> >> Ian >> >> On 5/23/07, Philippe Jacquet wrote: >>> I see, I confused with MsgHdr.Hopcount, sorry. Maybe this could be >>> specifed as a remark in the draft. >>> >>> I am not sure that the method specified in the draft will avoid a >>> quadratic flooding. In particular when slow interfaces have longer=20 >>> hauls >>> than fast interfaces. >>> >>> Consider a chain of n nodes, each having two interfaces a fast one >>> covering one hop, and a slow one covering two hops. The route with n-= 1 >>> hops will come first, then the n-2 hops, then the n-3, and finally n/= 2 >>> hops. This would give O(n) RREQ relayed per node. >>> >>> In fact the quadratic bound could explode if the metric has no >>> constraint on discrepancy. In this case it could become exponential o= r >>> even factorial in worst case. >>> >>> Why not an upper limit on the number of per RREQ per node relaying as= a >>> safeguard to flooding explosion? Even if it has the cost that optimal >>> route may not be attainable that way. >>> >>> Philippe >>> >>> Ian Chakeres a =E9crit : >>> > The MsgHdr.HopCount is not used in reference to routing=20 >>> information in >>> > DYMO. Node.HopCount (in an address block TLV) is optional. >>> > >>> > I have not read about super-flooding, but DYMO's method for >>> > determining the quality of routing information should be=20 >>> sufficient to >>> > avoid excess flooding. >>> > >>> > Ian >>> > >>> > On 5/16/07, Philippe Jacquet wrote: >>> >> I didn't know that you could disable hop counter, I thought >>> >> MsgHdr.HopCnt was mandatory in RREQ message. >>> >> >>> >> In case you use super-flooding, should you put a limit in the=20 >>> number of >>> >> retransmissions per node in order to avoid a flooding explosion? >>> >> >>> >> Philippe >>> >> >>> >> >>> >> >>> >> Ian Chakeres a =E9crit : >>> >> > If you don't include hop count information, it will not be used=20 >>> in the >>> >> > decision making. >>> >> > >>> >> > If you were interested in using "fasted RREQ" path, you would no= t >>> >> > include the hop count information. >>> >> > >>> >> > Ian >>> >> > >>> >> > On 5/16/07, Philippe Jacquet wrote: >>> >> >> Ian, I don't understand how the method you described in your=20 >>> paper for >>> >> >> AODV can be applied for DYMO. >>> >> >> >>> >> >> Assume you delay the RREQ retransmission on the two-hop route=20 >>> because >>> >> >> the routers have low willingness, so that it is transmitted=20 >>> after the >>> >> >> three hops route. Anyhow the two-hop RREQ will be relayed=20 >>> since it >>> >> has a >>> >> >> smaller hop-count and the shortest route will be in fact=20 >>> selected. >>> >> Or am >>> >> >> I wrong? >>> >> >> >>> >> >> Philippe >>> >> >> >>> >> >> Ian Chakeres a =E9crit : >>> >> >> > I had done some work on using different metrics by=20 >>> introducing delay >>> >> >> > during route discovery to influence route selection. >>> >> >> > >>> >> >> > Here is the paper info: >>> >> >> > >>> >> >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent >>> >> Influence >>> >> >> > of Path Selection in Heterogeneous Ad hoc Networks."=20 >>> Proceedings of >>> >> >> > the 15th IEEE International Symposium on Personal, Indoor=20 >>> and Mobile >>> >> >> > Radio Communications (PIMRC), Barcelona, Spain, September 200= 4. >>> >> >> > >>> >> >> > For the base spec we are not including any complex metrics, b= ut >>> >> >> > instead rely on DV & hopcount (if included) or other=20 >>> techniques that >>> >> >> > work under these assumptions (like the paper above). >>> >> >> > >>> >> >> > I think some additional TLVs and new functionality to enable=20 >>> DYMO to >>> >> >> > support more complex metrics would be interesting. >>> >> >> > >>> >> >> > Ian >>> >> >> > >>> >> >> > On 5/15/07, Philippe Jacquet wrot= e: >>> >> >> >> Hello, folks, >>> >> >> >> >>> >> >> >> I see in DYMO spec (5.3.4) that a RREQ message can be=20 >>> retransmitted >>> >> >> >> several times by a node if it receives copies on shorter=20 >>> routes. >>> >> >> >> >>> >> >> >> This reminds me the paper we did about this kind of=20 >>> super-flooding. >>> >> >> >> >>> >> >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc=20 >>> Networks >>> >> >> >> T. Clausen, P. Jacquet et L. Viennot >>> >> >> >> Med-hoc-Net, 2002 >>> >> >> >> >>> >> >> >> >>> >> >> >>=20 >>> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz >>> >> >> >> >>> >> >> >> It gives the shortest path to OrigNode in hop count, but the >>> >> number of >>> >> >> >> retransmissions may be important and exceed the network size >>> >> (can be >>> >> >> >> quadratic in the network size per RREQ). >>> >> >> >> >>> >> >> >> I wonder if one could also add other metrics than simply=20 >>> hop count. >>> >> >> For >>> >> >> >> example RREQ could seek the path with average shortest=20 >>> delay by >>> >> adding >>> >> >> >> the last hop average link delay to the current weight=20 >>> carried by >>> >> the >>> >> >> >> RREQ. The RREQ would carry a bit indicating that average=20 >>> shortest >>> >> >> delay >>> >> >> >> is activated). Or the RREQ could look to the largest bandwid= th >>> >> >> route (in >>> >> >> >> this case one take the minimum of the last hop bandwidth=20 >>> with the >>> >> >> weight >>> >> >> >> carried by the RREQ. >>> >> >> >> >>> >> >> >> Other metrics are possible (variance, etc). >>> >> >> >> >>> >> >> >> 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 >>> >> >> > >>> >> >> > >>> >> >> >>> >> > >>> >> > >>> >> >>> > >>> > >>> > _______________________________________________ >>> > manet mailing list >>> > manet@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/manet >>> > >>> > >>> >> >> > > > _______________________________________________ > Manet-dt mailing list > Manet-dt@ietf.org > https://www1.ietf.org/mailman/listinfo/manet-dt _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu May 24 05:08: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 1Hr9IX-0004NO-Sd; Thu, 24 May 2007 05:07:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hr9IW-0004NE-Jd for manet-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 05:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr9IW-0004N3-8d; Thu, 24 May 2007 05:07:52 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr9IU-00089z-Gi; Thu, 24 May 2007 05:07:52 -0400 Received: from [192.168.112.191] (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4O97NQg025438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2007 11:07:49 +0200 Message-ID: <465555CB.1040500@inria.fr> Date: Thu, 24 May 2007 11:07:23 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [Manet-dt] Re: [manet] DYMO RREQ flooding and super-flooding References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> <464B013A.6070601@inria.fr> <374005f30705160636p69ae55e8ya6ab9bbcf499c04a@mail.gmail.com> <46534361.4020703@inria.fr> <374005f30705222119q2508118ep7ef85cddf635e4f9@mail.gmail.com> <46546824.9040905@inria.fr> <46549EE5.7070509@nokia.com> In-Reply-To: <46549EE5.7070509@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at discorde with ID 465555E5.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 l4O97NQg025438 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 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 Hello, Charlie, Not sure you will have real transmission saving here. Since the area=20 with lowest RREQ retransmission number on the path will be a bottleneck,=20 then areas with highest retransmission number will generates useless=20 RREQ traffic that will actually not be forwarded. This would cost much=20 more than adding few bits in a RREQ in order to equalize RREQ=20 retransmissions, with exactly same effect but with much less waste of=20 retransmissions. Regarding default retransmission number, you already have two: one (no=20 NodeHop counter) and infinity (with NodeHop counter). You can add a=20 third one but I don't know if it will help. Maybe we can toss a coin=20 between two and ten. Perhaps DYMO will have too many default numbers at=20 the end in detriment of adaptibility to network condition. Regards, Philippe Charles E. Perkins a =E9crit : >=20 > Hello Philippe, >=20 > I have been following along, and have a minor comment about > the proposal. >=20 > In general, I think it is appropriate to maintain default values > but to enable modifications based on measurements of current > relevant traffic and network conditions. Having a default > value saves a great deal of repetition, and so saves a great > deal of wasted transmission capacity. The lesson we have > been learning in our measurements is that more bytes over > the air equals more congestion and always there must be > justification for the potentially degraded performance. >=20 > What would you say about having a default value and > a newly defined extension to change it when needed? > What happens when variable congestion conditions in > different parts of the network suggest different values for > the number of RREQs that should be retransmitted? > I don't automatically see a problem there, but it could > be a tricky point. >=20 > Regards, > Charlie P. >=20 >=20 >=20 > ext Philippe Jacquet wrote: >> Hard to see a default number value. To my opinion it should be=20 >> included in RREQ message and hinted that it should depend on traffic=20 >> conditions. A short relay number will imply a light flooding but=20 >> sub-optimal routes. This would be better suited for short lived path=20 >> or connection. For long lived connection where route sub-optimality=20 >> may be more costly than a heavy super-flooding, a larger relay number=20 >> may be more suitable. >> >> In general I would be careful when introducing additional default=20 >> parameters in DYMO since the latter is strongly based on network=20 >> dynamic. A bad default protocol timing may have great negative impacts. >> >> Philippe >> >> >> >> Ian Chakeres a =E9crit : >>> Sounds like a good idea, I will add a recommendation in the next DYMO >>> revision that devices SHOULD limit the number of RREQ forwarded. >>> >>> Do you have a suggestion for the default limit that should be forward= ed? >>> >>> Ian >>> >>> On 5/23/07, Philippe Jacquet wrote: >>>> I see, I confused with MsgHdr.Hopcount, sorry. Maybe this could be >>>> specifed as a remark in the draft. >>>> >>>> I am not sure that the method specified in the draft will avoid a >>>> quadratic flooding. In particular when slow interfaces have longer=20 >>>> hauls >>>> than fast interfaces. >>>> >>>> Consider a chain of n nodes, each having two interfaces a fast one >>>> covering one hop, and a slow one covering two hops. The route with n= -1 >>>> hops will come first, then the n-2 hops, then the n-3, and finally n= /2 >>>> hops. This would give O(n) RREQ relayed per node. >>>> >>>> In fact the quadratic bound could explode if the metric has no >>>> constraint on discrepancy. In this case it could become exponential = or >>>> even factorial in worst case. >>>> >>>> Why not an upper limit on the number of per RREQ per node relaying a= s a >>>> safeguard to flooding explosion? Even if it has the cost that optima= l >>>> route may not be attainable that way. >>>> >>>> Philippe >>>> >>>> Ian Chakeres a =E9crit : >>>> > The MsgHdr.HopCount is not used in reference to routing=20 >>>> information in >>>> > DYMO. Node.HopCount (in an address block TLV) is optional. >>>> > >>>> > I have not read about super-flooding, but DYMO's method for >>>> > determining the quality of routing information should be=20 >>>> sufficient to >>>> > avoid excess flooding. >>>> > >>>> > Ian >>>> > >>>> > On 5/16/07, Philippe Jacquet wrote: >>>> >> I didn't know that you could disable hop counter, I thought >>>> >> MsgHdr.HopCnt was mandatory in RREQ message. >>>> >> >>>> >> In case you use super-flooding, should you put a limit in the=20 >>>> number of >>>> >> retransmissions per node in order to avoid a flooding explosion? >>>> >> >>>> >> Philippe >>>> >> >>>> >> >>>> >> >>>> >> Ian Chakeres a =E9crit : >>>> >> > If you don't include hop count information, it will not be used= =20 >>>> in the >>>> >> > decision making. >>>> >> > >>>> >> > If you were interested in using "fasted RREQ" path, you would n= ot >>>> >> > include the hop count information. >>>> >> > >>>> >> > Ian >>>> >> > >>>> >> > On 5/16/07, Philippe Jacquet wrote: >>>> >> >> Ian, I don't understand how the method you described in your=20 >>>> paper for >>>> >> >> AODV can be applied for DYMO. >>>> >> >> >>>> >> >> Assume you delay the RREQ retransmission on the two-hop route=20 >>>> because >>>> >> >> the routers have low willingness, so that it is transmitted=20 >>>> after the >>>> >> >> three hops route. Anyhow the two-hop RREQ will be relayed=20 >>>> since it >>>> >> has a >>>> >> >> smaller hop-count and the shortest route will be in fact=20 >>>> selected. >>>> >> Or am >>>> >> >> I wrong? >>>> >> >> >>>> >> >> Philippe >>>> >> >> >>>> >> >> Ian Chakeres a =E9crit : >>>> >> >> > I had done some work on using different metrics by=20 >>>> introducing delay >>>> >> >> > during route discovery to influence route selection. >>>> >> >> > >>>> >> >> > Here is the paper info: >>>> >> >> > >>>> >> >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent >>>> >> Influence >>>> >> >> > of Path Selection in Heterogeneous Ad hoc Networks."=20 >>>> Proceedings of >>>> >> >> > the 15th IEEE International Symposium on Personal, Indoor=20 >>>> and Mobile >>>> >> >> > Radio Communications (PIMRC), Barcelona, Spain, September 20= 04. >>>> >> >> > >>>> >> >> > For the base spec we are not including any complex metrics, = but >>>> >> >> > instead rely on DV & hopcount (if included) or other=20 >>>> techniques that >>>> >> >> > work under these assumptions (like the paper above). >>>> >> >> > >>>> >> >> > I think some additional TLVs and new functionality to enable= =20 >>>> DYMO to >>>> >> >> > support more complex metrics would be interesting. >>>> >> >> > >>>> >> >> > Ian >>>> >> >> > >>>> >> >> > On 5/15/07, Philippe Jacquet wro= te: >>>> >> >> >> Hello, folks, >>>> >> >> >> >>>> >> >> >> I see in DYMO spec (5.3.4) that a RREQ message can be=20 >>>> retransmitted >>>> >> >> >> several times by a node if it receives copies on shorter=20 >>>> routes. >>>> >> >> >> >>>> >> >> >> This reminds me the paper we did about this kind of=20 >>>> super-flooding. >>>> >> >> >> >>>> >> >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc=20 >>>> Networks >>>> >> >> >> T. Clausen, P. Jacquet et L. Viennot >>>> >> >> >> Med-hoc-Net, 2002 >>>> >> >> >> >>>> >> >> >> >>>> >> >> >>=20 >>>> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz >>>> >> >> >> >>>> >> >> >> It gives the shortest path to OrigNode in hop count, but th= e >>>> >> number of >>>> >> >> >> retransmissions may be important and exceed the network siz= e >>>> >> (can be >>>> >> >> >> quadratic in the network size per RREQ). >>>> >> >> >> >>>> >> >> >> I wonder if one could also add other metrics than simply=20 >>>> hop count. >>>> >> >> For >>>> >> >> >> example RREQ could seek the path with average shortest=20 >>>> delay by >>>> >> adding >>>> >> >> >> the last hop average link delay to the current weight=20 >>>> carried by >>>> >> the >>>> >> >> >> RREQ. The RREQ would carry a bit indicating that average=20 >>>> shortest >>>> >> >> delay >>>> >> >> >> is activated). Or the RREQ could look to the largest bandwi= dth >>>> >> >> route (in >>>> >> >> >> this case one take the minimum of the last hop bandwidth=20 >>>> with the >>>> >> >> weight >>>> >> >> >> carried by the RREQ. >>>> >> >> >> >>>> >> >> >> Other metrics are possible (variance, etc). >>>> >> >> >> >>>> >> >> >> 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 >>>> >> >> > >>>> >> >> > >>>> >> >> >>>> >> > >>>> >> > >>>> >> >>>> > >>>> > >>>> > _______________________________________________ >>>> > manet mailing list >>>> > manet@ietf.org >>>> > https://www1.ietf.org/mailman/listinfo/manet >>>> > >>>> > >>>> >>> >>> >> >> >> _______________________________________________ >> Manet-dt mailing list >> Manet-dt@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet-dt >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu May 24 05: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 1Hr9vl-0005oU-Qt; Thu, 24 May 2007 05:48:25 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hr9vk-0005oP-BE for manet-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 05:48:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hr9vk-0005oH-19 for manet@ietf.org; Thu, 24 May 2007 05:48:24 -0400 Received: from mail.gdatech.co.in ([202.144.30.226] helo=gdatech.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hr9vi-0008K5-HU for manet@ietf.org; Thu, 24 May 2007 05:48:24 -0400 Received: from [192.168.0.2] (localhost.localdomain [127.0.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id 9D7F1878107 for ; Thu, 24 May 2007 02:48:27 -0700 (PDT) X-Propel-Return-Path: Received: from gdatech.co.in ([192.168.0.3]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.0.6841-branch_6613 $Rev: 6586 $) id gP3jr75o9Mr0; Thu, 24 May 2007 02:48:27 -0700 Received: from mail.gdatech.co.in (unknown [192.168.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id 6E9E68780FD for ; Thu, 24 May 2007 02:48:27 -0700 (PDT) Received: (qmail 5893 invoked by uid 89); 24 May 2007 09:58:39 -0000 Received: from unknown (HELO ?192.168.3.90?) (b.nagarajan@192.168.3.90) by 0 with SMTP; 24 May 2007 09:58:39 -0000 Message-ID: <46555F6C.6080304@gdatech.co.in> Date: Thu, 24 May 2007 15:18:28 +0530 From: nagarajan 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-Propel-ID: gP3jr75o9Mr0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [manet] AODV protocol-reg 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 would like to know software requirements to implement AODV routing protocol and to simulate the same. I appreciate your help and hands on tips in this regards. Looking forward your positive replies. Have a good day. Thanks and regards, Nagarajan _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu May 24 12:09: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 1HrFsH-0008N0-2j; Thu, 24 May 2007 12:09:13 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HrFsF-0008Mc-7N for manet-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 12:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrFsE-0008MT-Tc; Thu, 24 May 2007 12:09:10 -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 1HrFsA-0004xq-E9; Thu, 24 May 2007 12:09:10 -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 l4OG93LD008454; Thu, 24 May 2007 19:09:04 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 19:08:39 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 11:08:30 -0500 Received: from [10.162.89.134] ([10.162.89.134]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 May 2007 11:08:25 -0500 Message-ID: <4655B872.2040303@nokia.com> Date: Thu, 24 May 2007 09:08:18 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ext Philippe Jacquet Subject: Re: [Manet-dt] Re: [manet] DYMO RREQ flooding and super-flooding References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> <464B013A.6070601@inria.fr> <374005f30705160636p69ae55e8ya6ab9bbcf499c04a@mail.gmail.com> <46534361.4020703@inria.fr> <374005f30705222119q2508118ep7ef85cddf635e4f9@mail.gmail.com> <46546824.9040905@inria.fr> <46549EE5.7070509@nokia.com> <465555CB.1040500@inria.fr> In-Reply-To: <465555CB.1040500@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 24 May 2007 16:08:25.0658 (UTC) FILETIME=[C26E09A0:01C79E1D] X-Nokia-AV: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext13.nokia.com id l4OG93LD008454 X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae 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 Hello Philippe, Let's try it again from a somewhat different perspective. Suppose the default is appropriate for "normal" network conditions -- and, thus most packets do not need to have any such extension.=20 Now, your comment would apply to the less common case. When that happens, we would have more RREQ retransmissions in uncongested parts of the network, and RREQ retransmissions would be throttled in the congestion regions, effectively producing fewer completed route discoveries utilizing links in the congestion region. Overall, this doesn't seem too bad to me... We just have to pick the default wisely according to whatever experience we can acquire. What would you say if the default number of retransmissions were, for instance, 6 at every node? If, on the other hand, there is no observable regularity in the network congestion, and most packets end up setting new retransmission parameter values, then I can agree that setting aside some bits for this purpose would be reasonable. However, I do not recall any studies that have indicated the need for this, or any studies that have shown that having some adaptive behavior would improve performance. I didn't see any algorithms for making the adaptation. This does not mean the danger is nonexistent. But it does suggest we shouldn't automatically enlarge all packets to combat a potentially quite rare problem. Regards, Charlie P. ext Philippe Jacquet wrote: > Hello, Charlie, > > Not sure you will have real transmission saving here. Since the area=20 > with lowest RREQ retransmission number on the path will be a=20 > bottleneck, then areas with highest retransmission number will=20 > generates useless RREQ traffic that will actually not be forwarded.=20 > This would cost much more than adding few bits in a RREQ in order to=20 > equalize RREQ retransmissions, with exactly same effect but with much=20 > less waste of retransmissions. > > Regarding default retransmission number, you already have two: one (no=20 > NodeHop counter) and infinity (with NodeHop counter). You can add a=20 > third one but I don't know if it will help. Maybe we can toss a coin=20 > between two and ten. Perhaps DYMO will have too many default numbers=20 > at the end in detriment of adaptibility to network condition. > > Regards, > Philippe > > Charles E. Perkins a =E9crit : >> >> Hello Philippe, >> >> I have been following along, and have a minor comment about >> the proposal. >> >> In general, I think it is appropriate to maintain default values >> but to enable modifications based on measurements of current >> relevant traffic and network conditions. Having a default >> value saves a great deal of repetition, and so saves a great >> deal of wasted transmission capacity. The lesson we have >> been learning in our measurements is that more bytes over >> the air equals more congestion and always there must be >> justification for the potentially degraded performance. >> >> What would you say about having a default value and >> a newly defined extension to change it when needed? >> What happens when variable congestion conditions in >> different parts of the network suggest different values for >> the number of RREQs that should be retransmitted? >> I don't automatically see a problem there, but it could >> be a tricky point. >> >> Regards, >> Charlie P. >> >> >> >> ext Philippe Jacquet wrote: >>> Hard to see a default number value. To my opinion it should be=20 >>> included in RREQ message and hinted that it should depend on traffic=20 >>> conditions. A short relay number will imply a light flooding but=20 >>> sub-optimal routes. This would be better suited for short lived path=20 >>> or connection. For long lived connection where route sub-optimality=20 >>> may be more costly than a heavy super-flooding, a larger relay=20 >>> number may be more suitable. >>> >>> In general I would be careful when introducing additional default=20 >>> parameters in DYMO since the latter is strongly based on network=20 >>> dynamic. A bad default protocol timing may have great negative impact= s. >>> >>> Philippe >>> >>> >>> >>> Ian Chakeres a =E9crit : >>>> Sounds like a good idea, I will add a recommendation in the next DYM= O >>>> revision that devices SHOULD limit the number of RREQ forwarded. >>>> >>>> Do you have a suggestion for the default limit that should be=20 >>>> forwarded? >>>> >>>> Ian >>>> >>>> On 5/23/07, Philippe Jacquet wrote: >>>>> I see, I confused with MsgHdr.Hopcount, sorry. Maybe this could be >>>>> specifed as a remark in the draft. >>>>> >>>>> I am not sure that the method specified in the draft will avoid a >>>>> quadratic flooding. In particular when slow interfaces have longer=20 >>>>> hauls >>>>> than fast interfaces. >>>>> >>>>> Consider a chain of n nodes, each having two interfaces a fast one >>>>> covering one hop, and a slow one covering two hops. The route with=20 >>>>> n-1 >>>>> hops will come first, then the n-2 hops, then the n-3, and finally=20 >>>>> n/2 >>>>> hops. This would give O(n) RREQ relayed per node. >>>>> >>>>> In fact the quadratic bound could explode if the metric has no >>>>> constraint on discrepancy. In this case it could become=20 >>>>> exponential or >>>>> even factorial in worst case. >>>>> >>>>> Why not an upper limit on the number of per RREQ per node relaying=20 >>>>> as a >>>>> safeguard to flooding explosion? Even if it has the cost that optim= al >>>>> route may not be attainable that way. >>>>> >>>>> Philippe >>>>> >>>>> Ian Chakeres a =E9crit : >>>>> > The MsgHdr.HopCount is not used in reference to routing=20 >>>>> information in >>>>> > DYMO. Node.HopCount (in an address block TLV) is optional. >>>>> > >>>>> > I have not read about super-flooding, but DYMO's method for >>>>> > determining the quality of routing information should be=20 >>>>> sufficient to >>>>> > avoid excess flooding. >>>>> > >>>>> > Ian >>>>> > >>>>> > On 5/16/07, Philippe Jacquet wrote: >>>>> >> I didn't know that you could disable hop counter, I thought >>>>> >> MsgHdr.HopCnt was mandatory in RREQ message. >>>>> >> >>>>> >> In case you use super-flooding, should you put a limit in the=20 >>>>> number of >>>>> >> retransmissions per node in order to avoid a flooding explosion? >>>>> >> >>>>> >> Philippe >>>>> >> >>>>> >> >>>>> >> >>>>> >> Ian Chakeres a =E9crit : >>>>> >> > If you don't include hop count information, it will not be=20 >>>>> used in the >>>>> >> > decision making. >>>>> >> > >>>>> >> > If you were interested in using "fasted RREQ" path, you would=20 >>>>> not >>>>> >> > include the hop count information. >>>>> >> > >>>>> >> > Ian >>>>> >> > >>>>> >> > On 5/16/07, Philippe Jacquet wrote= : >>>>> >> >> Ian, I don't understand how the method you described in your=20 >>>>> paper for >>>>> >> >> AODV can be applied for DYMO. >>>>> >> >> >>>>> >> >> Assume you delay the RREQ retransmission on the two-hop=20 >>>>> route because >>>>> >> >> the routers have low willingness, so that it is transmitted=20 >>>>> after the >>>>> >> >> three hops route. Anyhow the two-hop RREQ will be relayed=20 >>>>> since it >>>>> >> has a >>>>> >> >> smaller hop-count and the shortest route will be in fact=20 >>>>> selected. >>>>> >> Or am >>>>> >> >> I wrong? >>>>> >> >> >>>>> >> >> Philippe >>>>> >> >> >>>>> >> >> Ian Chakeres a =E9crit : >>>>> >> >> > I had done some work on using different metrics by=20 >>>>> introducing delay >>>>> >> >> > during route discovery to influence route selection. >>>>> >> >> > >>>>> >> >> > Here is the paper info: >>>>> >> >> > >>>>> >> >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparen= t >>>>> >> Influence >>>>> >> >> > of Path Selection in Heterogeneous Ad hoc Networks."=20 >>>>> Proceedings of >>>>> >> >> > the 15th IEEE International Symposium on Personal, Indoor=20 >>>>> and Mobile >>>>> >> >> > Radio Communications (PIMRC), Barcelona, Spain, September=20 >>>>> 2004. >>>>> >> >> > >>>>> >> >> > For the base spec we are not including any complex=20 >>>>> metrics, but >>>>> >> >> > instead rely on DV & hopcount (if included) or other=20 >>>>> techniques that >>>>> >> >> > work under these assumptions (like the paper above). >>>>> >> >> > >>>>> >> >> > I think some additional TLVs and new functionality to=20 >>>>> enable DYMO to >>>>> >> >> > support more complex metrics would be interesting. >>>>> >> >> > >>>>> >> >> > Ian >>>>> >> >> > >>>>> >> >> > On 5/15/07, Philippe Jacquet =20 >>>>> wrote: >>>>> >> >> >> Hello, folks, >>>>> >> >> >> >>>>> >> >> >> I see in DYMO spec (5.3.4) that a RREQ message can be=20 >>>>> retransmitted >>>>> >> >> >> several times by a node if it receives copies on shorter=20 >>>>> routes. >>>>> >> >> >> >>>>> >> >> >> This reminds me the paper we did about this kind of=20 >>>>> super-flooding. >>>>> >> >> >> >>>>> >> >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc=20 >>>>> Networks >>>>> >> >> >> T. Clausen, P. Jacquet et L. Viennot >>>>> >> >> >> Med-hoc-Net, 2002 >>>>> >> >> >> >>>>> >> >> >> >>>>> >> >> >>=20 >>>>> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.gz >>>>> >> >> >> >>>>> >> >> >> It gives the shortest path to OrigNode in hop count, but t= he >>>>> >> number of >>>>> >> >> >> retransmissions may be important and exceed the network si= ze >>>>> >> (can be >>>>> >> >> >> quadratic in the network size per RREQ). >>>>> >> >> >> >>>>> >> >> >> I wonder if one could also add other metrics than simply=20 >>>>> hop count. >>>>> >> >> For >>>>> >> >> >> example RREQ could seek the path with average shortest=20 >>>>> delay by >>>>> >> adding >>>>> >> >> >> the last hop average link delay to the current weight=20 >>>>> carried by >>>>> >> the >>>>> >> >> >> RREQ. The RREQ would carry a bit indicating that average=20 >>>>> shortest >>>>> >> >> delay >>>>> >> >> >> is activated). Or the RREQ could look to the largest=20 >>>>> bandwidth >>>>> >> >> route (in >>>>> >> >> >> this case one take the minimum of the last hop bandwidth=20 >>>>> with the >>>>> >> >> weight >>>>> >> >> >> carried by the RREQ. >>>>> >> >> >> >>>>> >> >> >> Other metrics are possible (variance, etc). >>>>> >> >> >> >>>>> >> >> >> 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 >>>>> >> >> > >>>>> >> >> > >>>>> >> >> >>>>> >> > >>>>> >> > >>>>> >> >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > manet mailing list >>>>> > manet@ietf.org >>>>> > https://www1.ietf.org/mailman/listinfo/manet >>>>> > >>>>> > >>>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Manet-dt mailing list >>> Manet-dt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet-dt >> >> >> >> _______________________________________________ >> manet mailing 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 May 24 12:17: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 1HrG0f-0005D6-La; Thu, 24 May 2007 12:17:53 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HrG0e-00055Q-6K for manet-confirm+ok@megatron.ietf.org; Thu, 24 May 2007 12:17:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrG0d-00053I-Rl for manet@ietf.org; Thu, 24 May 2007 12:17:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrG0c-0007wh-BC for manet@ietf.org; Thu, 24 May 2007 12:17:51 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1243546ugc for ; Thu, 24 May 2007 09:17: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:in-reply-to:mime-version:content-type:references; b=DzeGXdjpprd2jUaskGJNxqsp4VuO+4isoHQCApnlLvFwRfIi0yAWsTb5hxvxXQEtTTvC9etKrIONO0oYgB4hhclnzvvLx92MpYSeh9R7tHf7lwcQip1a5fvNI+A3Lb2MzbHCY6+7FsVINzDafKmKYX2TaUdkK+9VCdT7UOrDKyU= 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=UvFTxBc2UGwoiXAFsXeE53CfV902+zvV0cR9HTphEEuBg+QkGWDBKA8VeU5oPCs4gIqsHF7eQ/xtz5YY7KCUxqqZ3ALAKGmsx87tdPE05h6S1605NDhUit1MYGetst+sHiVD8T/ChnhL6xRE12XhpSKsl68QxHTayhgzACDlk+I= Received: by 10.67.121.15 with SMTP id y15mr2242112ugm.1180023465364; Thu, 24 May 2007 09:17:45 -0700 (PDT) Received: by 10.66.217.20 with HTTP; Thu, 24 May 2007 09:17:45 -0700 (PDT) Message-ID: <87082b010705240917s5d344bd8qa0e1caa500c847da@mail.gmail.com> Date: Thu, 24 May 2007 18:17:45 +0200 From: "wafa Berrayana" To: manet@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [manet] Re: manet Digest, Vol 37, Issue 30 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="===============1751780775==" Errors-To: manet-bounces@ietf.org --===============1751780775== Content-Type: multipart/alternative; boundary="----=_Part_57451_21450242.1180023465268" ------=_Part_57451_21450242.1180023465268 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, AODV could be simulated under NS2 or J-SIM (http://www.j-sim.org/). J-SIM is better to manipulate than NS2 but NS2 has a completed implementation. Good luck wafa 2007/5/24, manet-request@ietf.org : > > 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. AODV protocol-reg (nagarajan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 24 May 2007 15:18:28 +0530 > From: nagarajan > Subject: [manet] AODV protocol-reg > To: manet > Message-ID: <46555F6C.6080304@gdatech.co.in> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi all, > > I would like to know software requirements to implement AODV > routing protocol and to simulate the same. I appreciate your help and > hands on tips in this regards. > > Looking forward your positive replies. > > Have a good day. > > Thanks and regards, > Nagarajan > > > > > ------------------------------ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > End of manet Digest, Vol 37, Issue 30 > ************************************* > ------=_Part_57451_21450242.1180023465268 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,
AODV could be simulated under NS2 or J-SIM (http://www.j-sim.org/). J-SIM is better to manipulate than NS2 but NS2 has a completed implementation.
Good luck
wafa

2007/5/24, manet-request@ietf.org <manet-request@ietf.org>:
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. AODV protocol-reg (nagarajan)


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

Message: 1
Date: Thu, 24 May 2007 15:18:28 +0530
From: nagarajan < b.nagarajan@gdatech.co.in>
Subject: [manet] AODV protocol-reg
To: manet <manet@ietf.org>
Message-ID: <46555F6C.6080304@gdatech.co.in >
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi all,

       I would like to know software requirements to implement AODV
routing protocol and to simulate the same. I appreciate your help and
hands on tips in this regards.

    Looking forward your positive replies.

    Have a good day.

Thanks and regards,
Nagarajan




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

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


End of manet Digest, Vol 37, Issue 30
*************************************

------=_Part_57451_21450242.1180023465268-- --===============1751780775== 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 --===============1751780775==-- From manet-bounces@ietf.org Fri May 25 04:29: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 1HrVB7-0001Hw-9g; Fri, 25 May 2007 04:29:41 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HrVB5-0001Ho-DB for manet-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 04:29:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrVB5-0001Hd-0m for manet@ietf.org; Fri, 25 May 2007 04:29:39 -0400 Received: from mail.gdatech.co.in ([202.144.30.226] helo=gdatech.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrVB3-00023g-HF for manet@ietf.org; Fri, 25 May 2007 04:29:38 -0400 Received: from [192.168.0.2] (localhost.localdomain [127.0.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id 331158780F7 for ; Fri, 25 May 2007 01:29:48 -0700 (PDT) X-Propel-Return-Path: Received: from gdatech.co.in ([192.168.0.3]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 2.1.0.6841-branch_6613 $Rev: 6586 $) id gP3jr75p8tM0; Fri, 25 May 2007 01:29:48 -0700 Received: from mail.gdatech.co.in (unknown [192.168.0.1]) by predator.gdatech.co.in (Postfix-out) with ESMTP id 0F3AC8780F6 for ; Fri, 25 May 2007 01:29:48 -0700 (PDT) Received: (qmail 31086 invoked by uid 89); 25 May 2007 08:39:55 -0000 Received: from unknown (HELO ?192.168.3.90?) (b.nagarajan@192.168.3.90) by 0 with SMTP; 25 May 2007 08:39:55 -0000 Message-ID: <46569E76.4040909@gdatech.co.in> Date: Fri, 25 May 2007 13:59:42 +0530 From: nagarajan 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-Propel-ID: gP3jr75p8tM0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [manet] GloMoSim-reg 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 would like to have GloMoSim for my simulation purpose. But in the website it has been mentioned that it is only for academic use. I would like to know the way to get GloMoSim. I appreciate your help in this regard. Thanks and regards, Nagarajan _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 25 09:25: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 1HrZnB-00053Y-Fs; Fri, 25 May 2007 09:25:17 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HrZn9-00053O-6y for manet-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 09:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrZn8-00053E-TE; Fri, 25 May 2007 09:25:14 -0400 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrZn6-0006po-06; Fri, 25 May 2007 09:25:14 -0400 Received: from [128.93.62.246] (dhcp-rocq-246.inria.fr [128.93.62.246]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l4PDPA4X007164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 May 2007 15:25:11 +0200 Message-ID: <4656E3B6.1050107@inria.fr> Date: Fri, 25 May 2007 15:25:10 +0200 From: Philippe Jacquet User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [Manet-dt] Re: [manet] DYMO RREQ flooding and super-flooding References: <4649E10A.5040007@inria.fr> <374005f30705152127m6a8bdfe2n99715930e2bd9393@mail.gmail.com> <464AEF53.7020506@inria.fr> <374005f30705160501v42c53e61h3f0b71569df2541c@mail.gmail.com> <464B013A.6070601@inria.fr> <374005f30705160636p69ae55e8ya6ab9bbcf499c04a@mail.gmail.com> <46534361.4020703@inria.fr> <374005f30705222119q2508118ep7ef85cddf635e4f9@mail.gmail.com> <46546824.9040905@inria.fr> <46549EE5.7070509@nokia.com> <465555CB.1040500@inria.fr> <4655B872.2040303@nokia.com> In-Reply-To: <4655B872.2040303@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Miltered: at discorde with ID 4656E3B6.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 l4PDPA4X007164 X-Spam-Score: 0.0 (/) X-Scan-Signature: da41e01217ab11ad82db577473e913ae 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 Hello, Charlie, Not sure it will likely work that way. It already fails in my simple=20 example. If nodes in the middle of the chain are congested it won't=20 prevent the path to go through even by locally adjusting RREQ=20 retransmission number. Super-flooding (limited or not) makes the path to evolve toward the=20 shortest path, by smoothing out unnecessary random excursion from the=20 optimal path that would incur in simple flooding. If the shortest path=20 has to go through a congested area, super-flooding won't help to avoid=20 it. I am afraid that the most likely outcome would be to create new=20 congested areas due to useless RREQ retransmissions without avoiding=20 existing congestion. If one really wants to avoid congested area, then one can add an=20 objective penalty to hop count when the link is in a congested area. For=20 example instead of making hop_count<-hop_count+1, adding the average=20 delay or, better, the average number of data packet retransmissions=20 experienced on that link. In fact this is equivalent to consider another=20 metric than simple hop count. But of course would imply a proactive=20 monitoring of local conditions. I am also not aware of an efficient congestion monitoring in reactive=20 protocols, this is why I was merely suggesting to insert the non-default=20 RREQ retransmission limit in the RREQ itself. A node can monitor the=20 previous routes to a given destination and if they happened to be stable=20 (no frequent RERR) and if the demanded connection is expected to last=20 long, then it would be worthy to spend more flooding in order to catch a=20 more optimal route and save in long term communication overhead. Of course this is just a one penny contribution... Best regards, Philippe Charles E. Perkins a =E9crit : >=20 > Hello Philippe, >=20 > Let's try it again from a somewhat different perspective. >=20 > Suppose the default is appropriate for "normal" network > conditions -- and, thus most packets do not need to have > any such extension. > Now, your comment would apply to the less common > case. When that happens, we would have more RREQ > retransmissions in uncongested parts of the network, > and RREQ retransmissions would be throttled in the > congestion regions, effectively producing fewer completed > route discoveries utilizing links in the congestion region. >=20 > Overall, this doesn't seem too bad to me... >=20 > We just have to pick the default wisely according to > whatever experience we can acquire. What would you > say if the default number of retransmissions were, for > instance, 6 at every node? >=20 > If, on the other hand, there is no observable regularity > in the network congestion, and most packets end up > setting new retransmission parameter values, then I > can agree that setting aside some bits for this purpose > would be reasonable. However, I do not recall any > studies that have indicated the need for this, or any > studies that have shown that having some adaptive > behavior would improve performance. I didn't see > any algorithms for making the adaptation. This > does not mean the danger is nonexistent. But it > does suggest we shouldn't automatically enlarge all > packets to combat a potentially quite rare problem. >=20 > Regards, > Charlie P. >=20 >=20 > ext Philippe Jacquet wrote: >> Hello, Charlie, >> >> Not sure you will have real transmission saving here. Since the area=20 >> with lowest RREQ retransmission number on the path will be a=20 >> bottleneck, then areas with highest retransmission number will=20 >> generates useless RREQ traffic that will actually not be forwarded.=20 >> This would cost much more than adding few bits in a RREQ in order to=20 >> equalize RREQ retransmissions, with exactly same effect but with much=20 >> less waste of retransmissions. >> >> Regarding default retransmission number, you already have two: one (no= =20 >> NodeHop counter) and infinity (with NodeHop counter). You can add a=20 >> third one but I don't know if it will help. Maybe we can toss a coin=20 >> between two and ten. Perhaps DYMO will have too many default numbers=20 >> at the end in detriment of adaptibility to network condition. >> >> Regards, >> Philippe >> >> Charles E. Perkins a =E9crit : >>> >>> Hello Philippe, >>> >>> I have been following along, and have a minor comment about >>> the proposal. >>> >>> In general, I think it is appropriate to maintain default values >>> but to enable modifications based on measurements of current >>> relevant traffic and network conditions. Having a default >>> value saves a great deal of repetition, and so saves a great >>> deal of wasted transmission capacity. The lesson we have >>> been learning in our measurements is that more bytes over >>> the air equals more congestion and always there must be >>> justification for the potentially degraded performance. >>> >>> What would you say about having a default value and >>> a newly defined extension to change it when needed? >>> What happens when variable congestion conditions in >>> different parts of the network suggest different values for >>> the number of RREQs that should be retransmitted? >>> I don't automatically see a problem there, but it could >>> be a tricky point. >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> ext Philippe Jacquet wrote: >>>> Hard to see a default number value. To my opinion it should be=20 >>>> included in RREQ message and hinted that it should depend on traffic= =20 >>>> conditions. A short relay number will imply a light flooding but=20 >>>> sub-optimal routes. This would be better suited for short lived path= =20 >>>> or connection. For long lived connection where route sub-optimality=20 >>>> may be more costly than a heavy super-flooding, a larger relay=20 >>>> number may be more suitable. >>>> >>>> In general I would be careful when introducing additional default=20 >>>> parameters in DYMO since the latter is strongly based on network=20 >>>> dynamic. A bad default protocol timing may have great negative impac= ts. >>>> >>>> Philippe >>>> >>>> >>>> >>>> Ian Chakeres a =E9crit : >>>>> Sounds like a good idea, I will add a recommendation in the next DY= MO >>>>> revision that devices SHOULD limit the number of RREQ forwarded. >>>>> >>>>> Do you have a suggestion for the default limit that should be=20 >>>>> forwarded? >>>>> >>>>> Ian >>>>> >>>>> On 5/23/07, Philippe Jacquet wrote: >>>>>> I see, I confused with MsgHdr.Hopcount, sorry. Maybe this could be >>>>>> specifed as a remark in the draft. >>>>>> >>>>>> I am not sure that the method specified in the draft will avoid a >>>>>> quadratic flooding. In particular when slow interfaces have longer= =20 >>>>>> hauls >>>>>> than fast interfaces. >>>>>> >>>>>> Consider a chain of n nodes, each having two interfaces a fast one >>>>>> covering one hop, and a slow one covering two hops. The route with= =20 >>>>>> n-1 >>>>>> hops will come first, then the n-2 hops, then the n-3, and finally= =20 >>>>>> n/2 >>>>>> hops. This would give O(n) RREQ relayed per node. >>>>>> >>>>>> In fact the quadratic bound could explode if the metric has no >>>>>> constraint on discrepancy. In this case it could become=20 >>>>>> exponential or >>>>>> even factorial in worst case. >>>>>> >>>>>> Why not an upper limit on the number of per RREQ per node relaying= =20 >>>>>> as a >>>>>> safeguard to flooding explosion? Even if it has the cost that opti= mal >>>>>> route may not be attainable that way. >>>>>> >>>>>> Philippe >>>>>> >>>>>> Ian Chakeres a =E9crit : >>>>>> > The MsgHdr.HopCount is not used in reference to routing=20 >>>>>> information in >>>>>> > DYMO. Node.HopCount (in an address block TLV) is optional. >>>>>> > >>>>>> > I have not read about super-flooding, but DYMO's method for >>>>>> > determining the quality of routing information should be=20 >>>>>> sufficient to >>>>>> > avoid excess flooding. >>>>>> > >>>>>> > Ian >>>>>> > >>>>>> > On 5/16/07, Philippe Jacquet wrote: >>>>>> >> I didn't know that you could disable hop counter, I thought >>>>>> >> MsgHdr.HopCnt was mandatory in RREQ message. >>>>>> >> >>>>>> >> In case you use super-flooding, should you put a limit in the=20 >>>>>> number of >>>>>> >> retransmissions per node in order to avoid a flooding explosion= ? >>>>>> >> >>>>>> >> Philippe >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> Ian Chakeres a =E9crit : >>>>>> >> > If you don't include hop count information, it will not be=20 >>>>>> used in the >>>>>> >> > decision making. >>>>>> >> > >>>>>> >> > If you were interested in using "fasted RREQ" path, you would= =20 >>>>>> not >>>>>> >> > include the hop count information. >>>>>> >> > >>>>>> >> > Ian >>>>>> >> > >>>>>> >> > On 5/16/07, Philippe Jacquet wrot= e: >>>>>> >> >> Ian, I don't understand how the method you described in your= =20 >>>>>> paper for >>>>>> >> >> AODV can be applied for DYMO. >>>>>> >> >> >>>>>> >> >> Assume you delay the RREQ retransmission on the two-hop=20 >>>>>> route because >>>>>> >> >> the routers have low willingness, so that it is transmitted=20 >>>>>> after the >>>>>> >> >> three hops route. Anyhow the two-hop RREQ will be relayed=20 >>>>>> since it >>>>>> >> has a >>>>>> >> >> smaller hop-count and the shortest route will be in fact=20 >>>>>> selected. >>>>>> >> Or am >>>>>> >> >> I wrong? >>>>>> >> >> >>>>>> >> >> Philippe >>>>>> >> >> >>>>>> >> >> Ian Chakeres a =E9crit : >>>>>> >> >> > I had done some work on using different metrics by=20 >>>>>> introducing delay >>>>>> >> >> > during route discovery to influence route selection. >>>>>> >> >> > >>>>>> >> >> > Here is the paper info: >>>>>> >> >> > >>>>>> >> >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transpare= nt >>>>>> >> Influence >>>>>> >> >> > of Path Selection in Heterogeneous Ad hoc Networks."=20 >>>>>> Proceedings of >>>>>> >> >> > the 15th IEEE International Symposium on Personal, Indoor=20 >>>>>> and Mobile >>>>>> >> >> > Radio Communications (PIMRC), Barcelona, Spain, September=20 >>>>>> 2004. >>>>>> >> >> > >>>>>> >> >> > For the base spec we are not including any complex=20 >>>>>> metrics, but >>>>>> >> >> > instead rely on DV & hopcount (if included) or other=20 >>>>>> techniques that >>>>>> >> >> > work under these assumptions (like the paper above). >>>>>> >> >> > >>>>>> >> >> > I think some additional TLVs and new functionality to=20 >>>>>> enable DYMO to >>>>>> >> >> > support more complex metrics would be interesting. >>>>>> >> >> > >>>>>> >> >> > Ian >>>>>> >> >> > >>>>>> >> >> > On 5/15/07, Philippe Jacquet =20 >>>>>> wrote: >>>>>> >> >> >> Hello, folks, >>>>>> >> >> >> >>>>>> >> >> >> I see in DYMO spec (5.3.4) that a RREQ message can be=20 >>>>>> retransmitted >>>>>> >> >> >> several times by a node if it receives copies on shorter=20 >>>>>> routes. >>>>>> >> >> >> >>>>>> >> >> >> This reminds me the paper we did about this kind of=20 >>>>>> super-flooding. >>>>>> >> >> >> >>>>>> >> >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc=20 >>>>>> Networks >>>>>> >> >> >> T. Clausen, P. Jacquet et L. Viennot >>>>>> >> >> >> Med-hoc-Net, 2002 >>>>>> >> >> >> >>>>>> >> >> >> >>>>>> >> >> >>=20 >>>>>> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim.ps.g= z >>>>>> >> >> >> >>>>>> >> >> >> It gives the shortest path to OrigNode in hop count, but = the >>>>>> >> number of >>>>>> >> >> >> retransmissions may be important and exceed the network s= ize >>>>>> >> (can be >>>>>> >> >> >> quadratic in the network size per RREQ). >>>>>> >> >> >> >>>>>> >> >> >> I wonder if one could also add other metrics than simply=20 >>>>>> hop count. >>>>>> >> >> For >>>>>> >> >> >> example RREQ could seek the path with average shortest=20 >>>>>> delay by >>>>>> >> adding >>>>>> >> >> >> the last hop average link delay to the current weight=20 >>>>>> carried by >>>>>> >> the >>>>>> >> >> >> RREQ. The RREQ would carry a bit indicating that average=20 >>>>>> shortest >>>>>> >> >> delay >>>>>> >> >> >> is activated). Or the RREQ could look to the largest=20 >>>>>> bandwidth >>>>>> >> >> route (in >>>>>> >> >> >> this case one take the minimum of the last hop bandwidth=20 >>>>>> with the >>>>>> >> >> weight >>>>>> >> >> >> carried by the RREQ. >>>>>> >> >> >> >>>>>> >> >> >> Other metrics are possible (variance, etc). >>>>>> >> >> >> >>>>>> >> >> >> 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 >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> >>>>>> >> > >>>>>> >> > >>>>>> >> >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > manet mailing list >>>>>> > manet@ietf.org >>>>>> > https://www1.ietf.org/mailman/listinfo/manet >>>>>> > >>>>>> > >>>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Manet-dt mailing list >>>> Manet-dt@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/manet-dt >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>> >>> >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri May 25 12:09: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 1HrcLf-0000la-OW; Fri, 25 May 2007 12:09:03 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HrcLe-0000lN-Du for manet-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 12:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrcLe-0000jG-31 for manet@ietf.org; Fri, 25 May 2007 12:09:02 -0400 Received: from mailgw10.technion.ac.il ([132.68.225.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrcLa-0006vj-Rl for manet@ietf.org; Fri, 25 May 2007 12:09:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEamVkaERCAf/2dsb2JhbAA X-IronPort-AV: E=Sophos;i="4.14,580,1170626400"; d="scan'208";a="7471550" Received: from csm.cs.technion.ac.il ([132.68.32.31]) by mailgw10.technion.ac.il with ESMTP; 25 May 2007 19:08:54 +0300 Received: from gabiklap (gabik-lap.cs.technion.ac.il [132.68.41.248]) by csm.cs.technion.ac.il (Postfix) with ESMTP id 22D9C18C418; Fri, 25 May 2007 19:08:54 +0300 (IDT) From: "gabik" To: "'Ian Chakeres'" , "'Philippe Jacquet'" Subject: RE: [manet] DYMO RREQ flooding and super-flooding Date: Fri, 25 May 2007 19:08:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acec8cnMAMOKwaNpRKihPpcXhgILLgB8nurA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <374005f30705222119q2508118ep7ef85cddf635e4f9@mail.gmail.com> Message-Id: <20070525160854.22D9C18C418@csm.cs.technion.ac.il> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae 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 Is not the same trick of limiting the number of RREQ messages per node = is already used in AODV/DSR? I know that studying from the simulators' code is not the best idea, = but: It seems that it is already implemented at least in glomosim in the = context of initiating RREQ messages in AODV (not forwarding) (AODV_MAX_RERR_DESTINATIONS, glomosim-2.03\glomosim\network\aodv.pc = 1997). But I was under an impression that the same mechanism is used for = forwarding as well. Gabi Kliot =20 -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: Wednesday, May 23, 2007 7:20 AM To: Philippe Jacquet Cc: manet Subject: Re: [manet] DYMO RREQ flooding and super-flooding Sounds like a good idea, I will add a recommendation in the next DYMO revision that devices SHOULD limit the number of RREQ forwarded. Do you have a suggestion for the default limit that should be forwarded? Ian On 5/23/07, Philippe Jacquet wrote: > I see, I confused with MsgHdr.Hopcount, sorry. Maybe this could be=20 > specifed as a remark in the draft. > > I am not sure that the method specified in the draft will avoid a=20 > quadratic flooding. In particular when slow interfaces have longer=20 > hauls than fast interfaces. > > Consider a chain of n nodes, each having two interfaces a fast one=20 > covering one hop, and a slow one covering two hops. The route with n-1 = > hops will come first, then the n-2 hops, then the n-3, and finally n/2 = > hops. This would give O(n) RREQ relayed per node. > > In fact the quadratic bound could explode if the metric has no=20 > constraint on discrepancy. In this case it could become exponential or = > even factorial in worst case. > > Why not an upper limit on the number of per RREQ per node relaying as=20 > a safeguard to flooding explosion? Even if it has the cost that=20 > optimal route may not be attainable that way. > > Philippe > > Ian Chakeres a =E9crit : > > The MsgHdr.HopCount is not used in reference to routing information=20 > > in DYMO. Node.HopCount (in an address block TLV) is optional. > > > > I have not read about super-flooding, but DYMO's method for=20 > > determining the quality of routing information should be sufficient=20 > > to avoid excess flooding. > > > > Ian > > > > On 5/16/07, Philippe Jacquet wrote: > >> I didn't know that you could disable hop counter, I thought=20 > >> MsgHdr.HopCnt was mandatory in RREQ message. > >> > >> In case you use super-flooding, should you put a limit in the=20 > >> number of retransmissions per node in order to avoid a flooding explosion? > >> > >> Philippe > >> > >> > >> > >> Ian Chakeres a =E9crit : > >> > If you don't include hop count information, it will not be used=20 > >> > in the decision making. > >> > > >> > If you were interested in using "fasted RREQ" path, you would not = > >> > include the hop count information. > >> > > >> > Ian > >> > > >> > On 5/16/07, Philippe Jacquet wrote: > >> >> Ian, I don't understand how the method you described in your=20 > >> >> paper for AODV can be applied for DYMO. > >> >> > >> >> Assume you delay the RREQ retransmission on the two-hop route=20 > >> >> because the routers have low willingness, so that it is=20 > >> >> transmitted after the three hops route. Anyhow the two-hop RREQ=20 > >> >> will be relayed since it > >> has a > >> >> smaller hop-count and the shortest route will be in fact = selected. > >> Or am > >> >> I wrong? > >> >> > >> >> Philippe > >> >> > >> >> Ian Chakeres a =E9crit : > >> >> > I had done some work on using different metrics by introducing = > >> >> > delay during route discovery to influence route selection. > >> >> > > >> >> > Here is the paper info: > >> >> > > >> >> > Ian D. Chakeres and Elizabeth M. Belding-Royer. "Transparent > >> Influence > >> >> > of Path Selection in Heterogeneous Ad hoc Networks."=20 > >> >> > Proceedings of the 15th IEEE International Symposium on=20 > >> >> > Personal, Indoor and Mobile Radio Communications (PIMRC), Barcelona, Spain, September 2004. > >> >> > > >> >> > For the base spec we are not including any complex metrics,=20 > >> >> > but instead rely on DV & hopcount (if included) or other=20 > >> >> > techniques that work under these assumptions (like the paper above). > >> >> > > >> >> > I think some additional TLVs and new functionality to enable=20 > >> >> > DYMO to support more complex metrics would be interesting. > >> >> > > >> >> > Ian > >> >> > > >> >> > On 5/15/07, Philippe Jacquet = wrote: > >> >> >> Hello, folks, > >> >> >> > >> >> >> I see in DYMO spec (5.3.4) that a RREQ message can be=20 > >> >> >> retransmitted several times by a node if it receives copies = on shorter routes. > >> >> >> > >> >> >> This reminds me the paper we did about this kind of super-flooding. > >> >> >> > >> >> >> Comparative Study of Routing Protocols for Mobile Ad Hoc=20 > >> >> >> Networks T. Clausen, P. Jacquet et L. Viennot Med-hoc-Net,=20 > >> >> >> 2002 > >> >> >> > >> >> >> > >> >> >> http://gyroweb.inria.fr/~viennot/postscripts/medhocnet2002sim > >> >> >> .ps.gz > >> >> >> > >> >> >> It gives the shortest path to OrigNode in hop count, but the > >> number of > >> >> >> retransmissions may be important and exceed the network size > >> (can be > >> >> >> quadratic in the network size per RREQ). > >> >> >> > >> >> >> I wonder if one could also add other metrics than simply hop count. > >> >> For > >> >> >> example RREQ could seek the path with average shortest delay=20 > >> >> >> by > >> adding > >> >> >> the last hop average link delay to the current weight carried = > >> >> >> by > >> the > >> >> >> RREQ. The RREQ would carry a bit indicating that average=20 > >> >> >> shortest > >> >> delay > >> >> >> is activated). Or the RREQ could look to the largest=20 > >> >> >> bandwidth > >> >> route (in > >> >> >> this case one take the minimum of the last hop bandwidth with = > >> >> >> the > >> >> weight > >> >> >> carried by the RREQ. > >> >> >> > >> >> >> Other metrics are possible (variance, etc). > >> >> >> > >> >> >> 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 > >> >> > > >> >> > > >> >> > >> > > >> > > >> > > > > > > _______________________________________________ > > manet mailing 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 Sat May 26 14:34: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 1Hs15G-00024j-EV; Sat, 26 May 2007 14:33:46 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Hs15E-00024b-7K for manet-confirm+ok@megatron.ietf.org; Sat, 26 May 2007 14:33:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hs15D-00024T-Tn for manet@ietf.org; Sat, 26 May 2007 14:33:43 -0400 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hs15B-0006ev-VT for manet@ietf.org; Sat, 26 May 2007 14:33:43 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1174091nzd for ; Sat, 26 May 2007 11:33: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:in-reply-to:mime-version:content-type:references; b=UhT1FXI8+v+8c0+hVz7bdjGszNNiUp1B+KQ6dPS0AmCFxn9jrbS9SpelapQEt2V9DIpoNBbFnxh2yloZrMWnUbAFsIEBxQ1H3i6C9CkkjWpHyrc1dSN83dVYiD5D/WhvB65BzAfqB2C7H+us5mUb0S6gjibkIbpivkjuXk+lqaY= 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=KK4Ps9dmrjTR81Yq5WfVZ6i6Ycx35xUzt1ZYizyll52i34lF9ACI2igpjFoQutwFwCQEPdUw/t47lhFjnSvyjqRPxwEX2uTA/EsBlUjVa1AQBw9PidU+LakRKVC3GEs4tYtkkevSI4Rtk6VB1OT2lQjvIZeXBv6iksa4w8xBZS0= Received: by 10.115.92.2 with SMTP id u2mr2040781wal.1180204420633; Sat, 26 May 2007 11:33:40 -0700 (PDT) Received: by 10.115.74.18 with HTTP; Sat, 26 May 2007 11:33:40 -0700 (PDT) Message-ID: <744aaa380705261133o404eb583y895f1a4f712717c8@mail.gmail.com> Date: Sat, 26 May 2007 20:33:40 +0200 From: "gmarfia@cs.ucla.edu" To: manet@ietf.org In-Reply-To: <744aaa380705261120p604b9efbna939245ee49bdd18@mail.gmail.com> MIME-Version: 1.0 References: <744aaa380705261120p604b9efbna939245ee49bdd18@mail.gmail.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Subject: [manet] Deadline Extension, June 10 - CFP: International Workshop on Mobile Vehicular Networks (MoVeNet 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="===============0387888567==" Errors-To: manet-bounces@ietf.org --===============0387888567== Content-Type: multipart/alternative; boundary="----=_Part_151534_1439726.1180204420575" ------=_Part_151534_1439726.1180204420575 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry for the duplicated copies of this CFP you may receive. ======================================================== International Workshop on Mobile Vehicular Networks (MoVeNet 2007) October 12, 2007, Pisa, Italy Co-Located with IEEE MASS 2007 IIT Institute c/o CNR Research Area Via G. Moruzzi, 1 56124 PISA - Italy Website - http://movenet.cs.ucla.edu EXTENDED DEADLINE: JUNE 10 ========================================================= THEME AND SCOPE In the last few years an enormous effort has been made by researches in both industry and academia aimed at creating highly scalable, high performance, secure and reliable vehicular networks (VANET) technologies. These new vehicular systems will enable roadside safety and homelands security as well as a broad range of entertainment environmental, and social applications. The aim of this workshop is to foster interactions among researchers from industry and academia on the state of the art as well the work in progress on wireless vehicular ad hoc networking (VANET) technologies. The focus is network protocols, and emerging communication standards as well as entertainment, safety, ITS, and commercial applications enabled by a vehicle-to-infrastructure (V2I) and vehicle-to-vehicle (V2V) wireless communication technology. Such technology should meet the QOS requirements of diverse applications and should permit self-organization with a minimal user configuration. Authors are invited to submit papers presenting new research related to the theory or practice of VANET. All submissions must describe original research, not published or currently under review for another conference or journal. Areas of interest include, but are not limited to: - Emerging applications such as content distribution, infotainment, Internet access, etc. - Implementation, testbeds, and field tests of VANET systems - Vehicular network architectures and protocols - Vehicular network performance modeling and analysis - Vehicular network medium access control and routing protocols - Intelligent Transportation Systems (ITS) - Challenges of V2V, V2I, and I2V wireless communication - Security, privacy issues in VANET and trustworthy networking - Use of wireless technology within cars - Emerging inter/intra-vehicle and infrastructure-to-vehicle wireless communication technologies - Incentives, cooperation, and reputation systems - Quality of Services (QoS) provisioning in wireless-enabled ITS systems - Traffic management, vehicle control, and safety related applications for ITS systems - Networking and information services for users on the roads - Cross-layer design and optimization for vehicular ad hoc networks - Mobility management - Potential modifications needed to improve the DSRC standard - Propagation issues PAPER SUBMISSIONS We encourage researchers from industry and academia to submit original works (reported results should not be under consideration in any other journal or conference). All submissions must be full papers in .pdf or .ps format. Submitted papers must be uploaded through EDAS ( http://www.edas.info/newPaper.php?c=5592) by June 10, 2007, and must not exceed eight (8) single-spaced, two-column pages using at least 11 point size fonts on 8.5 x 11 inch pages (standard IEEE conference format). However, please be aware that final (accepted) papers will be limited to six (6) pages. Accepted papers will be published in the IEEE MASS proceedings and appear in the IEEE Digital Library. REGISTRATION POLICY At least one author of each accepted paper must register for the conference at the full conference rate. The participation to MASS workshops is free for all the MASS registrants and do not requires and additional registration. IMPORTANT DATES - Submission Due: Extented to June 10, 2007 - Acceptance Notification: July 15, 2007 - Final Manuscript Due: August 10, 2007 - Workshop: October 12, 2007 ORGANIZATION General Chairs: - Mario Gerla, UCLA, USA - Adam Wolisz, Technical University of Berlin, Germany Steering Committee (tentative): - Mario Gerla, UCLA, USA - Adam Wolisz, Technical University of Berlin, Germany - Kenichi Mase, Niigata University, Japan - Victor Bahl, Microsoft Research, USA - Ray Chandaury, Rutgers University, USA Technical Program Chairs: - Michela Meo, Politecnico di Torino, Italy - Kenichi Mase, University of Niigata, Japan - Giovanni Pau, UCLA, USA Publicity Chairs: - Gustavo Marfia, UCLA, USA - Stefano Ferretti, University of Bologna, Italy Web Chair: - Claudio E. Palazzi, University of Bologna, Italy CONTACTS - Mario Gerla: gerla@cs.ucla.edu - Adam Wolisz: awo@ieee.org - Michela Meo: michela.meo@polito.it - Kenichi Mase: mase@ie.niigata-u.ac.jp - Giovanni Pau: gpau@cs.ucla.edu Gustavo Marfia UCLA CVeT Lab @ NRL http://vehicular.cs.ucla.edu http://www.cs.ucla.edu/NRL ------=_Part_151534_1439726.1180204420575 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry for the duplicated copies of this CFP you may receive.


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

             International Workshop on Mobile Vehicular Networks
                                (MoVeNet 2007)

                        October 12, 2007, Pisa, Italy
                       Co-Located with  IEEE MASS 2007
                                IIT Institute
                             c/o CNR Research Area
                      Via G. Moruzzi, 1 56124 PISA - Italy

                     Website - http://movenet.cs.ucla.edu
                    
                     EXTENDED DEADLINE: JUNE 10

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


THEME AND SCOPE

In the last few years an enormous effort has been made by researches in both
industry and academia aimed at creating highly scalable, high performance,
secure and reliable vehicular networks (VANET) technologies. These new
vehicular
systems will enable roadside safety and homelands security as well as a broad
range of entertainment environmental, and social applications.

The aim of this workshop is to foster interactions among researchers from
industry and academia on the state of the art as well the work in progress on
wireless vehicular ad hoc networking (VANET) technologies. The focus is network
protocols, and emerging communication standards as well as entertainment,
safety, ITS, and commercial applications enabled by a vehicle-to-infrastructure
(V2I) and vehicle-to-vehicle (V2V) wireless communication technology. Such
technology should meet the QOS requirements of diverse applications and should
permit self-organization with a minimal user configuration.

Authors are invited to submit papers presenting new research related to the
theory or practice of VANET. All submissions must describe original research,
not published or currently under review for another conference or
journal. Areas
of interest include, but are not limited to:
- Emerging applications such as content distribution, infotainment, Internet
access, etc.
- Implementation, testbeds, and field tests of VANET systems
- Vehicular network architectures and protocols
- Vehicular network performance modeling and analysis
- Vehicular network medium access control and routing protocols
- Intelligent Transportation Systems (ITS)
- Challenges of V2V, V2I, and I2V wireless communication
- Security, privacy issues in VANET and trustworthy networking
- Use of wireless technology within cars
- Emerging inter/intra-vehicle and infrastructure-to-vehicle wireless
communication technologies
- Incentives, cooperation, and reputation systems
- Quality of Services (QoS) provisioning in wireless-enabled ITS systems
- Traffic management, vehicle control, and safety related applications for ITS
systems
- Networking and information services for users on the roads
- Cross-layer design and optimization for vehicular ad hoc networks
- Mobility management
- Potential modifications needed to improve the DSRC standard
- Propagation issues



PAPER SUBMISSIONS

We encourage researchers from industry and academia to submit original works
(reported results should not be under consideration in any other journal or
conference). All submissions must be full papers in .pdf or .ps format.
Submitted papers must be uploaded through EDAS
( http://www.edas.info/newPaper.php?c=5592) by June 10, 2007, and must not exceed
eight (8) single-spaced, two-column pages using at least 11 point size fonts on
8.5 x 11 inch pages (standard IEEE conference format). However, please be aware
that final (accepted) papers will be limited to six (6) pages. Accepted papers
will be published in the IEEE MASS proceedings and appear in the IEEE Digital
Library.




REGISTRATION POLICY

At least one author of each accepted paper must register for the conference at
the full conference rate. The participation to MASS workshops is free for all
the MASS registrants and do not requires and additional registration.



IMPORTANT DATES

- Submission Due: Extented to June 10, 2007
- Acceptance Notification: July 15, 2007
- Final Manuscript Due: August 10, 2007
- Workshop: October 12, 2007



ORGANIZATION

General Chairs:
- Mario Gerla, UCLA, USA
- Adam Wolisz, Technical University of Berlin, Germany

Steering Committee (tentative):
- Mario Gerla, UCLA, USA
- Adam Wolisz, Technical University of Berlin, Germany
- Kenichi Mase, Niigata University, Japan
- Victor Bahl, Microsoft Research, USA
- Ray Chandaury, Rutgers University, USA

Technical Program Chairs:
- Michela Meo, Politecnico di Torino, Italy
- Kenichi Mase, University of Niigata, Japan
- Giovanni Pau, UCLA, USA

Publicity Chairs:
- Gustavo Marfia, UCLA, USA
- Stefano Ferretti, University of Bologna, Italy

Web Chair:
- Claudio E. Palazzi, University of Bologna, Italy


CONTACTS

- Mario Gerla: gerla@cs.ucla.edu
- Adam Wolisz: awo@ieee.org
- Michela Meo: michela.meo@polito.it
- Kenichi Mase: mase@ie.niigata-u.ac.jp
- Giovanni Pau: gpau@cs.ucla.edu

Gustavo Marfia
UCLA
CVeT Lab @ NRL
http://vehicular.cs.ucla.edu
http://www.cs.ucla.edu/NRL
------=_Part_151534_1439726.1180204420575-- --===============0387888567== 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 --===============0387888567==-- From manet-bounces@ietf.org Sun May 27 05:15: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 1HsEpz-00034i-K8; Sun, 27 May 2007 05:14:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HsEpx-00034d-7L for manet-confirm+ok@megatron.ietf.org; Sun, 27 May 2007 05:14:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsEpw-00034V-Tp for manet@ietf.org; Sun, 27 May 2007 05:14:52 -0400 Received: from smtp.rennes.supelec.fr ([193.54.192.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsEpv-0008B9-Hg for manet@ietf.org; Sun, 27 May 2007 05:14:52 -0400 Received: from arkoon.ssir.rennes.supelec.fr (smtp.rennes.supelec.fr [127.0.0.1]) by smtp.rennes.supelec.fr (8.13.1/8.13.1) with ESMTP id l4R9QhRs023362 for ; Sun, 27 May 2007 11:26:43 +0200 Received: (from uucp@localhost) by arkoon.ssir.rennes.supelec.fr id l4R9EohZ008096 for ; Sun, 27 May 2007 11:14:50 +0200 Received: from A by B ; Sun, 27 May 2007 09:14:44 +0000 Received: from A by B ; Sun, 27 May 2007 11:17:13 +0200 (CEST) Message-ID: <46594C0F.8090209@rennes.supelec.fr> Date: Sun, 27 May 2007 11:14:55 +0200 From: Adnane asmaa User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: "'manet'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [manet] problems in OLSR patch of 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: , Errors-To: manet-bounces@ietf.org Hi i use the OLSR patch of glomosim, and i found some problems in the calculation of two hop neighbor set, if the 2 hop neighbor exists in the two hop neighbor set, node will not verify if it is advertised by the same 1 hop neighbor , SO it will not be added even if it is reachable via another 1-hop neighbor. the solution is to add this condition *two_tmp->oneHopNeighborPtr->oneHopNeighborAddr ==originatorAddress * in int RoutingOlsrPopulatingTwoHopNeighborSet(GlomoNode *node, ToPopulatingTwoHopNeighborSet *toTwoNeiSet, NODE_ADDR originatorAddress, unsigned int originatorWillingness) .... two_tmp = olsr->TwoHopNeighborSet; while(two_tmp != NULL){ if(two_tmp->twoHopNeighborAddr == tmp->nodeAddr &&* two_tmp->oneHopNeighborPtr->oneHopNeighborAddr ==originatorAddress*){ break; } two_prev = two_tmp; two_tmp = two_tmp->next; } ........ There is also a problem with the mpr selection, for example: a node can select 2 mpr even if one provide reachability to all two hop neighbors ??? Asmaa _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon May 28 10:32: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 1HsgGD-0006Se-VP; Mon, 28 May 2007 10:31:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HsgG1-0006AZ-R1 for manet-confirm+ok@megatron.ietf.org; Mon, 28 May 2007 10:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsgG1-00069T-64 for manet@ietf.org; Mon, 28 May 2007 10:31:37 -0400 Received: from criges14.insa-lyon.fr ([134.214.76.242] helo=smtp.insa-lyon.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsgG0-00080y-Nc for manet@ietf.org; Mon, 28 May 2007 10:31:37 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.insa-lyon.fr (Postfix) with ESMTP id 09791F318C for ; Mon, 28 May 2007 16:31:34 +0200 (CEST) X-Virus-Scanned: SMTP at INSA-LYON Received: from smtp.insa-lyon.fr ([127.0.0.1]) by localhost (criges14.insa-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9iidT49VIXp for ; Mon, 28 May 2007 16:31:33 +0200 (CEST) Received: from [132.207.169.229] (unknown [132.207.169.229]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fvalois) by smtp.insa-lyon.fr (Postfix) with ESMTP id 99130F3134 for ; Mon, 28 May 2007 16:31:33 +0200 (CEST) Message-ID: <465AE7CB.8010806@insa-lyon.fr> Date: Mon, 28 May 2007 10:31:39 -0400 From: Fabrice Valois User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [manet] WiMob'07: Special Session on Mobility Models -- EXTENDED DEALINE: June 6, 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 (*** NEW EXTENDED DEADLINE ***) (*** MANUSCRIPT SUBMISSION DUE: June 6, 2007 ***) CFP for IEEE WiMOB=922007 Special Session on Mobility Models for Mobile Ad hoc Networks, Mesh networks, Wireless networks and NEMO networks The session is a part of the 3rd IEEE International Conference on Wireless and Mobile Computing, Networking and Communications =93WiMob 2007=94 Accepted papers will be published as regular paper in the proceedings of WiMob 2007 and will be available in IEEE Xplore. http://www.gel.usherbrooke.ca/WiMob2007/, which will take place in Crowne Plaza Hotel, White Plains, New York, USA, from October 8-10, 2007. Motivations: Because WiMob'07 conference is focused on wireless networks and because the performances of wireless networks are strongly linked to the mobility models used, we propose a special session focusing only on mobility models. This session is focused on these kind of wireless networks: - MANET: Mobile ad hoc networks where whole the topology is dynamic - Mesh networks and classical wireless networks offering an infrastructure topologies allowing fixed and mobile Internet for the end user. - Network Mobility (NEMO) networks offering new kind of dynamic topology where not only the user is mobile but also the network These kind of networks should deal with mobility: user mobility, group mobility, etc. But, what is really mobility? how mobility influences the performances? how to define new mobility models? etc. Scope of the Contributions for Mobility Models in the case of MANET, Mesh Networks, Wireless Networks and NEMO (include but are not limited to the following): - Performance evaluation of mobility models - New mobility models to mimic particular behavior - Theoretical aspects of mobility models - Theoretical frameworks for mobility - Mobility models based on realistic traces - Mobility management - Networking protocols and mobility models - Tools for mobility models (generators, integrators to simulators,..) - 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 format. The preferred submission format is PDF. Session Chair: Fabrice Valois, INSA Lyon, France Session Co-chair: Thomas Noel, University of Strasbourg, France Submissions should be sent attached by email to the session chairs at: fabrice.valois@insa-lyon.fr Thomas.Noel@dpt-info.u-strasbg.fr Important Dates : Manuscript Submission Due: June 6, 2007 Acceptance Notification: June 15, 2007 Final Manuscript Due: June 22, 2007 --=20 Fabrice Valois, Associate Professor INRIA ARES / CITI - INSA Lyon, Telecommunications Dpt. Web: http://fvalois.insa-lyon.fr/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue May 29 15:52: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 1Ht7jY-0003b3-0U; Tue, 29 May 2007 15:51:56 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ht7iG-0001SM-7H for manet-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 15:50:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7iD-0001KW-0n; Tue, 29 May 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ht7iC-0006rk-Es; Tue, 29 May 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5A8502ACC8; Tue, 29 May 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ht7hi-0007Lw-0H; Tue, 29 May 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: Tue, 29 May 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-iana-04.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 : Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group Author(s) : I. Chakeres Filename : draft-ietf-manet-iana-04.txt Pages : 6 Date : 2007-5-29 This document enumerates IANA allocations for use by MANET WG protocols. Specifically, a UDP port and two link-local multicast group addresses (IPv4 & IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-04.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-04.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-04.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-5-29113203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-iana-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-iana-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-29113203.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 May 29 18:40: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 1HtAMa-0004iK-JR; Tue, 29 May 2007 18:40:24 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HtAMY-0004i4-Fq for manet-confirm+ok@megatron.ietf.org; Tue, 29 May 2007 18:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtAMY-0004hw-6I for manet@ietf.org; Tue, 29 May 2007 18:40:22 -0400 Received: from faui45.informatik.uni-erlangen.de ([131.188.34.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtAMV-0002xx-8i for manet@ietf.org; Tue, 29 May 2007 18:40:22 -0400 Received: from faui7s0.informatik.uni-erlangen.de (faui7s0.informatik.uni-erlangen.de [131.188.37.210]) by faui45.informatik.uni-erlangen.de (Postfix) with ESMTP id 32AA04C3C for ; Wed, 30 May 2007 00:40:17 +0200 (MEST) Received: from [192.168.1.104] (port-87-234-153-219.dynamic.qsc.de [87.234.153.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by faui7s0.informatik.uni-erlangen.de (Postfix) with ESMTP id 01938B0038 for ; Wed, 30 May 2007 00:40:16 +0200 (CEST) Message-ID: <465CABD0.7030800@informatik.uni-erlangen.de> Date: Wed, 30 May 2007 00:40:16 +0200 From: Christoph Sommer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070504 Thunderbird/2.0.0.0 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [manet] New DYMO model for OMNeT++ 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 everybody, Just a short announcement: We have implemented a model of the DYMO routing protocol as a module of the OMNeT++ simulation environment and its INET Framework. Source code (along with short examples and documentation) is available from and can be distributed under the terms of the GPL. If you are working with OMNeT++, feel free to give it a spin. I'll be happy about any kind of feedback. Kind regards, Christoph _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 30 05:15: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 1HtKHU-0005bw-Tc; Wed, 30 May 2007 05:15:48 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HtKHT-0005bm-Ir for manet-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 05:15:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKHT-0005be-5T for manet@ietf.org; Wed, 30 May 2007 05:15:47 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtKHR-0001Om-Mw for manet@ietf.org; Wed, 30 May 2007 05:15:47 -0400 Received: by ug-out-1314.google.com with SMTP id j30so389317ugc for ; Wed, 30 May 2007 02:15: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=UNAbTqbzfSMQH3pIAukPwSdJWQY0lvxSI3LPKXfMqgaU1Le/9WlxcLi4FYJdIPn2utwxsmnHjXM15ngJHgrgw9rQyzIwipm8HAg4o5JOWNJpp8k8zZ+ry+UF5g0XpmCgoAZmnOEoYZCUYWJlvHVCjT4YjHYMvhpmj8f6qZWLkcA= 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=FF0ImQFQGdv00fDMyO82UKCyc2kyzIZbugXCOCsFi1H6ANvWcZs+TpGktnVYJ0mUgqRkKO7HYaH+lxM4KtNI5iDGmXIPXXbHhyPkgDSAaqfk2hR4jDToNhIGXj529uQ8E47ixB1gKmKH2b4+SHD/E9fKk4ZB6dajovTONbsTUSI= Received: by 10.78.142.14 with SMTP id p14mr2195833hud.1180516544831; Wed, 30 May 2007 02:15:44 -0700 (PDT) Received: by 10.78.45.10 with HTTP; Wed, 30 May 2007 02:15:44 -0700 (PDT) Message-ID: <374005f30705300215k6795518bw24a2dd45dfb47c2b@mail.gmail.com> Date: Wed, 30 May 2007 14:45:44 +0530 From: "Ian Chakeres" To: manet@ietf.org Subject: Re: [manet] I-D ACTION:draft-ietf-manet-iana-04.txt = WGLC continued 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: f60d0f7806b0c40781eee6b9cd0b2135 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 updated the ID based on the feedback I received; extremely minor changes. I believe this document is ready to go... If you have any comments please email me or the list. Ian On 5/30/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 : Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group > Author(s) : I. Chakeres > Filename : draft-ietf-manet-iana-04.txt > Pages : 6 > Date : 2007-5-29 > > This document enumerates IANA allocations for use by MANET WG > protocols. Specifically, a UDP port and two link-local multicast > group addresses (IPv4 & IPv6). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-04.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-04.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-04.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 Wed May 30 05:53: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 1HtKrn-0003Uz-9T; Wed, 30 May 2007 05:53:19 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HtKrk-0003Ut-8m for manet-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 05:53:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtKrj-0003Ul-SO for manet@ietf.org; Wed, 30 May 2007 05:53:15 -0400 Received: from bay0-omc3-s39.bay0.hotmail.com ([65.54.246.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtKrh-0008OS-Ho for manet@ietf.org; Wed, 30 May 2007 05:53:15 -0400 Received: from BAY106-W2 ([65.54.161.102]) by bay0-omc3-s39.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 30 May 2007 02:53:13 -0700 Message-ID: X-Originating-IP: [88.152.25.91] From: wael T. To: Date: Wed, 30 May 2007 12:53:13 +0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 May 2007 09:53:13.0169 (UTC) FILETIME=[566B5410:01C7A2A0] X-Spam-Score: 2.7 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [manet] need help with aodv-uu installation 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="===============0237921216==" Errors-To: manet-bounces@ietf.org --===============0237921216== Content-Type: multipart/alternative; boundary="_780aac9a-a81a-47a9-b17d-dbc793e103b6_" --_780aac9a-a81a-47a9-b17d-dbc793e103b6_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 8bit i already installed the ns-allinone-2.27 and i want to install aodv-uu-0.8 on it i have a problem with that when i write this thing > patch -p1 < aodv-uu/ns-2.27-aodv-uu-0.8.patch it tell me that there is no such directory or file name i followed the instruction exactly so please help me with any idea. _________________________________________________________________ Connect to the next generation of MSN Messenger  http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline --_780aac9a-a81a-47a9-b17d-dbc793e103b6_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: 8bit
i already installed the ns-allinone-2.27 and i want to install aodv-uu-0.8 on it i have a problem with that when i write
 
this thing
> patch -p1 < aodv-uu/ns-2.27-aodv-uu-0.8.patch
it tell me that there is no such directory or file name 
 
i followed the instruction exactly so please help me with any idea.

 


Connect to the next generation of MSN Messenger  Get it now! --_780aac9a-a81a-47a9-b17d-dbc793e103b6_-- --===============0237921216== 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 --===============0237921216==-- From manet-bounces@ietf.org Wed May 30 10:27: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 1HtP9A-0006xC-QY; Wed, 30 May 2007 10:27:32 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HtP98-0006x7-MP for manet-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 10:27:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtP98-0006wz-CO for manet@ietf.org; Wed, 30 May 2007 10:27:30 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtP97-0007pJ-OT for manet@ietf.org; Wed, 30 May 2007 10:27:30 -0400 Received: by an-out-0708.google.com with SMTP id c17so732078anc for ; Wed, 30 May 2007 07:27:28 -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=c8p8Ax5M3JNK7rHm6aS5xDGuZlNF0/nGHYvLG+j9Y0ndu8F2AVOLES/TfFiVVMMjjI3Hg8cboRfA1uqhDjn9gswRnXBm9vBm8ON7GY+1KjTkKJwPnRTsS1mN/HqBCX1+CjQL83U+/81V6LVcZR8JCypEqgQisj6q5i1WBFWbsRE= 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=oX9S5Se/ZlnBkqFaEGBpOs2Da6cdP7oFuB4tYxE4suNKRPXo/4xMRNV0yOAdbAfzOwMZo3+S0Yzgv1vNm29ieh1GNzVTpZs6Nq8VK++jKWcUuPnUETogoMVzszOpE/7TOL9vArhKok1uE+ftL57nY8jrrLNWFrKO3Ub7YlLpia8= Received: by 10.115.78.1 with SMTP id f1mr4007633wal.1180535248096; Wed, 30 May 2007 07:27:28 -0700 (PDT) Received: by 10.114.166.6 with HTTP; Wed, 30 May 2007 07:27:28 -0700 (PDT) Message-ID: <6f9cb4f10705300727t7b9ebea0sacdb87c851fc1f84@mail.gmail.com> Date: Wed, 30 May 2007 19:57:28 +0530 From: "shilpa sharma" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [manet] Fading calculation in JIST/SWANS 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="===============2055135736==" Errors-To: manet-bounces@ietf.org --===============2055135736== Content-Type: multipart/alternative; boundary="----=_Part_4675_2508430.1180535248050" ------=_Part_4675_2508430.1180535248050 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello everyone, 1. Im trying to calculate fading in bordercast simulation.. But is the compute function in Fading.java acutally dependent on any external parameter?? The function uses variance which is Rayleigh distribution.. But else it is using some randomly generated number.. Thats why it will give different fading values.. But then what is its use when we run a simulation and want to know the fading value?? We are not passing any value into it.. So how will we know actually how much fading is taking place?? 2. Also, similarly i am calculating Pathloss..What meaning does Pathloss have in JIST/SWANS context?? I sent the sender and receiver node locations as well as their radio information in the compute funciton of Pathloss.. For a distance of 834.1, pathloss comes out to be 108.36dbs.. What does this mean?? I have tried on google to find the formula of Pathloss which JIST/SWANS has used but could not find.. 3. I have another query regarding the stastics of NDP, IARP packets etc.. How are these calculated.. I tried to follow the flow of bordercast from RouteZRP.java to RouteZrpIerp.java.. But i m finding it too complicated to understand how NDP-packets-send.. etc.. are incremented.. Please can anyone help me out with these queries??? Shilpa. ------=_Part_4675_2508430.1180535248050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello everyone,
1. Im trying to calculate fading in bordercast simulation.. But is the compute function in Fading.java acutally dependent on any external parameter?? The function uses variance which is Rayleigh distribution.. But else it is using some randomly generated number..  Thats why it will give different fading values.. But then what is its use when we run a simulation and want to know the fading value?? We are not passing any value into it.. So how will we know actually how much fading is taking place??

2. Also, similarly i am calculating Pathloss..What meaning does Pathloss have in JIST/SWANS context?? I sent the sender and receiver node locations as well as their radio information in the compute funciton of Pathloss.. For a distance of 834.1, pathloss comes out to be 108.36dbs.. What does this mean?? I have tried on google to find the formula of Pathloss which JIST/SWANS has used but could not find..

3. I have another query regarding the stastics of NDP, IARP packets etc.. How are these calculated.. I tried to follow the flow of bordercast from RouteZRP.java to RouteZrpIerp.java.. But i m finding it too complicated to understand how NDP-packets-send.. etc..  are incremented..

Please can anyone help me out with these queries???

Shilpa.
------=_Part_4675_2508430.1180535248050-- --===============2055135736== 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 --===============2055135736==-- From manet-bounces@ietf.org Wed May 30 14:22: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 1HtSoX-0006M3-9c; Wed, 30 May 2007 14:22:29 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HtSoU-0006Ly-Rj for manet-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 14:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtSoU-0006Lq-I7 for manet@ietf.org; Wed, 30 May 2007 14:22:26 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtSoT-0004RX-BR for manet@ietf.org; Wed, 30 May 2007 14:22:26 -0400 Received: by nz-out-0506.google.com with SMTP id z31so2108676nzd for ; Wed, 30 May 2007 11:22: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:mime-version:content-type; b=rzISVhzduvYk/e9T2sDugDdzEG12BUEMVy14Vd2OQZLAh7mwoV45xnnbAEj7B0iidMDee17sj3XEIhBMrGGazBlWcQizYRRfF8+DrQJ9XkfHWDq6FIXWVkS9oLKNLx+jM3TmbsrhgQSxEgoNrzlCYw0/AvoqBE8hK/iYp30xj/w= 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=ZvU444pqU5z1V8VmWonr3PViX5k8I0TDVYJXC4sRu4rnKCAMXeG0V1h6v5W9cf49ss4BPUV3GQ4fGU3qPA7+jC24TkUJ2ZXJcca2nHoyH9gqRE7LmLhcRWmXXes+wYymFu/gmkPs2Ze1kd/DKS12xBkgqpgV4Ho7yY4YalvU+Og= Received: by 10.114.125.2 with SMTP id x2mr4135140wac.1180549344509; Wed, 30 May 2007 11:22:24 -0700 (PDT) Received: by 10.114.166.6 with HTTP; Wed, 30 May 2007 11:22:24 -0700 (PDT) Message-ID: <6f9cb4f10705301122h2bee6d2fs540cc7a43bb0b67d@mail.gmail.com> Date: Wed, 30 May 2007 23:52:24 +0530 From: "shilpa sharma" To: manet@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [manet] correction regarding Fading calculation JIST/SWANS query 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="===============1820411562==" Errors-To: manet-bounces@ietf.org --===============1820411562== Content-Type: multipart/alternative; boundary="----=_Part_8817_28501832.1180549344459" ------=_Part_8817_28501832.1180549344459 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello to all, I would like to make a correction regarding my query related to Fading Calculation in JIST/SWANS as well as Pathloss.. I had googled the formula for fading not for pathloss.. but hvnt been able to find it.. I have now understood the Pathloss calculation.. Cud anyone plz help me with the other two queries?? Shilpa. ------=_Part_8817_28501832.1180549344459 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello to all,
I would like to make a correction regarding my query related to Fading Calculation in JIST/SWANS as well as Pathloss.. I had googled the formula for fading not for pathloss.. but hvnt been able to find it.. I have now understood the Pathloss calculation.. Cud anyone plz help me with the other two queries??
Shilpa.
------=_Part_8817_28501832.1180549344459-- --===============1820411562== 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 --===============1820411562==-- From manet-bounces@ietf.org Wed May 30 16:23: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 1HtUhw-0000ip-OF; Wed, 30 May 2007 16:23:49 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HtUhu-0000ie-Hf for manet-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 16:23:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtUhu-0000iW-7P for manet@ietf.org; Wed, 30 May 2007 16:23:46 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtUhq-0001gJ-T7 for manet@ietf.org; Wed, 30 May 2007 16:23:46 -0400 Received: by py-out-1112.google.com with SMTP id a25so273973pyi for ; Wed, 30 May 2007 13: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:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=tbTc0XFEzhpRzR+JElk17xL9zx82O4V4koJo5XfkPBn+EwupzBm8o+t6QHH+0cqSEeVHpCmsN/k6H5pOdQAmHhTta5XdFpSatQVDFZ5bywqQjAaTy68kESFZueeKaJewKFLqeOgIkd0a89RBxpVgRnq6jdqoc1wZOGhL7ESHKOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=mIP1FZpQ/7gAMPEY5J4TUrouPA4t8xAC6glWBE8xUTYogW2bCA7Z/B06yjpWuj2jXz3C/07gsPD2E0+d2EPQt3z12PkjPFocYb2a6ZB7dI+d7xeNwTWHxlA2RUQWaTkcaKgki01k3xPnmsxeBGjFmxX33LjYpmsZixpnHedlq0w= Received: by 10.35.64.8 with SMTP id r8mr9617736pyk.1180556621973; Wed, 30 May 2007 13:23:41 -0700 (PDT) Received: by 10.35.102.13 with HTTP; Wed, 30 May 2007 13:23:41 -0700 (PDT) Message-ID: <83d5521f0705301323l444c7f8ci3ec304a696ef9118@mail.gmail.com> Date: Wed, 30 May 2007 16:23:41 -0400 From: "Zheng Jun" To: itc@comsoc.org, manet@ietf.org, multicomm@comsoc.org, mycolleagues@grid.lrg.ufsc.br, tccc@cs.columbia.edu MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 8cd799da914b52a3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: Subject: [manet] Call for papers: 2007 International Workshop on Wireless Ad Hoc, Mesh and Sensor Networks (WAMSNet-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: , Errors-To: manet-bounces@ietf.org We apologize in advance if you receive multiple copies of this CFP ================================================= Call for Papers 2007 International Workshop on Wireless Ad Hoc, Mesh and Sensor Networks (WAMSNet-07) http://eniac.cs.qc.edu/jzheng/WAMSNet07.html In conjunction with the 2007 International Conference on Future Generation Communication and Networking (FGCN 2007) http://www.sersc.org/FGCN2007/ Lotte Hotel Jeju, Jeju-Island, Korea, Dec. 6-8, 2007 Themes: The 2007 International Workshop on Wireless Ad Hoc, Mesh and Sensor Networks (WAMSNet-07) will be held in conjunction with the 2007 International Conference on Future Generation Communication Networking (FGCN 2007). This workshop is intended to provide a high-quality forum for researchers and practitioners to present their latest theoretical and practical work in this rapidly-changing area. Original papers are solicited in all aspects of Wireless Ad Hoc, Mesh and Sensor Networks. Topics: Topics of interest include, but not limited to, the following: * Network architectures and protocols * Media access control * Routing, multicasting, and broadcasting * Scheduling and load balancing * Congestion and admission control * Topology control * Mobility and location management * Quality of service (QoS) issues * Energy-efficient protocols * Cross-layer designs * Network management * Security and privacy * Applications and systems * Pervasive and wearable computing * Network planning and deployment * Performance evaluation, modeling and simulation * Fault resilience and fault isolation * Data management issues, query processing and data delivery Paper Submission: Authors are invited to submit original papers: They must not substantially duplicate work that any of the authors have published elsewhere or have submitted in parallel to any other conferences that have proceedings. All accepted papers in WAMSNet-07 will be included in the conference proceedings published by IEEE Computer Society(IEEE CS), included in IEEEXplore database and indexed by EI. Papers must be prepared with only PDF. Please use IEEE CS paper format (See website to download the template in MSWORD or LaTeX). Submissions must not exceed 8 pages, including tables, references and figures, with only PDF. Submission of a paper implies that should the paper be accepted, at least one of the authors will register and present the paper at the workshop. Paper should be submitted through paper submission system. Important Dates: Submission date: July 23, 2007 Acceptance notification: August 31, 2007 Camera-ready due: September 10, 2007 General Co-Chairs: Jun Zheng, The City University of New York, USA (junzhengieeeorg) Yan Zhang, Simula Research Laboratory, Norway (yanzhangieeeorg) Program Co-Chairs: Jinhua Guo, University of Michigan at Dearborn, USA (jinhuaumichedu) Bin Lu, West Chester University of PA, USA (bluwcupaedu) Technical Program Committee: To be announced _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed May 30 18:50: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 1HtWzg-0005Rf-5n; Wed, 30 May 2007 18:50:16 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HtWzV-0005Gn-48 for manet-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 18:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtWzU-0005GK-MB; Wed, 30 May 2007 18: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 1HtWzU-00041G-7D; Wed, 30 May 2007 18:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 3701026EC6; Wed, 30 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HtWzS-0002Sy-1x; Wed, 30 May 2007 18: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: Wed, 30 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: manet@ietf.org Subject: [manet] I-D ACTION:draft-ietf-manet-nhdp-03.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 Neighborhood Discovery Protocol (NHDP) Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-nhdp-03.txt Pages : 55 Date : 2007-5-30 This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-03.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-nhdp-03.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-nhdp-03.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-5-30155326.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-nhdp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-nhdp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-30155326.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 Wed May 30 20:25: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 1HtYTh-0002Tf-Ur; Wed, 30 May 2007 20:25:22 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HtYTg-0002TX-95 for manet-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 20:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtYTf-0002TK-VZ for manet@ietf.org; Wed, 30 May 2007 20:25:19 -0400 Received: from [202.54.124.130] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HtYTe-0005CB-4u for manet@ietf.org; Wed, 30 May 2007 20:25:19 -0400 Received: (qmail 20566 invoked by uid 510); 31 May 2007 00:19:21 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=B8xTlFiMcsYUazcGwf30a5J8v8TiVBBP6w625EcBqjck5VwkaESHvDhCwI4eQ/XoucoZ2VJRMseBs3Jiutl1KjbNzBNzJaHbFmJoPx6Eq0ISXPOd8U0+h+fT/xx7o/wHfuwppxpOifz9Gd3gYY86Tv1bVn54+iAtt75ORJdMpPQ= ; Date: 31 May 2007 00:19:21 -0000 Message-ID: <20070531001921.20562.qmail@webmail31.rediffmail.com> Received: from unknown (82.32.80.194) by rediffmail.com via HTTP; 31 may 2007 00:19:21 -0000 MIME-Version: 1.0 From: "harpreet" To: manet@ietf.org Cc: manet-request@ietf.org X-Spam-Score: 2.5 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [manet] help regarding manet programming. X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: harpreet List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0167488118==" Errors-To: manet-bounces@ietf.org This is a multipart mime message --===============0167488118== Content-type: multipart/alternative; boundary="Next_1180570761---0-202.54.124.130-20560" This is a multipart mime message --Next_1180570761---0-202.54.124.130-20560 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline =A0=0A=0Ahi=0Ai am looking for opent v 11.5 or ns2 programming for manet. = if anybody have this or knows from where i can have this. please send me de= tails. i need this urgently for my project work.. =0Athanks for help=0A=0Ah= arpreet singh --Next_1180570761---0-202.54.124.130-20560 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0A 
=0A
=0Ahi
=0Ai am looking for opent v 11.5 or ns2 pr= ogramming for manet. if anybody have this or knows from where i can have th= is. please send me details. i need this urgently for my project work..
= =0Athanks for help=0A

=0A=0A=0Aharpreet singh

=0A
3D'This
--Next_1180570761---0-202.54.124.130-20560-- --===============0167488118== 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 --===============0167488118==-- From manet-bounces@ietf.org Thu May 31 05:59: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 1HthQr-0002ru-Ow; Thu, 31 May 2007 05:59:01 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1HthQp-0002r8-9F for manet-confirm+ok@megatron.ietf.org; Thu, 31 May 2007 05:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HthQo-0002r0-S9 for manet@ietf.org; Thu, 31 May 2007 05:58:58 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HthQn-0007Da-Hu for manet@ietf.org; Thu, 31 May 2007 05:58:58 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1180605536!14849728!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 30245 invoked from network); 31 May 2007 09:58:56 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-2.tower-119.messagelabs.com with SMTP; 31 May 2007 09:58:56 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l4V9wqGE013482 for ; Thu, 31 May 2007 02:58:56 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l4V9wphA012859 for ; Thu, 31 May 2007 04:58:52 -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 l4V9wouQ012802 for ; Thu, 31 May 2007 04:58:50 -0500 (CDT) Message-ID: <465E9C53.5030404@gmail.com> Date: Thu, 31 May 2007 11:58:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: manet@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-0, 30/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [manet] Re: I-D ACTION:draft-ietf-manet-nhdp-03.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 Hi, thanks for submitting this draft. I have a very simple question that may look naive, sorry if I miss something big. What is the relationship between 1-hop neighbor discovery part of NHDP and Neighbor Discovery ND protocol RFC2461? By quick reading of the draft I think the two protocols have very similar - if not the same - requirements. NHDP: > This protocol uses an exchange of HELLO messages in order that each > node can determine the presence and status of its 1-hop and symmetric > 2-hop neighbors. But ND exchanges NS/NA/RS/RA messages also in order for each node to determine the presence and status of its 1-hop neighbor. 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 Neighborhood Discovery Protocol (NHDP) Author(s) : T. > Clausen, et al. Filename : draft-ietf-manet-nhdp-03.txt Pages : 55 > Date : 2007-5-30 This document describes a 1-hop and symmetric > 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc > networks (MANETs). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-03.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-nhdp-03.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-nhdp-03.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