Repository : ssh://git@open-mesh.org/doc
On branches: backup-redmine/2017-07-13,master
commit 9772bdc1399a06da8a3e20a5ac293f44a63e9049 Author: Antonio Quartulli a@unstable.cc Date: Sun May 22 23:23:13 2011 +0000
doc: batman-adv/Client-roaming
9772bdc1399a06da8a3e20a5ac293f44a63e9049 batman-adv/Client-roaming.textile | 31 +++++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index 80245924..3420f5e1 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -7,19 +7,38 @@ In particular, with this mechanism the packet destination is modified along the
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]; -uint8_t src[6]; -uint8_t client[6];</pre></code> +This new packet type is the **ROAMING-Advertisement** and its format is: + +<pre> + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Type | Version | Destination... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ...Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TTL | Source... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ...Address | Client... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ...Address... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +</pre> + 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 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 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. Forwarding data packets +h2. Routing data packets + +The basic routing procedure is the same described in the [[Client-announcement]] page. The only difference consists in giving the routing node the possibility of inspect the data packet (to possibly change the destination) even if the TTVN carried by the packet is not less than the one the router knows. +This chance must be given only in a case: the destination node is in *roaming phase*.
-(to add tt_poss_change description) +The **tt_poss_change** flag in the originator structure is used for this purpose. It is set tu true in case of receiving a ROAMING-Advertisement from an originator an it is set to false again once a new OGM is received from the same node.
h2. Detecting a roaming phase