commits July 2017

commits@lists.open-mesh.org

1 participants
1317 discussions

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (a86bf5e3)
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 a86bf5e37b41d1adf8ccd0d21bc8a3e12eca1af5 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Jun 19 21:08:59 2011 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- a86bf5e37b41d1adf8ccd0d21bc8a3e12eca1af5 batman-adv/Release-todo.textile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/batman-adv/Release-todo.textile b/batman-adv/Release-todo.textile index 8bc7ac3b..86157c22 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -20,7 +20,7 @@ h2. Code * [x] check against kernel versions * [x] check that maint branch is merged in next * [x] check for open patches on the ml -* [ ] git tag release +* [x] git tag release h2. Documentation @@ -48,7 +48,7 @@ h2. Distributions h2. Aftershow -* [ ] Merge differences (README, CHANGELOG, ...) into master branch -* [ ] Merge current next into maint (must be fast-forward or pre-tagging steps were done wrong) -* [ ] Get patches for next release from master-rebase/batctl-rebase repository +* [x] Merge differences (README, CHANGELOG, ...) into master branch +* [x] Merge current next into maint (must be fast-forward or pre-tagging steps were done wrong) +* [x] Get patches for next release from master-rebase/batctl-rebase repository * [ ] Rebase patches in next on top of linux-next and send it to kernel maintainers for future kernels (+ set version number in kernel)

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Release-todo (beb36a7d)
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 beb36a7d7f6f993579605048124e446b9c019cd1 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sun Jun 19 20:39:22 2011 +0000 doc: batman-adv/Release-todo >--------------------------------------------------------------- beb36a7d7f6f993579605048124e446b9c019cd1 batman-adv/Release-todo.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Release-todo.textile b/batman-adv/Release-todo.textile index cec6c604..8bc7ac3b 100644 --- a/batman-adv/Release-todo.textile +++ b/batman-adv/Release-todo.textile @@ -14,7 +14,7 @@ h2. Release Scheduling h2. Code -* [ ] make sure all code contains the release version strings +* [x] make sure all code contains the release version strings * [x] update copyright years (if needed) * [x] remove dead code (if any) * [x] check against kernel versions

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Compatversion (bfbb086d)
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 bfbb086d7435b124e97d2da3730d1b5df8e96c77 Author: Sven Eckelmann <sven(a)narfation.org> Date: Sat May 28 22:25:51 2011 +0000 doc: batman-adv/Compatversion >--------------------------------------------------------------- bfbb086d7435b124e97d2da3730d1b5df8e96c77 batman-adv/Compatversion.textile | 1 + 1 file changed, 1 insertion(+) diff --git a/batman-adv/Compatversion.textile b/batman-adv/Compatversion.textile index 8fbb1656..87cc5283 100644 --- a/batman-adv/Compatversion.textile +++ b/batman-adv/Compatversion.textile @@ -16,6 +16,7 @@ Following changes were identified and documented. The changes are to the last CO | 11 | next, v2010.1.0 | gateway flags were removed | | 12 | trunk, v2011.0.0, v2011.1.0 | unicast fragmentation added, gateway flags were readded | | 13 | next, v2010.2.0 | gateway flags were removed | +| 14 | master | 3-byte common header, tt queries and related fields added, roam adv packet added | (* means future version with already defined feature set)

1 0

