On Mon, Nov 17, 2014 at 9:20 AM, Henning Rogge <hro...@gmail.com> wrote: > On Mon, Nov 17, 2014 at 5:38 PM, Juliusz Chroboczek > <j...@pps.univ-paris-diderot.fr> wrote: >> If I understand Dave right, the idea is to switch things around: instead >> of having the Nest node speak a stub version of a Homenet protocol, you >> have a specialised Homenet node that speaks a degraded version of Nest's >> protocol (just like a babel-pinger node speaks both Babel and a degraded >> version of DNS). > > yes.
yes. > >> This solves the issue of unexpected routing pathologies (the Homenet node >> is participating in the native Homenet routing protocol, and hence doesn't >> introduce any new pathologies), as well as that of flash and RAM usage (the >> Nest node isn't running any new software). It does cause sub-optimal >> routing, though, unless the specialised node is at the right place in the >> network. > > If Homenet assume any "lightweight nodes" (e.g. a Nest node) speak IP, > then using ICMP might be an easy way to do this. > > If the node does not speak anything beyond its own protocol, I agree > it would need a special piece of code in the Homenet node. We are still quite in the dark about what we are dealing with here, and while the speculation is fun, it would be nice to truly grok the hw, code and ideas we are dealing with. My understanding of sensor networks is that they boot, request an address, and then periodically wake up to announce a bit of data - ¨The temperature where I am is now is 34C¨ - or ¨my address is about to expire, please tell me a new address in exactly 200ms when I am awake again¨ and ¨The window is open¨. The mere act of announcing a bit of data should be enough to refresh the route (or nd/arp?) table on the listening homenet router(s). The problem still remains of how to do address assignment to boxes that are not connected most of the time, and the problem of finding the right node to be the default gw for the sensor network as a whole (assuming it is also doing meshy routing itself) remains... As for address assignment I generally do p2p /128 routes... (This is something I basically do already with AHCP, distributing p2p routes out of a dedicated IPv6/64 subnet) As for a homenet house, consider the following topology (If you have a mail reader with proportional fonts, I also stuck this up at: http://pastebin.com/1dfgtbp1 ) R1| - - - N0 Motion detector / \ N9 weather station / \ / \ / \ / \ / \ / \ _______/_______________\____________ | | R2 | | N1 | | | | | |_______________N2____|_____________ | | | | | R3 | N3 | | | | | | N6 | |__________|_________________________| | | | | | N7 | | | | | N5 | | | | N8 | |________________|_R4______________CM| -----> (Internet) CM is a cable modem connecting R4 to the internet. R1, R2, R3, R4 are homenet routers, connected up every which way. R1 and R2 cannot directly reach R4. Nx are devices using whatever the heck protocol is connecting these sensor boxes together. (lest you think this is a contrived example, this is exactly the house armory.com has) Now, in this example, N1 can get to N8 and then R4 via its own protocol (probably), but a more robust and reliable method would be N1, N2, R2, R4, or it might be N1, R3, R4. But N0 needs to talk to R1 as everything else is too far away, and it is entirely likely that a more direct path from N1 to N2 OR N5 is blocked by a fireplace ... IF R1-R4 are all bridged together then things are possibly simpler, but different. I would imagine that all homenet routers would broadcast and receive packets from Nx in the hope that one or more would reach the right device. If they are all routed... As IPv6 addresses as distributed by certain providers are limited, a dedicated ipv6 subnet with p2p /128 routes, and whatever device had the best (signal strength?) should be the default gateway for it... So... how is a Nx network supposed to work with areas of disconnectivity? Range extenders? > > Henning Rogge > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
