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