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