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

Ralph Droms <rdroms.ietf@gmail.com> Thu, 02 April 2015 21:50 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2C61A7023 for <roll@ietfa.amsl.com>; Thu, 2 Apr 2015 14:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8qWk3PIlBqz for <roll@ietfa.amsl.com>; Thu, 2 Apr 2015 14:50:50 -0700 (PDT)
Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9DE1A702B for <roll@ietf.org>; Thu, 2 Apr 2015 14:50:50 -0700 (PDT)
Received: by qcay5 with SMTP id y5so77800086qca.1 for <roll@ietf.org>; Thu, 02 Apr 2015 14:50:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=MgTijG50vI8S/lQHEJ0TfkaEVIYILSUS1UvNnQj87jM=; b=SmcatvQy7rN5frcjJtW5/1IhQYfAs6l4uzCfjqsSPylupy+d5QIgf8uM0awghm4D/S 1QeHdWG5ySA4RiQmIP21ddqyHjiUKCkJgaIWdRgkZT8K5D5YmPbMzEUa3VRltwyp8ySz Yw4V58znCH/kgwzST5Y/HS7PBNBrbFfFvEeIZXipgSIFK6QLfhBZaqwriFA+1+dV5VUH vcKkmUP7rJb7679UBv08PLBUaZqfCoXAhPmX8Rsa/pvjU32HMBc+OCLixe9qfOMVfICu eHgoRcHnnOxWa4w2IDVcrPrGnQmGTE7AAkmtyZ9iVjJutsmChJF3mHal90HL/Cv9iFtU 4RAA==
X-Received: by 10.55.56.77 with SMTP id f74mr41516704qka.33.1428011449448; Thu, 02 Apr 2015 14:50:49 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c4:1004::174? ([2001:420:c0c4:1004::174]) by mx.google.com with ESMTPSA id 91sm4356232qkw.13.2015.04.02.14.50.45 for <roll@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 14:50:48 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <20150402203416.GA18697@omega>
Date: Thu, 2 Apr 2015 17:50:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <557AE653-44F3-49E9-887E-7C55CE8295B9@gmail.com>
References: <DC67D807-BCFD-4447-A58E-D6D1E30F2DE7@cisco.com> <21995.1428000041@sandelman.ca> <20150402203416.GA18697@omega>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/swvnDO2qUOlC2f2YwvBxDxTx2lg>
Subject: Re: [Roll] Looking for Linux implementation of RPL for interop testing
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2015 21:50:55 -0000

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 <alex.aring@gmail.com> wrote:
> 
> Hi Ralph and Michael,
> 
> On Thu, Apr 02, 2015 at 02:40:41PM -0400, Michael Richardson wrote:
>> Ralph Droms (rdroms) <rdroms@cisco.com> 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.
> 
> 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
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll