A few questions about Riot-OS

Help archive
#1

Hello rioters,

  I've seen the nice GitHub repository, and I would have a few questions about the current status of Riot-OS.

  The first one would be about simulation of Riot-OS (for debugging, for testing behavior with large simulations): is there a way to simulate it? - for instance have a home-made simulator with a basic   topology (like http://zboss.dsr-wireless.com/) ? - or have the possibility to compile it, or some parts,   as a standalone library, and later link it to a   simulator (e.g. ns3, OMNET++, ...) ? - or compile it to a known platform like Zolertia Z1,   TelosB and then use the COOJA simulator ?

  The another set is about 6lowpan+RPL implementation: - are all parts of the RFC(s) implemented ?   like storing/non-storing mode, DAO, and also for   data traffic, the "RPL option" IPv6 option field,   with rank error, and associated actions.

  And finally do you know if there is any port to PC machines (IA32/IA64), directly (as the only OS) or as a subprocess of the PC machine ? And do you plan to support Cortex-M3-based chip, such as the TI CC2538 ?

Thank you for any information, Best Regards, -- Cédric PSL I hope also the BeagleBoards are working well :slight_smile:

#2

Hi C�dric!

  The first one would be about simulation of Riot-OS (for debugging, for testing behavior with large simulations): is there a way to simulate it?

Unfortunately, so far we don't have a simulator for RIOT. However, it is indeed a high priority task to provide some simulation/emulation for RIOT soon.

- for instance have a home-made simulator with a basic   topology (like http://zboss.dsr-wireless.com/) ? - or have the possibility to compile it, or some parts,   as a standalone library, and later link it to a   simulator (e.g. ns3, OMNET++, ...) ? - or compile it to a known platform like Zolertia Z1,   TelosB and then use the COOJA simulator ?

We are considering several approaches like Cooja, skyeye [1], or the integration into existing network simulators using a user space process. So far we haven't decided, what's the most promising solution.

  The another set is about 6lowpan+RPL implementation: - are all parts of the RFC(s) implemented ?   like storing/non-storing mode, DAO, and also for   data traffic, the "RPL option" IPv6 option field,   with rank error, and associated actions.

The 6LoWPAN implementation should be fully RFC compliant. The RPL implementation is currently under revision for RFC compliance.

Stephan, can you give us an update on this?

  And finally do you know if there is any port to PC machines (IA32/IA64), directly (as the only OS) or as a subprocess of the PC machine ? And do you plan to support Cortex-M3-based chip, such as the TI CC2538 ?

We have some ideas to let RIOT run as a user space process for Linux. But I doubt that there will be a native port for x86.

There exists a port for a STM32 board with an ARM Cortex-M3 in a very early stage and as far as I know further development here is planned for the near future.

PSL I hope also the BeagleBoards are working well :slight_smile:

Yep, they're working pretty fine and are very nice toys. :wink:

Cheers, Oleg

[1] http://skyeye.sourceforge.net/wiki/index.php/Main_Page

#3

Hi,

> The another set is about 6lowpan+RPL implementation: > - are all parts of the RFC(s) implemented ? > like storing/non-storing mode, DAO, and also for > data traffic, the "RPL option" IPv6 option field, > with rank error, and associated actions.

The 6LoWPAN implementation should be fully RFC compliant. The RPL implementation is currently under revision for RFC compliance.

Stephan, can you give us an update on this?

The 6LoWPAN implemention is fully compliant to RFC4944 and draft-ietf-6lowpan-nd-15.

best regards, stephan

#4

Thank you for your answers, Oliver and Stephan, this is really helpful, Best Regards, -- Cédric

#5

Hi,

Hello rioters, *snip* The another set is about 6lowpan+RPL implementation: - are all parts of the RFC(s) implemented ? like storing/non-storing mode, DAO, and also for data traffic, the "RPL option" IPv6 option field, with rank error, and associated actions. http://lists.riot-os.org/mailman/listinfo/users

Adding a bit more on the RPL-implementation:

Our RPL implementation is not yet fully RFC-compatible. It was implemented based on the draft-version 19 of the RFC. Since the RFC is very large, I will give you a rundown on some aspects that I know differ/comply to the RFC (I took a good look at it, but I did not write the code, so no guarantees on finding everything):

- - Our implementation so far makes only use of storing mode with no multicast (MOP = 2). (Though this should compliant, as the RFC mentions implementations are expected to only support 1 mode for now)

- - All of the control traffic DAO/DAO-Ack/DIOs/DIS options for non-secure RPL are implemented and seem to conform to the RFC.

- - The RPL option for data traffic with rank error and associated actions are not implemented yet. So far, only DODAG creation and maintenance are implemented from what I saw.

- - Instead of NUD or other mechanisms for recognizing an unreachable parent, there is a lifetime for preferred parents, which will be refreshed every time a DIO is received from said parent. The default value for this lifetime is the same as for entries in the routing table of the node.

- - For now, our implementation allows a node only to be member of 1 instance, though the code should allow for an extension to multiple instances relatively easy.

- - The OF0 used is a very simple hop-metric, based on the OF0-RFC draft 7, which means it should differ from the now published RFC quite a bit.

That's it from me, if there are more questions, feel free to ask.

Regards,

(the other) Stephan