Hi Jonathan: I'd say that if a host hears a destination's NA(DOA) it should try that first.
If the medium has retries and the retries fail, then the packet should be passed to the router(s) in which ever order the node has them. If the failure is continuous, the node should be blacklisted with a holddown timer. If the medium does not have retries then reachability must be better asserted. The means that NS/NA provide that are not sufficient for most LoWPANs/LLNs because RCF 4861 is designed on the assumption that reachability is boolean whereas it is rather fuzzy in our world. All things that a RPL router have to do already :) Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Hui >Sent: mardi 13 octobre 2009 23:55 >To: Zach Shelby >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND > > >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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
