Re: [Roll] Border router failure detection

[Ines Robles <[e-mail]>]

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 <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>