[Roll] Interest in opportunistic routing?

Simon Duquennoy <simonduq@sics.se> Fri, 07 March 2014 09:54 UTC

Return-Path: <simon.duquennoy@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 53D151A0164 for <roll@ietfa.amsl.com>; Fri, 7 Mar 2014 01:54:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 gx_zGvglfs10 for <roll@ietfa.amsl.com>; Fri, 7 Mar 2014 01:54:41 -0800 (PST)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id AF5C51A02E2 for <roll@ietf.org>; Fri, 7 Mar 2014 01:54:41 -0800 (PST)
Received: by mail-ve0-f181.google.com with SMTP id oy12so3917899veb.40 for <roll@ietf.org>; Fri, 07 Mar 2014 01:54:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=GKaA+PA2uPZwn42ISbHS55DhpPjwaU9j+S/bAicAAoI=; b=uPPwQ7SxRpRpK4egJtr6hyrKYaxjxpqoFf3PlEDxuxrzCfVozHR6XgXHI/yZa1HIy0 ZdQcRhZYB9kU07AeNYwe2s41YPjgALJRowx3LDti9E3HtCNQxJQw2RErppiFDUo8WBbc DrGckO2ny6Lh7jiFx6hrnsG6Le5oIHuRQFPkAoRf0dYNLmA3wKUr2UjcPDsaeTWXsz1y /kPKSo/5zKPQTrPTSs3yQ3fWim/uGlWVoNXtACFS//BUmE/ETi5q4qNTBupZ6vhDZMks UIoQfN7Bvwb3ON/BuwV/McJa6NB4oBn4IOuV4/1IL6a94tWICrPvs6Lpw09nWqp22Sl0 nCBg==
MIME-Version: 1.0
X-Received: by 10.58.188.78 with SMTP id fy14mr9622731vec.23.1394186077230; Fri, 07 Mar 2014 01:54:37 -0800 (PST)
Sender: simon.duquennoy@gmail.com
Received: by 10.220.150.209 with HTTP; Fri, 7 Mar 2014 01:54:37 -0800 (PST)
Date: Fri, 7 Mar 2014 10:54:37 +0100
X-Google-Sender-Auth: IUFy0aWvTvdWEfrtIvsS-L62iSM
Message-ID: <CAMxvJtKqhSMpFE5pP42h-Dt3_zCLnJ8WWochjjg7TOCO8kMQVg@mail.gmail.com>
From: Simon Duquennoy <simonduq@sics.se>
To: roll@ietf.org
Content-Type: multipart/alternative; boundary=089e013a12f0e25d4a04f4013dc6
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/MHp7RmHU6UWzwHszR32T_GkTEEg
Subject: [Roll] Interest in opportunistic routing?
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: Fri, 07 Mar 2014 09:56:20 -0000

Dear all,

We have designed an opportunistic extension of RPL, where the basic idea is
to exploit all links of the DODAG rather than the tree defined by links to
preferred parents. We do this using anycast: transmissions are intended
either (upwards) to any parent or (downwards) to any child having the
destination below in the DODAG.

The intuition why this is a good idea is that you don't even need to find
out which link is best for you, but rather use available links whenever
they are usable (increases robustness). Furthermore, in radio duty cycled
environment, anycast is also notoriously more energy-efficient and
low-latency than unicast.

We have a working prototype [1] in Contiki that we evaluated thoroughly in
a 135-node testbed [2]. In a 4-min packet interval data collection, we
increase the reliability of RPL from 97.4 to 99.5%, while halving the
latency (below 0.5s) and radio duty cycle (below 0.5%).

If there is interest, we can come up with a simplified version of the
design presented in the paper, and propose a way to integrate it in RPL
through only a few minor additions. To be more specific, the simplified
version would use the existing RPL routing tables rather than Bloom
filters, and would be MAC-layer agnostic (the only assumption being that
the MAC layer supports anycast).

Best regards,
Simon Duquennoy

[1] https://github.com/simonduq/orpl
[2] www.simonduquennoy.net/papers/duquennoy13orpl.pdf