Hi Jonathan, I think we're on sync. All I claim is that for the specific purpose of ND over LoWPAN, the white board model is more efficient then multicast; and that the different is most apparent when we're doing multihop (mesh under). I do not want to ban work on multicast. But if we have a preferred solution that do not depend on specific mesh under / mac variation for broadcast/multicast support, it's all the better. If that solution enables scaling with a BbR for no additional control, well, fine.
Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: mercredi 12 décembre 2007 19:02 >To: Pascal Thubert (pthubert) >Cc: Geoff Mulligan; Timothy J. Salo; 6lowpan >Subject: Re: [6lowpan] ND optimization for sensor nodes (power >saving/ Idle/Sleep mode) > > >Hi Pascal, > >Yes, I do see a bunch of cases where BrB and "white-board" may >make a lot of sense. But, we're drifting a bit from the >genesis of this discussion. The proposed statement from Tim >was to place a moratorium on the use of multicast in proposed >solutions. My suggestion is that this statement is over >constraining. One such example where multicast may be useful >is in route-over networks. Link-local multicast only has a >scope of a single radio transmission hop and is often done by >either implementing or emulating broadcast at L2, which most >energy-management protocols for 802.15.4 support. > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan and Geoff: >> >> This makes sense to me. Now; >> >> The BrB draft is 2 fold; part of it is routing from to the >backbone and the Internet; and part of it is white board >concept applied to 6LoWPAN. We could separate the features in >2 drafts, but it seems simpler to specify that the >implementation of the proxy part towards the backbone be >required only when there is a backbone in the first place. >> >> It also seems that the white board is a good approach >regardless of whether we have a backbone or not, considering >the very nature of the LoWPAN. We can do a very refined >multicast support and try to approach the energy cost and >latency that we get with the white board model; but it seems >to me that the nearest to that grail we could get, the more >states we'd add in nodes all around, and still we'd never get >as good as white board. I've no handy proof of this assertion, >but I'd be surprised and quite interested to be proven wrong. >> >> Also, it makes sense that the behavior of the motes be the >same whether there's a backbone or not; if we recognize the >need for the backbone router for a number of supported >situations, and if we agree that the white board approach >enables the registration for the proxy function transparently, >then isn't it the fair approach overall? >> >> In all of the architectures and deployments I've seen, there >is always a special box, called a sink, a router, a manager or >a gateway, that plays a central role for the LoWPAN. The case >when that special box does not exist seems really remote, so >we can quite safely assume that the special box exists and is >a good candidate for the white board. >> >> Does that make sense? >> >> Pascal >> >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >>> Sent: vendredi 7 décembre 2007 23:20 >>> To: Pascal Thubert (pthubert) >>> Cc: Timothy J. Salo; 6lowpan >>> Subject: Re: [6lowpan] ND optimization for sensor nodes (power >>> saving/ Idle/Sleep mode) >>> >>> >>> Hi Pascal, >>> >>> The backbone solution proposed in your draft targets a particular >>> configuration and we should definitely consider it. >>> Though I strongly believe that we are going to see different >>> 6LoWPAN/802.15.4 network configurations. There may be some that do >>> not connect to the Internet and do not require or cannot afford a >>> router. There may be others that choose a route-over approach vs. >>> mesh-under. I just want to reiterate my wish that we don't >force the >>> WG into a solution space that only covers a particular >>> 6LoWPAN/802.15.4 configuration. >>> Instead, we should consider a few representative configurations as >>> Tim suggested. While it'd be great to see a single solution satisfy >>> all of them, we should be open to having different ones if needed. >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi >>>> >>>> I tend to agree with Tim here; multicast is a complex issue >>> in the low >>>> power / sleepy space. It's even unclear which WG should be >>> responsible >>>> to define it. >>>> >>>> Back to basics, there are basically 2 extreme models to locate >>>> somebody; cry out loud or white board. ND on Ethernet uses >the first >>>> model based on multicast. Mobile IP uses the second. When >>> you look up >>>> a mobile node on the Home Link, the Home Agent is the >reference that >>>> responds the ND requests on behalf of the mobile nodes. >>>> >>>> So my question is: Should we take as granted that ND on the LoWPAN >>>> requires multicast? Maybe the white board model based on >unicast is >>>> enough, in which case we get rid of a very difficult dependency. >>>> Considering that there is a need for a router that >>> understands 6LowPAN >>>> to connect the LoWPAN to the Internet, that router is the natural >>>> location for a white board. >>>> >>>> So the concept of backbone router is this: cry out loud on >the high >>>> speed backbone that federates LoWPANs, and white board on >>> the LoWPAN, >>>> and ND proxying to federate the whole thing. The backbone router >>>> implements ND proxying in a fashion that is compatible with >>> mobile IP >>>> so one day, sensors with a global address can move away and stay >>>> virtually there. >>>> >>>> In the meantime, a link local address is enough to connect >>> to any node >>>> in the network federated by backbone routers, and a mote can >>> move from >>>> a backbone router to another within the federated network without >>>> renumbering. >>>> >>>> The story begins in >>>> >>> >http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-rou >>> t >>>> er >>>> -00.txt :) >>>> >>>> Pascal >>>> >>>> >>>>> -----Original Message----- >>>>> From: Timothy J. Salo [mailto:[EMAIL PROTECTED] >>>>> Sent: Thursday, December 06, 2007 11:11 PM >>>>> To: 6lowpan >>>>> Subject: Re: [6lowpan] ND optimization for sensor nodes (power >>>>> saving/ Idle/Sleep mode) >>>>> >>>>> Samita Chakrabarti wrote: >>>>>> ... That way, periodic RA will not wake up all the nodes in the >>>>>> 6lowpan. ... >>>>> To the best of my knowledge, 802.15.4 implementations >>> power-down the >>>>> radio when the system sleeps. As such, a broadcast >packet does not >>>>> wake a sleeping 802.15.4 node. >>>>> Rather, the packet is simply never received by the sleeping node. >>>>> >>>>> If my understanding about this behavior is incorrect, >>> someone please >>>>> correct me. I have been meaning to check and see what the >>> spec says >>>>> about this, but haven't yet... >>>>> >>>>> Given that the response to broadcast packets differs in 802.16 >>>>> networks (where an idle node wakes to process the packet) and >>>>> 802.15.4 networks (where a sleeping node is never even >aware of the >>>>> packet), different solutions are probably required. >>>>> >>>>> To reiterate what I have said before, I believe that we must >>>>> explicitly specify the behavior we expect of multicast in 6lowpan >>>>> networks that contain sleeping nodes. In particular, does >>> multicast >>>>> mean "received by the potentially very small percentage of >>> the nodes >>>>> that aren't currently sleeping" or might it mean >"received by every >>>>> node after they wake up [whenever day that might be]"? After we >>>>> specify the behavior of multicast, then we can then try to >>> figure out >>>>> whether we can actually implement that behavior in a useful way. >>>>> >>>>> In the interim, I suggest a moratorium on simply assuming that >>>>> multicast is a potential solution to any of the >challenges we face >>>>> (e.g., duplicate address detection, router announcements, >neighbor >>>>> discovery, ...) >>>>> >>>>> -tjs >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> [email protected] >>>>> https://www1.ietf.org/mailman/listinfo/6lowpan >>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> [email protected] >>>> https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
