Re: [Roll] updating DAO caches - a proposal

["Roger K. Alexander" <roger.alexander at ekasystems.com>]

Hi Richard,

As indicated below, I would support this proposal as a base for further DAO
operation specification.

Roger

> -----Original Message-----
> From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of
> Richard Kelsey
> Sent: Thursday, November 19, 2009 2:22 PM
> To: roll at ietf.org
> Subject: [Roll] updating DAO caches - a proposal
> 
> 
> Below is an actual concrete proposal for managing DAO
> caches.  I believe that this would work well when all nodes
> cache DAOs and when no nodes do so.  It does a reasonable
> job when only some nodes cache DAOs, although in some
> situations there will be some superfluous DAOs transmitted.
> 
> This assumes that DAOs are sent only to the preferred
> parent.  If DAO are sent to multiple parents the situation
> becomes more complex.
> 
> In a network with no DAO caches the new (C) flag is never
> set.  Whenever a node moves it sends a single DAO that
> propagates to the root, which stores the nodes new location.
> 
> In a network where all nodes cache DAOs, a node that moves
> sends the contents of its cache to its new parent.  These
> propagate up the tree, with each node forwarding on only
> those prefixes which are new to its cache.  The forwarding
> stops when it reaches the least common ancestor of the
> node's old and new locations.

Agreed.

> In a mixed network, nodes with caches and nodes whose only
> caching ancestor is the root will have the same behavior
> as above.  A node without a cache will send its own DAO and
> set the Destination Advertisement Trigger to cause its
> sub-DAG to send DAOs as well.  The Trigger will propagate
> downwards causing more DAOs to be sent, but descedents that
> have a cache will not propagate the Trigger to their own
> sub-DAG.

Some further refinement may need to be considered. Where nodes maintain DAO
caches the triggering of outward routing updates to the sub-DAG is not
needed unless there has been a change in the path cost from the moving node
to the DAG root, which would then affect connectivity decisions of the
sub-DAG nodes (one of the traffic reducing benefits of multiple parents is
the potential to mute the effect of individual link connectivity changes).
For nodes that do not maintain DAO caches, it should be possible to apply
the same mechanism since the moving parent node sends a DAO update towards
the root updating subsequent outward routes. 

>
>                                   -Richard Kelsey
> 
> ----------------
> Proposal:
> 
> Add a new DIO flag:
> 
>          Destination Advertisements Cache (C): The Destination
>                Advertisement Cache (C) flag is set when a node below
>                the DAG root in the successor chain caches DAOs sent
>                upwards.  DAG roots NUST NOT set this flag.  Nodes
>                below the root that maintain a DAO cache MUST set this
>                flag.  Nodes below the root that do not maintain a DAO
>                cache MUST set this flag to the value received from
>                their preferred DAG Parent.
> 
> 
> In 5.10.1.1. replace
> 
>    A node that modifies its DAG Parent set may set the `D' bit in
>    subsequent DIO propagation in order to trigger destination
>    advertisements to be updated to its DAG Parents and other ancestors
>    on the DAG.  Additional recommendations and guidelines regarding
>    the use of this mechanism are still under consideration and will be
>    elaborated in a future revision of this specification.
> 
> with
> 
>    When a node selects a new preferred parent it MUST send that parent
>    a unicast DIO.  If the node maintains a DIO cache the DIO sent MUST
>    include the prefixes in the DAO cache.  If the node does not
>    maintain a DIO cache and either the new preferred parent's DIO or
>    the old preferred parent's DIO has the Destination Advertisements
>    Cache set, then the node MUST set the Destination Advertisement
>    Trigger in its own subsequent DIO.
> 
> ----------------
> 
> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll at ietf.org
> https://www.ietf.org/mailman/listinfo/roll