Re: [Roll] Border router failure detection

Ines Robles <mariainesrobles@googlemail.com> Tue, 03 March 2020 12:28 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B633A1E80 for <roll@ietfa.amsl.com>; Tue, 3 Mar 2020 04:28:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
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 iPmiI5yaOiRl for <roll@ietfa.amsl.com>; Tue, 3 Mar 2020 04:28:11 -0800 (PST)
Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 8E2BE3A1E7F for <roll@ietf.org>; Tue, 3 Mar 2020 04:28:11 -0800 (PST)
Received: by mail-ua1-x92d.google.com with SMTP id o42so1013694uad.10 for <roll@ietf.org>; Tue, 03 Mar 2020 04:28:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NGkulb60bIwjZORSMxEPn05QhAw1S3e4si+WbB4tXbU=; b=ipsv6fSws87yW3PZESL6la46p6Q8Vx5UVF9ItBpde1WyCX0uiT1v7D5cs48RihElOT 8T5hNAAhzpid9fqNyvTypmcWO514m8Gb7QyF4dPOm20b2SRLOTvNvV3kOFEFn0piD8qv +osuX9auVaVEezDmN2UjVpBAeu67GSMsVSl5FbW6wBAi9U+hiEtLg3aOX6gsWq3gjfCz C5KLxw/U3n4LVbS/K/MqD2fXxFW9mmBsMPzS+zapyjxuZnWSXS2cxyILb0s7zI83Sek0 QKXmy5yM8kcEE919pOGSuGq+apJ4jRG/lj9T062RNrvchQp9yFBbGLEz8nZBFphFJa3X ffQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NGkulb60bIwjZORSMxEPn05QhAw1S3e4si+WbB4tXbU=; b=uTTD8rdXh1BgAr7EQsZZKCGa6eQwj2uWs2jUZfhSzX+Rpinx/wvmELuPCsrGBItBjV uy9nuZ+9/AFixNM01DLaUWrXdz9VqhqAMTvxmjxcDklmW7qxadqMXCvdheTS03wvTkTX r4WCUWHSJWUZeleaz1Zo+71tEVusLi1XTb8/LX3E4ffK9AsOq0VRTSaPXKCBzSrHSqao Pw8u7Bsvpu7UkX162vHzsFEVbCFdZ+mnqKEBOmAFg8v+N7WEOWaPSEVE22RlwWwRbsyh 5UmkordIIuwsa7jhJ2W56EEPMyLddRRC2XeFZd1x/pBDrccQICT3sssxs4XfVkPiXn0x PGnQ==
X-Gm-Message-State: ANhLgQ1vRoQHczbknO4TT7gIScej5U/mDYavVzkplQhre9WJmeqddEx1 5R9QuJbkqwKbiY6ELQScLHumPXq13A+Cbo29XHFHHwsYFVk=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsEogF1GEzR4OGPd4XnSLQ3quGpfHgVhMrjbggf?= =?utf-8?q?rpK71cAj4c26SdCQKLE1Mbn23bUvfY3ArxUJ4d9vOgXwUlI=3D?=
X-Received: by 2002:ab0:66c1:: with SMTP id d1mr2513742uaq.51.1583238490274; Tue, 03 Mar 2020 04:28:10 -0800 (PST)
MIME-Version: 1.0
References: <CAP+sJUfcEY2DNEQV=duJdN6P8zZn0ccuei+4ra-B6TcLb5z8Kg@mail.gmail.com> <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl>
In-Reply-To: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Tue, 3 Mar 2020 14:27:34 +0200
Message-ID: <CAP+sJUdj4VrmR=+=9_uKyvKOFE5uu98x3Qog43+_tOmTgd+A3A@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cec02d059ff26f8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/tEUxxNh_nDd0wA5kzqc62TU7T38>
Subject: Re: [Roll] Border router failure detection
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 03 Mar 2020 12:28:14 -0000

Hi Konrad,

Thank you very much for your email to the mailing list and welcome :-)

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.

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.

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.

Please let us know if you need further help.

Best regards,

Ines.

[1]
https://ietf.org/about/participate/tutorials/process/creating-internet-drafts-and-rfcs/

[2]
https://www.ietf.org/about/participate/tutorials/process/writing-rfcs-and-internet-drafts-markdown-and-bit-yaml/
[3] https://www.rfc-editor.org/pubprocess/tools/
[4] https://www.ietf.org/about/participate/tutorials/
[5] https://www.ietf.org/about/participate/tutorials/newcomers/
[6] https://www.ietf.org/about/note-well/
[7] https://github.com/roll-wg
[8] https://www.ietf.org/how/tools/
[9] https://ietf.org/how/meetings/107/remote/



On Mon, Mar 2, 2020 at 1:59 PM Konrad Iwanicki <iwanicki@mimuw.edu.pl>
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@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>