Re: [Roll] updating DAO caches (was Re: Something to ADD)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Jonathan and Richard:

My thought process lead me to following (buy or not :) design, that is
what you find in the MANEMO implementations.

* Nodes that can store should if that's what the deployment requires
(that's policy). 

* Source route trace a path. It can be done on traffic, one every so
many messages with exponential backoff, using small messages that can be
extended for the purpose of LSRR.

* In particular when there are movements (churn) only a snapshot is
consistent. Assembling asynchronous pieces some of which might be out of
date into a routing header is doomed.

A node that cannot store states 

* needs *no* DAO support at all and the whole thing still works. Nodes
that do DAO cohabit with nodes that do without a problem.

* Announce in DIO but still silently absorb for the DAO if they come
nevertheless.

* But they forward and add to the source route. Adding to the source
route means add up the SR stack the information about the next hop. That
information is derived from the source of the packet. Then the node sets
its own address as the source of the packet so it is topologically
correct all the way.

A Node that supports DAO states 

* If the state matches the source route path then the node does not need
to add to the source route header. A state matches if the route to the
highest (newest) entry in the source route header is via the source of
the packet. This confirms that the associated routing state learnt from
DAO is still correct.

* The node does not need to store the source route either. Only the
endpoint does that. In our case the root could intercept and store.

* The node still updates the source of the packet with their own address
to keep it topologically correct and allow the next hop to record the
right thing if it needs.

* But if the states does not match the source route, then the states are
obsolete, and the node should add to the source route header and set the
source to self. 

When you run the MANEMO trilogy (tree discovery, nina (DAO) and RRH
(source route)), you see the source route RH2/4 grow upon movement and
quickly shrink again as the NINA (DAO) states are reestablished. 
When things are stable you only see as many entries as non DAO capable
nodes along the path. In my case, the source route is done on a MIP/NEMO
tunnel, so the RH states are stored in eth binding cache on the home
agent. But we could store that at the root with exactly the same
process.
I can demo that next time we meet if you wish.

http://tools.ietf.org/html/draft-thubert-nemo-reverse-routing-header
details the RRH, since there is not LSRR in IPv6.

Note that in our case, the information in the header should be locally
significant, like a label.

cheers

Pascal

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
Jonathan Hui
>Sent: mardi 17 novembre 2009 17:38
>To: Richard Kelsey
>Cc: [e-mail]
>Subject: Re: [Roll] updating DAO caches (was Re: Something to ADD)
>
>
>On Nov 17, 2009, at 8:12 AM, Richard Kelsey wrote:
>
>>> From: Roger Alexander <[e-mail]>
>>> Date: Mon, 16 Nov 2009 15:33:33 -0800
>>>
>>> Not clear why there is a need to know who records DAOs. In response
>>> to
>>> a new child a parent that does maintain state will add itself to the
>>> path information from the child and pass that information to it's
>>> parent. That information will pass inward towards the root until a
>>> node is encountered that can store the path information and
>>> previously
>>> supported connectivity to the node at the same cost.
>>
>
>[nice example of what DAOs need to be sent]
>
>> In the first case a single DAO needs to be sent.  In the
>> second case D has to send two DAOs and the nodes in its
>> subdag, just E here, each need to send one.  If only the
>> root caches DAOs then the first case always applies.  If
>> other nodes may cache DAOs, then we have to assume that we
>> are in the second case after every move.
>
>I was in the process of creating a similar example.  All I'll add is
>that, intuitively, the more places state gets "replicated" within the
>network, the more costly it is to maintain that state and the more you
>have to deal with inconsistencies between replicated instances.  Of
>course, the hope in replicating this routing state is that it creates
>shorter paths and ultimately offsets the cost of maintaining that
state.
>
>I'll have to admit that I'm not yet convinced of the benefits in
>storing DAO state as it currently exists in the draft.  It seems like
>a mediocre attempt to optimize point-to-point routing and something
>that folks wanting P2P support aren't satisfied with.  If that is the
>end-goal, then we should be developing better mechanisms.  For now, we
>are focusing on one-to-many and many-to-one.  And, I see more benefits
>to simply maintaining state at the root.
>
>--
>Jonathan Hui
>
>_______________________________________________
>Roll mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/roll