Hi Philip Thanks a bunch for your answers, and sorry for being delayed; please see inline.
>> So my question is: Should we take as granted that ND on the LoWPAN >> requires multicast? Maybe the white board model based on unicast is >> enough, in which case we get rid of a very difficult dependency. >> Considering that there is a need for a router that >understands 6LowPAN >> to connect the LoWPAN to the Internet, that router is the natural >> location for a white board. > >The issue here is whether sleep schedules are visible to the >network layer, or whether it observes longer latency. MACs >which do not support a "cry out" approach, e.g., TDMA with no >broadcast slot, typically emulate broadcast through unicast to >each neighbor for which a slot exists. The network layer is >not made aware of this, as the TDMA schedule will by necessity >constrain the set of neighbors that you have a "link" to. Or >are you assuming mesh under? Yes; I have in mind the following requirements: - One link throughout (same subnet) - potentially multiple radio hops (mesh-under) - potentially a high speed federating backbone (proxy ND) - one fits-it-all ND solution for motes (no "profile" for ND) And the multiple radio hops are mesh under in this case. If we used ROLL all the time then we could assume a model close to the 802.11 infrastructure mode and simplify the problem quite a bit. But there are already mesh-under approaches that are well-advanced and using 6LoWPAN so we have to support them as well. The white board is a clean way to decouple ND from the multicast problem. Note: I'm not 100% sure that we need to solve the multicast problem at network level in the mesh-under LoWPAN anyway. For the specific needs such as upload trigger or software image upgrade, application level support could be good enough, for instance using RFC 2090 to optimize a download. Remember that we have this minimum LoWPAN node IPv6 support to define. If we can avoid multicast stuff like MLD snooping we simplify that support quite a bit. > >> So the concept of backbone router is this: cry out loud on the high >> speed backbone that federates LoWPANs, and white board on >the LoWPAN, >> and ND proxying to federate the whole thing. The backbone router >> implements ND proxying in a fashion that is compatible with >mobile IP >> so one day, sensors with a global address can move away and stay >> virtually there. > >I guess I don't quite understand why you think the whiteboard >approach is necessary. Can you describe a use case where "cry out" >doesn't work? The "nodes are off" case seems very suspect to >me: if nodes are *really* off, e.g., for long, >application-level periods, you would not expect multicast to >reach them. Instead, you would depend on higher-layer >protocols (e.g., SRM) for improving reliability. If nodes are >off for very short, link-layer periods, the MAC should take >care of this. Networks in deployment today tend to solely use >the latter approach, as it's quite sufficient. > I'm arguing that we do not need multicast for the specific mission of ND over LoWPAN and that the white board model saves energy and time even if we had mesh level multicast support. You need to go through Samita's draft to see how ND uses multicast and the issues and costs that are associated to that. I'm not arguing that multicast can not be done. I'm not convinced it should be done because I've not seen the requirement docs that prove that a generic network service is required in the mesh-under space at least for the applications that are currently envisioned. Finally I'm making a difference between multicast and broadcast. If multicast is actually implemented over a mac level broadcast, that makes it completely inefficient for the mission at hand (NS, DAD, etc...). OTOH, if we have mesh-under multicast routing, we save a lot of bandwidth and latency, and the flows start to compare with white board, but we add states everywhere for mcast routing we're still not as good anyway. Neither way achieves ND flows faster than white board. White board enables instant response to DAD within a LoWPAN. Backbone router enables instant response over the transit even if the node is sleeping. The only trouble with white board is that it's not fully distributed P2P. Maybe that's acceptable WRT the benefits in the LoWPAN case. > It might be the best approach for performance reasons, but >it may not be. The fact that such a tradeoff might depend on >the actual media access approach used suggests to me that this >is something e > >> >> In the meantime, a link local address is enough to connect >to any node >> in the network federated by backbone routers, > >So this assumes mesh under? Does. That's the model for WiHART and ISA 100.11a. That model is here to stay, even if the brighter future is ROLL. I'd concentrate the multicast routing effort in ROLL, reusing well known techniques, and keep mesh-under simple enough for the missions that it is currently designed for. > >> and a mote can move from a >> backbone router to another within the federated network without >> renumbering. > >This is definitely a desirable property. > Yes, the requirement comes from ISA. They want 10K nodes in a single network. They want a link local address to be valid throughout, and transparent mobility: the network is thus a single link, and the BbR is designed with a mobility support that inherits from RFC 3775 - with slight differences. Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
