Re: [Roll] Border router failure detection

[Konrad Iwanicki <[e-mail]>]

Dear Michael,

On 02.03.2020 20:11, Michael Richardson wrote:
> Konrad Iwanicki <[e-mail]> wrote:
>     > 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.
>
> Use the markdown method, and use someone's template github.

Thanks. But I guess, I would also need some guidelines doing the writing.

>     > 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.
>
> Rahul and Pascal (and others) have had a lot of conversation about how we
> deal with the various lollipop counters.  So I am interested in what your
> border router does when it boots: how does it announce the new DIOs?

Internal lollipop counters used within RNFD are always relative to the 
DODAG version number counter. Whenever that counter is refreshed, the 
others are initialized anew. Therefore, for RNFD, the easiest solution 
upon a border router reboot is to broadcast a DIO with a new value of 
the DODAG version.

This, however, is not completely straightforward. We have to either keep 
the counter value in the router's persistent memory, which is not always 
feasible, or learn the last DODAG version value by having the router 
broadcast a DIS and its neighbors reply with DIOs containing the last 
number they are aware of.

In either case, it makes sense for the router to delay broadcasting a 
new DODAG version (and hence the first DIO) for a while after the 
reboot. If "for a while" is long enough, this heuristic helps alleviate 
situations in which the router continuously reboots for some reason but 
manages to bump the DODAG version (e.g., when power is restored but then 
shortly after lost again). More elaborate mechanisms can be deployed as 
well.

>     > [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
>
> Unfortunately, it's behind the IEEE paywall.
> I have given up on getting documents from the IEEE.

Try the ACM Digital Library (the paper is in both libraries):
https://dl.acm.org/doi/abs/10.5555/2959355.2959368

If you fail to download from this source, I can try to get you a preprint.

> I guess you have been working on this for at least five years now.

Well, we wanted to have the problem well studied. And it inspired other 
interesting research as well.

Best regards,
-- 
- Konrad Iwanicki.