commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-roaming (07213f0b)
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 07213f0b0586542677beed920c5bcc749c846dfa Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon May 23 08:38:29 2011 +0000 doc: batman-adv/Client-roaming >--------------------------------------------------------------- 07213f0b0586542677beed920c5bcc749c846dfa batman-adv/Client-roaming.textile | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index 3420f5e1..57326a30 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -7,7 +7,14 @@ 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 its format is: +This new packet type is the **ROAMING-Advertisement** and this is its format: + +* Packet type: Initialize this field with the ROAM_ADV 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. +* Source Address: Address of the host sending this message. +* Client Address: Address of the roaming client that the source node has to communicate to the destination one in order to update the global translation table. <pre> 0 1 2 3

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (4d6ba8ff)
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 4d6ba8ff8101657cc502b34dd48e5124282797f4 Author: Antonio Quartulli <a(a)unstable.cc> Date: Sun May 22 22:24:20 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- 4d6ba8ff8101657cc502b34dd48e5124282797f4 batman-adv/Client-announcement.textile | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index c06149a8..c1be97ca 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -19,10 +19,15 @@ At boot time, every node will have an empty local table and empty global one. It As soon as a local event occurred (client added/deleted) the ttvn is incremented by one on the next propagation event (OGM broadcast). In addition, the local changes since the last OGM broadcast are appended to the OGM itself. This mechanism helps to avoid the more expensive table request operation (see below) as any receiving node can retrieve the changes from the OGM to update its global translation table. Each change entry is represented by a tt_change structure: -<pre><code>struct tt_change { - uint8_t flags; - uint8_t addr[ETH_ALEN]; -};</code></pre> +<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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Client... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ...Address | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +</pre> The flags field indicates the related operation (**add** a client or **delete** a client), while the addr field contains the interested client MAC address.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (3549574d)
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 3549574df5e899fbde4af6696229b4f45d527612 Author: Antonio Quartulli <a(a)unstable.cc> Date: Sun May 22 22:28:21 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- 3549574df5e899fbde4af6696229b4f45d527612 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 c1be97ca..64663936 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -50,7 +50,7 @@ In particular the TT_REQUEST/TT_REPONSE messages are two subtypes of the TT_QUER +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TTL | Flags | Source... | + | TTL | Flags | Source... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (e88f1b6f)
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 e88f1b6fe1c6ab674009dfe1c4ab3d9ca2d18b4a Author: Antonio Quartulli <a(a)unstable.cc> Date: Sun May 22 22:28:47 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- e88f1b6fe1c6ab674009dfe1c4ab3d9ca2d18b4a 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 64663936..9b558292 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -54,7 +54,7 @@ In particular the TT_REQUEST/TT_REPONSE messages are two subtypes of the TT_QUER +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TTVN | TT_Data | + | TTVN | TT_Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </pre>

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (6185df78)
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 6185df789677c4fa5ecc5863eda7afd3be364f90 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Sun May 22 20:27:12 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- 6185df789677c4fa5ecc5863eda7afd3be364f90 batman-adv/Client-announcement.textile | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index dd13b78f..de7e155a 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -6,7 +6,7 @@ h2. The local translation table Every client MAC address that is recognized through the mesh interface will be stored in a node local table called "local translation table" which will contain all the clients the node is currently serving. This table is the information a node has to spread among the network in order to make clients reachable. This is because when a node wants to contact a particular client, thanks to this information, it knows the originator it has to send the data to. Each node local table has a particular attribute: the translation table version number (ttvn). The value of this attribute represents the version of the table that is incremented by one each time the local table changes (a client has been added/removed). For optimization reasons all changes which happen within the same OGM interval are aggregated into a single ttvn. -Every OGM broadcast contains the current ttvn and a crc16 value of the local table to allow the receiving nodes to quickly decide whether they tables are in sync or not. +Every OGM broadcast contains the current ttvn and a crc16 checksum value of the local table to allow the receiving nodes to quickly decide whether they tables are in sync or not. h2. The global translation table @@ -14,10 +14,9 @@ Every node in the network has to store all the other node's local tables. To ach h2. Updating the tables -At boot time, every node will have an empty local table and empty global one. Its ttvn will be initialised to 0. The OGM sending represents the local table -spread event. -At this point, on each OGM sending, if something changed in the local table since the last event, the ttvn is incremented by one and the list of the changes is appended to the OGM message. On the receiver side when receiving a new OGM, the node can use the new ttvn field to detect any change in the -originator's local table. If so the receiver node will use the appended changes to update its global translation table. +At boot time, every node will have an empty local table and empty global one. Its ttvn will be initialized to 0. The OGM broadcast represents the local table propagation event. + +As soon as a local event occurred (client added/deleted) the ttvn is incremented by one on the next propagation event (OGM broadcast). In addition, the local changes since the last OGM broadcast are appended to the OGM itself. This mechanism helps to avoid the more expensive table request operation (see below) as any receiving node can retrieve the changes from the OGM to update its global translation table. Each change entry is represented by a tt_change structure: <pre><code>struct tt_change { @@ -27,13 +26,11 @@ Each change entry is represented by a tt_change structure: The flags field indicates the related operation (**add** a client or **delete** a client), while the addr field contains the interested client MAC address. -In case of missing OGM, a query mechanism has been provided. A node will detect the missing information using the next OGM's ttvn field: in case of gap the node will ask for the needed information using a TT_REQUEST message. - -In particular a node can ask for two different information: +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 the originator sent within the OGM. +- The last set of changes from the current ttvn. -This distintion is done using the TT_FULL_TABLE bit of the bitwise **flag field** in the TT_QUERY packet. +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.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (3fe62347)
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 (d4e4cf6f)
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 (4a9eb611)
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 (902b58d6)
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 902b58d6224747d62bfa6f189b83068fd8aab615 Author: Antonio Quartulli <a(a)unstable.cc> Date: Sun May 22 21:53:10 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- 902b58d6224747d62bfa6f189b83068fd8aab615 batman-adv/Client-announcement.textile | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index bcce07a8..c06149a8 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -35,12 +35,23 @@ This distinction is done using the TT_FULL_TABLE bit of the bitwise **flag field 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 fields (only fields related to the TT mechanism have been reported): - -<pre><code>uint8_t flags; -uint8_t src[ETH_ALEN]; -uint8_t ttvn; -uint16_t tt_data;</code></pre> +In particular the TT_REQUEST/TT_REPONSE messages are two subtypes of the TT_QUERY message which has the following format: + +<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 | Flags | Source... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ...Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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.

1 0

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

14 Jul '17

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017