From delta@net.ie.niigata-u.ac.jp Wed Jul 1 02:06:28 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09E063A6CB3 for ; Wed, 1 Jul 2009 02:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88JLhwHsUaEo for ; Wed, 1 Jul 2009 02:06:27 -0700 (PDT) Received: from mxav01.cc.niigata-u.ac.jp (mxav01.cc.niigata-u.ac.jp [133.35.17.129]) by core3.amsl.com (Postfix) with ESMTP id E384428C101 for ; Wed, 1 Jul 2009 02:06:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 03BAE4F421E; Wed, 1 Jul 2009 18:06:16 +0900 (JST) Received: from ms01.net.ie.niigata-u.ac.jp (ms01.net.ie.niigata-u.ac.jp [133.35.156.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with ESMTP id C80184F41E0; Wed, 1 Jul 2009 18:06:10 +0900 (JST) Received: from localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id 302442EF4D; Wed, 1 Jul 2009 18:06:05 +0900 (JST) X-Virus-Scanned: amavisd-new at net.ie.niigata-u.ac.jp Received: from ms01.net.ie.niigata-u.ac.jp ([127.0.0.1]) by localhost (ms01.net.ie.niigata-u.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGNVTVajblee; Wed, 1 Jul 2009 18:06:05 +0900 (JST) Received: from msq82.net.ie.niigata-u.ac.jp (ms05.net.ie.niigata-u.ac.jp [133.35.156.5]) by ms01.net.ie.niigata-u.ac.jp (Postfix) with ESMTP id DF1802EF4C; Wed, 1 Jul 2009 18:06:04 +0900 (JST) Message-ID: <4A4B2702.8060701@net.ie.niigata-u.ac.jp> Date: Wed, 01 Jul 2009 18:06:10 +0900 From: Lee Speakman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2 MIME-Version: 1.0 To: jacquet References: <4A1BB562.7000104@net.ie.niigata-u.ac.jp> <4A1FE2EC.5060406@inria.fr> <4A25027E.3070503@net.ie.niigata-u.ac.jp> <4A28E99A.6050905@net.ie.niigata-u.ac.jp> <4A29152A.4010007@inria.fr> <4A30D67A.7050702@net.ie.niigata-u.ac.jp> <25c114b90906110314p9bae335j4bbb1a058a98cd42@mail.gmail.com> <4A31F6F8.4000101@net.ie.niigata-u.ac.jp> <4A325647.1040108@inria.fr> In-Reply-To: <4A325647.1040108@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: mase , "manet@ietf.org" Subject: Re: [manet] New draft: "Routing Loop Issue in Mobile Ad Hoc Networks (MANETs)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 09:06:28 -0000 Dear Philippe, regarding the use of Instant Hellos and Instant TCs, with your consideration we are more closely looking at the effects of our implementation of Instant Hello / TC on LLN trigger to see if it is functioning as it supposed to. Thanks for your input. Cheers, Lee -S- PS. In relation to the looping issue in general in OLSRv2, I'll be available at the 75th IETF meeting in Stockholm to discuss it. (2009年06月12日 22:21), jacquet さんは書きました: > Dear Lee, > > It is still not clear if you properly simulate the instant TC. Instant > hellos can only push loops one hop away the failed link but would not > suppress them (unless the source is one hop away). What surprise me is > this 10% loop reduction means 170 packet transmission less, and you > assume it is still smaller than the instant hello overhead. Do you > mean you attempt to send more than 170 instant hellos for the same LLN? > > I think you may have a MAC issue if the first packet loop blocks the > transmission of hellos. If this phenomenon is not a simulation > artefact (look strange anyhow) then Chris proposal to send instant TC > before clearing link in the local routing table may work well and > suppress transient loops. > > Loop Deduction mechanism would locally suppress loops but would not > increase delivery rate (since packets don't reach destination). To > make it working you must send the instant TC anyhow. > > Best regards, > Philippe > > > Lee Speakman a écrit : >> Dear Phillipe and Ulrich, >> >> >> ... >> >> >> In more recent simulation, with the same parameters as given in our >> published work, we measure the number of nodes that receive each >> broadcast packet (control packet). >> >> This is done for 60 nodes with a maximum mobility of 5m/s (random >> waypoint, random mobility between 0 and 5m/s). >> >> >> i. At modest loads, 8 applications (CBR, UDP), then we find that >> OLSRv2-LLN has a ~85% PDR (end-to-end delivery) with ~1700 looping >> packet observations on average per simulation. >> An Instant Hello on LLN gives no improvement in PDR and the number of >> loops is approximately the same. An Instant TC on LLN gives the same >> result. >> >> At almost no load, a control packet is on average received by 17.5 >> nodes (more in the center, less on the edges), but at a load of 8 >> apps this is down to just over 16 nodes. This is worse at the time a >> transient looping packet is existing. >> >> Disregarding Instant Hellos / TCs, we can get real improvements by >> simply using a Loop Detection mechanism and discarding the packets >> (Packet Discard), bringing the PDR up to ~94.5%, and better >> improvements by cutting the link over which a looping packet is >> detected (Link Cut), bringing the PDR up to ~96%. >> >> >> ii. At 12 application, where there are more loops, then we find that >> OLSRv2-LLN has a ~74% PDR with ~4300 looping packet observations on >> average per simulation. >> An Instant Hello on LLN gives about a 3% improvement in PDR (to ~77%) >> and the number of observed loops is ~3700. An Instant TC on LLN gives >> the same result. >> >> At almost no load, a control packet is on average received by 17.5 >> nodes (more in the center, less on the edges), but at a load of 12 >> apps this is down to less than 15 nodes. This is worse at the time a >> transient looping packet is existing. >> >> Again, using Packet Discard on Loop Detection brings the PDR up to >> ~92.5%, and with Link Cut on Loop Detection we get the PDR up to ~94%. >> >> >> Simply discarding the observed looping packets and the improvement >> that has on PDR shows the negative effects of looping packets on >> surrounding traffic. >> >> >> We have also looked at Instant Hellos and Instant TC on Loop >> Detection which shows some improvement; to 88% PDR (up 3%) for 8 apps >> (removing ~24% of loops), and to 79% PDR (up 4%) for 12 apps >> (removing ~19% if loops). This appears to become less effective at >> higher loads. The looping packet is not discarded nor is the link cut >> over which the packet loops, so on every node the looping packet >> passes an Instant Hello or TC is generated on Loop Detection. >> >> None of these Instant Hellos / TCs interrupted any of the periodic >> scheduling of the control packet broadcasts but were done "extra." >> >> >> Cheers, >> Lee -S- >> From obli.olsr@gmail.com Fri Jul 3 02:20:13 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9183A6DEC for ; Fri, 3 Jul 2009 02:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ia7f3f6ZIqB for ; Fri, 3 Jul 2009 02:20:13 -0700 (PDT) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id A8A883A6DF6 for ; Fri, 3 Jul 2009 02:20:12 -0700 (PDT) Received: by mail-ew0-f215.google.com with SMTP id 11so892335ewy.37 for ; Fri, 03 Jul 2009 02:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=uZXUSOZa6gjBAfzWVUm4DmZFEr6/KFw7UR/DtghNCuQ=; b=gcTVUGO+TozUS/iKSXix8eYEMuETZKuBhVJHn0oQM1kKEK8yVeTJBNfHvu4b5aOjel V5tQIsCaTBSZQceh9Dh0dih2agy73rwgoL4jal3kv2xGSDeod5+ocm/gUgnlYvkIjfag riuh08Z2CpSvgQWpQu5b18D2jXWJSb1d8h9jw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nNno70Rf3PxSQxUJ7DhvybhC4428hG7CeWHHheyvbRuom6F7uowqho17WO45QjBn50 oQwWfzfhKC7Z3TpXEpsWMDe9zgbZ1lRmLwnATUjkiWDeIbP3ibx1cgmWxjeyc/SD6kaH EcDxgm0Che9mD5+J4uxND8RLZ8QfZdvkUBB4A= MIME-Version: 1.0 Received: by 10.216.2.201 with SMTP id 51mr311312wef.17.1246612835953; Fri, 03 Jul 2009 02:20:35 -0700 (PDT) Date: Fri, 3 Jul 2009 11:20:35 +0200 Message-ID: <28f06f0b0907030220s69e63ec6mcaee6e6105a29c10@mail.gmail.com> From: =?ISO-8859-1?Q?Aur=E9lien_Ribon?= To: MANET group Content-Type: multipart/alternative; boundary=0016364c7cfb426e8e046dc9ab06 Subject: [manet] OLSR : Depth of the Topology Set ? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 09:20:13 -0000 --0016364c7cfb426e8e046dc9ab06 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, I am currently writing an hardware architecture of OLSR in VHDL, and as a consequence I can not use as many RAM blocks as I want to store the repositories' data. So, I need to know what is the worst case for each olsr repository. I am considering a network of 256 nodes with a maximum of 16 neighbours per node, and 3 interfaces per node. It is not really hard to see that as a result there should not be more than 16 entries in the MPR Set, 16 in the MPR Selector Set, etc. Actually, the only repository for which I can not figure its maximum size i= s the "Topology Set". In my opinion, if there is 256 nodes in the network and a maximum of 16 neighbours per node, the worst case for this set is to contain 256 * 16 entries. Am I right about that ? Thank you, Aur=E9lien Ribon --0016364c7cfb426e8e046dc9ab06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I am currently writing an hardware architecture of OLSR in VH= DL, and as a consequence I can not use as many RAM blocks as I want to stor= e the repositories' data. So, I need to know what is the worst case for= each olsr repository.

I am considering a network of 256 nodes with a maximum of 16 neighbours= per node, and 3 interfaces per node.
It is not really hard to see that = as a result there should not be more than 16 entries in the MPR Set, 16 in = the MPR Selector Set, etc.

Actually, the only repository for which I can not figure its maximum si= ze is the "Topology Set".
In my opinion, if there is 256 nodes= in the network and a maximum of 16 neighbours per node, the worst case for= this set is to contain 256 * 16 entries. Am I right about that ?

Thank you,
Aur=E9lien Ribon
--0016364c7cfb426e8e046dc9ab06-- From joseph.macker@nrl.navy.mil Mon Jul 6 08:40:10 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFAE28C212 for ; Mon, 6 Jul 2009 08:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_43=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoLRhUEmESFt for ; Mon, 6 Jul 2009 08:40:10 -0700 (PDT) Received: from s2.itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3]) by core3.amsl.com (Postfix) with ESMTP id 0EB6C28C211 for ; Mon, 6 Jul 2009 08:40:09 -0700 (PDT) Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8/8.13.8) with SMTP id n66F1EBo021564 for ; Mon, 6 Jul 2009 11:01:24 -0400 Received: (from sextant [132.250.92.22]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009070611011406363 for ; Mon, 06 Jul 2009 11:01:14 -0400 From: "Joe Macker" To: Date: Mon, 6 Jul 2009 11:01:11 -0400 Message-ID: <006201c9fe4a$99a39780$cceac680$@macker@nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn+SplSy0o4A71nT++NrTmq52QSoA== Content-Language: en-us Subject: [manet] Agena Items for Stockholm Meeting X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 15:40:10 -0000 All: We should have discussions of active WG documents in Stockholm. So we are reserving slots for those discussions. Ian Chakeres will not be able to attend but I have plans to attend. If anyone else would like a slot to discuss follow-on work,etc. please mail both Ian and myself. I hope to generate an agenda by the end of the week. -Joe From nani1only@gmail.com Tue Jul 7 04:24:14 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222CF3A6E3E for ; Tue, 7 Jul 2009 04:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLxLsfjTTlTP for ; Tue, 7 Jul 2009 04:24:13 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id DB2E53A6E5A for ; Tue, 7 Jul 2009 04:23:50 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1690179wff.31 for ; Tue, 07 Jul 2009 04:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=/5THJ96LjHMy8jtLlXWVKPiYzN481gboM5w4/Ucbx+Y=; b=BAtp9Zwlv0UjMentsjO0QSYHCqGPRHGAjhoBbWn6YXEh9Kndw39BF0lh+PyxpfO7Q3 Zo4lY8zBoX28dfGJOoPqr0yr0/TRmtLzzT4LqicEUpsj337qe7OkMLwU9LMbOMvGD8G8 FmyJ2bGh4+F8skPh7R2wj18yTeroatn4mzFtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uPxGbd5kvuvks94JNCWA6fVgM4+U2SE8zU5CTYLmD/PUtnxezIS73w+zM5OAc894u3 +qncvRMCboXEl9m+LTxLcuka2/iqLFRbQzsJwgxhNyxsNggIlysnFQbFxwvTGlnQ9g/6 b0SbM2P6odyrTHCCBPEwBBwCvM0dhl9QSedzY= MIME-Version: 1.0 Received: by 10.143.8.10 with SMTP id l10mr1758705wfi.301.1246965840232; Tue, 07 Jul 2009 04:24:00 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jul 2009 07:24:00 -0400 Message-ID: From: rahimanuddin shaik To: manet@ietf.org Content-Type: multipart/alternative; boundary=001636e90c32f44086046e1bdb46 X-Mailman-Approved-At: Tue, 07 Jul 2009 14:27:24 -0700 Subject: Re: [manet] manet Digest, Vol 63, Issue 3 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 11:24:14 -0000 --001636e90c32f44086046e1bdb46 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All: Its been a long time that there had been no serious discussion on topics like security issues and anonymous attack issues, i hope the active members in the community should start discussing such issues. with regards S Rahmanuddin --001636e90c32f44086046e1bdb46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All:
=A0=A0=A0=A0=A0 Its been a long time that there had been no serious= discussion on topics like security issues and anonymous attack issues, i h= ope the active members in the community should start discussing such issues= .
with regards
S Rahmanuddin


--001636e90c32f44086046e1bdb46-- From Deepak.Gopalakrishnan@Lntemsys.com Thu Jul 9 03:36:23 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107F53A6AC0 for ; Thu, 9 Jul 2009 03:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVpjqL6QSwfq for ; Thu, 9 Jul 2009 03:36:22 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by core3.amsl.com (Postfix) with SMTP id 2451B3A6902 for ; Thu, 9 Jul 2009 03:36:22 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Deepak.Gopalakrishnan@Lntemsys.com X-Msg-Ref: server-13.tower-85.messagelabs.com!1247135807!4525270!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [59.145.122.242] Received: (qmail 22396 invoked from network); 9 Jul 2009 10:36:48 -0000 Received: from unknown (HELO emsyssmtpout.lntemsys.com) (59.145.122.242) by server-13.tower-85.messagelabs.com with SMTP; 9 Jul 2009 10:36:48 -0000 Received: from emsysmail.lntemsys.com ([192.168.178.22]) by emsyssmtpout.lntemsys.com (Lotus Domino Release 6.5.4) with ESMTP id 2009070916143285-88660 ; Thu, 9 Jul 2009 16:14:32 +0530 To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Deepak Gopalakrishnan Date: Thu, 9 Jul 2009 16:15:39 +0530 X-MIMETrack: S/MIME Sign by Notes Client on Deepak Gopalakrishnan/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:04:25 PM, Serialize by Notes Client on Deepak Gopalakrishnan/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:04:25 PM, Serialize complete at 07/09/2009 04:04:25 PM, S/MIME Sign failed at 07/09/2009 04:04:25 PM: The cryptographic key was not found, Serialize by Router on EMSYSMAIL/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:15:43 PM, Serialize complete at 07/09/2009 04:15:43 PM, Itemize by SMTP Server on EMSYSSMTPOUT/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:14:32 PM, Serialize by Router on EMSYSSMTPOUT/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:14:36 PM, Serialize complete at 07/09/2009 04:14:36 PM Content-Type: multipart/alternative; boundary="=_alternative 003A1539652575EE_=" Subject: [manet] RFC doubt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 10:38:25 -0000 This is a multipart message in MIME format. --=_alternative 003A1539652575EE_= Content-Type: text/plain; charset="US-ASCII" can someone explain the section 6.2.2 in RFC3561. it talks about the intermediate node sending RREP if it has the route to destination. i am not able to follow what are the steps to be followed for implementing this. Can someone break it it up a little bit...? Regards, Deepak Gopalakrishnan --=_alternative 003A1539652575EE_= Content-Type: text/html; charset="US-ASCII"
can someone explain the section 6.2.2 in RFC3561.
it talks about the intermediate node sending RREP if it has the route to destination.
i am not able to follow what are the steps to be followed for implementing this.
Can someone break it it up a little bit...?
Regards,
Deepak Gopalakrishnan --=_alternative 003A1539652575EE_=-- From Deepak.Gopalakrishnan@Lntemsys.com Thu Jul 9 03:37:13 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF453A69B3 for ; Thu, 9 Jul 2009 03:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQaIJ7d5aatr for ; Thu, 9 Jul 2009 03:37:12 -0700 (PDT) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by core3.amsl.com (Postfix) with SMTP id 4AE833A6AC0 for ; Thu, 9 Jul 2009 03:37:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Deepak.Gopalakrishnan@Lntemsys.com X-Msg-Ref: server-4.tower-87.messagelabs.com!1247135855!54034435!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [59.145.122.242] Received: (qmail 30923 invoked from network); 9 Jul 2009 10:37:36 -0000 Received: from unknown (HELO emsyssmtpout.lntemsys.com) (59.145.122.242) by server-4.tower-87.messagelabs.com with SMTP; 9 Jul 2009 10:37:36 -0000 Received: from emsysmail.lntemsys.com ([192.168.178.22]) by emsyssmtpout.lntemsys.com (Lotus Domino Release 6.5.4) with ESMTP id 2009070916152179-88662 ; Thu, 9 Jul 2009 16:15:21 +0530 To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Deepak Gopalakrishnan Date: Thu, 9 Jul 2009 16:16:30 +0530 X-MIMETrack: S/MIME Sign by Notes Client on Deepak Gopalakrishnan/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:05:15 PM, Serialize by Notes Client on Deepak Gopalakrishnan/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:05:15 PM, Serialize complete at 07/09/2009 04:05:15 PM, S/MIME Sign failed at 07/09/2009 04:05:15 PM: The cryptographic key was not found, Serialize by Router on EMSYSMAIL/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:16:32 PM, Serialize complete at 07/09/2009 04:16:32 PM, Itemize by SMTP Server on EMSYSSMTPOUT/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:15:21 PM, Serialize by Router on EMSYSSMTPOUT/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:15:25 PM, Serialize complete at 07/09/2009 04:15:25 PM Content-Type: multipart/alternative; boundary="=_alternative 003A28E5652575EE_=" Subject: [manet] Sequence number doubt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 10:38:36 -0000 This is a multipart message in MIME format. --=_alternative 003A28E5652575EE_= Content-Type: text/plain; charset="US-ASCII" Hi Im trying to implement AODV algorithm and i have this doubt about sequence number. What happens when there is a roll over in the sequence number? I am not getting a clear idea of how to implement a algorithm according to what is given in the aodv RFC3561. For example, i have allocated a 8bit value for sequence number.. suppose in a intermediate node the sequence number is 254.....but at the destination, the sequence has incremented twice due to some reason....then the present sequence wud be 1... now if we compare the sequence numbers....the fresh packet will be discarded by the intermediate node.... also..if the intermediate node has updated the sequence number to 2(the case after a roll over has occured)...but receives a packet which was created before the roll over...then the node wud accept that node thinking that it has a "fresher" packet.... im totally confused.... Can anyone help me with the algorithm to tackle this roll over problem..... thanks in advance Regards, Deepak Gopalakrishnan --=_alternative 003A28E5652575EE_= Content-Type: text/html; charset="US-ASCII"
Hi
Im trying to implement AODV algorithm and i have this doubt about sequence number.
What happens when there is a roll over in the sequence number? I am not getting a clear idea of how to implement a algorithm according to what is given in the aodv RFC3561.
For example,
i have allocated a 8bit value for sequence number..

suppose in a intermediate node the sequence number is 254.....but at the destination, the sequence has incremented twice due to some reason....then the present sequence wud be 1...
now if we compare the sequence numbers....the fresh packet will be discarded by the intermediate node....

also..if the intermediate node has updated the sequence number to 2(the case after a roll over has occured)...but receives a packet which was created before the roll over...then the node wud accept that node thinking that it has a "fresher" packet....

im totally confused....

Can anyone help me with the algorithm to tackle this roll over problem.....
thanks in advance

Regards,
Deepak Gopalakrishnan --=_alternative 003A28E5652575EE_=-- From Deepak.Gopalakrishnan@Lntemsys.com Thu Jul 9 03:36:16 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36E93A691A for ; Thu, 9 Jul 2009 03:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnqBH7oYyg0S for ; Thu, 9 Jul 2009 03:36:16 -0700 (PDT) Received: from mail145.messagelabs.com (mail145.messagelabs.com [216.82.242.163]) by core3.amsl.com (Postfix) with SMTP id B630D3A6902 for ; Thu, 9 Jul 2009 03:36:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Deepak.Gopalakrishnan@Lntemsys.com X-Msg-Ref: server-7.tower-145.messagelabs.com!1247135714!4371128!2 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [59.145.122.242] Received: (qmail 13228 invoked from network); 9 Jul 2009 10:36:41 -0000 Received: from unknown (HELO emsyssmtpout.lntemsys.com) (59.145.122.242) by server-7.tower-145.messagelabs.com with SMTP; 9 Jul 2009 10:36:41 -0000 Received: from emsysmail.lntemsys.com ([192.168.178.22]) by emsyssmtpout.lntemsys.com (Lotus Domino Release 6.5.4) with ESMTP id 2009070916131436-88659 ; Thu, 9 Jul 2009 16:13:14 +0530 To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Deepak Gopalakrishnan Date: Thu, 9 Jul 2009 16:14:22 +0530 X-MIMETrack: S/MIME Sign by Notes Client on Deepak Gopalakrishnan/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:03:07 PM, Serialize by Notes Client on Deepak Gopalakrishnan/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:03:07 PM, Serialize complete at 07/09/2009 04:03:07 PM, S/MIME Sign failed at 07/09/2009 04:03:07 PM: The cryptographic key was not found, Serialize by Router on EMSYSMAIL/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:14:24 PM, Serialize complete at 07/09/2009 04:14:24 PM, Itemize by SMTP Server on EMSYSSMTPOUT/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:13:14 PM, Serialize by Router on EMSYSSMTPOUT/LNTEMSYS(Release 6.5.4|March 27, 2005) at 07/09/2009 04:14:29 PM, Serialize complete at 07/09/2009 04:14:29 PM Content-Type: multipart/alternative; boundary="=_alternative 0039F6FE652575EE_=" X-Mailman-Approved-At: Sun, 12 Jul 2009 07:47:43 -0700 Subject: [manet] AODV implementation doubts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 10:38:16 -0000 This is a multipart message in MIME format. --=_alternative 0039F6FE652575EE_= Content-Type: text/plain; charset="US-ASCII" I have started to implement the AODV algorithm and i am facing hell lot of problems. I want to know how the reverse path and forward path maintained. Is it that there is one route table and there is one entry for forward path and one for reverse path...? or is it like there is a route table for forward path and another for reverse path.? also in this concept of precursor...if i have to forward a RREP packet from a intermediate node to the precursor...im not able to decide which precursor i have to send because in my route table there are multiple precursors.... i am totally stuck in this... Regards, Deepak Gopalakrishnan --=_alternative 0039F6FE652575EE_= Content-Type: text/html; charset="US-ASCII"
I have started to implement the AODV algorithm and i am facing hell lot of problems. 

I want to know how the reverse path and forward path maintained.
Is it that there is one route table and there is one entry for forward path and one for reverse path...?
or is it like there is a route table for forward path and another for reverse path.?

also in this concept of precursor...if i have to forward a RREP packet from a intermediate node to the precursor...im not able to decide which precursor i have to send because in my route table there are multiple precursors....

i am totally stuck in this...
Regards,
Deepak Gopalakrishnan
 --=_alternative 0039F6FE652575EE_=-- From ulrich@herberg.name Mon Jul 13 04:52:42 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9F428C381 for ; Mon, 13 Jul 2009 04:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LehGJJh36-j7 for ; Mon, 13 Jul 2009 04:52:42 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id A6D3E28C264 for ; Mon, 13 Jul 2009 04:52:41 -0700 (PDT) Received: by bwz28 with SMTP id 28so98673bwz.37 for ; Mon, 13 Jul 2009 04:53:04 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.63.193 with SMTP id c1mr5089157bki.20.1247485984592; Mon, 13 Jul 2009 04:53:04 -0700 (PDT) Date: Mon, 13 Jul 2009 13:53:04 +0200 X-Google-Sender-Auth: 9a74858cbc8152e8 Message-ID: <25c114b90907130453h108b8cecnb8232e98f851e99b@mail.gmail.com> From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=001636c5bdc4f952b8046e94f685 Subject: [manet] Triggered message and jitter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 11:52:42 -0000 --001636c5bdc4f952b8046e94f685 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear authors of NHDP/OLSRv2/RFC5148, I have a question about jitter in NHDP/OLSRV2 when triggering a message -- which I think is not clearly explained in the NHDP/OLSRv2 drafts or in RFC5148. RFC5148 says: "when a (externally triggered) message is transmitted, the next message is allowed after a time (MESSAGE_MIN_INTERVAL - jitter)" I understand that, however, there are two cases which are not clear to me: 1) The last message has been sent longer ago than MESSAGE_MIN_INTERVAL In that case, how do I jitter? I would suppose to use a *positive* jitter from 0 to MAX_JITTER in that case instead of the negative jitter in the cited sentence from RFC5148. 2) If a message is triggered just very shortly before (last_message_sent + MESSAGE_MIN_INTERVAL). In that case, if I simply subtract jitter from MESSAGE_MIN_INTERVAL, I might have a negative value. Thomas told me to choose a jitter value between the current time and MESSAGE_MIN_INTERVAL in that case. But that leads to a) a non-uniform distribution between 0 and MAX_JITTER b) a possibly very small value of jitter; collisions might occur. Can you explain me how to handle these cases? Thanks Ulrich --001636c5bdc4f952b8046e94f685 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear authors of NHDP/OLSRv2/RFC5148,

