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

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

commit 91bfbd56d4b0eebc6ad79fae08797c740ab5ae8c Author: Antonio Quartulli a@unstable.cc Date: Wed May 18 16:36:02 2011 +0000

doc: batman-adv/Client-announcement

91bfbd56d4b0eebc6ad79fae08797c740ab5ae8c batman-adv/Client-announcement.textile | 6 ++++++ 1 file changed, 6 insertions(+)

diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index 23f24387..9bdd2ee5 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -103,6 +103,12 @@ h2. TT structures in details: struct hlist_node hash_entry; };</pre></code>

+h2. Impact on data flow + +The ttvn field has also been added to the unicast packet header. A node sending a packet of this type will set this field to the currently known destination's ttvn. Along the path fro the source to the destination, every node will inspect the packet and check whether it knows an higher ttvn for the same destination; if so, the node will look in its global translation table to see which is the current mesh node serving the client which the packet is directed to. At this point the intermediate node will replace the destination and the ttvn values in the unicast packet header and will re-forward the packet to the new destination (possibly the same). + +This behaviour slightly helps in case of roaming: a client moved from a mesh node to another, but the source node doesn't know this change yet. Data is sent to the old node serving the client, but as soon as the packet reaches an updated node, it will be redirected to the new (an possibly correct) destination. + h2. Limitations

h2. Notes