Re: [Roll] [manet] Understanding RPL [was: Working group re-charter ideas]

You pretty much have it all, Cenk, I thank you for this great explanation.

Let me observe a few things:

One is that poisoning gives you only half of the value of detaching since detaching maintains connectivity within the detached DODAG, which is a useful consideration in A MANET situation. This mode is an inheritance from MANEMO where we were looking for the minimal topological awareness so as to ensure maximum resilience to swarming in a highly mobile situation.

Second is that both RPL methods derive from the desire of getting a similar service as the diffusion algorithm  in DUAL/EIGRP, but in a MANET situation where connectivity is uncertain and the real diffusion algorithm is doomed to fail.

We had to adapt to the real world and its statistical behavior, and had to cover for the exception, which RPL does as you describe. So DUAL was replaced with a trickle-based diffusion, and the packets were instrumented beyond hop count to detect and fix the anomalies.

There was ample simulation work that showed the value for traffic continuity vs. plain black holing (till the next sequence is advertised). Same goes for the stretch to the feasibility condition.

Now if you disable those functionalities - arguably in a rather fast and stable network - , and you make one mop0 DODAG per router in one instance, you get something that is highly similar to BABEL - and that is no magic. And in that, BABEL is less than EIGRP, but arguably, for that same reason, EIGRP is not applicable to MANET.

If you make that 2 instances, you can select the Homenet multi homed GW without the need for source/destination routing.

If you add the option of P2P RPL you probably get a reactive DV in the close family of AODV.

RPL aggregated the quintessence of classical DV with the best knowledge of people applying DV to mobility (MANEMO/ NINA), and of those applying it to sensors (such as CTP and multiple proprietary solutions from WSN vendors).

At the same time, RPL kept out anything specific to a particular type of use case - metrics, logic, policies. One really creates a solution by choosing his own objective function. It can be said that RFC 6550 is generic and that the application of an OF creates an instance which is the real routing protocol.

The text is arguably hard to read.

Part of that came from the aggregation process over 19 rounds of the draft. I'm afraid that if we pass the BABEL RFC through the WG process, one will hardly recognize it in the end, even if we manage to preserve the basic operations.

Another reason is that we had to strip all the why's and focus on specifying observable behaviors. That is certainly not how one would write a book or a paper. I'm afraid that what makes BABEL such a great read today will be lost if the same process is applied.

Cheers,

Pascal

Le 3 avr. 2015 à 08:15, Cenk Gündogan <cnkgndgn@gmail.com<mailto:cnkgndgn@gmail.com>> a écrit :

Hello Juliusz,

On 03.04.2015 01:41, Juliusz Chroboczek wrote:

Local repair is done by either poisoning or detaching, sections
8.2.2.5.

I don't see how that can be implemented.

Suppose A is B's parent.  A advertises INFINITE_RANK.  A's retraction
("poison") is lost.  B has no reason to change parents, so B has a parent
with infinite rank.  Oops, B is just violating the MUST NOT in 8.2.2.5.2.

Are you assuming the network is reliable?  Or am I missing some mechanism
that prevents that from happening?

I also did struggle with this scenario for quite some time.
However, there are several places in the RFC that specifically deal (directly or indirectly) with this issue.

8.2.2.5<https://tools.ietf.org/html/rfc6550#section-8.2.2.5>.  Poisoning

   1.  A node poisons routes by advertising a Rank of INFINITE_RANK.

   2.  A node MUST NOT have any nodes with a Rank of INFINITE_RANK in
       its parent set.

My interpretation of these bullet points is that DIOs advertising INFINITE_RANK are sent out periodically
(probably in a decaying fashion via Trickle), in order to reduce the chance that these DIOs stay unnoticed.
However, this might not be a complete solution, as all DIOs from A to B can become lost thus leading to the same problem,
but then the RFC states that links should be guaranteed to be symmetric anyways, e.g. by using NUD [1] or other alternatives.

Something else I want to mention is that RPL utilizes a few lifetime counters (e.g. for the dodag or route),
which would also help in this scenario (We wouldn't refresh the lifetime of a node with INFINITE_RANK, would we?),
but admittedly, depending on the specified lifetime values, in a very sluggish way.

At last, it is important to remember that RPL uses data-path validation to reduce the chattiness of control packets,
described in [2] and most likely realized by using [3].
In that case A can reset its Trickle timer when encountering inconsistencies and start e.g. another poisoning routine
by sending out another set of INFINITE_RANK DIOs.

Best,
Cenk

[1] Neighbor Unreachability Detection (https://tools.ietf.org/html/rfc2461#page-66)
[2] https://tools.ietf.org/html/rfc6550#section-3.2.7
[3] https://tools.ietf.org/html/rfc6553
_______________________________________________
manet mailing list
manet@ietf.org<mailto:manet@ietf.org>
https://www.ietf.org/mailman/listinfo/manet