Hi all, It's good that we resume the rechartering discussion. Comments are inline;
> > Charter 1/5 > > > > Charter 2/5 > > > > > > 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.
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.
> > 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.
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 _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