I have a question about jitter = in NHDP/OLSRV2 when triggering a message -- which I think is not clearly ex= plained in the NHDP/OLSRv2 drafts or in RFC5148. RFC5148 says:

"= ;when a (externally triggered) message is transmi= tted, the next message is allowed after a time (MESSAGE_MIN_INTERVAL - jitt= er)"

I understand that, however, there are two cases which are not clear to = me:
1) The last message has been sent longer ago than MESSAGE_MIN_INTERV= AL
=A0=A0=A0 In that case, how do I jitter? I would suppose to use a *po= sitive* jitter from 0 to MAX_JITTER in that case instead of the negative ji= tter in the cited sentence from RFC5148.
2) If a message is triggered just very shortly before (last_message_sent + = MESSAGE_MIN_INTERVAL). In that case, if I simply subtract jitter from MESSA= GE_MIN_INTERVAL, I might have a negative value. Thomas told me to choose a = jitter value between the current time and MESSAGE_MIN_INTERVAL in that case= . But that leads to
=A0=A0 a) a non-uniform distribution between 0 and MAX_JITTER
=A0=A0 b) = a possibly very small value of jitter; collisions might occur.

Can y= ou explain me how to handle these cases?

Thanks
Ulrich

--001636c5bdc4f952b8046e94f685-- From root@core3.amsl.com Mon Jul 13 08:00:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E28EF3A6B87; Mon, 13 Jul 2009 08:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713150001.E28EF3A6B87@core3.amsl.com> Date: Mon, 13 Jul 2009 08:00:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-nhdp-10.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 15:00:02 -0000 --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-10.txt Pages : 80 Date : 2009-07-13 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-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-manet-nhdp-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13075455.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 13 08:15:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B6D5C3A67F3; Mon, 13 Jul 2009 08:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713151501.B6D5C3A67F3@core3.amsl.com> Date: Mon, 13 Jul 2009 08:15:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-olsrv2-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 15:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : The Optimized Link State Routing Protocol version 2 Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-olsrv2-09.txt Pages : 71 Date : 2009-07-13 This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-manet-olsrv2-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13081117.I-D@ietf.org> --NextPart-- From Chris.Dearlove@baesystems.com Mon Jul 13 09:17:33 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83CA3A6E4D for ; Mon, 13 Jul 2009 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMR60ZYAQlS1 for ; Mon, 13 Jul 2009 09:17:31 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 634723A6E1E for ; Mon, 13 Jul 2009 09:17:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,391,1243810800"; d="scan'208";a="11983562" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 13 Jul 2009 17:18:02 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6DGI4RR016437; Mon, 13 Jul 2009 17:18:04 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 17:18:00 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 13 Jul 2009 17:17:59 +0100 Message-ID: In-Reply-To: <25c114b90907130453h108b8cecnb8232e98f851e99b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Triggered message and jitter Thread-Index: AcoDsIxRuMQum3Z9Q/2Yr1JSQZ88dwAIkmVA References: <25c114b90907130453h108b8cecnb8232e98f851e99b@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ulrich Herberg" , X-OriginalArrivalTime: 13 Jul 2009 16:18:00.0246 (UTC) FILETIME=[7D87F560:01CA03D5] Subject: Re: [manet] Triggered message and jitter X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 16:17:33 -0000 > I have a question about jitter in NHDP/OLSRV2 when triggering a message > -- which I think is not clearly explained in the NHDP/OLSRv2 drafts or in RFC5148. > RFC5148 says: > "when a (externally triggered) message is transmitted, the next message is allowed > after a time (MESSAGE_MIN_INTERVAL - jitter)" OK, that's about how long since the last message. > I understand that, however, there are two cases which are not clear to me: > 1) The last message has been sent longer ago than MESSAGE_MIN_INTERVAL > In that case, how do I jitter? I would suppose to use a *positive* jitter > from 0 to MAX_JITTER in that case instead of the negative jitter in the > cited sentence from RFC5148. You always have to use a positive jitter - if triggered you can't go back in time! There are two rules: (i) Wait between 0 and MAXJITTER. This of course depends on the reason this has happened. If this is something local (like changing addresses for internal reasons) then there's no need to wait at all. If it's due to something external (such as a received message that's likely to induce change is several nodes that receive the message) then jitter. (ii) The minimum interval. Note that this is jittered because otherwise in a busy network things will become de facto periodic, which is a bad thing. The reasons for the negative jitter on intervals are discussed in RFC 5148. (Strictly the reasons apply to the maximum interval, but they need to allow for non-responsive systems where the two are equal, hence applying them to the minimum interval avoids special cases.) You need to satisfy both. Typically one or the other will be the limiting factor, but you have a case where both have an effect: > 2) If a message is triggered just very shortly before (last_message_sent > + MESSAGE_MIN_INTERVAL). In that case, if I simply subtract jitter from > MESSAGE_MIN_INTERVAL, I might have a negative value. Thomas told me to > choose a jitter value between the current time and MESSAGE_MIN_INTERVAL > in that case. But that leads to > a) a non-uniform distribution between 0 and MAX_JITTER > b) a possibly very small value of jitter; collisions might occur. I would say, obey both (i) and (ii). But note that RFC 5148 does not specify an exact algorithm. That's by intent, as there are enough complicating factors. (One such being packetisation, which allows scope for the clever implementor to get better performance - and we didn't want to constrain him, as he might have a better idea than us) And it's not essential for interworking (if it were we would specify an algorithm). > Can you explain me how to handle these cases? I know I've implemented more than one timing algorithm for OLSRv1/v2. (Note that we invented the minimum interval and jittering it here as a proprietary extension to OLSRv1 - see the first OLSR Interop.) So there is more than one way to do things. But right now I don't recall exactly how I handle this case, except to note carefully. Is this critical? Well, you point out issues if you do one thing. Are those show-stoppers? Probably not. Are they undesirable? Probably. (Note that handling of forwarding of messages in multi-message packets takes care to indicate a single jitter value for all messages to avoid exactly those issues.) ******************************************************************** 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. ******************************************************************** From themq15@yahoo.com Mon Jul 13 06:46:25 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F116928C1F2 for ; Mon, 13 Jul 2009 06:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yy3Foiz6ev7 for ; Mon, 13 Jul 2009 06:46:25 -0700 (PDT) Received: from n56.bullet.mail.sp1.yahoo.com (n56.bullet.mail.sp1.yahoo.com [98.136.44.52]) by core3.amsl.com (Postfix) with SMTP id 330CD28C2E8 for ; Mon, 13 Jul 2009 06:46:25 -0700 (PDT) Received: from [69.147.84.145] by n56.bullet.mail.sp1.yahoo.com with NNFMP; 13 Jul 2009 13:46:53 -0000 Received: from [69.147.84.107] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 13 Jul 2009 13:46:52 -0000 Received: from [127.0.0.1] by omp202.mail.sp1.yahoo.com with NNFMP; 13 Jul 2009 13:46:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 971541.2640.bm@omp202.mail.sp1.yahoo.com Received: (qmail 96493 invoked by uid 60001); 13 Jul 2009 13:46:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247492812; bh=KA58gw6KFxJQqcP4q4FXmlBF7i5oJ3Ibph+PPNFQ8gE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=XvDPkckK5E3+7YAQVrz9lyjfE7qmpn16QdBiMcijw5aesoJIWHTo1TukprXDGYjj/labbg15xyo5N9sB90e7hlcWJyHXJKIg7zL2glhcBNxwo40PUd7vboVSQydoBDFK1sAiTNnjOP476vcFwUAywFk9a7n64V1PBkS2I+Rmcxc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=kC3whZ8tRJGLEp4+uhYWTiHKf/aSNy21+kxa663ivx082IWvmY1z9Vb+dTytBz4OI82QVInqd9NZEVbzgueXfWE4bK0CVHPzaBLDuay9HHyGs+gp+MrRWNH3cr9a6nN65AHQV19nfcMMGt5lJupVNeoUxaeY0Lie4Dx/1idUrx8=; Message-ID: <386202.96142.qm@web43414.mail.sp1.yahoo.com> X-YMail-OSG: fmpqsHsVM1n4NFJ1jWNFuh_7KveXrzwBGkgq1kPn_Xc_2VxRPuy0aJPd9I13AfZuNyLJT6WT_lb96mUjWzEu8m.3YcXeo6qBgJMIi4qYDfsLfL2IIWjp9KEtbeDRLKgKtsIdoRNXMtgGhsh4o2aZWp7UeNIhlJFHiacDDalWcDVIXi0Abc.Y06IFhMeV3SwyNNolqL8ROWunRrBExPaGvPef0FkgYbHr1Bh.UqaZRfFLHfy1FCbyuv5lAuVJn2bLmGva9zeCCX00AA81 Received: from [119.153.0.72] by web43414.mail.sp1.yahoo.com via HTTP; Mon, 13 Jul 2009 06:46:50 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 Date: Mon, 13 Jul 2009 06:46:50 -0700 (PDT) From: Bringo Shawn To: IETFManet MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1324521341-1247492810=:96142" X-Mailman-Approved-At: Mon, 13 Jul 2009 10:43:52 -0700 Subject: Re: [manet] AODV implementation doubts X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 13:46:26 -0000 --0-1324521341-1247492810=:96142 Content-Type: text/plain; charset=us-ascii To maintain forward and reverse paths, both of your suggestions are applicable but the former should be preferred as it demands only one table. For the precursor, as for as I know, a list of precursor nodes is maintained at every node and you should send to the whole precursor list. IMPORTANT: Please DO INFORM me if you get any better solutions OR you or any one else thinks me wrong. Regards --0-1324521341-1247492810=:96142 Content-Type: text/html; charset=us-ascii
To maintain forward and reverse paths, both of your suggestions are applicable but the former should be preferred as it demands only one table.
For the precursor, as for as I know, a list of precursor nodes is maintained at every node and you should send to the whole precursor list.

