commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-roaming (fbc4aa14)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (ccedfa4f)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit ccedfa4fd9eb291f919a9f32abd61a32b988ffa2 Author: Antonio Quartulli <a(a)unstable.cc> Date: Wed May 25 15:47:01 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- ccedfa4fd9eb291f919a9f32abd61a32b988ffa2 batman-adv/Client-announcement.textile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index 5a3de4b5..25d9c5e6 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -48,11 +48,11 @@ The tt request format: 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 | + | Packet Type | Version | TTL | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TTL | Flags | Source Address | + | Destination Address | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-roaming (62847a79)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 62847a7963d8baee7d1418faafd6a5fb425dbd4f Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Wed May 25 14:24:37 2011 +0000 doc: batman-adv/Client-roaming >--------------------------------------------------------------- 62847a7963d8baee7d1418faafd6a5fb425dbd4f batman-adv/Client-roaming.textile | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index 57326a30..af3181ce 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -2,12 +2,13 @@ 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, 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). +The base idea consists in exploiting the new forwarding mechanism for data packets described in the [[Client-announcement]] page in order to reduce the interruption time a non-mesh client experiences when moving from one mesh node to the next. This procedure of a non-mesh client switching to a new mesh node is called "roaming". At its core it simply is a synchronization issue: Whenever roaming occurs the new mesh node "parent" needs to inform the entire mesh that a particular non-mesh client is now to be found at a new location. Even under ideal conditions it might take a full originator interval in which the client is not reachable at all. The bigger the mesh, the higher the packetloss or originator interval the longer the client has to wait before it can use the network again. -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. +The main idea behind the roaming improvements is to make use of the fact that batman-adv has full control over the payload traffic traveling through the mesh network. 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) until the mesh network is in sync again. In addition, a roaming advertisement packet is sent 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 this is its format: +h2. Roaming advertisement + +The roaming advertisement format: * Packet type: Initialize this field with the ROAM_ADV packet type. * Version: Set your internal compatibility version. @@ -20,25 +21,23 @@ This new packet type is the **ROAMING-Advertisement** and this is its format: 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... | + | Packet Type | Version | TTL | Align | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ...Address | + | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TTL | Source... | + | Destination Address | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ...Address | Client... | + | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ...Address... | + | Client 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. +These information are used to update the old node's global table so that, in case of payload packet directed to him while the network is not in sync, with a payload destination equal to 'client address is redirected to 'source address'. -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. +Due to this mechanism, immediately after a roaming the data packets might follow a slightly sub-optimal path (data flow is going through the old node) until the network is in sync again and every node has updated its global translation table. This strategy will help to avoid losing packets that are still flowing to the old node. h2. Routing data packets

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-roaming (9772bdc1)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 9772bdc1399a06da8a3e20a5ac293f44a63e9049 Author: Antonio Quartulli <a(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

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (07d247d8)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (30940cb7)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (6487b052)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (58745e0d)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit 58745e0db7451bc4444a244de669ce1032012499 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Mon May 23 02:23:26 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- 58745e0db7451bc4444a244de669ce1032012499 batman-adv/Client-announcement.textile | 41 ++++++++++++++-------------------- 1 file changed, 17 insertions(+), 24 deletions(-) diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index b86a5e8a..e9d25fee 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -33,42 +33,35 @@ The tt change entry format: </pre> These changes are also appended to the 2 following OGMs if there were no new changes in the meantime, thereby increasing the chance for neighbor node to receive the changes in the event of packet loss. If a node receives an OGM containing a new ttvn without the changeset (e.g. it missed all 3 OGMs with the changeset or the changeset exceeded the packet size) or the crc16 checksum does not match it can issue a table request. In particular a node can ask for two different information: -- The originator's full local table -- The last set of changes from the current ttvn. - -This distinction is done using the TT_FULL_TABLE bit of the bitwise **flag field** in the TT_QUERY packet. - -The originator that receives the TT_REQUEST message will reply with a TT_RESPONSE to which the node will append the requested data. - -The TT_REQUEST message will contain the following fields: -In particular the TT_REQUEST/TT_REPONSE messages are two subtypes of the TT_QUERY message which has the following format: +* The originator's full local table +* The changeset of the current ttvn. + +The tt request format: +* Packet type: Initialize this field with the NDP packet type. +* Version: Set your internal compatibility version. +* Destination Address: Address of the host this packet should be forwarded to. +* TTL: Time-To-Live field decreased by with one with each hop. Packet is to be discarded when counter reaches 0. +* Flags: The flag field is used to distinguish between a TT_REQUEST and a TT_RESPONSE and to inform whether the message is asking for/carrying a full local table or only the changeset of the current ttvn. +* Source Address: Address of the host sending this message. +* TTVN: If the message is of type TT_REQUEST this field specifies the request translation table version number. If it is of type TT_RESPONSE it contains the ttvn of the data in the reply. +* TT Data: If the message is of type TT_REQUEST this field is filled with the crc16 checksum of the specified ttvn. If it is of type TT_RESPONSE this field is set to the number of entries the message is carrying. This information is needed to let the receiver node correctly handle the appended buffer. <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... | + | Packet Type | Version | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ...Address | + | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TTL | Flags | Source... | + | TTL | Flags | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | ...Address | + | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TTVN | TT_Data | + | TTVN | TT Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </pre> -The flag field is used to distinguish between a TT_REQUEST and a TT_RESPONSE and to inform whether the TT_QUERY message is asking for/carrying a full local table or only the last OGM transtable buffer. - -The ttvn field is used to inform about the ttvn is asking for/replying with. -So, in case of OGM buffer request, this value will be set to the ttvn associated to the buffer the node needs. - -The tt_data field has different content in case of TT_REQUEST or TT_RESPONSE. -If the message is a TT_REQUEST, this field is set to the tt_crc value (for details about this value, please read the TT consistency section) that the -requesting node received by means of the OGM from the destination (of this TT_REQUEST). -If the message is a TT_RESPONSE then this field is set to the number of entries the message is carrying. This information is needed to let the receiver -node correctly handle the appended buffer. In case of unavailability of the last OGM transtable buffer the node will answer with the full table.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (bb437589)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (f5503720)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

Repository : ssh://git@open-mesh.org/doc On branches: backup-redmine/2017-07-13,master >--------------------------------------------------------------- commit f5503720eced417ed09b3e0f489dc31b728b30d0 Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon May 23 08:38:51 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- f5503720eced417ed09b3e0f489dc31b728b30d0 batman-adv/Client-announcement.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index e9d25fee..34d24200 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -37,7 +37,7 @@ These changes are also appended to the 2 following OGMs if there were no new cha * The changeset of the current ttvn. The tt request format: -* Packet type: Initialize this field with the NDP packet type. +* Packet type: Initialize this field with the TT_QUERY packet type. * Version: Set your internal compatibility version. * Destination Address: Address of the host this packet should be forwarded to. * TTL: Time-To-Live field decreased by with one with each hop. Packet is to be discarded when counter reaches 0.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017