Re: [Roll] updating DAO caches - a proposal
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Roll] updating DAO caches - a proposal
> Date: Mon, 23 Nov 2009 16:06:18 +0100
> From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
>
> Richard> In a network with no DAO caches the new (C) flag is never
> Richard> set. Whenever a node moves it sends a single DAO that
> Richard> propagates to the root, which stores the nodes new location.
>
> But then its children that are dragged along do not update the root?
Correct.
> That would work only if you use DAO for one_hop
> information and leave it up to the root to rebuild the
> source route. Please let us know what you have in mind
> here, since that might yield complexities.
Yes, it is what I have in mind. If the root has
A->B->C->D->E in its cache and then it receives
F->G->C, its route to E becomes F->G->C->D->E.
I do not see where complexities could arise.
> I'll continue with the assumption that the Reverse Route
> Stack contains multiple hops.
I wasn't proposing otherwise.
> Richard> In a network where all nodes cache DAOs, a node that moves
> Richard> sends the contents of its cache to its new parent. These
> Richard> propagate up the tree, with each node forwarding on only
> Richard> those prefixes which are new to its cache. The forwarding
> Richard> stops when it reaches the least common ancestor of the
> Richard> node's old and new locations.
>
> IF we all agree on the above, that is sending only to one preferred
> parent, then there can only be one child that advertises a DAO
> destination. Thus there can be only one route to a destination. Thus if
> 2 children advertise a same destination, one is wrong.
Not necessarily, if the destination is not on the subnet.
There may be be redundant routes.
> The newest sequence in the DAO indicates the one that is
> correct. The other one should be cleaned up.
The newest sequence is assumed to be correct. Earlier
sequences may also be correct, but they are redundant
and not saved.
> Several things:
>
> - I fail to see why the DAG root does not set the flag. What happens if
> it is the only one that caches then? It appears that movements do not
> trigger DAOs though the source route path changes.
If the DAG root sets the flag then sub-DAGs have to send
DAOs after every move. Those DAOs contain no information
that is not already cached on the root, so it is wasteful
to send them.
> - the D bit is not enough. The initial spec has a hash. In multihop
> source route, are you sure the D will propagate without a loss? The hash
> is one of those values that would cause resetting trickle if changed so
> it should propagate efficiently.
This is a good point. A hash doesn't work for what I am
proposing, because a change in the route to the root does
not necessarily require that a new DAO be sent. A sequence
number might work. I'll have to think about it.
As an aside, the DAO mechanism depends on the link layer
being 100% reliable. If the link layer can lose messages a
number of changes will be necessary. The ROLL document
needs to be explicit about the link-layer requirements.
> - I think the node that does not cache should send a DAO to its parent
> when the hash in the DIO changes. The hash should start up there at the
> first parent (included) that caches and include the path down the
> preferred tree to this node. So if anything happens between the cache
> and this node, or if the parent that caches changes, this node knows and
> sends a DOA, and propagate the DIO with itself added to the changed
> hash, so the hash changes. IOW if there is a cache up there and if the
> path to that cache or the cache itself changes then this node must send
> a DAO to inform nodes along that path. DAOs can be absorbed by the cache
> up there if that yields no difference that requires informing its own
> parent.
This will again require nodes to send redundant DAOs,
especially in the case where the only the root stores DAOs.
-Richard Kelsey
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.