Subject: [Roll] Implementing gateway routers

From: Jon Smirl <[email-masked]>
Date: Tue, 6 Jul 2010 11:15:13 -0400

I've been working with the Contiki RPL implementation.  There are two
ways to make gateway routers....

Linux hosted - RPL runs on Linux and 802.15.4 device is treated as a
serially attached radio peripheral
MCU hosted - RPL runs on MCU, Linux uses PPP/SLIP to talk to MCU/radio
over SPI/USB.

There are multiple gateways attached to the RPL network.

Which of these two architectures is better to implement? The same
hardware can be used for both models. The MCU can run a small program
that makes it look like a serially attached radio.

Are there any advantages in integrating RPL/6lowpan into Linux's
networking code? The project has already been started (linux-zigbee),
I'm trying to figure out which model to work further on. It's not
obvious to me how these two models interact with multiple gateways to
the RPL network.

-- 
Jon Smirl
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 06 Jul 2010 21:29:04 +0200

Hmm... this is interesting, let me try to picture to see if I understand
correctly.

(I am also listening to RPL expert implementation opinion).

>  serially attached radio peripheral

         o antenna
         |
         |    ------   PC bus   ------  eth0
         +---|802154|----------|Linux |---
             |device|          |"host"|
              ------            ------

To my speculative reading this would be a very easy way to go, because
RPL implementation could have access to Linux's host memory and CPU
ressources.  I would try this first.

> MCU hosted - RPL runs on MCU, Linux uses PPP/SLIP to talk to
> MCU/radio over SPI/USB.

         o antenna
         |
         |    ------   USB      ------  eth0
         +---|MCU   |----------|Linux |---
             |device|PPP/SLIP  |"host"|
              ------            ------

I see a need to take IP-over-serial into account.

I think in this case the MCU should be able to have two interfaces: one
on which it runs RPL and another (USB serial) on which it doesn't.  And
IP route between the two ("route -n" shows two distinctive routes, the
one towards serial being probably the default).

> There are multiple gateways attached to the RPL network.

Hmm... if one wants to have these gateways interact on their egress,
using some non-RPL protocol (ND, OSPF), then one would prefer to have
the RPL implemented in the first figure... because it would be hard to
make non-RPL implementations on the MCU.

> that makes it look like a serially attached radio.

Could the MCU also implement non-RPL stuff: ND and OSPF to talk to the
Linux "host"?

> networking code?

WEll sure there are, IMHO.  At least if IPv6-over-802154 (6lowpan's
RFC4944) is implemented in the main linux kernel trunk.

> The project has already been started (linux-zigbee), I'm trying to
> figure out which model to work further on. It's not obvious to me
> how these two models interact with multiple gateways to the RPL
> network.

Just two cents worth.

Alex

---

From: Jon Smirl <[email-masked]>
Date: Tue, 6 Jul 2010 16:07:06 -0400

>> ways to make gateway routers....

There are two types of hardware involved:
   embedded CPU with SPI attached radio - like a Atmel RF230.
   USB sticks with microcontroller and radio

The SPI radio has no microcontroller so it is forced to run
6lowpan/RPL on the Linux host.  6lowpan/RPL support has been partially
implemented on Linux but the implement is not complete.

The USB stick has a choice, it can pretend to be a dumb radio or it
can run a full TCP/IP stack and talk to the host using SLIP/PPP. I
have this type of hardware.

>        +---|802154|----------|Linux |---

Contiki has already implemented a dual interface gateway - SLIP and 6lowpan/RPL.
It works fine with one gateway.

> make non-RPL implementations on the MCU.

That's the core part of my question, how do you set up routing with
multiple gateways when the gateways are using SLIP/PPP to talk to
their host? If that's too hard to set up then the better option is to
run 6lowpan/RPL on the host and treat the microcontroller like a dumb
radio.

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

-- 
Jon Smirl
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Jul 2010 23:19:49 +0200

