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 PROTECTED]> 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 protected]
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 protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
