Hi Zach,
On Jun 10, 2009, at 8:53 AM, Zach Shelby wrote:
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.
I don't see the whiteboard as a good substitute for NUD - the
whiteboard knows it has heard from a node, but doesn't know that it
can actually communicate with that node. Using the whiteboard for NUD
also assumes that you mesh through the whiteboard. Note that using the
whiteboard for NUD is only really useful in mesh-under networks. For
route over, NUD using the whiteboard doesn't make any sense to me.
ND proxy is the real mechanism that enables extended LoWPAN
topologies. But again, a number of mechanisms in the BbR draft were
intended for mesh-under networks. In a route-over network, the
whiteboard isn't necessary to maintain routes.
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).
I guess we have different view points on this. In my mind, the
whiteboard is very similar to DHCP. The whiteboard is telling a node
whether or not it is OK to use an address, that is logically the same
as assigning the node that address. The whiteboard may assign a 16-bit
short address, for use with an IP address - that is exactly the same
as assigning the node that address.
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 vast majority of DHCP servers in use today don't require any real
network administration either. How many consumers really change the
DHCP settings on their $50 linksys router? But when something does go
wrong (e.g. dhcp server does not properly hand out addresses), those
consumers are left to wonder. The whiteboard (DHCP server) is another
component in the network, whether or not it is co-located on the ER
(linksys router).
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.
Agreed. We should get as much feedback as we can.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
