Hi Zach, > -----Original Message----- > From: Zach Shelby [mailto:[email protected]] > Sent: mercredi 14 octobre 2009 20:45 > To: Julien Abeille (jabeille) > Cc: Carsten Bormann; 6lowpan > Subject: Re: [6lowpan] Fundamental assumptions of > 6lowpan-nd-06: (1) Addressresolution is a waste of energy > > On Oct 14, 2009, at 18:05 , Julien Abeille (jabeille) wrote: > > > Hi Carsten, > > > > I got the mesh under point. > > Do we agree that > > - in route over > > - considering duty cycled nodes with efficient duty cycling > techniques > > (smapled listening, centralized scheduling) > > (RFC4861) AR works (I can resolve addresses of one hop > neighbors), NUD > > works, > > AR and NUD initiated by an RFC4861 interface on an Edge > Router will fail in route-over configurations for any > destinations outside of radio range. This is the result of > the non-transient link: Yes, this is the point. In route over you do not want to resolve two hop neighbors. Otherwise you will use their MAC as L2 destination of any message, and it will not reach them. You want to resolve and confirm reachability of one hop neighbors only. It works and is more power efficient than a multihop unicast to the sink if - average number of neighbors + 1 < 2 x average number of hops to the sink.
Julien > > ER ---- A ---- B ----- C > ++++++ > > As you concluded, NS/NA is only useful within radio range. > Let's assume ER and A are within radio range. ER attempts to > send to C. What happens to the NS? Fails. This is why I don't > see RFC4861 without any adaptation as a solution on a LoWPAN > interface. It expects that NS/NA messages reach the whole > subset of nodes on the link, but that is not the case. > > This is the reason why we have a whiteboard with entries for > all LoWPAN nodes (A, B, C). For all AR, NUD and DAD requests > coming from the ER side it is able to answer them immediately > (without any overhead to the LoWPAN!). The whiteboard also > enables DAD for NRs coming from the LoWPAN side. > > I agree that within the LoWPAN some kind of 1-hop NUD may be > useful, and that should be discussed. > > Zach > > > > router and prefix discovery... Work > > DAD fails > > In other terms features related to reachability of one hop > neighbors, > > resolution of their address, router/parameter/prefix discovery work? > > Addressing related features fail? > > > > Julien > > > >> -----Original Message----- > >> From: Carsten Bormann [mailto:[email protected]] > >> Sent: mercredi 14 octobre 2009 16:50 > >> To: Julien Abeille (jabeille) > >> Cc: 6lowpan > >> Subject: Re: [6lowpan] Fundamental assumptions of > >> 6lowpan-nd-06: (1) Addressresolution is a waste of energy > >> > >>> it does. We also need to understand, what IP advantages we > >> keep with > >>> 6lowpan-ND, what we loose, in terms of reusability, > >> simlicity, cost... > >> > >> There is no change to IP. > >> > >>> - reusability: we reevent protocols per link type. This > one can get > >>> important when it comes to education, network management... > >> > >> It's much better to have a new protocol than to misuse an old > >> protocol in ways it never was designed for. > >> > >>> A. one camp assumes although nodes are sleeping, well known and > >>> deployed duty cycling techniques makes nodes appear > always on. The > >>> other camp thinks there are always nodes that cannot be > >> reached 100% > >>> of the time. > >> > >> I think 6lowpan-ND must cope with both kinds of nodes. > >> In general, that makes all protocol mechanisms that expect > hosts to > >> react to unsolicited messages somewhat difficult. > >> > >>> C. one camp considers the link asymetric. IP applications > will not > >>> work in this scenario either. I do not think we are in a UDLR > >>> environment > >> > >> Well, there is no assurance of symmetry, but I'm not sure what you > >> mean here. > >> > >>> D. we all agree we are considering a route over scenario > >> > >> I don't agree with that. > > Got it. > >> 6lowpan-ND should work for mesh-under as well, and should > not require > >> LoWPAN-wide multicast for that. > >> 6lowpan-ND should also work in a minimal "star network". > >> > >>> For those who think duty cycling solves the sleeping nodes issues: > >>> - only DAD fails. Do we agree on this? > >> > >> 4861 DAD (and everything else that would require multicasting NS > >> throughout a LoWPAN) fails independent of sleeping nodes. > >> > >>> For those who sleeping nodes are a problem: > >>> - AR, NUD, DAD fails > >> > >> 4861 AR (and everything else that would require multicasting NS > >> throughout a LoWPAN) fails independent of sleeping nodes. > >> Wait, 4861 does not even *specify* AR for NBMAs, so nothing is > >> failing, it's just not there. > >> (To return to the subject of this thread: Losing AR > apparently is not > >> a problem.) > > I'll stop on semantics > >> > >> NUD is interesting, because 4861 uses it for a number of things. > >> Maybe we can return to this later. > >> > >> Gruesse, Carsten > >> > >> > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lowpan > > -- > 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
