Subject: Re: [6lowpan] Whiteboards

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 27 Nov 2009 13:39:08 +0100 (CET)

Hi LoWPANners,

Me and other colleagues here at UPC believe that DAD is necessary in many
contexts, specially, given the counterfeiting and manufacturing error
phenomena that may occur.

We also believe that the whiteboard mechanism is a nice solution that
makes DAD possible in a very appropriate way. In addition, the whiteboard
offers other interesting features (e.g. support for node location and
mobility in extended lowpans).

That being said, it is also true that there may be some particular
scenarios where DAD may not be required (or could be performed in other
ways). Then, the whiteboard mechanism could be made optional. But if
interoperability cannot be assured in that case, then we would support the
whiteboard mechanism being a MUST.

Thanks,

Carles

> I agree with the recent proposal to remove the mandatory requirement for
> a whiteboard and duplicate address detection.
>
> However, 16 bit 802.15.4 addresses are a very useful optimisation.
> Assigning these in a standard way is important in the absence of a
> whiteboard.  One option may be to use DHCPv6.  However, the DHCPv6
> packet sizes are quite large and so some sort of DHCPv6 message
> compression would be useful. Extended LowPANs would also be useful in
> some applications.
>
> If the whiteboard and DAD are removed, I would like the issues of 16 bit
> address assignment and extended LowPANs to still be addressed by an RFC
> within the IETF 6LowPAN group, rather than having several different non
> interoperable implementations.
>
>
> --
> __________________________________________________
> Daniel Gavelle, Software Engineer
> Tel: +44 114 281 2655
> Fax: +44 114 281 2951
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
> Comp Reg No: 3191371  Registered In England
> http://www.jennic.com
> __________________________________________________
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Nov 2009 12:53:44 +0100

On Nov 27, 2009, at 13:39, Carles Gomez Montenegro wrote:

> interoperability

The idea behind the split of the draft was that, at the host-router interface, it does not matter whether/in what way DAD is performed, so 6LoWPAN hosts will be interoperable with any way we do this.

Now, within the "fabric" (set of 6LoWPAN routers and possibly edge routers), the interoperability becomes more interesting.
In particular it would be useful to enable routers with minimal memory requirements to work together with larger routers that provide additional services.  (That was also the idea between the router/ER dichotomy, but it seems we need a more flexible assignment of functions.)  It would be nice if all the alternative ways of running the fabric I mentioned in my split proposal wouldn't lead to different, non-interoperable protocols.  I think that can be done, but a design with many options is significantly more complex than one that can be limited to a single model.  Fortunately, this complexity is limited to the routers/ERs; hosts don't have to care.

Gruesse, Carsten

---

From: Zach Shelby <[email-masked]>
Date: Mon, 30 Nov 2009 15:45:14 +0200

> The idea behind the split of the draft was that, at the host-router interface, it does not matter whether/in what way DAD is performed, so 6LoWPAN hosts will be interoperable with any way we do thi…

Exactly. 

> In particular it would be useful to enable routers with minimal memory requirements to work together with larger routers that provide additional services.  (That was also the idea between the route…

There is actually another nice side-effect of this split. It turns out that for LoWPANs with just a single router (mesh-under), the host-router interface mechanism already provides DAD as the binding table has that information. 

For LoWPANs realizing an extended LoWPAN, this also achieves DAD as well. 

For simple route-over LoWPANs the split might also help us out by allow us to re-use the registration mechanism as one option. I don't have a big problem with achieving DAD within the fabric in a couple different ways, but would prefer a single way if possible.

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
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.