Hi Jonathan; The Whiteboard lost quite a bit of its value when route over was added to the picture, that is true. I think that the value of a more generic solution compensates largely. The Whiteboard still serves its main purpose, that is to save multicast flows and let the node sleep when they need to. But NUD, Redirect, and first hop security are either distributed or replaced by services from the routing world (routing updates and ICMP unreachable). Guess what, the result is in fact a lot more compatible with NBMA at large.
What might be misunderstood reading your (correct) words is how important and complex DAD can be in a LoWPAN. We want to enable a node mobility within the subnet and we want it as part of the base mechanism, with no renumbering, no additional discovery, no MIP tunnel, no P-MIP in the LoWPAN routers, and whether the node uses the same edge router or moves to a different one. So a big question in DAD is whether this is the same node that moved or rebooted, or a different node coming in. And the whiteboard is responsible to figure that out, in a distributed manner when you have a backbone. Then there's first hop security. In the mesh under model, that is something that the edge router could handle and it still has its value in route over though the LoWPAN router could be asked to do their share - that piece of the design is not completed yet. Then as Zach mentioned, there is SeND. A economical way for the device to get SeND over the backbone would be to use the white board to compute the CGA in the first place so the white board can defend it later as part of the ND proxy operation. Finally there's global mobility. We could easily use the white board registration as a MIP6/NEMO proxy HA binding (not P-MIP but rather Global HAHA type proxy). The Whiteboard would operate as a proxy for the ND protocol and handle all the route optimization flows on behalf of the node. Remind me to ask you about IPinIP compression in HC :) So I fully support the change - that I did not trigger - to make the Whiteboard a mandatory feature of the edge router. Still I understand we need to work on the flows where the White board is saturated, see about DoS attacks etc... Cheers, Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Hui >Sent: mercredi 10 juin 2009 17:18 >To: Zach Shelby >Cc: Carsten Bormann; [email protected] >Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] > > >Hi Zach, > >On Jun 10, 2009, at 7:47 AM, Zach Shelby wrote: >> It is not only about detecting collisions. Because you don't have a >> transitive link with all nodes awake at all times, there is no basis >> for which to perform traditional Neighbor Discovery tasks such as >> DAD and NUD, furthermore it is a very useful thing for at least one >> node in a LoWPAN (the Edge Router) to actually know which IPv6 >> addresses are in use. > >Let's be a bit more precise on this statement. In a route-over >network, the whiteboard is primarily just for detecting collisions. >Address resolution, NUD, router discovery, etc. has nothing to do with >the whiteboard. In a mesh-under network, I'd still argue that the >whiteboard has nothing to do with NUD, router discovery, etc - but >could help with address resolution. > >> RFC4861 ND makes use of quite a few information caches already now >> (neighbor cache, destination cache etc.). A whiteboard is just one >> more cache in ND, so it shouldn't be made into something strange. >> Instead of requiring all nodes to carry a ND caches about all >> neighbors and destinations, we reduce that and just require one or a >> few edge routers to have a whiteboard cache. > >I disagree that the whiteboard is simply a cache. Traditionally, a >cache allows you to make a performance tradeoff. With cache's, it's OK >to have no cache at all - if you are willing to accept the performance >hit of a cache miss every time. The whiteboard, on the other hand, >needs to maintain state about all nodes in the network - or it will >not properly implement DAD. > >>> It comes down to the tradeoff between the costs and benefits >>> of having a whiteboard. It isn't clear to me that the >>> benefits so outweight the costs that 6LoWPAN ND should >>> require a whiteboard, especially if only EUI64 are being >>> used. >> >> In a Simple LoWPAN, the whiteboard really is just a simple cache, >> not that different from a neighbor cache. Regarding implementation, >> we have it implemented on a CC2430 without a problem. > >The whiteboard is a simple mechanism (but not cache) to implement. But >complexity is often not just an implementation issue. It's another >mechanism that a network designers/maintainers need to worry about. >It's another pile of state placed somewhere in the network. Looking at >history, same thing happened with DHCP. At a high-level, the >whiteboard is not much different than a simple DHCP server handing out >addresses with leases. But IPv6 developed SLAAC for a reason - because >it removed the need for another component in the network - not because >it was hard to implement. So we should not be narrow-minded in just >looking at implementation aspects. > >> The reason why we made it a built-in feature - was that having it >> optional was adding more implementation complexity for nodes than >> justified, it makes this easier to understand, and ND for 6LoWPAN is >> pretty useless without it. >> >> Considering that the vast majority of the time an edge router also >> has a complete IPv6 stack(!) this is not something to worry about. >> For ad-hoc cases where you configure a router to host a whiteboard - >> I also don't see a problem from experience - you have several other >> caches already and the size of a LoWPAN would often be small. >> Anyways, even in ad-hoc networks you often have a natural node with >> more memory (which is what we are talking about here, not processing >> power). >> >> As Carsten already pointed out, LoWPANs are stub networks, so you >> don't have routers routing between LoWPANs directly. Instead nodes >> would join both LoWPANs. > >Note that I'm not disagreeing that the whiteboard can be very useful >for DAD. Just wanted to make sure we're on the same page as what the >whiteboard is and what it provides. > >-- >Jonathan Hui > >> >> - Zach >> >> -Richard Kelsey >> >> -- >> 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 > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
