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
