Hi Roger,
On Nov 17, 2009, at 12:25 PM, Roger Alexander wrote:
The conclusions drawn are not entirely valid in part due to the
particular example given. Quite often the examples used to
demonstrate the protocol are of necessity simpler ones but may not
capture the larger variety of connectivity seen particularly in
larger multihop networks. I will try to make the case using a
slightly more complex network graph which illustrate the benefit of
intermediate state storage and how it might work without explicit
indications of which note are maintaining state.
A fair characterization is that the change in down route state must
be reflected up until there is a common ancestor that provides
connectivity both before and after the change in connectivity *and*
can store down routes. In the example that Richard provided, A was
the common ancestor and it also happened to be the root. But it is
also true that nodes within the sub-DAG of A must update their DAO
routing state to reflect the change in topology. As Richard's
example points out, when you allow nodes to chose whether they can
store down route state, nodes within the sub-DAG must assume the
worst case and originate their own DAO messages in case nodes
between it and the common ancestors cannot maintain down routes.
That said, the cost savings of having storage at intermediate nodes
depends mostly on the depth of the common ancestor - a common
ancestor with greater depth will result in less transmissions that
propagate information towards the root. Of course, in the worst
case, the common ancestor will be the root. An unfortunate edge
case with hierarchical structures is that the common ancestor of you
and your neighbor could be the root.
I think it is fair to say that the current DAO caching capabilities
specified in the RPL doc need quite a bit more thought before I
would be comfortable with putting it into the base specification.
If there is a way to treat it as an optimization, I would prefer to
do so and work on that in a separate draft.
--
Jonathan Hui
