Repository : ssh://git@open-mesh.org/doc

On branches: backup-redmine/2017-07-13,master

commit 4e47bfcaa4784821bd9f4cb091c57bdf20ca9b30 Author: Marek Lindner mareklindner@neomailbox.ch Date: Thu May 26 01:43:21 2011 +0000

doc: batman-adv/Client-roaming

4e47bfcaa4784821bd9f4cb091c57bdf20ca9b30 batman-adv/Client-roaming.textile | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index 4ea8d202..e08b0b38 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -46,19 +46,17 @@ The enhanced data routing is built on top of the data routing procedure describe

When payload data reaches either node (new or old mesh node) they will not only check if the translation table version number (ttvn) of the destination host is outdated but also check if the roaming flag is active. If one of the conditions is met the payload traffic is rerouted if necessary.

-h2. Keeping table consistency +h2. Translation 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 (global) tt_crc 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. 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.

-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. +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).

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.

-(to be reread/reviewed) - h2. Limitations

* MAC conflict: In case of more than one node announcing the same client MAC address, each node will interpret this situation as a "continued roaming" and will start sending roaming advertisement messages multiple times. To reduce the impact of this problematic scenario a roaming-protection has been provided: A client can roam on the same node a fixed amount of times in a fixed length period (look into main.h for the exact values). In case of exceeding the limit, the interested node will not issue any new roaming advertisement unless the protection period is terminated.