Subject: [Roll] Looking for Linux implementation of RPL for interop testing

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Wed, 1 Apr 2015 14:48:09 +0000

Can anyone point me at an implementation of RPL for Linux that provides non-storing mode operation?  I'm looking for both an LBR/DODAG root implementation and an LR implementation.  THe purpose is interoperability testing with an independent implementation.

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Apr 2015 14:40:41 -0400

Ralph Droms (rdroms) <[email-masked]> wrote:
    > Can anyone point me at an implementation of RPL for Linux that provides
    > non-storing mode operation?  I'm looking for both an LBR/DODAG root
    > implementation and an LR implementation.  THe purpose is
    > interoperability testing with an independent implementation.

No, I can't point you at this, but I thought I'd answer about why we aren't
seeing this yet.

A non-storing mode implementation would require kernel implementation of the
RH3 header in order to make work (particularly as DODAG root), and at this
point, I'm unaware of anyone who has done that work, and it certainly isn't
in the mainstream kernel.

Perhaps someone out there is already working on it, and has patches.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Turner, Randy" <[email-masked]>
Date: Thu, 2 Apr 2015 18:45:28 +0000

I agree with Michael, we are looking into Linux mods for RPL as well, especially how to get RPL options outbound with every packet bound to a low pan interface -

Randy

> On Apr 2, 2015, at 2:40 PM, Michael Richardson <[email-masked]> wrote:
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Alexander Aring <[email-masked]>
Date: Thu, 2 Apr 2015 22:34:19 +0200

Hi Ralph and Michael,

> Perhaps someone out there is already working on it, and has patches.

I know three 3 RPL implementation for linux, all of them has limitations:

One kernelspace and two userspace implementations, I can't say much
about these limitations because I doesn't looked deeper into these
implementations and I have no idea about RPL stuff (currently). :-)

The kernelspace one:

 - Known as linux-rpl [0].
   In my opinion there is still much stuff to do there for bringing this
   stuff mainline. There is a blog article [1] about somebody who tested it
   with contiki nodes and it "seems" basically to work with limitations.

The userspace implementations:

 - SimpleRPL [2].
   Prototype implementation in python.

 - unstrung [3].
   I think the most people on this mailinglist knows about this
   implementation.

For using these implementation with current mainline:

NOTE: We changed in linux the ARPHRD (the uapi type for a netdev) from
ARPHRD_IEEE802154 to ARPHRD_6LOWPAN for the 802.15.4 6LoWPAN interface.

The reason was before the 802.15.4 and 802.15.4 6LoWPAN interface used
the same ARPHRD type, this situation occurs several troubles. Now BTLE
6LoWPAN and 802.15.4 6LoWPAN uses the same ARPHRD type which is
ARPHRD_6LOWPAN. On ARPHRD_6LOWPAN you will have a IPv6 view without L2
information, the ARPHRD_IEEE802154 wpan interface has 802.15.4 frames view.

I mostly saw that userspace applications evaluates the ARPHRD value for
checking on an EUI64 mac address length, which is the same for BTLE
6LoWPAN and 802.15.4 6LoWPAN.

I notice this because some applications still evaluates the old ARPHRD
value (I noticed this about another mail on mailinglist at [4]). So you
will have trouble to run current implementations with current mainline
if you don't this behaviour.

- Alex

[0] https://github.com/joaopedrotaveira/linux-rpl
[1] http://sixpinetrees.blogspot.de/2014/11/linux-rpl-router.html
[2] https://github.com/tcheneau/simpleRPL
[3] http://unstrung.sandelman.ca/
[4] http://lists.sandelman.ca/pipermail/unstrung-hackers/2015-March/000014.html

---

From: Ralph Droms <[email-masked]>
Date: Thu, 2 Apr 2015 17:50:07 -0400

Thanks, Alex - your response is *very* helpful...

Anyone have a suggestion about other ways to do interop testing, especially with a non-storing mode LBR/DODAG root?

- Ralph

> On Apr 2, 2015, at 4:34 PM 4/2/15, Alexander Aring <[email-masked]> wrote:
> 
> Hi Ralph and Michael,
>

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 03 Apr 2015 12:46:52 -0600

Yes - pick a decent protocol :-)

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 03 Apr 2015 12:48:31 -0600

sorry - meant to send that to ralph.  frustration with implementing some 
kernel software.

         Geoff

---

From: João Pedro Taveira <[email-masked]>
Date: Fri, 17 Apr 2015 20:57:03 +0000

Hi to all,

I'm glad to know that there's some interested on my RPL linux
implementation.

Since september 2014, I had no opportunity to work on RPL on linux.

When I started this implementation, I thought on possible roadmap:
1. RFC 6206 trickle
2. RFC 6550 RPL
3. RFC 6552 OF0
4. Root Node mode
5. Router Node mode
6. userland tools
7. OF0 Integration tests Linux/Linux
8. OF0 Integration tests with Linux/contiki
9. Tests with Linux/at86rf23x + contiki/atmega128rfa1
10. Tests with Linux/xbee + contiki/m1284p+xbee
11. RFC 6719 MRHOF
12. RFC 6551 Routing Metrics
...

I also tested rpl linux implementation using CORE (
http://www.nrl.navy.mil/itd/ncs/products/core). Using kernel namespaces,
it's easy to test the implementation.

I stop on issues 11. and 12. I got stuck when I start to get MRHOF, ETX and
metrics working. I had to dive on linux netstack to figure out how to get
ETX without breaking (or breaking too much) abstraction layers on netstack.

Since RPL Linux implementation worked very well with 0OF and contiki, I
just tried to make some use of linux nodes with very basic network support
on a small mesh with contiki and linux nodes. The results could be better.
I faced too many basic issues, with very simple resolutions but that would
require some free time to fix that I hadn't.
Regarding to contiki, there's nothing to say since RPL it's quite solid. I
simply needed more ram for the IP buffer since it was only 400bytes long
(there wos no more free space). About RPL implementation, it took too long
to react on mesh changes. At least, multi-hop worked. About linux nodes
within the mesh, I tried to fly to high and I can say that ssh really want
the minimum of ipv6 max MTU. Connecting one of the linux nodes to internet
as gw, the network basic protocols seam to work without problems like DNS,
ICMP6 and CoAP.

Still on MRHOF, I contact linux-zigbee/linux-wpan group to get some
information about roadmap about MAC802154 and I was told that it was too
soon to know what and how things would be. I think there was a merge from
linux zigbee to linux-wpan, but in the meanwhile, it was agreed between
linux groups to merge wpan with bluetooth.

As last resort on ETX and MRHOF on linux and to see it working, I just
tried to use nd6 timers as indication on link quality on linux side.
Basically, when some neighbour moved to state REACHABLE would count as a
good packet delivered. When a neighbour moved to state FAILED would count
as several non-acked packets. Assuming that nodes wouldn't send too many
packets, neighbours would move frequently to IDLE state. On each packet
exchange this would make state to move to REACHABLE and count as good
packet. Using RPL linux as root, this metric would be more or less
acceptable but I didn't like the idea of different metrics. Anyway, I was
able to get correct behaviour from MRHOF from linux nodes (even with a
strange metric).

Since 4thQ 2014, I had no time available to work on this. I think I already
know how to get ETX working. I'll see linux-wpan/linux-bluebooth current
status and I hope to continue what I was doing back then.

About the blog which talks about tests to RPL Linux implementation, I just
want to say that I wasn't contact about it before the post.

Best Regards,
João Pedro Taveira