Subject: [6lowpan] 6lowpan rechartering

From: Mark Townsley <[email-masked]>
Date: Thu, 24 May 2007 15:11:12 +0200

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).

> 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.

>
> 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.

>
> 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.

Thanks,

- Mark

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

---

From: "Ki-Hyung Kim" <[email-masked]>
Date: Fri, 25 May 2007 01:00:49 +0900

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:

> > Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND
> > Optimizations" to define the required optimizations to make

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
> > Produce "Recommendations for 6lowpan
> > Applications" to define a set of recommendations of

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.

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.

>
> Charter 4/5
>
> Produce "6lowpan Mesh Routing" to evaluate different
> requires a mesh routing protocol below the IP layer. "6lowpan
> Mesh Routing" may be several proposed standard
> documents.

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).
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. 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.

>
> Charter 5/5
>
> Produce "6lowpan Security Analysis" to define the threat

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

-- 
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

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Mon, 28 May 2007 17:39:05 +0900

Hi all,

It's good that we resume the rechartering discussion.
Comments are inline;

> services), and mobility support.

I agree that this work should be done by two steps; (1) 6lowpan
applications. (2) 6lowpan architecture based on the considerations
which are discussed in (1)

However, I have a little bit different view about the scope of the
architecture work(2).
Although Architecture work is for drawing broad view of all necessary
tech. for 6lowpan, I don't think Architecture should state all the
technology. I don't believe we can make such a "giant" document. It
may delay whole standard processing. IMHO, we'd better focus on
showing what is covered in 6lowpan, instead of stating all technical
solutions in one document.
Please let me know if I misunderstand your point.

> routing table on sensor nodes might incur too much overhead to manage

We really need to clear this item. Do we want to do routing issues in
6lowpan? or do we just want to adapt routing protocol(s) from other
WG?

About the necessary of mesh under routing, I agree with KIM. RSN
targets IP layer routing which covers all possible sensor networks,
independently from L2/L1. 6lowpan specifically targets IEEE 802.15.4,
and the short-term solution (before RSN builds up the powerful
all-covered routing protocol for various sensor networks) for 6lowpan
will surely be working on mesh-under routing; we can end up with
adapting an existing one or designing a new protocol. The thing is
that we need to study on this item in either case.

I hope we can have a good discussion on rechartering before the next IETF.

Best,

- Eunsook Kim