Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-13,master
commit fbc4aa14850f824ba4beb036b15f3db202c990b6 Author: Marek Lindner mareklindner@neomailbox.ch Date: Thu May 26 02:51:52 2011 +0000
doc: batman-adv/Client-roaming
fbc4aa14850f824ba4beb036b15f3db202c990b6 batman-adv/Client-roaming.textile | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index e08b0b38..465cfd70 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -48,14 +48,11 @@ When payload data reaches either node (new or old mesh node) they will not only
h2. Translation table consistency
-As described in the [[Client-announcement|client announcement document]] each node computes a crc16 checksum value and floods it through the network using OGMs. In case of roaming, a temporary inconsistent global table could lead to a wrong crc16 checksum value computed on the nodes making them issue a new TT_REQUEST. +As described in the [[Client-announcement|client announcement document]] each node computes a crc16 checksum value and floods it through the network using OGMs. The translation table changes triggered by the roaming advertisement message leads to a temporary inconsistent global translation table because the table changes happen outside of the ttvn/crc16 mechanism.
-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 it will lose any route towards it. -So the idea is to keep the client entry in the nodes global tables. By the way this solution 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 (global) tt_crc value for A (they are using C in the computation). +A node receiving a roaming advertisement message will add a global translation table entry pointing towards the new mesh node, remove the client address from its local table and announces that change with the next OGM. The sender of the roaming advertisement message will complete a similar operation: The client's global entry is removed, the local entry is added and change propagated with the coming OGM. All inconsistencies will be cleaned up by the ttvn/crc16 system once the new OGMs reach the nodes.
-To solve this issue, a new flags field has been added to the tt_change and the tt_global_entry structure. In particular, every **delete** 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 it is 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. +However, neighboring nodes face an interesting problem: If the OGM from the new mesh node containing the "add event" is received before the OGM with "delete event" is coming in, the delete event is silently discarded. But if a node receives the "delete event" first, it has no working route towards the client until the "add event" shows up. To avoid this gap the "delete event" comes with a roaming flag (TT_GLOBAL_ROAM) which tells neighboring nodes to use this route until the "add event" arrives. It also excludes this entry from the crc16 checksum computation.
h2. Limitations