[doc] backup-redmine/2017-07-13, master: doc: open-mesh/Filing (f6a8d390)
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 f6a8d390c0d027037db85e0715df08c464f54386 Author: Marek Lindner <mareklindner(a)neomailbox.ch> Date: Sun May 29 13:45:46 2011 +0000 doc: open-mesh/Filing >--------------------------------------------------------------- f6a8d390c0d027037db85e0715df08c464f54386 open-mesh/Filing.textile | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/open-mesh/Filing.textile b/open-mesh/Filing.textile index dd8ea228..9c3823e0 100644 --- a/open-mesh/Filing.textile +++ b/open-mesh/Filing.textile @@ -44,9 +44,14 @@ h2. Using B.A.T.M.A.N. advanced (layer 2) * "Batman-adv multicast optimization (video)":http://downloads.open-mesh.org/batman/misc/wbmv4-multicast.avi - how batman-adv optimizes multicast traffic by Linus and Simon [March 2011] * "Bisect the batman-adv routing protocol (video)":http://downloads.open-mesh.org/batman/misc/wbmv4-bisect.avi - the bisect tool explained & demonstrated by Marek [March 2011] * "Project CATWOMAN - network coding with batman-adv (video)":http://downloads.open-mesh.org/batman/misc/wbmv4-network_coding.avi - introduction into network coding with batman-adv by Martin and Jeppe [March 2011] -* [[batman-adv:bonding-alternating|Bonding and Interface Alternating]] - Use multiple links in batman-adv for fun and profit. +h2. B.A.T.M.A.N. advanced (layer 2) protocol documentation + +* [[batman-adv:bonding-alternating|Bonding and Interface Alternating]] - Use multiple links in batman-adv for fun and profit. +* [[batman-adv:Client-announcement|Client announcement]] - how batman-adv handles non-mesh clients bridged into the mesh +* [[batman-adv:Client-roaming|Client roaming]] - non-mesh clients moving from one mesh node to the next + h2. Misc

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (2f436566)
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 2f4365665339e7d1b7b5435f9c706a3dd17e6cab Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sun May 29 22:55:34 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- 2f4365665339e7d1b7b5435f9c706a3dd17e6cab batman-adv/Client-announcement.textile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/batman-adv/Client-announcement.textile b/batman-adv/Client-announcement.textile index 25d9c5e6..06b51493 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -1,11 +1,11 @@ h1. Client announcements -Each mesh protocol offering network access to non-mesh clients needs a 'client announcement' system. The task of such a system is to inform every mesh node in the network of any connected non-mesh client, in order to find the path towards that client from any given point in the mesh. A client has an identifier (usually its address: IP address for layer 3 routing and MAC address for layer 2 routing) that is flooded through the mesh. As B.A.T.M.A.N.-Advanced is a Layer2 mesh routing protocol clients are represented by their MAC address. +Each mesh protocol offering network access to non-mesh clients needs a 'client announcement' system. The task of such a system is to inform every mesh node in the network of any connected non-mesh client, in order to find the path towards that client from any given point in the mesh. A client has an identifier (usually its IP address for layer 3 routing and MAC address for layer 2 routing) that is flooded through the mesh. As B.A.T.M.A.N.-Advanced is a Layer2 mesh routing protocol clients are represented by their MAC address. 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 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 its 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 increment. 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 the tables are in sync or not. h2. The global translation table @@ -56,7 +56,7 @@ The tt request format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TTVN | TT Data | + | TTVN | TT Data | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </pre>

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-roaming (2f36cf16)
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 2f36cf1643f23ef4db4e930e3a42e9afa606550b Author: Simon Wunderlich <sw(a)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

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-roaming (6fa34020)
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 6fa3402058051101ba8acdabbe07a0e24f22189f Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sun May 29 23:06:46 2011 +0000 doc: batman-adv/Client-roaming >--------------------------------------------------------------- 6fa3402058051101ba8acdabbe07a0e24f22189f batman-adv/Client-roaming.textile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/batman-adv/Client-roaming.textile b/batman-adv/Client-roaming.textile index d2153c95..73569865 100644 --- a/batman-adv/Client-roaming.textile +++ b/batman-adv/Client-roaming.textile @@ -42,7 +42,7 @@ Due to this mechanism, immediately after a roaming the data packets might follow h2. Routing data packets -The enhanced data routing is built on top of the data routing procedure described in the [[Client-announcement]] page. When a mesh node receives a roaming advertisement concerning one of its former non-mesh clients it will mark the client entry with the roaming flag. The mesh node sending the roaming advertisement will do the same. This extra flag is needed as long as the translation tables are not in sync and will have to be deactivated once an OGM with the new ttvn arrives. +The enhanced data routing is built on top of the data routing procedure described in the [[Client-announcement]] page. When a mesh node receives a roaming advertisement concerning one of its former non-mesh clients it will mark the client entry with the roaming flag in its own translation table. The mesh node sending the roaming advertisement will do the same. This extra flag is needed as long as the translation tables are not in sync and will have to be deactivated once an OGM with the new ttvn arrives. When payload data reaches either node (new or old mesh node) they will not only check if the translation table version number (ttvn) of the destination host is outdated but also check if the roaming flag is active. If one of the conditions is met the payload traffic is rerouted if necessary.

1 0

