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