Subject: Re: [6lowpan] "cry out loud" vs. "white board"

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Mar 2008 15:41:05 +0100

The point is:

The nodes does not need to listen for multicast, and the SOLLICIT mcst
can be actually be mapped onto a functional unicast address, in other
words a 16bits PAN local address that targets the backbone router, as
opposed to mac-level broadcast.

Pascal

>-----Original Message-----
>From: Benoit Lourdelet (blourdel)
>Sent: jeudi 20 mars 2008 14:10
>To: Carsten Bormann
>Cc: Jonathan Hui; Philip Levis; 6lowpan; Pascal Thubert (pthubert)
>Subject: RE: [6lowpan] "cry out loud" vs. "white board"
>
> Cartsten,
>
>If we push DHCPv6 to the limit, only the SOLLICIT is multicasted, the
rest of the messages (ADVERTISE,
>REQUEST (through the unicast option), and REPLY are unicasted).
>
>
>Regards
>
>Benoit
>
>-----Original Message-----
>From: Carsten Bormann [mailto:[email-masked]]
>Sent: Thursday, March 20, 2008 11:25 AM
>To: Pascal Thubert (pthubert)
>Cc: Carsten Bormann; Jonathan Hui; Philip Levis; 6lowpan; Benoit
Lourdelet (blourdel)
>Subject: Re: [6lowpan] "cry out loud" vs. "white board"
>
>On Mar 20 2008, at 11:02, Pascal Thubert (pthubert) wrote:
>
>> DHCP is the protocol of choice to perform the registration
>
>Wait a minute; DHCP uses broadcast (well, link-scoped multicast).
>So I don't know how much this helps as is.
>
>Gruesse, Carsten

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Porcu Giorgio" <[email-masked]>
Date: Tue, 25 Mar 2008 17:18:16 +0100

Hi Carsten,
thanks a lot for your fast answer. You get the point exactly! 

Carsten Bormann wrote:
>>I'd say: The "backbone router" as a SPOF is a problem *if* the network 
>>can do anything useful without the "backbone router".

For me it's important that nodes could communicate even without the "backbone router" up and running.
Not only for the SPOF problem but also for interoperability reason.
The main idea is that we can have many PANs that we can see like a single and wide PAN (at the L3). 

In my opinion it's important to have a mechanism (at the L3, depending on routing strategy) that many nodes could use to switch from a PAN into another one, as result of a backbone router crash or some other event.
A backup coordinator could be a naive strategy but, I think, the best is to converge into a single-standard solution (or one for routing strategy).

Maybe this aspect is a little out of scope for the draft in discussion but I think that some input and feedback we can get from ROLL WG.
What do you think?

Regards 
Giorgio

________________________________

Da: [email-masked] per conto di [email-masked]
Inviato: gio 20/03/2008 20.00
A: [email-masked]
Oggetto: 6lowpan Digest, Vol 38, Issue 27

Send 6lowpan mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/6lowpan
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of 6lowpan digest..."

Today's Topics:

   1. Re: "cry out loud" vs. "white board" (Carsten Bormann)
   2. Re: "cry out loud" vs. "white board" (Jonathan Hui)

----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Mar 2008 13:43:53 +0100
From: Carsten Bormann <[email-masked]>
Subject: Re: [6lowpan] "cry out loud" vs. "white board"
To: "Porcu Giorgio" <[email-masked]>
Cc: Carsten Bormann <[email-masked]>, [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

On Mar 20 2008, at 13:21, Porcu Giorgio wrote:

> But what happens within a PAN when a backbone router crashes? How 
> can a =
> node get routing info about other nodes belonging to its same PAN if 
> it =
> can't access the white board residing on the crashed backbone 
> router? =

I'd say: The "backbone router" as a SPOF is a problem *if* the network 
can do anything useful without the "backbone router".

If it can't (e.g., the whole point is connecting the sensors to some 
other node on the Internet), then the network can just fall apart (of 
course, the failure still needs to be battery-efficient, and there 
needs to be an orderly re-bootstrap when the/a backbone router comes 
up again).

If it can: you need to elect a new coordinator.  That might work best 
if there is a backup coordinator in operation all the time.
Multiple coordinator candidates do cause all the partition/merge 
problems that I won't go into right now.

A coordinator is also a useful thing to have for key management, so I 
believe it is best to think of the address management and key 
management problems in combination.

Gruesse, Carsten

PS.: Giorgio: You need to fix your mail setup: you should never send 
ms-tnef towards the Internet; I'm not sure how many people could even 
read your message.

------------------------------

