Re: [6lowpan] LOAD Updated
"Ian Chakeres" <ian.chakeres@gmail.com> Tue, 21 March 2006 04:58 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLYxB-0006sw-32; Mon, 20 Mar 2006 23:58:45 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLYx9-0006sr-Kb for 6lowpan@ietf.org; Mon, 20 Mar 2006 23:58:43 -0500
Received: from zproxy.gmail.com ([64.233.162.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLYx8-00052r-Bf for 6lowpan@ietf.org; Mon, 20 Mar 2006 23:58:43 -0500
Received: by zproxy.gmail.com with SMTP id i1so1404700nzh for <6lowpan@ietf.org>; Mon, 20 Mar 2006 20:58:42 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OuQElP3dOaUyV85PqqE/P/IgPFI8TebovuxDeHg/QiB7wZc0ZmDwIWmJx+tKYT+buZM/KNIxP9aTxPKdyocU6/As5+zdiXvDuhCVxRQUPwa5AyQXGF2BBeWiGe15gKnT1VOXPddaMCUN50Fz9VM5YkmZrv7+AzOxoF5kw9fBOzg=
Received: by 10.36.221.37 with SMTP id t37mr2369684nzg; Mon, 20 Mar 2006 20:58:41 -0800 (PST)
Received: by 10.37.18.77 with HTTP; Mon, 20 Mar 2006 20:58:41 -0800 (PST)
Message-ID: <374005f30603202058r503deb87qdd15316839992e7c@mail.gmail.com>
Date: Mon, 20 Mar 2006 20:58:41 -0800
From: Ian Chakeres <ian.chakeres@gmail.com>
To: Soohong Daniel Park <soohongp@gmail.com>
Subject: Re: [6lowpan] LOAD Updated
In-Reply-To: <f7c7d76e0603061325w12a0fd04wd789ef04c0343d5c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <007901c640b8$1403eec0$45706f0a@daniellaptop> <f7c7d76e0603061325w12a0fd04wd789ef04c0343d5c@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: 6lowpan@ietf.org
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
Errors-To: 6lowpan-bounces@ietf.org
I have several comments about the LOAD draft. I will enumerate them below. I still believe that DYMO is more appropriate for 6lowpan, it should require few if any modifications to run in 6lowpan networks. Ian Chakeres FYI: I am in Dallas. Comments: As I mentioned at the last IETF during the meeting, AODV and LOAD will create routing loops if sequence numbers are not included and considered correctly. Therefore, I think that sequence numbers MUST be used - 16 bits are probably enough. That is the length we are currently considering for DYMO. As I also mentioned during the last IETF, the interaction between a QoS metric and distance vector routing is unclear. This topic is still a research topic and not ready for protocol engineering. The lifetime definition in the routing table entry should be changed to something like AODV or DYMO, that is it should be the time the route expires; as opposed to the current text, which states it is the time before expiration/deletion. How do links break? Are links monitored? How do route entries timeout? Do you update the route timeout on transmission or reception of packets? Additional discussion on using link quality to ignore weak control messages and on using the "weak" link indicator in RREQ should be included. I think if you expect to have unidirectional links (after the above mentioned changes) you should probably specify a blacklisting mechanism. RERR for low battery and routing cost not supported will result in broadcast storms. I suggest they be removed. If nodes need to discourage their routing of packets on behalf of others (being on the chosen route), I suggest a mechanism in one of my research papers that I think is appropriate and flexible. """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.""" I don't think the load format requires an IANA port since it will be operating at L2. On 3/6/06, Soohong Daniel Park <soohongp@gmail.com> wrote: > Here is an official release: > http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-load-adhoc-routing-02.txt > > > On 3/6/06, Soohong Daniel Park <soohong.park@samsung.com> wrote: > > Folks - LOAD (6LoWPAN Ad Hoc On-Demand Distance Vector Routing) > > has been updated and you can use the following links before ietf repository. > > > > http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-load-adhoc-routing-02.txt > > > > Diff from 01 version: > > http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-load-adhoc-routing-02_diff.htm > > > > Any comments are highly welcome, > > > > See you in Dallas soon. > > > > Daniel (Soohong Daniel Park) > > Mobile Convergence Laboratory, SAMSUNG Electronics. > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan
- [6lowpan] LOAD Updated Soohong Daniel Park
- Re: [6lowpan] LOAD Updated Soohong Daniel Park
- Re: [6lowpan] LOAD Updated Ian Chakeres
- Re: [6lowpan] LOAD Updated gabriel montenegro
- Re: [6lowpan] LOAD Updated Timothy J. Salo
- Re: [6lowpan] LOAD Updated Ian Chakeres
- Re: [6lowpan] LOAD Updated kevin