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

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

commit 2f36cf1643f23ef4db4e930e3a42e9afa606550b Author: Simon Wunderlich sw@simonwunderlich.de Date: Sun May 29 23:04:54 2011 +0000

doc: batman-adv/Client-roaming

2f36cf1643f23ef4db4e930e3a42e9afa606550b batman-adv/Client-roaming.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index 465cfd70..d2153c95 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -52,13 +52,13 @@ As described in the [[Client-announcement|client announcement document]] each no

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.

-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. +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 solve this problem 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

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

-* multiple roaming in one OGM interval: In case of a node roaming from node A to B a roaming advertisement is sent from B to A, but if the client moves again from node B to C, before B issued a new OGM, C will send the roaming advertisement to A again! This happens because C doesn't know anything yet about the last client movement. *A possible solution to this problem could consist in implementing a roaming advertisement forwarding procedure that in scenarios like this make the roaming advertisement message going through all the steps the client did. +* multiple roaming in one OGM interval: In case of a node roaming from node A to B a roaming advertisement is sent from B to A, but if the client moves again from node B to C, before B issued a new OGM, C will send the roaming advertisement to A again! This happens because C doesn't know anything yet about the last client movement. A possible solution to this problem could consist in implementing a roaming advertisement forwarding procedure that in scenarios like this make the roaming advertisement message going through all the steps the client did.

h2. Notes