Before reading your post, I tended to think that managing different networks, one per gateway, would be the best approach. At least for non-mobile networks. Of course, what you suggest is far better as this adds a level of redundancy between gateways.
On 14 July 2010 00:36, Jon Smirl <[email protected]> wrote: > I added the Contiki and linux-zigbee lists.... > > On Tue, Jul 13, 2010 at 4:53 PM, Umberto Manzoli <[email protected]> > wrote: >> On 13 July 2010 20:47, Jon Smirl <[email protected]> wrote: >>> >>> PPP/SLIP are adding an unnecessary layer of complexity. For example >>> I'm not sure yet if they work right for IPv6. It also makes routing >>> more complex. Now the 802.15.4 LAN is hooked to the Ethernet LAN by a >>> PTP link instead of a direct connection. Broadcast packets are not >>> normally forwarded over PTP links so radvd is messed up. All of this >>> is making me learn a lot more about IPv6 than I wanted to. >>> >> The main problem is that PPP - because of the presence of a "type of upper >> protocol" field in its frame - can handle different protocols in its >> payload, so there are extensions for IPv6 and IPv6CP (IPv6 Control Protocol >> for PPP). Moreover, through LCP packets, it is possible to manage the status >> of the link, i.e. it is possible to send and receive alive packets to and >> from the device and thus to automatically disconnect from the serial device >> and make some further retries. >> RFC 5072 : IPv6 over PPP >> RFC 5172 : IPv6CP >> >> SLIP is not recommended for IPv6 operations and IPv6 extensions are not >> supported by all operating systems, as it is only a straight-and-forward way >> to encapsulate IP frames into a serial stream. There is no link control, >> neither different protocol handling. >> >> The big problem with PPP is that the connected device turns into a router, >> so a lot of Contiki routing stuff should be rewritten in order to process >> and forward IP packets (maybe in different context/prefixes). This means >> that device should answer to router-broadcast FE80::2 and forward them. >> The other main problem is that, as the connected device acts as a router, >> you cannot easily copy-and-forward packets from one interface to another, >> but you should route them. So radvd should/could run over the connected >> device and the 6LoWPAN nwk and the PPP link should be given different >> prefixes and a way to correctly define routing should be provided, at least >> at application level, once the PPP link is up. >> Again, it is supposed that Linux sets up a PPP link as a slave (i.e. similar >> way to the one you use when connecting to a standard modem). Thus, up to >> now, IPCP and IPV6CP do provide needed IPv4 addresses and IPv6 interface >> identifiers. As PPP means point-to-point, Linux do not forward neighbour >> discovery/solicitations over the PPP link. > > I'm about ready to declare that hooking these devices up over a PTP > protocol link is too much trouble. > > The alternative is the linux-zigbee model. That means treating the USB > stick as a dumb radio and running 6lowpan/RPL on the Linux host. > > I'm looking for a good routing solution to the multiple gateway > problem. Say you have a net of 200 RPL devices and five gateways. I > want the RPL devices to use the nearest gateway. I don't want the > packets making 10 hops to getting to a gateway that is far away. > > Complicating things more, my gateways are wired together with 1GbE. > How are the packets gong to figure out that it is faster to hop to a > gateway, use the 1GbE and then hop back into the RPL net. > >> >> Bye, >> UM >> > > > > -- > Jon Smirl > [email protected] > > _______________________________________________ > mc1322x mailing list > [email protected] > http://devl.org/cgi-bin/mailman/listinfo/mc1322x > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Linux-zigbee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
