On Sun, Nov 16, 2014 at 6:02 AM, Juliusz Chroboczek
<[email protected]> wrote:
>>> Is there interest in a stub-only implementation of Babel?  Should it be
>>> a standalone daemon, or should it be integrated in the HNCP daemon?
>
>> I think the most interesting thing would be reference code which implements
>> stub-only babel; does it even need to listen?
>
> Yes, it needs (1) to discover a default route and (2) to participate in
> the request/response sub-protocol (by replying "I have no idea" to any
> requests it gets).  Point (2) avoids a timeout when clearing a retracted
> route from the network.

To add a little mental context, I have just been thinking about the link layer
problem in general, and that of encapsulation...

:

Another question is that Homenet Router X, needs some sort of wireless
dongle to talk to these devices (I expect it is not 802.11 we are
talking about here). So I imagine there is some sort of existing
dongle that has a linux driver to talk to?
Does it already work in openwrt? What kind of interface does it
present? That device does not have any power constraints,
and could for example (probably) talk to another router Y with the
same dongle elsewhere in the house....

....

I have been looking over some of these 16 bit microcontrollers for
another project, the advent of FRAM is quite useful (for high rad
environments especially) and the power consumption, amazing. They can
run off a coin cell battery for 5 years and I figure you can easily
solar power them, also.

http://en.wikipedia.org/wiki/TI_MSP430 - .1ua Ram retention!

But they seem to have no inherent wireless capability, except whatever
you could hook up over the SPI bus. The Xcore
stuff is neat, and there are a zillion arm mcus with various
capability, and I (still making assumptions here, as the
Thread group has not published any specs I have seen yet) figure this
is a 6lowpan-like layer we are talking about here?

Zigbee has a very small native packet size.
http://www.lsr.com/white-papers/zigbee-vs-6lowpan-for-sensor-networks

(bluetooth is also interesting perhaps?
http://www.ti.com/ww/en/wireless_connectivity/sensortag/index.shtml?DCMP=PPC_Google_TI&k_clickid=
)

Doing hnetd + a routing protocol over bluetooth could be useful in
context with solving the link layer problems more generally.

And a 16 bit arch would be kind of novel for us...

So... it is not useful to speculate further. While I think many IoT
devices are arm based, it would be nice to know what sorts of chips
they are using, and to get a look at the toolchain and OS. ? (/me
makes eyes at nest folk) (?)

The higher end of the IoT world is all linux it seems. (It seems
strange to be referring to things like the beaglebone black, raspberri
pi, and parallela as high end... Aside: has anyone played with a
galieo?

)




> -- Juliusz
>
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet



-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to