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

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

commit 29207df430b0cee7171c8f16de27b5c7c24cdd20 Author: Antonio Quartulli a@unstable.cc Date: Thu May 19 11:04:08 2011 +0000

doc: batman-adv/Client-roaming

29207df430b0cee7171c8f16de27b5c7c24cdd20 batman-adv/Client-roaming.textile | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index 15b30d75..2e0d0694 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -2,9 +2,10 @@ h1. Roaming-improvements

h2. Speeding up the roaming

-The base idea consists in exploiting the new forwarding mechanism for data packets described in the [[Client-announcement]] page. In particular this mechanism modify the route of packets in case of the path reaches an update router. If so data packet is rerouted to a new destination and the information on the packet are updated too. +The base idea consists in exploiting the new forwarding mechanism for data packets described in the [[Client-announcement]] page. +In particular, with this mechanism the packet destination is modified along the path, if needed, as the message reaches an up-to-date router. If so data packet is rerouted to the new destination and information in the packet header are updated too (destination and ttvn field).

-As it is possible to understand, in case of client roaming, nodes need to wait for the next OGM from the new mesh node serving such client to update their tables. The idea behind the roaming speeding up consists in sending a particular packet in case of roaming to immediately inform the old originator that the client has moved and it is now located on another node. This message can be seen as an asynchronous update that permits to the old node to redirect data packets as soon as they arrive at it. +As it is possible to understand, in case of roaming client nodes need to wait for the next OGM issued by the new mesh node serving such client to update their tables. The idea behind the roaming speeding up consists in sending a particular packet in case of roaming to immediately inform the old originator that the client has moved and that it is now located on another node. This message can be seen as an asynchronous update that permits the old node to redirect data packets as soon as they reach it.

This new packet type is the **ROAMING-Advertisement** and it simply contains (only interesting fields are shown): <pre><code>uint8_t dst[6]; @@ -12,23 +13,24 @@ uint8_t src[6]; uint8_t client[6];</pre></code> These information are used to update the old node global table so that, in case of packet directed to him, with a real destination equal to *client*, it is redirected to *src*.

-Exploiting this mechanism, immediately after a roaming data packets will follow a slightly sub-optimal path (data flow is going through the old node) until the new OGMs will update the source global table. At that point the packets will start following the best path. +Exploiting this mechanism, immediately after a roaming the data packets will follow a slightly sub-optimal path (data flow is going through the old node) until the new OGMs will update the source node's global table. At that point the packets will start following the best path.

-This strategy will help in avoiding to lose packets that are still flowing to the old node in the time that the source get updated using the next OGMs. +This strategy will help to avoid to lose packets that are still flowing to the old node in the time that the source get updated using the next OGMs.

h2. Detecting a roaming phase

-To detect a roaming phase, a node in case of new client detection will look into its global translation table for the address of the new host. In case of positive match (the same MAC address is already in the table but pointing to another originator) the new mesh node will send a **ROAMING-Advertisement** message to the old node serving this client so that it will be able to update its global table and possibly redirect packets immediately to the new mesh node. +To detect a roaming phase, a node in case of new local client detection will look into its global translation table for the address of the new host. In case of positive match (the same MAC address is already in the table but pointing to another originator) the new mesh node will send a **ROAMING-Advertisement** message to the old node serving this client so that it will be able to update its global table and possibly redirect packets to the new mesh node.

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

-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). +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 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. +To solve this issue, a new flags field has been added to the tt_change and the tt_global_entry structure. In particular, every **del** 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. +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)