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, 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
