Hi Erik > The purpose of NUD in 6lowpan-nd is primarily to be able to detect when > one of the host's default routers have disappeared. > Thus I don't see how NUD can not be mandatory; the registration is for the > reverse direction - traffic from the router to the host.
2 things: 1) I favor the use of NUD as defined in RFC 4861 whenever possible. My reason is that it enables longer registration lifetime and thus more quietness in the peaceful / sleeping areas. RPL chose to include something similar for its own needs. 2) Still, we can live without NUD exactly like MIPv6 lives without it. Yes, traffic will be lost. And end-to-end failures can be a trigger to reassert the registration from the end node standpoint when that happens. Bidirectional reachability is asserted in the following fashion: - Host to router: As you point out, NUD from the node can be important to avoid traffic loss since it enables the node to select an alternate router. You'll note, though, that many of the issues we see in a LoWPAN are really transient (like a 500ms interference) and are dealt with retries at L2 followed by sending the packet to an alternate router upon retries exhaustion, without necessarily declaring the first router off, or loosing traffic. A node can stay in a mode like this till the next registration. Having a sequence counter echoed is a useful thing because some of these links exhibit huge latencies. - Router to host: NUD from the router may induce false positives if the node is sleeping. OTOH, it can be quite critical to clean routes up and avoid mislead traffic to reach an area of the network where the node is no more. If the router keeps receiving registrations, it means that recent registrations passed. So we do not assert connectivity at that exact moment but recent connectivity. This is what REACH tells you seconds later anyway. When the node fails to register to a given router it will try another one and get its traffic through that one while the first one exhausts its registration lifetime and cleans up. This is why it is so important to enable seamless mobility in the subnet (MIPv6 would reject the analog move). So not having NUD as defined in RFC 4861 may makes us loose some degree of immediateness, and some packets. This can be compensated by L2 and L4/5 triggers. An L2 trigger informs the L3 that the retries are exhausted and passes the packet back for alternate default routing. An L4/5 trigger informs that packets are lost and that connectivity to the default router(s) should be reasserted. Pascal > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Erik Nordmark > Sent: Friday, May 28, 2010 10:55 PM > To: [email protected] > Subject: Re: [6lowpan] [Roll] how does a node get an IP address > > On 05/12/10 04:31 AM, Pascal Thubert (pthubert) wrote: > > Hi Anders; > > > > The current ND draft has a white board, though it calls it a neighbor > > cache. Sometimes, renaming things is good. In this instance, I do not > > know. Clearly, standard neighbor cache entries must not be confused > > with the ones gleaned for the registration process, because only the > > latter can be fed into the backbone mechanism, be it route over or mesh > under. > > I clarification might be in order. > > In 6lowpan-nd-09, the only way a neighbor cache entry is created is from the > registration process. Thus there isn't any "gleaning" and any risk of conflicts. > > > The White Board conceptually differs from the traditional Neighbor > > Cache: > > > > - The WB is a table as opposed to a cache. A neighbor cache entry can > > stay STALE for a very long time after the node is gone. A neighbor > > cache entry can be flushed to make room anytime. So a neighbor cache > > entry does not represent the node accurately enough to be > > redistributed in a routing protocol or proxied over a backbone. > > That is true in RFC 4861, but section 6 in 6lowpan-nd-09 tries to make it clear > that the entries stay around until they time out. Is there something we > should make more clear in that section? > > > - It is fed proactively using a registration as opposed to reactively > > to traffic. The registration and timely reregistration guarantees the > > presence of the node proactively. NUD is reactive, depends on traffic. > > It is nice to have but not mandatory as long as you have a registration. > > The purpose of NUD in 6lowpan-nd is primarily to be able to detect when > one of the host's default routers have disappeared. > Thus I don't see how NUD can not be mandatory; the registration is for the > reverse direction - traffic from the router to the host. > > Erik > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