[doc] backup-redmine/2017-07-13, master: doc: batman-adv/Client-announcement (c442fca6)
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 c442fca67c58f57252a628ac81750770fd0febbf Author: Simon Wunderlich <sw(a)simonwunderlich.de> Date: Sun May 29 23:00:46 2011 +0000 doc: batman-adv/Client-announcement >--------------------------------------------------------------- c442fca67c58f57252a628ac81750770fd0febbf 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 06b51493..58c43f88 100644 --- a/batman-adv/Client-announcement.textile +++ b/batman-adv/Client-announcement.textile @@ -68,7 +68,7 @@ To reduce the overhead of the table request operations, each node on the path of h2. Computing the crc16 checksum: -The crc16 checksum field which is sent along with the ttvn field in the OGM is computed for a generic originator O as "the xor of all the crc16 values of each local tt table address entry". +The crc16 checksum field which is sent along with the ttvn field in the OGM is computed for a generic originator O as "the xor of the crc16 values of the MAC addresses in the local translation table entries". **Pseudocode**: <pre><code>tt_local_crc(orig_node O) {

1 0

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

14 Jul '17

1 0

[doc] backup-redmine/2017-07-13,master: doc: batman-adv/T_X's_Junkyard_–_MGO (a212c918)
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 a212c91801d521a372ab2a9a2c643276998cda61 Author: Linus Lüssing <linus.luessing(a)c0d3.blue> Date: Sat May 28 03:44:58 2011 +0000 doc: batman-adv/T_X's_Junkyard_–_MGO >--------------------------------------------------------------- a212c91801d521a372ab2a9a2c643276998cda61 .../T_X's_Junkyard_\342\200\223_MGO.textile" | 120 ++++++++++++++++----- 1 file changed, 94 insertions(+), 26 deletions(-) diff --git "a/batman-adv/T_X's_Junkyard_\342\200\223_MGO.textile" "b/batman-adv/T_X's_Junkyard_\342\200\223_MGO.textile" index 0a3ca92d..9b4e85b3 100644 --- "a/batman-adv/T_X's_Junkyard_\342\200\223_MGO.textile" +++ "b/batman-adv/T_X's_Junkyard_\342\200\223_MGO.textile" @@ -11,6 +11,7 @@ The MGO protocol is split into two parts: The Router Alert part to mark the curr h1. Definitions * penalized link TQ - The product of link TQ times the asymmetric penalty of the same link's link RQ (see [[Ndp|NDP]] and [[Ogm|OGM]], asymmetric TQ penalty, for details) +* best router - the router with the highest, penalized path TQ in the router list h2. RA - Router Alert @@ -21,7 +22,7 @@ The purpose of an MGO-RA is to mark the currently selected best path as 'fragile h3. Router Alert Event Detection -A node usually measures the link quality more frequently than the quality of whole pathes (see NDP). If a node detects a major change in the global TQ it has last advertised, it will send a Router Alert Messages. More precisely, if: +A node usually measures the link quality more frequently than the quality of whole pathes (see NDP). If a node detects a major change in the global TQ it has last advertised, it will send a Router Alert Message. More precisely, if: * The best of all penalized link TQ values towards a neighbor node decreased (see [[Ndp|NDP]] for details). * The according node is a selected router towards one or more originators. @@ -50,7 +51,7 @@ An MGO-RA of the following format is broadcasted MGO_RA_NUM_BCASTS times. h4. The Router Alert (MGO-RA) Message Format: -* Packet type: Initialize this field with the NDP packet type. +* Packet type: Initialize this field with the MGO-RA packet type. * Version: Set your internal compatibility version. * TTL: Set this field to TTL_INIT. * Num RA Entries: Set this field to the number of attached Router Alert entries. @@ -90,7 +91,7 @@ h4. The Router Alert Entry Format: h4. The Router Alert (MGO-RA) Message Format (simple): -* Packet type: Initialize this field with the NDP packet type. +* Packet type: Initialize this field with the MGO-RA packet type. * Version: Set your internal compatibility version. * Originator: Set this field to the originator address the Router Alert Event was detected for. * Last Seqno: Set this field to the current sequence number of the router towards the originator the Router Alert Event was detected for. @@ -153,7 +154,7 @@ For each MGO-RA having passed the preliminary checks the following actions must ---- -h3. Re-broadcasting other nodes' MGO-RAs +h3. Re-broadcasting other nodes' Router Alerts (MGO-RAs) When an MGO-RA is to be re-broadcasted some of the message fields must be changed others must be left unchanged. All fields not mentioned in the following section remain untouched: @@ -168,7 +169,7 @@ The modified MGO-RA is then rebroadcasted MGO_RA_NUM_BCASTS times. ---- -h3. Re-broadcasting other nodes' MGO-RAs (simple) +h3. Re-broadcasting other nodes' Router Alerts (MGO-RAs) (simple) When an OGM is to be re-broadcasted some of the message fields must be changed others must be left unchanged. All fields not mentioned in the following section remain untouched: @@ -193,13 +194,20 @@ instead any node with a new enough OGM sequence number may resend its last OGM. h3. Router Request Event Detection -The MGO-RR process will be triggered for a packet past to the Router Request Event -Detection (see 'Receiving +The MGO-RR process will be triggered for an MGO-RA packet past to the Router Request Event +Detection (see 'Receiving a Router Alert (MGO-RA)'). The MGO-RR process will be triggered for any MGO-RA entry in the packet matching: -* We are the MGO-RA:Preference Router +* We are the Preference Router of the MGO-RA entry. +* We have a non-'stale' router towards the originator stated in the MGO-RA entry + (which might be a usable, alternative router towards the originator, but might + not be the best alternative router, see note below). +* We have not send an MGO-RR for the same originator, as well as the same or higher sequence number + as stated in the MGO-RA entry over the best, non-'stale' router before. + (Todo: specify the limits for 'higher') -For any match we are sending an MGO-RR to our according best next hop. + +For each we are sending an MGO-RR to our according best next hop. ---- @@ -211,32 +219,69 @@ h3. Router Request Event Detection (simple) h4. Unicasting own Router Request (MGO-RR) message +Upon a positive Router Request Event detection for an MGO-RA entry a unicast packet needs to be generated +(see 'The Router Request (MGO-RR) Message Format). + +It is then send via unicast to the best, non-'stale' router. + +---- + h4. Unicasting own Router Request (MGO-RR) message (simple) +---- + h4. The Router Request (MGO-RR) Message Format: +* Packet type: Initialize this field with the MGO-RR packet type. +* Version: Set your internal compatibility version. +* Originator: Set this field to the originator address of the MGO-RA entry which the Router Request Event was detected for. +* Last Seqno: Set this field to the sequence number of the MGO-RA entry which the Router Request Event was detected for. +* TTL: Set this field to TTL_INIT. + <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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 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 | Originator | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Originator | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Last Seqno | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TTL | + +-+-+-+-+-+-+-+-+ </pre> +---- + h4. The Router Request (MGO-RR) Message Format (simple): -h3. Reception +---- -A node receiving an MGO-RR has to check whether it has a valid, non-'stale' -path towards the stated originator. If it only has a 'stale' path then -this means that node's previous MGO-RA have not been heard by the last sender -and the receiving node may resend its last MGO-RA. +h3. Receiving a Router Request (MGO-RR) -h3. Reception (simple) +Upon receiving an MGO-RR packet a node must perform the following preliminary checks before the packet is further processed: -h3. Forwarding +* If the MGO-RR contains a version which is different to the own internal version the message must be silently dropped (thus, it must not be further processed). +* If the sender address of the MGO-RR's ethernet frame is a multicast address the message must be silently dropped. +* If the destination address of the MGO-RR's ethernet frame is a multicast address the message must be silently dropped. +* If we are the originator stated in the MGO-RR and the sequence number of the MGO-RR last seqno field is higher than our own, current OGM sequence number then the message must be silently dropped. +* If we are not the originator stated in the MGO-RR and have no router towards the originator stated in the MGO-RR the message must be silently dropped. -h3. Forwarding (simple) +In case the MGO-RR was not dropped yet one of the following four actions needs to be performed: +* If we are the originator stated in the MGO-RR and our own, current OGM sequence number is equal to the last seqno stated in the MGO-RR: +** Broadcast a new, unscheduled OGM immediatly, including the increase of the sequence number. The OGM timer should be reset after the broadcasting. See 'Broadcasting own Originator Message (OGM)' for details. +* Else if we are not the originator stated in the MGO-RR and our own, best router is 'stale': +** Rebroadcast the MGO-RA from that best router again as the neighbor we received the MGO-RR from did not have heard that MGO-RA the last time. +* Else if we are not the originator stated in the MGO-RR and our own, best router has a sequence number equal to or lower than the last seqno field in the MGO-RR: +** Forward the MGO-RR to our own, best router towards the originator stated in the MGO-RR. +** Memorize that to be able to forward the unicast OGM response later (TODO: be more specific) +* Else the following action needs to be performed: +** Send a unicast OGM response: Forward the last (re)broadcasted OGM for the originator stated in the MGO-RR (which is the OGM received via the currently selected, best router towards the originator or the originator itself) via unicast to the neighbor we received the MGO-RR from. + +h4. Receiving an OGM via Unicast + +TODO h4. OGM on 'stale' path @@ -245,24 +290,41 @@ dropped and not further forwarded the following additional checks have to be performed instead: * Am I on a matching, 'stale' path? (has this node previously broadcasted an MGO-RA with an orig entry matching OGM:orig). -* If yes, is the OGM:seqno newer than MGO-RA:last-seqno? -* If yes, is the OGM:path-TQ higher than MGO-RA:path-TQ? +* If yes, is the seqno field of the OGM newer than the last-seqno field of the MGO-RA? +* If yes, is the path-TQ field of the OGM higher than the path-TQ field of the MGO-RA? If any of the previous checks does not match, then the OGM has to be dropped as the OGM protocol would have done itself. Otherwise the OGM will be further processed in the same way as if SEQ_DIFF_MAX were reached: * The old, 'stale' router will be purged. * The OGM will be rebroadcasted. -Additionally the rebroadcasting should be done in a robust way, the same way -as nodes forwarding OGMs reliably due to MGO-RRs (e.g. 3x rebroadcast). +Additionally the rebroadcasting should be done in a robust way (e.g. 3x rebroadcast) +to lower the latency for reparing routes. Furthermore, any rebroadcasted OGM matching an MGO-RA will remove the 'stale' status for that originator (no matter if due to common OGM rebroadcast rule or MGOs graceful rebroadcasting rule). As well as any OGM coming from the old, 'stale' best next hop, no matter if we are going to rebroadcast it or not. +---- + +h3. Receiving a Router Request (MGO-RR) (simple) + +Upon receiving an MGO-RR packet a node must perform the following preliminary checks before the packet is further processed: + +* If the MGO-RR contains a version which is different to the own internal version the message must be silently dropped (thus, it must not be further processed). +* If the sender address of the MGO-RR's ethernet frame is a multicast address the message must be silently dropped. +* If the destination address of the MGO-RR's ethernet frame is a multicast address the message must be silently dropped. +* If we are the originator stated in the MGO-RR and the sequence number of the MGO-RR last seqno field is higher than our own, current OGM sequence number then the message must be silently dropped. + +TODO + h4. OGM on 'stale' path (simple) +the same, see above + +---- + h2. Proposed Values for Constants MGO_RA_NUM_BCASTS: 3 @@ -289,6 +351,7 @@ h1. Questions (both) * Note: For instance node N5 might have heard a sequence number x while node B might not have received due to packet loss. Node B could theoretically switch its route already with a smaller sequence number than x + 1, having a lower router request delay... an optimization could be a list of seqnos or something similar. * Does a 'stale' path cause instability / undesired route switching in certain topologies? +* If we did not have a new enough sequence number for a neighbor we received and MGO-RR before and if we are receiving an OGM with a higher sequence number but lower penalized path TQ compared to our currently selected, best router, then according to the OGM protocol we are usually not switching our selected router. But should we do so and therefore rebroadcast (or unicast, due to memorized MGO-RR) the OGM anyway, if the sequence number is higher than the last seqno field of any memorized MGO-RRs to help that and other poor nodes on the broken path? h1. Notes and further clarifications @@ -297,3 +360,8 @@ h1. Notes and further clarifications * The path TQ modification in an MGO-RA is the same as for the OGMs. h1. Notes and further clarifications (simple) + +h1. Further Optimizations + +* MGO-RRs could be aggregated and kept aggregated for the different originator as long as the router is the same. + Though might not be _that_ crucial for now, as these are small packets send via unicast, not large broadcast packets. \ No newline at end of file

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

commits July 2017