On Oct 14, 2009, at 0:55 , Jonathan Hui wrote:
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.
OK, now I got you. Neighborhood is local scope and the LoWPAN is the
whole link in 6lowpan-nd terminology.
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.
Right, those limitations were known when we added the ability to use
NR/NC information for that. I can understand the usefulness of NUD in
local scope.
It is a more fundamental question if we need AR at all, and how useful
AR for only local nodes is? The whole point of 6LoWPAN is header
compression. If you then assign IP addresses that can't be compressed
- why bother using 6LoWPAN in the first place? In your implementation
you make the same assumption, AR is not needed. We do the same. I am
waiting to hear of a case where AR is actually needed and why?
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?
Yep, that would be awkward. The current text basically says that NS/NA
is not used nor required. It just doesn't prevent it. So the current
draft assumes NS/NA is not there (earlier it was optional). That is
how an ND protocol should work, all nodes on the link implement the
same protocol.
Zach
--
Jonathan Hui
--
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
