Hi Zach,
On Oct 13, 2009, at 2:35 PM, Zach Shelby wrote:
The discussion below is really useful. Aside from do we need to perform DAD (yes, we do, but I'll get back to that later) - what I hear you saying is that being able to perform functions like NUD and AR within your local scope is useful? This really is local neighbor discovery as it only gets you one hop. NS/NA doesn't help you with neighborHOOD operations (across the whole LoWPAN).
I guess we have different definitions of neighborhood. I was talking about 1-hop radio (IP) neighbors. I typically do not associate nodes multiple radio (IP) hops apart as being within the same neighborhood.
If the link is providing a mechanism to deal with sleeping neighbors (you can't always assume that though), then NS/NA would allow you to check on those neighbors for NUD. Is NUD really useful just for nodes within radio range (maybe a very small subset of the LoWPAN)? Separately there needs to be a discussion if AR is needed at all and over what scope.
NUD is useful for 1-hop neighbors to determine reachability. AR is required unless we assume that the binding table is *not* a cache and if communication only occurs with the attachment router or you can always compute the link address from the IID. I've already mentioned some limitations in this thread that 6lowpan-nd imposes in using NR/NC to replace NUD and AR.
The whole discussion around sleepy nodes is problematic for me as well. The link is either up or down, not sort-of kind-of. There are well-known ways to preserve this abstraction at least for the time scales applications require. Are we really trying to solve the DTN problem?
Currently NS/NA is totally optional for nodes to implement. In the last couple versions of the draft they had been unused.
Making NS/NA optional to implement is equivalent to saying that NUD and AR only occurs in the limited way that 6lowpan-nd allows. How would one that implements NS/NA and one that doesn't interoperate?
-- Jonathan Hui _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
