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

From: "Eunsook Kim" <[email-masked]>
Date: Mon, 5 Mar 2007 17:21:42 +0900

Kris, Ian, 
 
The "6LoWPAN Mesh Routing Requirements" draft 
[http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt] was written 
based on cautioning against some discussion of designing routing protocols for 6lowpan.
We think the first step is to mull over the differences from manet work, from the routing perspective.
I think it is very important to clarify of the design goals and requirements of 6lowpan routing,
before discussing detail solution space.
 
In this point of view, I'm happy to see your comments and consideration of this work. 
I don't think we are ready to build up specification of 6lowpan routing protocols 
when we are not sure how much we can use Manet protocols;
if 6lowpan may use 100% of pure manet protocols or may need major changes of them.
That's why I would like to suggest to take some time to think of
our goals and requirement in routing. 
 
The current version of the "6LoWPAN Mesh Routing Requirements" draft doesn't fill up
the chapter 5, "Analysis of Existing Mesh Routing Candidates". 
I think this is important job to do in 6lowpan.
We will see if we really need to define 6lowpan routing protocols or not.
If we find the answer that we can use manet works, we don't need to consider seperate routing solution.
 
I wish we could have nice discussion about more of fundamental points of 6lowpan routing in this meeting, instead of details.
 
- eunsook

---------- 
From: "Kris Pister" <[email-masked]> 
>From Date: 2007-03-03 ?? 1:52:34 
To: "Dominik Kaspar" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]> 
Subject: RE: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements 

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, 

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.t 
xt]. 
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 

_______________________________________________ 
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: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 5 Mar 2007 10:44:47 +0100

>the chapter 5, "Analysis of Existing Mesh Routing Candidates".

Seems the people in the MANEMO Mailing List are very interested in
participating to that analysis, so I copy the list.

Pascal

>From: Eunsook Kim [mailto:[email-masked]]
>Sent: Monday, March 05, 2007 9:22 AM
>To: Kris Pister; Dominik Kaspar
>We think the first step is to mull over the differences from manet
work, from the routing
>perspective.
>If we find the answer that we can use manet works, we don't need to
consider seperate routing
>solution.
>
>I wish we could have nice discussion about more of fundamental points
of 6lowpan routing in this
>meeting, instead of details.
>
>- eunsook
>
>----------