Message: 2
Date: Thu, 20 Mar 2008 08:18:27 -0700
From: Jonathan Hui <[email-masked]>
Subject: Re: [6lowpan] "cry out loud" vs. "white board"
To: "Pascal Thubert (pthubert)" <[email-masked]>
Cc: 6lowpan <[email-masked]>, "Benoit Lourdelet \(blourdel\)"
        <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Pascal,

Pascal Thubert (pthubert) wrote:
> IID derived from the EUI-64 and Optimistic DAD can save some ND flows.
> But then again this is only dampening the shouting and in any case less
> efficient than white board approach.

Yes, IID from EUI-64 isn't the best solution for many cases. I was only
suggesting a quick-and-dirty possibility for those cases where a
centralized solution is not favorable.

> About implementing white board, my initial draft extends ND but I seems
> clear now that this will create confusion.  I'd rather follow Jonathan's
> view that DHCP is the protocol of choice to perform the registration.
> I'll have that in mind for version 01 and probably migrate to DHCP, and
> sollicit help of DHCP specialists.

I plan to address both SAA and DHCPv6 in a route-over autoconfiguration
for 6LoWPAN draft. We should coordinate our efforts to see if there's
some commonality. While I expect mesh-under and route-over to utilize
different mechanisms, it would still be good to make them similar in
areas that they do overlap. On a side note, I'm not sure we want to use
the formats as specified in RFC3315. I was thinking of scoping RFC3315
and making it less general to compress the DHCPv6 options formats.

For Carsten: DHCP does use link-local multicast, but such a restriction
hasn't stopped us from optimizing protocols in 6LoWPAN networks to
utilize unicast communication.

--
Jonathan Hui

> I'm not claiming that we get rid of ND, I'm saying that we propose a
> solution where NS and NAs are fully replaced by DHCP requests over the
> LoWPAN. We do not MUST or SHOULD the support of NS/NA and propose a
> clear DHCP based alternative. Whether we do mesh under or route over, it
> seems clear that DHCP will be supported, so the model will still work.
>
> The following tools already exist:
>
> RFC3315 (DHCPv6) that we can use to obtain a DADless address
> 
> RFC5007 : (Lease query for Ipv6) that we can use to sollicit another
> node's address.
>  
> For Carsten:
>
> http://www.ietf.org/internet-drafts/draft-van-beijnum-cga-dhcp-interacti
> on-00.txt
>
> explains that we do not need the dhcp server to generate the CGA
> address, a point that I certainly disagree with :)
>
> Pascal
>> From: Jonathan Hui [mailto:[email-masked]]
>> Sent: jeudi 20 mars 2008 02:41
>> To: Philip Levis
>> Cc: Pascal Thubert (pthubert); 6lowpan
>> Hi Phil,
>> Philip Levis wrote:
>>> I think the idea of a whiteboard is powerful. It definitely makes
> more
>>> sense than "shout out."
>> Yes. DHCP has proven itself useful, and for many reasons other than
> just
>> avoiding "shout out".
>>
>>> single coordinating node, however. Your text puts it precisely:
>>> "consider that LowPANs *usually* have a sink of some sort" (emphasis
>>> mine). Forcing this to be centralized requires such a node exist and
>>> therefore precludes certain kinds of LowPANs.
>> A solution may simply be to configure your IP addresses using an IID
>> derived from the EUI-64, which must be unique within a PAN. If you
>> really want automatic assignment of short addresses, then that's a
>> different beast. But it might not be worth the overhead.
>>
>>> That being said, this approach seems to implicitly assume mesh under?
>>> Nodes "use Neighbor Discovery to determine the link-layer addresses
> for
>>> neighbors known to reside on attached links and to quickly purge
> cached
>>> values that become invalid." ND could operate on a single hop basis.
>> Let's be clear on what kind of hop. I'm sure you meant a single 15.4
>> radio hop, not an IP hop.
>>
>>> This simplifies everything. The place where the whiteboard approach
> is
>>> necessary is for DAD. But given that the goal is eventual consistency
> on
>>> address assignment, it may be possible to distribute the table in an
>>> effective way.
>> While I agree it does simplify many things, it doesn't simplify
>> everything :-). RFC 4861 explicitly assumes multicast-capable links
> with
>> reflexive and transitive reachability. DAD is only one example. ND is
>> also used for redirect and to propagate network parameters. In a
>> route-over configuration, the mechanisms currently defined aren't very
>> useful in a route-over 15.4 PAN. I'm currently signed up to work on an
>> I-D that addresses this case, as it is an interesting case to consider.
>>
>> --
>> Jonathan Hui
>

------------------------------

End of 6lowpan Digest, Vol 38, Issue 27
***************************************