On Mon, Jul 15, 2013 at 1:24 PM, Tony Cheneau <tony.chen...@amnesiak.org> wrote: > Hi Jon, > > [...] > > >> I haven't tried running the code yet, but does it support routing >> between two network interfaces? For example could it route between >> 802.15.4 and Ethernet? That is one of the key features of the BATMAN >> implementation. > > Yes, simpleRPL handle system with multiple network interfaces. I haven't > tested a mix of IEEE 802.15.4 and Ethernet, but I don't see any reason why > it would fail. I tested the two of link technologies independently, and I > tested the multi-interface aspects using ethernet-only links (actually, it > was my development platform).
One issue is six byte versus eight byte MAC addresses. I believe there is a Linux API that lets you determine the link type but it has been too long since I have used it. It will return ARPHRD_IEEE802154 or ARPHRD_IEEE802 (? for Ethernet), wifi ARPHRD_IEEE80211 > > >> BATMAN let you set up a wifi based mesh. You can connect any of those >> wifi mesh points with Ethernet and BATMAN will route over the Ethernet >> and assign it zero cost in the routing algorithm. > > I used BATMAN a long time ago, and indeed, it was pretty straightforward to > setup a network that would span over multiple network interfaces. SimpleRPL > will not work in the way you describe (see more below), but RPL does > encourage such a behavior. > > >> The same model occurs in the 802.15.4. Suppose you had a whole >> building wired 802.15.4. Everything becomes one big subnet mesh. But >> now you add a 802.15.4/Ethernet router on each floor. Those Ethernet >> links can obviously save a lot of hops. Note that all of the 802.15.4 >> nodes make one big subnet. So those Ethernet jumps need to happen >> inside the RPL calculation otherwise you'd need to make one subnet per >> floor. > > For the "calculation" part, each nodes computes a rank for its parent > (depending on the objective function) in order to elect its preferred > parent. Because simpleRPL can't obtain (yet) information from the underlying > link layers (the linux kernel does not seem to export any indication on the > link quality), the rank increase is fixed. This means that the path > computation favors shorter paths. While this is OK for my own purpose, I can > understand it could be an issue to some. For the case you indicated (mixing > 15.4 and Ethernet), the fact that simpleRPL does not properly handle rank > increases would mean that an ethernet link will always not be favored to a > 15.4. > > I hope it answers you question. > > Regards, > Tony -- Jon Smirl jonsm...@gmail.com ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
