[Roll] Ew: RPL Design Questions

["Anders Jagd" <anders.jagd at ekasystems.com>]

Tim,

As for your questions:

>Question A:  Should RPL make use of the currently proposed local ...
>Question B:  Should RPL make use of a hold-up timer and related ...
>Question C:  Should RPL make use of a hold-down timer and related ...

A+B: 

My opinion would be that a Sequence number/"Heartbeat" scheme generally
provides a more reliable, efficient, and simple method compared to timer
based approaches. 

Determining reasonable settings for timer(s) may prove difficult, and no
matter what value is chosen, there is no guarantee that the scheme achieves
the intended goal, rather a likelihood. Not that I am in general against
"likelihoods", as long as they are not "too small" (not good enough),
neither "too large" (too expensive/conservative) - something not trivial to
achieve, in particular since nodes/roots rarely/never have complete atomic
snapshots in time of the full DAG, and even if they did, the DAG could be
quite unbalanced with a mix of short and long branches. 

After deciding on (or occasionally adjusting) proper timer values, those
values then have to be propagated. As of 03 this is through RA-DIO. It does
appear a bit wasteful to continuously broadcast values that typically are
quite static. However, new nodes need to be informed, so if it is not done
regularly through RA-DIO, some other way would have to be defined, basically
some signaling scheme. Either way, this sounds "expensive".

The sequence number approach has little to no timers involved; as soon as a
new sequence number is observed, a node is good to go (merge). It appears to
basically be a semi "self-timed" approach ("semi" since root, but only root,
may need a timer for triggering the heartbeat). How frequently should this
heartbeat (sequence number increment) then happen ? Again, we run into the
"too short/too long" discussion. But what if a node wishing to merge into a
DAG (and thus needing to see a new SQN), could be allowed to request the
root to increment the sequence number ? If any other heartbeat trigger is
required, it could probably be chosen quite conservatively, and the value
certainly would not have to be propagated.

Bursts of such "increment SQN" requests could be reduced by some form of
aggregation: Any node issuing or forwarding a "SQN update request" would
stop forwarding other such requests (drop them) until it sees a new SQN.

C: I think some form of mechanism to limit flapping is important, but again,
I would ask how to determine and configure/propagate a proper timer value.
Can we somehow base it on the heartbeat instead (maybe multiple heartbeats)
?

/Anders