IMPORTANT:  Please DO INFORM me if you get any better solutions OR you or any one else thinks me wrong.

Regards

--0-1324521341-1247492810=:96142-- From wwwrun@core3.amsl.com Mon Jul 13 12:57:42 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 92A9F28C523; Mon, 13 Jul 2009 12:57:42 -0700 (PDT) From: IETF I-D Submission Tool To: macker@itd.nrl.navy.mil Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090713195742.92A9F28C523@core3.amsl.com> Date: Mon, 13 Jul 2009 12:57:42 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-smf-09 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 19:57:42 -0000 A new version of I-D, draft-ietf-manet-smf-09.txt has been successfuly submitted by Joseph Macker and posted to the IETF repository. Filename: draft-ietf-manet-smf Revision: 09 Title: Simplified Multicast Forwarding Creation_date: 2009-07-13 WG ID: manet Number_of_pages: 49 Abstract: This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. The IETF Secretariat. From root@core3.amsl.com Mon Jul 13 13:00:01 2009 Return-Path: X-Original-To: manet@ietf.org Delivered-To: manet@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 45ADE3A69DD; Mon, 13 Jul 2009 13:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713200001.45ADE3A69DD@core3.amsl.com> Date: Mon, 13 Jul 2009 13:00:01 -0700 (PDT) Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-smf-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 20:00:01 -0000 --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 : Simplified Multicast Forwarding Author(s) : J. Macker, S. Team Filename : draft-ietf-manet-smf-09.txt Pages : 49 Date : 2009-07-13 This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-manet-smf-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13125742.I-D@ietf.org> --NextPart-- From rogge@fgan.de Tue Jul 14 07:13:29 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B8F28C108 for ; Tue, 14 Jul 2009 07:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijOF82mV-csD for ; Tue, 14 Jul 2009 07:13:28 -0700 (PDT) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 8F2B23A692A for ; Tue, 14 Jul 2009 07:13:28 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MQiQY-0002G2-0M for manet@ietf.org; Tue, 14 Jul 2009 15:52:14 +0200 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MQiQX-0006Jw-LM for manet@ietf.org; Tue, 14 Jul 2009 15:52:13 +0200 From: Henning Rogge To: manet@ietf.org Date: Tue, 14 Jul 2009 15:52:08 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.28-13-generic; KDE/4.2.2; i686; ; ) References: <20090713151501.B6D5C3A67F3@core3.amsl.com> In-Reply-To: <20090713151501.B6D5C3A67F3@core3.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart14021948.CU8x8O4qAx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200907141552.14790.rogge@fgan.de> X-Virus-Scanned: yes (ClamAV 0.95.1/9561/Tue Jul 14 14:51:15 2009) by mailguard.fgan.de X-Scan-Signature: 38bebb0b8fa0111ad382b5b9a8cedd42 Subject: Re: [manet] I-D Action:draft-ietf-manet-olsrv2-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 14:13:29 -0000 --nextPart14021948.CU8x8O4qAx Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Mon July 13 2009 17:15:01 schrieb Internet-Drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Mobile Ad-hoc Networks > Working Group of the IETF. > > > Title : The Optimized Link State Routing Protocol version 2 > Author(s) : T. Clausen, et al. > Filename : draft-ietf-manet-olsrv2-09.txt > Pages : 71 > Date : 2009-07-13 This version does NOT contain the suggested change that TCs only need to=20 contain routable addresses of a OLSR router, right ? I still think to deman= d=20 interface IPs in a TC is a bad idea. Henning Rogge --nextPart14021948.CU8x8O4qAx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpcjYkACgkQRIfGfFXsz+CikACdFG4w8NmjPfoi3JESVn9Vq+oT VU8An1gzufUmSiSU7onn/wD0Ebe2pgtc =Y3N4 -----END PGP SIGNATURE----- --nextPart14021948.CU8x8O4qAx-- From ulrich@herberg.name Wed Jul 15 03:10:51 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA6C3A6ABD for ; Wed, 15 Jul 2009 03:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiogfIMAz517 for ; Wed, 15 Jul 2009 03:10:50 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 1F7293A67F7 for ; Wed, 15 Jul 2009 03:10:49 -0700 (PDT) Received: by bwz28 with SMTP id 28so1310389bwz.37 for ; Wed, 15 Jul 2009 03:09:51 -0700 (PDT) MIME-Version: 1.0 Sender: ulrich@herberg.name Received: by 10.204.103.203 with SMTP id l11mr7539098bko.71.1247652591187; Wed, 15 Jul 2009 03:09:51 -0700 (PDT) In-Reply-To: <20090713150001.E28EF3A6B87@core3.amsl.com> References: <20090713150001.E28EF3A6B87@core3.amsl.com> Date: Wed, 15 Jul 2009 12:09:51 +0200 X-Google-Sender-Auth: 5514930d13ef5395 Message-ID: <25c114b90907150309n65175ba5u56f718bc94984f49@mail.gmail.com> From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=0016e6d7dff4809622046ebbc17a Subject: Re: [manet] I-D Action:draft-ietf-manet-nhdp-10.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 10:10:51 -0000 --0016e6d7dff4809622046ebbc17a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the new version of the NHDP draft. I like the Appendix E which illustrates the "Interval and Timer Illustrations". I suggest to add some cases with jitter in this appendix. In my implementation, I spent most of the time trying to understand the different cases with timers and jitters, and I am still not 100% sure that I got all cases correctly (in particular with jittering for externally triggered messages). Some examples using jitter in the new Appendix could help to understand that better. Ulrich On Mon, Jul 13, 2009 at 5:00 PM, 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-10.txt > Pages : 80 > Date : 2009-07-13 > > 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-10.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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://www.ietf.org/mailman/listinfo/manet > > --0016e6d7dff4809622046ebbc17a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the new version of the NHDP draft. I like the Appendix E which i= llustrates the "Interval and Timer Illustrations". I suggest to a= dd some cases with jitter in this appendix. In my implementation, I spent m= ost of the time trying to understand the different cases with timers and ji= tters, and I am still not 100% sure that I got all cases correctly (in part= icular with jittering for externally triggered messages). Some examples usi= ng jitter in the new Appendix could help to understand that better.

