commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (017460af)
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 (2926f473)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: attachments/circle-v2.dia (f869fabf)
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 f869fabfd67506161002f90fa9d34a56b1fffd2f Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Tue May 3 14:46:22 2011 +0000 doc: attachments/circle-v2.dia >--------------------------------------------------------------- f869fabfd67506161002f90fa9d34a56b1fffd2f attachments/circle-v2.dia | Bin 0 -> 3149 bytes 1 file changed, 0 insertions(+), 0 deletions(-) diff --git a/attachments/circle-v2.dia b/attachments/circle-v2.dia new file mode 100644 index 00000000..d68baa36 Binary files /dev/null and b/attachments/circle-v2.dia differ

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-roaming (a6fceb67)
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 a6fceb674b3c86d30038c0f8d2619478296f3d26 Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon May 2 10:26:16 2011 +0000 doc: batman-adv/Client-roaming >--------------------------------------------------------------- a6fceb674b3c86d30038c0f8d2619478296f3d26 batman-adv/Client-roaming.textile | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index 7da26fda..64919d00 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -2,20 +2,23 @@ h1. Roaming-improvements h2. Base concept -This new mechanism relies on the information obtained thanks to the [[Hna-improvements|new client announcement mechanism]]. +This new mechanism relies on the information obtained thanks to the [[Client-announcement|new client announcement mechanism]]. -In particular the first concept consists in permitting ''light inspection'' on the routers in case of fresher global translation-table. -This means that every unicast packet will contain a new field: the '''ttvn''', which is filled with the ttvn associated to the destination at the source node. Any node along the path that has a greater value for the same destination has to query its global table for the real client destination and check whether the packet destination is correct or not. +The first concept consists in permitting ''light inspection'' on the routers in case of fresher global translation-table. -In case of positive match, the router will change the destination and will consequently route the packet. The ttvn value carried by the unicat packet is updated too. +This means that every unicast packet will contain a new field: the **ttvn**, which is filled with the ttvn associated to the destination on the source node. Any node along the path that has a greater value for the same destination. In this case it means that something changes on the destination node and the destination client could had moved. For this reason the router has to query its global table for the real client destination and check whether the packet destination is correct or not. + +In case of positive match, the router will change the destination, update the **ttvn** and will consequently route the packet. h2. Speeding up the roaming -The base idea is simple and clean and permit nodes with a fresher table to redirect packets to the correct destination (a new one). But in case of roaming we have the same issue as the previous implementation because nodes have to wait for the OGM before updating their tables. To solve this issue a new mechanism has been introduced: in case of roaming a new packet type is used to send a message to the old node which was serving the client do that it can update its global table on time! +The base idea is simple and clean and permit nodes with a fresher table to redirect packets to the correct destination (a new one). But in case of roaming we have the same issue as the previous implementation because nodes have to wait for the OGM before updating their tables. + +To solve this issue a new mechanism has been introduced: in case of roaming a new packet type is used to send a message to the old node which was serving the client so that it can update its global table on time! -To detect a roaming phase a node will simply look in its global translation-table for the address of its new client. In case of positive result (the same MAC address was already in the table but pointing to another node) the new node will send a ROAMING-Advertisement to the old node serving this client so that it will be able to update its global table and possibly redirect packets immediatly to the new mesh node. +To detect a roaming phase a node, in case of new client detection, will look into its global translation table for the address of the new host. In case of positive result (the same MAC address was already in the table but pointing to another node) the new node will send a **ROAMING-Advertisement** to the old node serving this client so that it will be able to update its global table and possibly redirect packets immediatly to the new mesh node. + +This strategy will help in avoid losing packets that are still flowing to the old node in the time that the source get updated using the OGMs. So at the beginning a suboptimal path will be used, but sooner or later the source will be updated and the packet will directly be sent to the new mesh node. Notes: A research project has been done on this topic and it will be linked on this page as soon as it get ready. \ No newline at end of file - -TO BE COMPLETED

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (2b6795d3)
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 (f57d19e1)
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 f57d19e126191b8e411149581169787a0f1c843a Author: Antonio Quartulli <a(a)unstable.cc> Date: Mon May 2 10:06:20 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- f57d19e126191b8e411149581169787a0f1c843a batman-adv/Client-announcement.textile | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index 4bf01293..a3905780 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -4,23 +4,25 @@ The code has not been released yet. For those interested in reviewing the code, h2. Current Contstraints of client announcement -Up until recently, BATMAN-Adv. was mostly used to build a mesh network and to allow communitcation between BATMAN-Adv. nodes or a few hosts being bridged into the mesh through certain nodes. However, the desire to also use BATMAN-Adv. to interconnect a larger, common, wired LAN with Wifi access points for client devices into a single subnet has increased. The current implementation just adds the clients' mac addresses to the responsible nodes OGMs - so called HNAs (host network announcements) which has three constraints: -* A lot of overhead even when the HNAs do not change. -* The amount of HNAs per OGM is quite limited and does not work when bridging larger LANs into the mesh cloud. -* It can take up to a couple of seconds for a node to roam and being recognised at its new position, depending on the link qualities. A unicast packet send to the outdated orignator will just be dropped at this node. +Up until recently, B.A.T.M.A.N.-Advanced was mostly used to build a mesh network and to allow communitcation between B.A.T.M.A.N.-Advanced nodes or a few hosts being bridged into the mesh through certain nodes. However, the desire to also use B.A.T.M.A.N.-Advanced to interconnect a larger, common, wired LAN with Wifi access points for client devices into a single subnet has increased. + +The current implementation just adds the client mac addresses to the responsible nodes OGMs - so called HNAs (host network announcements) which has three constraints: +* A lot of overhead even when the HNAs do not change (the addresses are always attached). +* The amount of HNAs per OGM is quite limited and does not work when bridging larger LANs into the mesh cloud (frame size limit). +* It can take up to a couple of seconds for a node to roam and being recognised at its new position, depending on the link qualities. A unicast packet sent to the outdated orignator will just be dropped at this node. h2. Concept Ideas h3. How the announcement works -* Instead of adding all client MAC addresses, the OGM packet format has been modified to include: -** a local translation table reference ID (TT version number); +* Instead of adding all the client MAC addresses, the OGM packet format has been modified to include: +** a local translation table version number (TTVN); ** a set of local translation table changes which happened in the last OGM interval -* When a node local translation table changes at least once in one OGM interval (added or (re)moved client), increase TT version number by one. +* When a node local translation table changes at least once in a OGM interval (a client is added or removed), the TTVN is increased by one. * If a node receives an OGM with a newer, higher ref.-ID, it updates its global translation table with the set of changes carried by the OGM. -** if an OGM was missed (we have a gap in the changes list), then the node must queries the originator for an update with a special unicast packet: TT-REQUEST -* Any node on the paths between the querier and the destination may decide to not forward the TT-REQUEST and answer it by itself if it already has the needed changes. => This avoids a storm of unicast packets towards the destination after its local translation table changes. +** if an OGM has been missed (a is detected in the changes list), then the node must queries the originator for an update with a special unicast packet: TT-REQUEST +* Any node on the paths between the querier and the destination may decide to not forward the TT-REQUEST and directly answer. This is possible only if the node already has the needed changes. **This avoids a storm of unicast packets towards the destination after its local translation table changes.** Most of the times the request will stop on the first hop. * Every node memorizes the last changeset announced within the OGM of each node in the network * A TT-REQUEST can request a complete local table or just a the last sent changeset.

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-roaming (2e22b00c)
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 (d8bb0115)
by postmaster＠open-mesh.org 14 Jul '17

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-roaming (c6927d2c)
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