Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements

From: "Dominik Kaspar" <[email-masked]>
Date: Fri, 2 Mar 2007 16:34:14 +0900

Ian, all,

Ian, thanks a lot for your fast reply and detailed commenting on the 
"6LoWPAN Mesh Routing Requirements" draft 
[http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt]. 
I'm taking the right to post this answer to both the 6lowpan and MANET 
working groups, as MANET folks might be interested in this discussion as 
well.

Ian, I find your inputs very reasonable, but they made me feel that the term 
"6lowpan" is not yet defined precisely enough to set up a strict set of 
6lowpan routing requirements. For example, you give me the scenario of a 
6lowpan network, in which all devices are powered and power usage is not 
important. But if I read the "6lowpan Problem Statement" 
[http://tools.ietf.org/wg/6lowpan/draft-ietf-6lowpan-problem], I'm not sure 
if such a set-up could still be called a 6lowpan, because that document 
explains that in a LoWPAN "typically, some or all devices are battery 
operated."

This draft's intention is to provide the primary design goals of 6lowpan 
mesh routing and to stimulate responses for defining a set of requirements. 
The requirements I listed are still as vague as the term "6lowpan" itself, 
not at all proven and not fixed yet. I will keep all of your detailed 
comments on the requirements in mind for a next revision. Also, it has 
already been my intention to include a Section about what exactly the 
differences are between routing in a MANET and in a LoWPAN.

Best regards,

Dominik

----- Original Message ----- 
From: "Ian Chakeres" <[email-masked]>
To: "Dominik Kaspar" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 01, 2007 2:00 AM
Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements

>
> Good to see some requirements for 6lowpan routing.
>
> Personally, I'd like to know what can't be done with MANET protocols
> and why. Hopefully, a future version will include this information. If
> you have any comments please send them to me or the MANET list.
>
> Ian
>
> I have some quick comments about the document.
>
> I don't think LQI by itself should be used. LQI must be matched with
> other indicators to make good decisions. LQI can be bad for routing.
> Similarly, shortest path can be bad.
>
> I think that operating with low routing state should be an
> additionally goal. For example, if devices have only 32 forwarding
> entries available. This fact could probably be captured in one of the
> existing sections.
>
> Regarding the requirements section:
>
> I think that R2 is a bad requirement. I would instead say that routing
> should be efficient. Efficiency can be defined in many ways. There
> might be 6lowpan networks where all devices are power so power usage
> is not important. Alternatively there might be nodes that choose not
> to participate even though they have energy. I think that requiring
> minimal energy routing is too harsh and unrealistic.
>
> R3. I would say that 6lowpan works below IP. Therefore,
> interconnection is not seamless but below IP. Some device will need to
> bridge (PAN coordinator or gateway) this gap. For example,  RFD edge
> devices will likely not include this capability.
>
> R4. I'm not sure that routing needs to be aware of sleeping nodes. We
> could reverse the requirement and say that sleeping nodes must be
> aware of routing. Or we could create a routing protocol that should
> work independent of the sleep schedule. For example, flooding.
>
> R5. How do we measure simplicity and robustness? How much simplicity
> and robustness are required by the various 6lowpan players?
>
> R6. How mobile? How dynamic?
>
> R7. Are you referring to IPv6 ND or routing (L2 in this case)
> neighbor(hood) discovery?
>
> R9. What is the scalability requirement? How many nodes & at what density?
>
> R10. Is L2 (WEP like) security enough?
>
> Ian
>
>
> On 2/27/07, Dominik Kaspar <[email-masked]> wrote:
>> Hi all,
>>
>> A new Internet-Draft has just been submitted to emphasize the importance 
>> of
>> mesh routing in LoWPANs. I believe that well thought-out mesh routing is 
>> a
>> vital precondition for fully functional LoWPANs and should be discussed 
>> in
>> more detail within the 6lowpan working group.
>>
>> Comments are welcomed for the Internet-Draft titled:
>> "Design Goals and Requirements for 6LoWPAN Mesh Routing"
>>
>> Abstract:
>> This document defines the problem statement, design goals, and 
>> requirements
>> for mesh routing in low-power wireless personal area networks (LoWPANs).
>>
>> A URL for this Internet-Draft is:
>> www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt
>>
>> Best regards,
>> Dominik
>>
>>
>>
>> _______________________________________________
>> 6lowpan mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/6lowpan
>>
> 

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

---

From: 김용운 <[email-masked]>
Date: Sat, 3 Mar 2007 01:10:34 +0900

>other indicators to make good decisions.

I agree. But, in my opinion,
LQI is likely to be the primary key.
The reason is saving TCO.

>LQI can be bad for routing.

Good point.

My sales experience taught me
that we had to struggle to save any cost issues.
Then we could be winner and
our products made our customers save their TCO.

A harsh system specification is a natural choice and
the low routing state must be a goal as well as a requirement.

>minimal energy routing is too harsh and unrealistic.

In my opinion,
most 6lowpan devices are powered by battery and
The battery power must be the weakest point in business.

As time goes after wireless devices have been installed,
management cost, for examples, battery cost, labor cost for
battery change, maintenance cost, remote monitoring and management
cost, etc. will overwhelm installation cost.

Minimal energy usage is worth adopting for requirement to
save battery cost and relevant labor cost, I think.

"harsh and unrealistic" is a good expression
but solving it must be a technical target.

>work independent of the sleep schedule. For example, flooding.

Interesting reversion.

First of all, the meaning of "sleeping" needs to be clarrified.
As far as I know, "sleeping" is mainly hibernation of
RF transceiver.

If routing is aware of sleeping nodes, routing can choose
an alternative path. But if sleeping nodes are aware of routing,
they cannot take actions for routing activities.

That's my understanding.

>and robustness are required by the various 6lowpan players?

Theoretically good question.

The authors need to think about how to measure them.

By the way, just my curiosity
because I'm a newbie at routing protocols.
Are there any metrics for other routing protocols in terms of
simplicity and robustness? If they don't use the terms,
how about efficiency or scalability?
Answers could be good reference to tackle the questions.

>R6. How mobile? How dynamic?

As in the case of R5,
the authors need to change the way to express the requirements,
I think.

>neighbor(hood) discovery?

Not concerning about the R7.

As an end user of wireless sensor nodes and network,
I hate v6 ND and v4 ARP because they consume my battery a lot.

For my simple sensor network,
fixed manual configuration is enough.

>R10. Is L2 (WEP like) security enough?

In terms of information security, L2 security is not enough but
a minimal requirement I think. L3 or L4 security is a tough
requirement for tiny devices.
If higher layer security is required, system specification has to
be upgraded. So, in my opinion, L2 security could be
a reasonable solution.

Regards,
Qkim

-----Original-----
From: "Ian Chakeres" <[email-masked]>
From Date: 2007-03-01 오전 2:00:11
To: "Dominik Kaspar" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements

Ian

Ian

On 2/27/07, Dominik Kaspar <[email-masked]> wrote:
> Hi all,
>
> A new Internet-Draft has just been submitted to emphasize the importance of
> mesh routing in LoWPANs. I believe that well thought-out mesh routing is a
> vital precondition for fully functional LoWPANs and should be discussed in
> This document defines the problem statement, design goals, and requirements

---

From: "Kris Pister" <[email-masked]>
Date: Fri, 2 Mar 2007 08:52:34 -0800

I would like to caution against designing the mesh routing protocols
from the top down, without paying careful attention to what the MAC
sub-layer will look like.  In principle, from a strict
layer-separationist perspective, it shouldn't matter.  In practice, when
some devices will be running at 100% duty cycle, and (most?) others will
be constrained to run at 0.1% duty cycle, it makes all the difference.
LQI is certainly important, but 1000x difference in available bandwidth
on different links is even more important, and *must* drive the design
of higher layers if they are to be efficient.
We have seen the results of traditional networking applied to this new
class of hardware platform, and they are entertaining, academically
interesting, and commercially disastrous.
I'm a newbie to IETF, so forgive me if I'm missing some key information,
but as I see it we have come up with a reasonable format for IPv6 over
15.4 when the radios are on.  The next step should be to figure out when
the radios turn on, how they avoid interference, how they
learn/announce/enforce their duty cycles, etc.  Once that's done, or at
least roughed out, then a rational discussion of routing can take place.

ksjp

Kristofer S.J.Pister
Prof. EECS, UC Berkeley
Founder & CTO, Dust Networks

-----Original Message-----
From: Dominik Kaspar [mailto:[email-masked]] 
Sent: Thursday, March 01, 2007 11:34 PM
To: Ian Chakeres
Cc: [email-masked]; [email-masked]
Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements

Ian, all,

[http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.t
xt]. 

well.

Ian, I find your inputs very reasonable, but they made me feel that the
term 
"6lowpan" is not yet defined precisely enough to set up a strict set of 
6lowpan routing requirements. For example, you give me the scenario of a

important. But if I read the "6lowpan Problem Statement" 
[http://tools.ietf.org/wg/6lowpan/draft-ietf-6lowpan-problem], I'm not
sure 
if such a set-up could still be called a 6lowpan, because that document 
explains that in a LoWPAN "typically, some or all devices are battery 
operated."

mesh routing and to stimulate responses for defining a set of
requirements. 
The requirements I listed are still as vague as the term "6lowpan"
itself, 
not at all proven and not fixed yet. I will keep all of your detailed 
comments on the requirements in mind for a next revision. Also, it has 
already been my intention to include a Section about what exactly the 
differences are between routing in a MANET and in a LoWPAN.

Best regards,

Dominik

---

From: "KIM Yong-Woon" <[email-masked]>
Date: Thu, 8 Mar 2007 15:50:24 +0900

>From Date: 2007-03-03 AM 1:15:27

<snip>

>On 3/2/07, Yong-Woon KIM <[email-masked]> wrote: 
>I guess my comment has more to do with how we solve the problem.  I 
>think that a routing protocol that can handle sleeping nodes (and 
>adapt quickly) and also one that can be influenced by nodes 
>willingness (maybe remaining battery) is sufficient. Therefore, I'm 
>not sure we need an energy aware routing protocol.

I'm not a technology expert in this area. 
But I'm VERY interested in how I can be winner against 
my competitors in my business and battle field. 
Energy saving is a vital factor for my business.

You think R2 seems to be a bad requirement. 
I revisited the R2: "R02: Shortest path calculation must 
be based on minimal energy usage." 
I'm very happy with R2.

Regarding your comment.. 
We have to define "energy aware routing protocol" first.

"a routing protocol that can handle sleeping nodes (and 
adapt quickly) and can be influenced by nodes 
willingness (maybe remaining battery)" seems to me that 
it is a kind of energy saving routing protocol.

How to save energy is a technical target to be achieved. 
R2 doesn't state any solution. 
Your idea and comment is ok to me if it is helpful for 
energy saving in routing operations. A new energy saving 
routing protocol also is ok to me. 

The only one that I want to ask you and sincere engineers is 
to give me an efficient routing protocol for energy saving. 
Then I can meet the TTM first. 
Brand-new one, adaptation or reuse is not an issue to me.

I REALLY THANK YOU FOR YOUR SINCERE EFFORTS IN THIS AREA.

Regards, 
KIM, Yong-Woon

ps) 
I'm not a real salesman but was. 
I think so in my mind all the time while doing my R/D jobs.