Ulrich

On Mon, Jul 13, 2009 at 5:00 P= M, <Inter= net-Drafts@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of th= e IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : MANET Neighborhood Discovery Pr= otocol (NHDP)
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : T. Clausen, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-manet-nhdp-10.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 80
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-07-13

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-nh= dp-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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
h= ttps://www.ietf.org/mailman/listinfo/manet


--0016e6d7dff4809622046ebbc17a-- From yannick.lacharite@crc.gc.ca Wed Jul 15 06:01:58 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E52BD3A6BC4 for ; Wed, 15 Jul 2009 06:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usWXmzGL1Z8K for ; Wed, 15 Jul 2009 06:01:58 -0700 (PDT) Received: from mailgate01.crc.ca (mailgate01.crc.ca [142.92.160.36]) by core3.amsl.com (Postfix) with ESMTP id 11B663A6B56 for ; Wed, 15 Jul 2009 06:01:55 -0700 (PDT) Received: from mail01.crc.ca ([142.92.39.50]) by mailgate01.crc.ca (8.13.8/8.13.8) with ESMTP id n6FCwZXG002412 for ; Wed, 15 Jul 2009 08:58:36 -0400 Received: from RASNHPPC2 (virgo.dgim.crc.ca [142.92.53.82]) by mail01.crc.ca (8.13.8/8.13.8) with ESMTP id n6FCwMlI031340 for ; Wed, 15 Jul 2009 08:58:35 -0400 From: =?utf-8?Q?Yannick_Lacharit=C3=A9?= To: Date: Wed, 15 Jul 2009 08:58:20 -0400 Organization: CRC Message-ID: <01f901ca054b$f4070fb0$dc152f10$@lacharite@crc.gc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoD+jM/RlAhwGBvQTORn98ZN+ZwEwBUai5g Content-Language: en-ca X-Scanned-By: MIMEDefang 2.65 on 142.92.160.36 X-Scanned-By: MIMEDefang 2.65 on 142.92.39.50 Content-Disposition: inline X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mailgate01.crc.ca [142.92.160.36]); Wed, 15 Jul 2009 08:58:36 -0400 (EDT) Subject: [manet] FW: New Version Notification for draft-lacharite-manet-holsr-02 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: yannick.lacharite@crc.gc.ca List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 13:01:59 -0000 A new version of I-D, draft-lacharite-manet-holsr-02.txt has been successfu= ly submitted by Yannick Lacharite and posted to the IETF repository. Filename: draft-lacharite-manet-holsr Revision: 02 Title: Hierarchical OLSR Creation_date: 2009-07-13 WG ID: Independent Submission Number_of_pages: 38 Abstract: This document describes the Hierarchical Optimized Link State Routing (HOLSR) mechanism for heterogeneous mobile ad hoc networks. In this specification a heterogeneous mobile ad hoc network is defined as a network of mobile routers that are characterized by different communication capabilities, such as communication channels, processing powers or energy levels. The HOLSR mechanism is an extension to the OLSRv2 protocol. HOLSR takes advantage of the router's distinct communications capabilities to reduce the routing control overhead in large heterogeneous ad hoc networks, thus improving the performance of the routing mechanism. More precisely, HOLSR defines a hierarchy in the network and presents a routing scheme for this hierarchical structure with a better scalability. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20 The IETF Secretariat. From fnumber@gmail.com Sun Jul 19 22:41:04 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D5B73A6943 for ; Sun, 19 Jul 2009 22:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX3AAfWN3ILV for ; Sun, 19 Jul 2009 22:41:02 -0700 (PDT) Received: from mail-px0-f198.google.com (mail-px0-f198.google.com [209.85.216.198]) by core3.amsl.com (Postfix) with ESMTP id CAAB03A67B3 for ; Sun, 19 Jul 2009 22:41:02 -0700 (PDT) Received: by pxi36 with SMTP id 36so432246pxi.29 for ; Sun, 19 Jul 2009 22:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IHxRsJgH0o7Ci/wjoqHZZGI6YA7OgjRHp8kLFtDskKY=; b=YY9PbqsTK/vFMmqRaVl258F8jrSXcX7iGXKkWQvpkoiMfqBXTlPOuXcs2pfd5sRn7V PjoY3DfShXxtxdnoNBZTl+jYWFf56LrrF41MaDIiSd4DQmjcl5qSV6XE9vJwZyiqYR+q qcCDPX7efTpfDUQYp7OFkJhKL8Jp5IlFEExcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SeraLFP9LCYZV0hk2zxceuxqWM0gdXCtNfLGEcJa+QnEu9KEB588JFjAS8ZduI38qT QApGgF3VQ3IcREg+BGMtI5NR4tXtahBrexmXfzW7DXtV3Fl8SD+QrDHxa2MnVV7Yar6P xrTW/l79eZwq6hjmAq3Ot95oed7gNTVnaLybQ= MIME-Version: 1.0 Received: by 10.142.212.21 with SMTP id k21mr886790wfg.244.1248068459019; Sun, 19 Jul 2009 22:40:59 -0700 (PDT) In-Reply-To: <20090706130001.ED85E28C270@core3.amsl.com> References: <20090706130001.ED85E28C270@core3.amsl.com> Date: Mon, 20 Jul 2009 14:40:58 +0900 Message-ID: From: Jung-Soo Park To: manet@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1496227bf0e046f1c9545 Cc: yghong@etri.re.kr, dongkyun@knu.ac.kr, khj@etri.re.kr, hjjeong@monet.knu.ac.kr Subject: [manet] Fwd: I-D Action:draft-park-manet-multipath-analysis-scenarios-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 05:41:04 -0000 --000e0cd1496227bf0e046f1c9545 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, all. We formalized our ideas on supporting multiple paths in MANET routing. As the first work result, we published general ideas about using the multi-path routing in MANET. Currently, we are making our multi-path routing protocol using Linux kernel. After the 75IETF, we will also publish the details about multi-path routing protocol. Please welcome to comment. Best Regards. JungSoo. ---------- Forwarded message ---------- From: Date: Mon, Jul 6, 2009 at 10:00 PM Subject: I-D Action:draft-park-manet-multipath-analysis-scenarios-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis and Scenarios of generating the Multi-Path Routings Author(s) : J. Park, et al. Filename : draft-park-manet-multipath-analysis-scenarios-00.txt Pages : 10 Date : 2009-07-06 This document discusses the use of multiple interfaces of Mobile Ad hoc NETworks (MANETs) nodes and multiple path MANET routings protocols with respect to traditional, single network interface based ones. It then describes the design principles and methods of multiple path routing over MANET nodes with multiple interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-manet-multipath-analysis-scenarios-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -- JungSoo PARK ----------------- u-Infra Standardization Team Electronics and Telecommunications Research Institute (ETRI), Korea Tel:+82-42-860-6514, Fax:861-5404 MSN: fnumber@msn.com, E-mail : pjs@etri.re.kr --000e0cd1496227bf0e046f1c9545 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, all.

