Hello, > Sleeping in Contiki is done with a duty-cycled radio mechanism where the > radio is switched off for most of the time and turned on for a few
My concern for this sleeping method is very low power nodes. These would be parasitic nodes for example that can only wake up every few seconds at most. These super-low power nodes could not listen continuously. Forcing them to require waking up would basically eliminate them from the picture. Regards, -Colin -----Original Message----- From: Adam Dunkels [mailto:[email protected]] Sent: October 13, 2009 6:16 PM To: Colin O'Flynn Cc: 'Julien Abeille (jabeille)'; '6lowpan' Subject: Re: [6lowpan] Fundamental concerns about 6lowpan ND Colin O'Flynn wrote: > Yes, but is Contiki a usable implementation for what we want to do? > > > > How well does sleeping or mesh routing work for instance? That is what I > mean by an implementation that uses full ND6 - someone doing mesh + > sleeping + RFC4861/2. Sleeping in Contiki is done with a duty-cycled radio mechanism where the radio is switched off for most of the time and turned on for a few milliseconds to check for radio activity. If there is radio activity, the radio is kept on to receive the full packet. To send a packet, the sender sends a string of strobe packets to wake up the receiver. This type of mechanism reduces the power consumption (typically to < 1% of the radio transceiver power) without affecting the abstraction provided by the link layer: nodes appear to be awake all the time, even if they spent most of their time sleeping. /adam > > > Regards, > > > > -Colin > > > > > > *From:* Julien Abeille (jabeille) [mailto:[email protected]] > *Sent:* October 13, 2009 2:23 PM > *To:* Colin O'Flynn; 6lowpan > *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND > > > > Hi Colin, > > > > any stack that passes IPv6 ready tests does, i know two of these, one > being Contiki/uipv6. > > > > Best, > > Julien > > > > ------------------------------------------------------------------------ > > *From:* Colin O'Flynn [mailto:[email protected]] > *Sent:* lundi 12 octobre 2009 18:46 > *To:* Julien Abeille (jabeille); '6lowpan' > *Subject:* RE: [6lowpan] Fundamental concerns about 6lowpan ND > > Hello, > > > > I understand the problems with 'redesigning' a core IPv6 protocol. > > > > However I'm curious about existing implementations that use full > IPv6 ND, do you have details? > > > > I see the 6LoWPAN ND as a 'necessary evil', however I would love to > be proven wrong! > > > > Regards, > > > > -Colin > > > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Julien Abeille (jabeille) > *Sent:* October 12, 2009 1:47 PM > *To:* 6lowpan > *Subject:* [6lowpan] Fundamental concerns about 6lowpan ND > > > > Dear WG, > > > > I have serious concerns about the 6lowpan ND draft and would like to > have the WG opinion on this. I agree that a few issues arise in > lowpan environments, which are mostly linked to the non transitivity > of some link layers used in lowpans. However, my two major points of > concern are: > > - RFC4861 and RFC4862, which are core to IPv6, are being very > heavily redesigned. I believe that the proposal if it is done in > 6lowpan MUST be designed as an optional extension to ND, not a > redesign. The charter states that the draft should propose > "optimizations" and "limited extensions" to ND. It is not the case > at the moment. The proxy ND proposal, the mandatory addressing model > proposed, also goes beyond the scope of the document as spelled out > in the charter. > > - non transitivity is not a lowpan only issue, hence if adaptations > to ND must be done, it should be in another WG, probably 6man > > > > If these two points are not respected, > > - it questions the applicability of IPv6 in smart object networks: > the draft is redesigning roughly 80% of RFC4861 and RFC4862, which > are core to IPv6 > > - existing IPv6 implementations will be strongly impacted, as a > number of major components will have to become layer 2 dependant: > > -- address resolution will have to be disabled > > -- DAD will have to be modified > > -- NUD will have to be modified > > -- prefix discovery will have to be modified > > -- autoconf will have to be modified > > -- IPv6 addresses will not be configurable if their IID is not based > on the MAC address > > -- ... all these changes are 6lowpan dependant, as they do not > impact traditional links. This will raise important interoperability > issues. > > - new layer 3 protocol designs will become layer 2 dependant. This > is what is currently happenning in the ROLL WG by proposing to use a > different message to transport routing information, depending on the > medium. > > > > Moreover, a number of existing deployments show that the issues > arised on lowpan networks as far as ND is concerned are not huge: > the deployments work, and ND as it is has proven to be power > consumption friendly. DAD is the most problematic procedure, that > requires work, as two hop neighbors do not see NS sent for DAD (see > at the bottom) > > > > In conclusion, I believe the advantages of rebuilding neighbor > discovery for lowpans are by far inferior to those of keeping using > the "same IP" on all medium. If some redesign has to be done, it > MUST be done in a more general fashion, probably in 6man, and in a > much lighter way. > > > > Best, > > Julien > > > > DAD issue description: > > node A and node C see node B, but not each other. nodes A and B > boot, configure a link local address, perfom traditional DAD. It > works. Node C boots with the same MAC address than A, configures the > same IP address, sends a NS to perform traditional DAD. A does not > see the NS hence C address configuration works. A and C have the > same address. B will not differentiate A and > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan -- Adam Dunkels <[email protected]>, +46707731614 http://twitter.com/adunk | http://www.sics.se/~adam/ _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