Le 06/07/2010 22:07, Jon Smirl a écrit :
>> Hmm... this is interesting, let me try to picture to see if I
>> understand correctly.
>>
>>> I've been working with the Contiki RPL implementation.  There
>>> are two ways to make gateway routers....
>
> There are two types of hardware involved: embedded CPU with SPI
> attached radio - like a Atmel RF230. USB sticks with microcontroller
> and radio
>
> 6lowpan/RPL on the Linux host.  6lowpan/RPL support has been
> partially implemented on Linux but the implement is not complete.
>

That USB stick sounds interesting.  Can you set up a SLIP interface on
it?  If yes then can you set IP forwarding on it (proc sys net
ip_forwarding 1)?   Can you run ND on that interface, on the USB stick?

Does the stick run some form of linux at all?

>>> Linux hosted - RPL runs on Linux and 802.15.4 device is treated
>>> as a serially attached radio peripheral
>>
>> o antenna | |    ------   PC bus   ------  eth0
>> +---|802154|----------|Linux |--- |device|          |"host"|
>> ------ ------
>>
>> To my speculative reading this would be a very easy way to go,
>> because RPL implementation could have access to Linux's host
>> memory and CPU ressources.  I would try this first.
>>
>> o antenna | |    ------   USB      ------  eth0 +---|MCU
>> |----------|Linux |--- |device|PPP/SLIP  |"host"| ------ ------
>>
>> I think in this case the MCU should be able to have two
>> interfaces: one on which it runs RPL and another (USB serial) on
>> which it doesn't.  And IP route between the two ("route -n" shows
>> two distinctive routes, the one towards serial being probably the
>> default).
>
> Contiki has already implemented a dual interface gateway - SLIP and
> 6lowpan/RPL. It works fine with one gateway.

Ah?  I doubt Contiki could run on the USB stick too.

>> Hmm... if one wants to have these gateways interact on their
>> egress, using some non-RPL protocol (ND, OSPF), then one would
>> prefer to have the RPL implemented in the first figure... because
>> it would be hard to make non-RPL implementations on the MCU.
>
> their host?

To my speculative thinking: if the USB stick can set up a SLIP
interface, and see it with 'ifconfig' and add routes on the USB stick
that are visible on it with 'route -n' running on stick then it's
straightforward to set up routing between these sticks, their hosts and
between them - it's a matter of properly planning the addressing
architecture.

> If that's too hard to set up then the better option is to run
> 6lowpan/RPL on the host and treat the microcontroller like a dumb
> radio.

I tend to agree with this.  It is much easier to implement and run RPL
and 6lowpan on the linux host computer (not the stick) and treat the
microcontroller as a dumb radio.  ('dumb' in the IP sense, but could be
as intelligent as running 802.15.5 mesh 'networking' which involves
link-layer 'routing' and link-layer multicast).   This is a very
tempting case for implementation.

 From this implementation perspective it is very tempting.  The approach
can help answer many unknowns in the RPL 6lowpan space.

(sometimes this discussion turns into "mesh-under" vs "route-over" a
delimitation which is not as hard as it may sound - not all problems are
solved if we just use "mesh-under" - e.g. how does IP routing and MLD
over the "mesh-under"  take advantage of the features it offers: does
MLD REPORT map into XXXXX.join of 802.15.5? how does ND use the
multicast of the "mesh-under"? and similar).

I am eager to listen about the implementation approaches and how do they
influence the RPL 6lowpan design.

Alex

>>> hardware can be used for both models. The MCU can run a small
>>> program that makes it look like a serially attached radio.
>>
>> Could the MCU also implement non-RPL stuff: ND and OSPF to talk to
>> the Linux "host"?
>>
>>> The project has already been started (linux-zigbee), I'm trying
>>> to figure out which model to work further on. It's not obvious
>>> to me how these two models interact with multiple gateways to
>>> the RPL network.
>>
>> Just two cents worth.
>>
>> Alex _______________________________________________ Roll mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/roll
>>
>
>
>