We formalized our ideas on supporting multiple = paths in MANET routing.
As the first work result,=A0
we= published general ideas about using the multi-path routing in MANET.

Currently, we are making our multi-path routing protoco= l using Linux kernel.
After the 75IETF, we will also publish= the details about multi-path routing protocol.=A0

Please welcome to comment.

Best Regards.

JungSoo.

---------- Forwarded message ----------
From: <Internet-Drafts@ietf.org>
Date: Mon, Jul 6, 2009 at 10:00 PM
Subject: I-D Action:draft-park-manet-= multipath-analysis-scenarios-00.txt
To: i-d-announce@ietf.org


A New Internet-Draft is avail= able from the on-line Internet-Drafts directories.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Analysis and Scenarios of gener= ating the Multi-Path Routings
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : J. Park, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-park-manet-multipath-analys= is-scenarios-00.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 10
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-07-06

This document discusses the use of multiple interfaces of Mobile Ad
hoc NETworks (MANETs) nodes and multiple path MANET routings
protocols with respect to traditional, single network interface based
ones. =A0It then describes the design principles and methods of
multiple path routing over MANET nodes with multiple interfaces.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-dr= afts/draft-park-manet-multipath-analysis-scenarios-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt




--
JungSoo PARK
----------------= -
u-Infra Standardization Team
Electronics and Telecommunications Res= earch Institute (ETRI), Korea
Tel:+82-42-860-6514, Fax:861-5404
MSN: = fnumber@msn.com, E-mail : pjs@etri.re.kr
--000e0cd1496227bf0e046f1c9545-- From hannemann@nets.rwth-aachen.de Mon Jul 20 06:39:32 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3753A683E for ; Mon, 20 Jul 2009 06:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPwTwSFBpoqF for ; Mon, 20 Jul 2009 06:39:31 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 810363A6D6D for ; Mon, 20 Jul 2009 06:39:31 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KN300IK51XUVY30@mta-2.ms.rz.RWTH-Aachen.de> for manet@ietf.org; Mon, 20 Jul 2009 15:39:30 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.43,234,1246831200"; d="scan'208";a="19669182" Received: from relay-1.ms.rz.rwth-aachen.de (HELO relay.rwth-aachen.de) ([134.130.7.74]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 20 Jul 2009 15:39:31 +0200 Received: from [137.226.12.123] (informatik-4-137-226-12-123.nn.RWTH-Aachen.DE [137.226.12.123] (may be forged)) by relay.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n6KDdTli014397; Mon, 20 Jul 2009 15:39:29 +0200 (CEST) Message-id: <4A64737C.6080407@nets.rwth-aachen.de> Date: Mon, 20 Jul 2009 15:39:08 +0200 From: Arnd Hannemann User-Agent: Thunderbird 2.0.0.22 (X11/20090608) To: "manet@ietf.org" References: <20090713151501.B6D5C3A67F3@core3.amsl.com> In-reply-to: <20090713151501.B6D5C3A67F3@core3.amsl.com> X-Mailman-Approved-At: Mon, 20 Jul 2009 10:04:24 -0700 Cc: T.Clausen@computer.org Subject: Re: [manet] I-D Action:draft-ietf-manet-olsrv2-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 13:39:32 -0000 Internet-Drafts@ietf.org schrieb: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > > Title : The Optimized Link State Routing Protocol version 2 > Author(s) : T. Clausen, et al. > Filename : draft-ietf-manet-olsrv2-09.txt > Pages : 71 > Date : 2009-07-13 > > This document describes version 2 of the Optimized Link State Routing > (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). I noticed a typo in Section 7.1 on page 28: 2. Otherwise: 1. Otherwise: 1. If the message is of a type which may be processed, including being a TC message, then the message is considered for processing according to Section 7.2, AND; One "Otherwise:" should probably be eliminated... Best regards, Arnd From Chris.Dearlove@baesystems.com Tue Jul 21 02:36:10 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0333A6B89 for ; Tue, 21 Jul 2009 02:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GteJOII9AcZD for ; Tue, 21 Jul 2009 02:36:09 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 76D8D3A6880 for ; Tue, 21 Jul 2009 02:36:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.43,239,1246834800"; d="scan'208";a="13252428" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by ukmta3.baesystems.com with ESMTP; 21 Jul 2009 10:35:26 +0100 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.0/Switch-3.4.0) with ESMTP id n6L9ZMuN031882; Tue, 21 Jul 2009 10:35:31 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Jul 2009 10:35:21 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Jul 2009 10:35:20 +0100 Message-ID: In-Reply-To: <4A64737C.6080407@nets.rwth-aachen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] I-D Action:draft-ietf-manet-olsrv2-09.txt Thread-Index: AcoJXCnCd4e2/cFHQGatNONomHDkYwAiko0A References: <20090713151501.B6D5C3A67F3@core3.amsl.com> <4A64737C.6080407@nets.rwth-aachen.de> From: "Dearlove, Christopher (UK)" To: "Arnd Hannemann" , X-OriginalArrivalTime: 21 Jul 2009 09:35:21.0446 (UTC) FILETIME=[9111A060:01CA09E6] Cc: T.Clausen@computer.org Subject: Re: [manet] I-D Action:draft-ietf-manet-olsrv2-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 09:36:10 -0000 Thanks for that. I've made a note in my local working version. -- Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Arnd Hannemann Sent: 20 July 2009 14:39 To: manet@ietf.org Cc: T.Clausen@computer.org Subject: Re: [manet] I-D Action:draft-ietf-manet-olsrv2-09.txt *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet. Keep this in mind if you answer this message. Internet-Drafts@ietf.org schrieb: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > > Title : The Optimized Link State Routing Protocol version 2 > Author(s) : T. Clausen, et al. > Filename : draft-ietf-manet-olsrv2-09.txt > Pages : 71 > Date : 2009-07-13 > > This document describes version 2 of the Optimized Link State Routing > (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). I noticed a typo in Section 7.1 on page 28: 2. Otherwise: 1. Otherwise: 1. If the message is of a type which may be processed, including being a TC message, then the message is considered for processing according to Section 7.2, AND; One "Otherwise:" should probably be eliminated... Best regards, Arnd _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From jpmacker@gmail.com Sat Jul 25 05:25:02 2009 Return-Path: X-Original-To: manet@core3.amsl.com Delivered-To: manet@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7BD93A6967 for ; Sat, 25 Jul 2009 05:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmHIz35+OTaw for ; Sat, 25 Jul 2009 05:25:02 -0700 (PDT) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id E87923A6811 for ; Sat, 25 Jul 2009 05:25:01 -0700 (PDT) Received: by qyk41 with SMTP id 41so2844385qyk.29 for ; Sat, 25 Jul 2009 05:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=AJCN2A1XIKNCaauzD+MWYyVuW2aCPQwaCicuUtpVWYY=; b=PhbcF35xI4rZKzxJmGcSOL7dfyLEVqJ3LIMPM/ZGpF+4zvv4EGktt2aXSX35NDyQYV SEhWySlaSxiZK0ywcB6XKb/6E28zlLjtPQpuWBbJ53X7Br7XT8ytgdA5DtkmmQ8IgJxl H4mIG00puY5orEzQsI1YlTm55Mw2qKSpLNYyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=AWCiRSWf+1lj3nV2UDKKE19sTvjps1aETkc5s9AqfkMnEaOor/tFCS/6mdy1aKMLAa IOShSXrwL5hbAhctQJeQNByLA8jWlwZ/CWuutQki2pVAfOhVZhwuKi25Yb1y+MbDDL1b E6OL+/qBLPogMu9qUgggfGRjx8iMlm2pFB8Vc= MIME-Version: 1.0 Received: by 10.220.93.67 with SMTP id u3mr3015358vcm.21.1248524700667; Sat, 25 Jul 2009 05:25:00 -0700 (PDT) Date: Sat, 25 Jul 2009 08:25:00 -0400 Message-ID: From: Joseph Macker To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [manet] Meeting Plans and Chairs Travel Issues X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 12:25:02 -0000 All: Ian Chakeres (co-chair) had planned to be absent in Stockholm due to (child on way,etc). I had planned to cover this meeting as chair. Unfortunately, I have had a last minute problem causing my travel plans to be cancelled. I was really looking forward to attending and discussing work in person with the everyone. The manet meeting will proceed as planned and the agenda has been updated on-line. The chairs have asked Brian Adamson to proxy chair in our absence. Brian is an experienced Transport Area chair and active in the manet WG as well. As I receive presentations I will be posting. I will plan to follow along in jabber session,etc and am available for remote discussions through next Wednesday. As a reminder you can view meeting agenda, materials at: http://datatracker.ietf.org/meeting/75/materials.html This will continue to be updated as materials arrive over the weekend and during next week. -Joe