Hi Carsten: We have one hop NUD in the draft. Any node that wants to pass a packet to a next-hop router must first register to that router using NR/NC. If the router is not a whiteboard then it will relay.
NR/NC serves a number of purposes: 1) the edge router handles DAD and transparent mobility. It May generate the address on behalf of the node. 2) the edge router validates address ownership and the right to use it if the node is a host 3) the edge router validates the right to forward packet from below if the node is a router 4) the next-hop router implements the Source address validation accordingly 5) the next-hop router validates that it has the resources to serve the node (simple call admission control, can be augmented by additional options) 6) NR/NC confirms liveliness and bidirectional reachability 7) NR/NC can carry additional information such as RPL DAO and MIP registration As opposed to NDP, this form of NUD is not symmetrical. Traffic from the router does not trigger our NR/NC. This helps conserve energy for low power nodes. Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of Zach Shelby >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: > >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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
