Re: [Roll] Border router failure detection

Konrad Iwanicki <> Wed, 04 March 2020 13:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AE773A0E66 for <>; Wed, 4 Mar 2020 05:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HXgO-6BR8Yqp for <>; Wed, 4 Mar 2020 05:01:56 -0800 (PST)
Received: from ( [IPv6:2001:6a0:5001::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 580AC3A0E60 for <>; Wed, 4 Mar 2020 05:01:56 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABC55605A370D; Wed, 4 Mar 2020 14:01:54 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id J2gW_ZpHmSS1; Wed, 4 Mar 2020 14:01:52 +0100 (CET)
Received: from [IPv6:2001:6a0:5001:2:f041:42a0:d6:8071] (unknown [IPv6:2001:6a0:5001:2:f041:42a0:d6:8071]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA; Wed, 4 Mar 2020 14:01:50 +0100 (CET)
From: Konrad Iwanicki <>
To: Routing Over Low power and Lossy networks <>, Ines Robles <>
References: <> <> <>
Message-ID: <>
Date: Wed, 04 Mar 2020 14:02:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Roll] Border router failure detection
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Mar 2020 13:02:01 -0000

Dear Ines,

On 03.03.2020 13:27, Ines Robles wrote:
> Thank you very much for your email to the mailing list and welcome :-)

Thank you.

> Here are some guidelines [1] to write IETF-Drafts, e.g. as Michael says
> for markdown[2], good tools for writing IETF-Drafts [3] and good
> tutorials about IETF [4] and for newcomers [5].
> Please be aware that all the IETF activities follows the note well [6]
> This is our github [7], in general we create one repository for
> ietf-draft. If you desire, you could give me your username I can add you
> with the permissions, so you can create a repository and put your public
> work there. That is very useful to work together and easy for people to
> create issues.

Sure. That would be great. My login is just: konrad-iwanicki

> To submit the draft to the ROLL site, please goes to [8] and select I-D
> submission tool: name your draft as
> follows: draft-yourlastname-roll-maintopicofdraft-00 and it is going to
> be displayed in the section called "Related Internet-Drafts " in the
> ROLL Documents page.

Thank you for the pointers. Once I am at that stage, it will be 
extremely useful to have everything in one place.

> It would be great if you could attend the IETF 107 remotely [9], so you
> can see how it is an IETF meeting. There is no fee to participate
> remotely in IETF, but registration is required to access video and other
> information via Meetecho.

Thanks for the invitation. I will try to find a slot in my agenda.

> Please let us know if you need further help.

Thank you. This is definitely more than enough for now.

Best regards,
- Konrad Iwanicki.

> On Mon, Mar 2, 2020 at 1:59 PM Konrad Iwanicki <
> <>> wrote:
>     Dear all,
>     I am new to the list, so apologies if I fail to follow some conventions.
>     In a nutshell, I would like to propose an extension to RPL that had
>     been
>     invented to significantly improve handling crashes of border routers.
>     Since I have little experience writing RFC-like drafts, I would greatly
>     appreciate any help.
>     Following Dominique’s advice, I did browse the topics that were being
>     discussed on the ROLL list in the last two years and did not find any
>     major overlaps. At the same time, the extension seems to match the
>     current charter of the WG, notably with respect to reliability and
>     manageability. Below I thus try to briefly motivate and summarize the
>     extension, so that you can judge how relevant it is and so that
>     hopefully somebody gets interested in helping to write it up.
>     The extension was inspired by numerous commercial LLN deployments,
>     which
>     we did for a range of industries. What we noticed in virtually all
>     cases
>     is that the major causes of sensor data unavailability were crashes of
>     border routers. The explanation is rather intuitive. Border routers
>     typically rely on a tethered power supply and in practice it is often
>     not economic, or even impossible, to provide them with a battery
>     backup.
>     Therefore, power outages are major problems. Another issue is that
>     border routers are also more intricate, in terms of both hardware and
>     software, than low-power nodes. As such, they are also more likely to
>     malfunction.
>     What we observed, however, is that RPL does not efficiently handle
>     crashes of border routers [1][2]. Upon such a failure, tearing down
>     nonexistent upward routes can take a lot of time (depending on the
>     data-plane traffic) and generate considerable control traffic, which is
>     problematic in many applications.
>     What we did to address the problem was developing an algorithm, called
>     RNFD, in which nodes collaborate to monitor the state of a border
>     router
>     of the DODAG they belong to [1]. Experiments with a TinyOS
>     implementation of the algorithm on two testbeds (32 nodes at 2.4GHz and
>     76 nodes at 868MHz) and in simulations show that it can outperform bare
>     RPL: it can detect a border router crash one or two orders of magnitude
>     faster and with much lower control traffic [1].
>     To verify these results and come up with a way of best integrating RNFD
>     with RPL, we also did an independent implementation of RNFD (for
>     which I
>     did not write a single line of code) and integrated it with RPL-Lite
>     from ContikiNG [3]. Experiments with that implementation on a
>     network of
>     ~150 nodes at 2.4GHz and in a different simulator again confirmed the
>     aforementioned performance gains resulting from employing RNFD [3].
>     I am looking forward to your comments or questions (and hopefully
>     volunteers to help me with the draft). Below you can find the previous
>     citations. I would also be happy to provide more details.
>     References:
>     [1] K. Iwanicki: “RNFD: Routing-Layer Detection of DODAG (Root) Node
>     Failures in Low-Power Wireless Networks,” in IPSN 2016: Proceedings of
>     the 15th ACM/IEEE International Conference on Information Processing in
>     Sensor Networks. IEEE. Vienna, Austria. April 2016. pp. 1—12. DOI:
>     10.1109/IPSN.2016.7460720
>     [2] A. Paszkowska and K. Iwanicki: “Failure Handling in RPL
>     Implementations: An Experimental Qualitative Study,” in
>     Mission-Oriented
>     Sensor Networks and Systems: Art and Science (Habib M. Ammari ed.).
>     Springer International Publishing. Cham, Switzerland. September 2019.
>     pp. 49—95. DOI: 10.1007/978-3-319-91146-5_3
>     [3] P. Ciolkosz: “Integration of the RNFD Algorithm for Border Router
>     Failure Detection with the RPL Standard for Routing IPv6 Packets,”
>     Master's Thesis, University of Warsaw. November 2019.
>     Best regards,
>     --
>     - Konrad Iwanicki.
>     _______________________________________________
>     Roll mailing list
> <>
> _______________________________________________
> Roll mailing list