Pascal Thubert (pthubert) wrote: > Hi: > > Neighbor Discovery is traditionally implemented over multicast. And > multicast is more often than not implemented over a plain mac level > broadcast. This is the "cry out loud" paradigm, perfectly suited for > Ethernet, and totally unsuited for LowPANs. > > draft-chakrabarti-6lowpan-ipv6-nd makes a great point on explaining the > steps that this takes and the associated cost. I think that this part of > the document has already most of the attributes to be turned into a ND > problem statement WG doc for 6LoWPAN. > > What I disagree with is the approach to solve the problem by patching > optimizations all over the process. We have to face that the result is > still not acceptable and that the whole paradigm should be revised for > the LowPAN. In a memory constrained device, implementing MLDv2 is huge > overkill, even if its use can be reduced in runtime by refined > optimizations. In a same fashion, relying on mesh-under multicast > support is unrealistic. > > At the other end of the routing spectrum from the "cry out loud" > paradigm, the "white board" model proposes a solution where one node > acts as a reference for all the others. With that model, every node > claims an address by writing on the white board and looks up an address > by reading from the white board. DAD is a lookup / commit collapsed in a > single NS flow. All NS/NA become unicast activity, no MLD, dead simple. > And RAs are broadcast. > > The catch is obviously that the white board is not a fully distributed > model. Is that even acceptable? If we consider that LowPANs usually have > a sink of some sort, probably a higher-power never-sleeping router, then > it makes a lot of sense to use that special node for placing the > function. So why not? > > I tried to capture this idea in > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. On top > of the white board, the draft adds the capability for the white board to > act as a ND proxy and extend the LoWPAN across an IP backbone and > potentially scale the PAN into a very large link. > > Note that the draft was renamed from LoWPAN to 6lowpan but the content > is unchanged. > > So, what do you think? > I think the idea of a whiteboard is powerful. It definitely makes more sense than "shout out." I am leery of the requirement that there be a single coordinating node, however. Your text puts it precisely: "consider that LowPANs *usually* have a sink of some sort" (emphasis mine). Forcing this to be centralized requires such a node exist and therefore precludes certain kinds of LowPANs.
That being said, this approach seems to implicitly assume mesh under? Nodes "use Neighbor Discovery to determine the link-layer addresses for neighbors known to reside on attached links and to quickly purge cached values that become invalid." ND could operate on a single hop basis. This simplifies everything. The place where the whiteboard approach is necessary is for DAD. But given that the goal is eventual consistency on address assignment, it may be possible to distribute the table in an effective way. Phil _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
