Hi,
Richard Kelsey wrote:
Date: Wed, 10 Jun 2009 18:53:43 +0300
From: Zach Shelby <[email protected]>
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.
Zach,
Requiring that Edge Routers have a whiteboard was a
significant change from -02 to -03. I am concerned because
the whiteboard is a single point of failure and because of
the memory required to store it.
I called out to the list before making the change, didn't hear
complaints, sorry if you missed that.
Yes, if an Edge Router has a full IPv6 stack, or generally
has plenty of memory, it should certainly have a whiteboard.
In an extended LoWPAN, the Edge Routers clearly have to
have whiteboards. My concern is with ad-hoc networks of
small devices.
Got you, so its just the ad-hoc case that worries you... For Simple
LoWPAN and Extended LoWPAN cases the whiteboard should definitely be a
built-in feature.
I agree that the ad-hoc case is a question mark. In the previous version
it was discussed that a router in the Ad-hoc LoWPAN could optionally be
configured with a whiteboard, and thus provide the services that a
Simple LoWPAN does. At the minimum some router in the Ad-hoc LoWPAN MUST
be configured to generate a ULA prefix and disseminate that to other
routers.
The problem we got into, was how to advertise and detect if a whiteboard
is supported or not as it was also optional for Simple LoWPANs. So if
there would be no whiteboard in an Ad-hoc LoWPAN, how would a node
detect there is no whiteboard feature, and then operate after that? In
practice you would then have no ER at all in an Ad-hoc LoWPAN.
1. We do have an error code (code 129) which a router can respond with
to tell a node that no ER is available, so trial and error?
2. Or would we define that if a node sees an RA with a ULA prefix, then
it assumes there is no whiteboard? Then there really is no whiteboard
support at all in an Ad-hoc LoWPAN.. fine by me.
3. Or routers in an Ad-hoc LoWPAN could set the M flag to 0 in the RA to
indicate if there is no ER.
4. Or all of the above?
I would say that #3 is the most logical. And #2 would also be a behavior
in case a node did try to register.
Then there is the question of how an Ad-hoc LoWPAN really functions
after that. All addresses would stay optimistic, we would probably need
to require node to implement NS/NA (now not required, and which don't
work well over multiple hops and with sleeping nodes), you would be
stuck with EUI-64 optimistic addresses (and pray they are unique), and
short-address assignment is out of scope. We would almost be falling
back to RFC4861 - although 6lowpan-nd still has some useful
simplifications for this case as well.
What do others think, is this a concern? Do we just run Ad-hoc LoWPANs
with no ER at all by default? If so, what is the simplest way to detect
this, and are you happy with how the network will function after this?
- Zach
It looks to me as if a whiteboard entry requires at least 20
bytes or so, or 2k bytes for a 100-node network. Fitting
that into an embedded device with, say, 6k of RAM is going
to be difficult. If the core benefit is detecting duplicate
EUI64s, it really doesn't seem worth the trouble. As I
mentioned before, having the Edge Router assign 16-bit IDs
helps with header compression, but is not required for
routing.
As to the technical details, if DAD is the main purpose of
the whiteboard, it seems to me that it might be able to do
so in a more timely fashion. As I understand the protocol,
if a second node appears with the same EUI64 as a device
already in the network, the collision will not be detected
until the existing device renews its registration. The
first appearance of the new device will be treated as a
reboot by the original one. Would it be OK to require that
routers keep address data in non-volatile memory? If not,
is the collision going to have to be re-detected every time
the colliding device reboots?
The collision is detected immediately in that case. With the TID you
would allow the first one to continue operating. So the newer one loses.
Agreed that we need to go over all the cases in detail again, surely
there are still some bugs.
By the way, if two devices with the same EUI64 are powered
up or reboot at the same time, it looks to me as if the
conflict might never be detected. Assuming that the Edge
Router gives them the same registration lifetimes, the two
TIDs will move forward in leap frog fashion, never getting
more than one removed from each other.
That could theoretically occur, any suggestions how to avoid that?
With Carsten we have noticed some other fine points to improve in the
DAD mechanism using TIDs, so all suggestions helpful.
We also need to detail the registration rules for addresses better to
avoid any problems there (a ticket on that is coming).
Thanks,
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
