Hi,
Yep, we are basically on the same page. I am just trying to find good
analogies ;-)
Jonathan Hui wrote:
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.
The whiteboard can also be used for NUD across the whole LoWPAN, you are
correct that DAD is the main purpose. The whiteboard also enables
extended LoWPAN topologies (which is where the idea originally comes
from, the BbR draft from Pascal). Furthermore the whiteboard gives an ER
some valuable information about which IPv6 addresses are in the LoWPAN
for filtering, management etc.
Additionally we have some ideas for security which the whiteboard may be
able to help with in the future (to enable a kind of SEND).
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.
Cache may be a bad analogy, I see your point. It is very similar to a
binding cache in MIPv6, and it does keep (soft) state about all IPv6
addresses registered to it.
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.
Right. Just brought up the implementation aspect as an example, I
remember Richard asked about that.
There is no state in a whiteboard that a network administrator would be
involved with. It is unlike DHCP, but more like a MIPv6 binding. There
are no addresses being doled out. Nodes register a binding with the ER.
The address generation function is stateless - requiring no
administration. A node could (and may very well) generate its own
address and register it with the same result (possibly needing more
NR/NC exchanges).
Agreed that we would not want a new component in the network, ERs
already exist, and they will already implement ND on their 6lowpan
interfaces. You would not install a "Whiteboard Server" somewhere in
your network, it comes built-into the 6lowpan interface driver on an ER
for example. Humans would not be in the loop here.
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.
Yep, DAD is the core feature.
So apart from a generic discussion about whiteboards - how about we
concentrate on technical details. As a WG we really need to check that
all the fine details here work - and if not suggest a way to fix/improve
them. We would like to submit -04 before the Stockholm cutoff.
--
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
--
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
