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 PROTECTED] per conto di [EMAIL PROTECTED] Inviato: gio 20/03/2008 20.00 A: [email protected] Oggetto: 6lowpan Digest, Vol 38, Issue 27 Send 6lowpan mailing list submissions to [email protected] 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 PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] 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 PROTECTED]> Subject: Re: [6lowpan] "cry out loud" vs. "white board" To: "Porcu Giorgio" <[EMAIL PROTECTED]> Cc: Carsten Bormann <[EMAIL PROTECTED]>, [email protected] Message-ID: <[EMAIL PROTECTED]> 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 PROTECTED]> Subject: Re: [6lowpan] "cry out loud" vs. "white board" To: "Pascal Thubert (pthubert)" <[EMAIL PROTECTED]> Cc: 6lowpan <[email protected]>, "Benoit Lourdelet \(blourdel\)" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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 >> -----Original Message----- >> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >> Sent: jeudi 20 mars 2008 02:41 >> To: Philip Levis >> Cc: Pascal Thubert (pthubert); 6lowpan >> Subject: Re: [6lowpan] "cry out loud" vs. "white board" >> >> >> 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 > ------------------------------ _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan End of 6lowpan Digest, Vol 38, Issue 27 *************************************** _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
