Subject: Re: [6lowpan] 6lowpan rechartering

From: JP Vasseur <[email-masked]>
Date: Tue, 17 Jul 2007 19:26:33 -0400

Hi,

On May 24, 2007, at 12:00 PM, Ki-Hyung Kim wrote:

> Hi, Mark,
> This is Ki-Hyung Kim. It is a great news from you.
> We have been waiting for this start of rechartering so long time.
>
> My comments are in-line.
>
>
> On 5/24/07, Mark Townsley <[email-masked]> wrote:
>
> Folks,
>
> I'd like the group to continue its work on rechartering. RSN is  
> starting
> to work on the routing piece, and this group needs to formulate its
> charter in concert with this for the remaining items.
>
> Starting with what we have from the last meeting, I'll offer the  
> group my
> thoughts on each as work items to start discussion. Please give your
> feedback now, I'd like for the chairs to be able to get a proposed
> charter together in time for Chicago.
>
> I copied text from
> http://www3.ietf.org/proceedings/07mar/slides/6lowpan-0.pdf
>
> > Charter 1/5
> >
> > Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND
> > Optimizations" to define the required optimizations to make
> > IPv6 ND applicable in 6lowpans, given the fact that IPv6 ND
> > is too expensive for the devices of 6lowpan and requires
> > multicast. This document will define how to bootstrap a
> > 6lowpan network and explore ND optimizations such as
> > reusing the 802.15.4 network structure (use the
> > coordinators), and obviate multicast by having devices talk
> > to coordinators without creating a single point-of-failure, and
> > changing the IPv6 ND multicast semantics. This document
> > will be a proposed standard.
>
> Bootstrapping and ND would seem to be related, but separate, work  
> items
> (but feel free to convince me otherwise). I think this work item needs
> better scoping with respect to what "bootstrapping" really means.  
> Also,
> it would be nice to get away from 802.15.4-specific jargon ( e.g., you
> shouldn't have to be intimately familiar with 802.15.4 to understand
> what the work item is).
>
> Kim: Yes, I agree with you that bootstrapping and ND should be  
> separate items, even though they are related. In order to get  
> interoperable 6lowpan products, we should have a common  
> bootstrapping protocol. A sensor node should inter-work with  
> neighbors and 6lowpan routers when it boots or moves to the new  
> 6lowpan region.
>
>
>
> > Charter 2/5
> >
> > Produce "Problem Statement for Stateful Header
> > Compression in 6lowpans" to document the problem of
> > using stateful header compression (2507, ROHC) in
> > 6lowpans. Currently 6lowpan only specifies the use of
> > stateless header compression given the assumption that
> > stateful header compression may be too complex. This
> > document will determine if the assumption is correct and will
> > be an informational document.
>
> I see no problem documenting this informationally, I would hope  
> that it
> wouldn't slow down PS work though.
>
> >
> > Charter 3/5
> >
> > Produce "Recommendations for 6lowpan
> > Applications" to define a set of recommendations of
> > protocols to use for applications. The recommendations
> > will cover protocols for transport, application layer,
> > discovery, configuration and commissioning. This
> > document will be an informational document.
>
> This sounds more like an overall framework document. I wonder why
> Routing isn't listed here.
>
> Kim: I think the title and the details of this item seem to be a  
> little bit out of focus. My idea is to separate this item into the  
> following two items. (Much of this idea was already discussed with  
> Geoff and David Culler at the last IETF meeting)
> Kim: First item is Recommendations for 6lowpan Applications which  
> states and classifies typical 6lowpan applications and possible  
> protocol requirements and adaptations for each of them.

Yes, see my previous comment wrt to the new proposed charter and  
applicability statements.

>
> Kim: Second item is 6lowpan Network Architecture which states the  
> architecture of the IP over LoWPAN. It states routing protocols  
> (Mesh under IP, Route over IP, or both of them, scalable routing,  
> or other candidate routing protocols), commissioning,  
> bootstrapping, ND, reliable and efficient delivery of packets (or  
> fragments), configuration, discovery of networks and services), and  
> mobility support.

Absolutely: Geoff, David and I started such as ID. Should be posted  
right after this IETF with welcome comments.

>
>
> >
> > Charter 4/5
> >
> > Produce "6lowpan Mesh Routing" to evaluate different
> > mesh routing protocols for use within 6lowpans. While most
> > routing protocols are defined above the IP layer, 6lowpan
> > requires a mesh routing protocol below the IP layer. "6lowpan
> > Mesh Routing" may be several proposed standard
> > documents.
>
> Something to discuss with RSN so that we have a clear understanding of
> the goals of MAC vs. IP routing, whether we need to do both or not,  
> how
> much of the mechanism could be shared if we do need both, etc.

I can't agree more ! See the email that I just sent out.

>
> Kim: I think we need routing protocols underneath IP, regardless of  
> the efforts at RSN (I agree with JP and David that it is valuable  
> to try to find possible routing protocols for sensor networks  
> especially over IP).

Good, although I'm still questioning why we need mesh-under routing.  
But times will come when we should have that discussion.

> This is because we will have lots of 6lowpan fragments of IP  
> packets (of course depending on the applications and packet size).  
> The fragments should anyway be routed underneath IP because the  
> fragments can not be seen above IP.

Not sure of what you mean by "routing fragment underneath IP" ??

> Mesh routing protocol is one of the candidates, and a scalable  
> routing protocol could be an alternate choice especially when lots  
> of 6lowpan nodes are to be deployed in a network, in that a routing  
> protocol based on the routing table on sensor nodes might incur too  
> much overhead to manage routing table updates.

Well this has to be demonstrated.

Thanks.

JP.

>
>
> >
> > Charter 5/5
> >
> > Produce "6lowpan Security Analysis" to define the threat
> > model of 6lowpans and to document suitability of existing
> > key management schemes and to discuss
> > bootstrapping/installation/commissioning/setup issues. This
> > document will be an informational document.
>
> Yes, and we will want to appoint a security adviser unless we already
> have an expert in the group.
>
> These Charter items, with some cleanup and tightening, seem like a
> reasonable start to me. I'd like to know what others in the group
> believe, and if we have editors and energy lined up for the tasks.
>
> Kim: Overall, I hope we could start off the works on PS as well as  
> the informational documents.
> The routing protocol could be one of them. Indeed, the market is  
> waiting for the 6lowpan products.
> We spent two and half years for making one PS document. That is  
> just start of the actual impact on the market.
> We need to do some work at least routing protocols ASAP while  
> starting off the sensor-op testing (sensor network version of  
> interop).
>
> Thanks,
>
> - Mark
> >
>
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/6lowpan
>
>
>
>
> -- 
> Ki-Hyung Kim (김기형, 金起亨)
> Associate Professor
> Division of Information and Computer Eng., Ajou University, Suwon,  
> Korea 442-749
> Tel: +82-31-219-2433, Cel: +82-17-760-2551,  Fax: +82-31-219-2433  
> http://www.6lowpan.org
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/6lowpan

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