Ralph, A couple more thing I wanted to touch on below.
On Nov 16, 2009, at 7:43 , Ralph Droms wrote: > > Any description of 6lowpan needs to differentiate between mesh-under > and router-over behavior, or explain which parts of the document apply > to which form of lowpan. I can understand how a mesh-under lowpan has > datagram delivery behavior that approximates wired ethernet, and how > additional functions are required because of the differences in lowpan > delivery reliability, node sleep/available cycles and > broadcast/multicast/unicast semantics. I would expect that a > mesh-under lowpan does not use lowpan routers, and uses some > additional machinery to work around differences between a mesh-under > lowpan and the more usual link-layer delivery characteristics assumed > by IP-over-foo documents. Correct, in the current document the only difference is that there are no LoWPAN Routers in mesh-under - only hosts and an ER. The nice thing about splitting the document, is that it makes explaining the architecture and dealing with mesh-under vs. route-over much easier as we are only discussing the host-router interface which we have over both kinds of link layers. It also allows us to deal with a router and an ER in basically the same way in a base document. There are good reasons for generalizing the characteristics of these link-layers, whether performing L2 mesh or not. This kind of L2 technology turns out to be very heterogeneous. There is no de-facto L2 mesh technique, and there are (too) many ways of setting up IEEE 802.15.4. We have also learned that 6LoWPAN is used over many other L2 technologies including Sub-GHz radios, Z-wave, PLC etc. What we have been doing is finding the common characteristics of these, and applying a host-router mechanism that always works. We should better document the assumptions made about the link for this mechanism to work, but I think this is the right approach. We need to allow stack developers to support 6LoWPAN over suitable link-layer setups. > > Is the route-over architecture, using nodes and lowpan routers, shared > with any other lowpan architectures like the work in the roll, > autoconf or manet WGs? If so, it would be good to coordinate closely > with those models; if not, the new route-over architecture needs a > more detailed description. It's also at least a little surprising to > me that the IEEE 802.15.4 spec isn't referenced directly; are there > some architectural notions that can be shared from that spec? I am currently working with autoconf people to share the addressing model, and we work very closely with roll already. The autoconf model should let us avoid having to define our own "route-over" at least, and to simplify terminology. The problem with IEEE 802.15.4 is that there are so many variations of it. I do think that the IP notion of host/router is similar to the IEEE 802.15.4 notion of RFD/FFD. But right, we could reference 802.15.4 as a good example link and explain how this works over a few different 802.15.4 configurations in the base document? > > My suggestion is to add some text that describes the model and > behavior of the various lowpan components that are used to build a > lowpan protocol that provides the functions of RFC 4861 ND. The > fundamental datagram machinery needs to be formulated and described > first and then the new protocol can be built on that machinery. OK, we can do that. > > - Ralph > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan -- http://www.sensinode.com http://zachshelby.org - My blog “On the Internet of Things” Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
