Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-13,master
commit 31ecae28e266037820cec47fc1f7777767035dd4 Author: Antonio Quartulli a@unstable.cc Date: Thu May 19 00:20:47 2011 +0000
doc: batman-adv/Client-roaming
31ecae28e266037820cec47fc1f7777767035dd4 batman-adv/Client-roaming.textile | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index ecf6a435..341255dc 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -10,5 +10,25 @@ To detect a roaming phase a node, in case of new client detection, will look int
This strategy will help in avoid losing packets that are still flowing to the old node in the time that the source get updated using the next OGMs. So at the beginning a suboptimal path will be used, but sooner or later the source will be updated and the packet will directly be sent to the new mesh node.
-Notes: +h2 Keeping table consistency + +As described [[Client-announcement|here]] each node computes its local tt_crc value and spread it over the network using the OGMs. In case of roaming, a temporary inconsistent global table could lead to a wrong tt_crc value computed on the nodes making them issue a new TT_REQUEST. + +In particular, a node receiving a Roaming-Advertisement message will track this change as a simple removal and will send it within the next OGM. The receiver node has to do not delete this client immediately, otherwise will lose any route toward it. Then the idea is to keep the client entry in the nodes global tables. By the way this idea could lead to an inconsistent state: if client C roams from A to B, A won't have C in its local table any more, but nodes keeping this entry pointing to A will then compute a wrong tt_crc value for A (they are using C in the computation). + +To solve this issue, a new flags field has been added to the tt_change and the tt_global_entry structure. In particular, every change generated by a roaming event will have the TT_CHANGE_ROAM bit set so that receiving node can set the corresponding TT_GLOBAL_ROAM flag in the tt_global_entry they are going to modify/create. This flag will slightly modify the tt_crc computation for global tables: entry with TT_GLOBAL_ROAM set will not be used for the computation to reflect the state of the originator's local table keeping a valid route to clients at the same time. + +The TT_GLOBAL_ROAM in the tt_global_entry structure will be reset to 0 as soon as a new OGM containing an "add" event for that client is received. + +(to be reread/reviewed) + +h2. Limitations + +- MAC conflict +- Multiple-roaming in one OGM interval + +(to be modified) + +h2. Notes + A research project has been done on this topic and it will be linked on this page as soon as it get ready. \ No newline at end of file