Subject: RE: [6lowpan] Fwd: I-DACTION:draft-daniel-6lowpan-load-adhoc-routing-00.txt

From: Ki-Hyung Kim <[email-masked]>
Date: Thu, 14 Jul 2005 01:48:53 +0900

Hello Tiago,

>I have some comments/suggestions in your new draft: 6LoWPAN Ad Hoc
Routing Protocol(LOAD):
>            1) In introduction you say that "the existing AODV protocol is not suitable for 6LoWPAN", I think that in general case all the MANET protocols can not be directly applied to 6LoWPAN, since they do not take in consideration its characteristics (i.e. strong energy limitations);

I agree on this.

>            2) In the overview chapter you say that your protocol relies on three routing tables: neighbor, routing and route request. But in chapter 5 you only described the last two tables. Are you not considering describing the Neighbor Table, just because it is build on MAC layer? 

One of the main reason of missing the description of neighbor table is
that the table will be used in the hilow(hierarchical routing over
6lowpan) and described in the draft
(http://daniel.vsix.net/ietf/6lowpan/draft-daniel-6lowpan-hilow-hierarchical-routing-00.txt).
The use of the neighbor table in LOAD is still TBD. We will update it
soon.

>           3) In chapter 3 you affirm that LOAD cooperation with hierarchical routing is TBD, but do you think that it will be possible to merge these two concepts? It seems to me that they present a very different structure;
Currently, we believe that LOAD should work cooperatively with
HiLow(hiearchical routing) due to its simple routing nature working
even without routing tables.

>             4) How is calculated the link cost, just by "accumulated link cost from the originator to the destination"? This approach could lead to bad choices, since a path can have a good energy average but it could present a node with low energy level.
The way of calculating the link cost is TBD currently. We will update
the mechanism soon. Thank you for your all valuable comments.

All comments and feedbacks are warmly welcome.

Thanks and Regards,
__
Ki-Hyung Kim
Associate Professor
Division of Information and Computer Eng., Ajou University, Korea

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 13 Jul 2005 14:01:31 -0700 (PDT)

--- Ki-Hyung Kim <[email-masked]> wrote:

> >            1) In introduction you say that "the existing AODV protocol is not
> suitable for 6LoWPAN", I think that in general case all the MANET protocols can not be
> directly applied to 6LoWPAN, since they do not take in consideration its
> characteristics (i.e. strong energy limitations);
> 
> I agree on this.

One can say "protocol X is not suitable for LoWPAN cuz of reason Y" for *any* protocol X,
given
a particular scenario. Besides, in the deployment model envisioned by IEEE 802.15.4, the
FFD versus
RFD separation implies that in a very common scenario, FFDs will be mains powered. In
this particular
scenario, only the FFDs participate in the ad hoc routing protocol, while the puny
battery-driven 
RFDs don't (given that most of their sorry lives they are asleep, having them participate
is more
trouble than it's worth). All these need to do is discover a closest FFD in a fashion
similar to how
"normal" hosts just do router discovery, and leave routing protocols up to routers.

So in this scenario, I don't see such issues. This happens to be an important scenario
commercially.
It is an important one for ZigBee, which is, perhaps, why they chose a simple variant of
AODV 
as one of the mesh-enabling solutions.

-gabriel

---

From: Zachary Smith <[email-masked]>
Date: Thu, 14 Jul 2005 11:06:51 -0400

On Jul 13, 2005, at 5:01 PM, gabriel montenegro wrote:

> FFDs will be mains powered

i'd like to caution people against this assumption. in my experience  
there's a really strong rationale for allowing battery-powered  
routers/FFDs and it woul dbe a mistake to rule it out from the get-go.

my $0.02US,

   z

-----
zachary smith, chief software architect
http://www.ember.com/