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?

Pascal 

_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to