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

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

commit 54f51c3995d4b2873d40d5681ed830c13a7d8e45 Author: Simon Wunderlich sw@simonwunderlich.de Date: Mon Oct 24 21:00:33 2011 +0000

doc: batman-adv/Bridge-loop-avoidance-II

54f51c3995d4b2873d40d5681ed830c13a7d8e45 batman-adv/Bridge-loop-avoidance-II.textile | 69 +++++++++++++++++++---------- 1 file changed, 45 insertions(+), 24 deletions(-)

diff --git a/batman-adv/Bridge-loop-avoidance-II.textile b/batman-adv/Bridge-loop-avoidance-II.textile index fe561b96..07fa722c 100644 --- a/batman-adv/Bridge-loop-avoidance-II.textile +++ b/batman-adv/Bridge-loop-avoidance-II.textile @@ -113,46 +113,68 @@ All gateways announce the clients within their LAN and ignore roaming messages f

Other non-gateway meshnodes may select their best gateway to the LAN based on the TQ value.

-h3. Claim packets +h3. Claim frames

-TODO: rework this with the new packet defintions +!claimtypes.dia.png!

-To claim a packet, a gratious ARP packet may be used with the following settings: +All claim operations are sent using "special" gratious ARP frames. 4 types are used which are illustrated above:

- * SRC IP: 0.0.0.0, SRC HW: [Originator-MAC of the Gateway] - * DST IP: 0.0.0.0, DST HW: FF:FF:FF:FF:FF:FF - * Ethernet DST: FF:FF:FF:FF:FF:FF, Ethernet SRC: [Mac of the Client] + * CLAIM frames are used to tell others that a backbone gateway feels responsible for a client now + * UNCLAIM frames are sent when a backbone gateway does not feel responsible anymore + * ANNOUNCE frames are sent regularly to find other backbone gateways and provides the CRC of its local table + * REQUEST frames are used to ask for a full table update when the information is out of sync (i.e. the announced crc does not match with the local crc)

-To unclaim a packet, the SRC HW and Ethernet SRC shall be swapped: +the claim type is announced within the 4th byte of the Target HW address. Each claim frame is discussed in detail further.

- * SRC HW: [Originator-MAC of the Gateway] - * Ethernet SRC: [Mac of the Client] - -Note: Although this is a misuse of ARP packets, the "normal" ARP process should not be disturbed as the IP addresses ++Note:+ Although this is a misuse of ARP packets, the "normal" ARP process should not be disturbed as the IP addresses (0.0.0.0) should not be in any sane ARP table. As far as I understand, a gratious ARP should only be considered if the IP address is already in an ARP table [2].

[1] http://tools.ietf.org/html/rfc826 [2] http://tools.ietf.org/html/rfc2002#section-4.6

-+Periodic self announcements:+ ++CLAIM frames+ + +A CLAIM frame is sent when a new client is added to the local table and the backbone gateway wants to be responsible now. + +Backbone gateways which receive a CLAIM frame (and accept the backbone gateway) must add the claim in their tables, replacing older claims if they are present (even their own). + ++UNCLAIM frames+

-Periodic self announcement packets by the gateways are basically special claim packets, which are sent by the gateways periodically (e.g. every 30 seconds) and serve the following purposes: +An UNCLAIM frame is sent when the backbone gateway is not responsible anymore, e.g. due to detected roaming into the backbone or a timeout

- * gateways learn that other gateways exist on the LAN (this is important e.g. for new gateways) - * when no self announcements packets are received anymore, we can assume that this gateway is no longer serving the LAN and can remove its claims - * it contains a checksum which other gateways can use to check their table consistency. If a table is not consistent, a gateway can ask for the full claim table via mesh. +Backbone gateways which receive an UNCLAIM frame (and accept the backbone gateway) must remove the the claim from their tables.

-self announcement packets are also sent as gratious arp packets with the following format: ++ANNOUNCE frames+

- * SRC IP: 0.0.0.0, SRC HW: 43:05:43:05:[CRC16 of the local table] - * DST IP: 0.0.0.0, DST HW: FF:FF:FF:FF:FF:FF - * Ethernet DST: FF:FF:FF:FF:FF:FF, Ethernet SRC: [Originator-MAC of the Gateway] +The periodic ANNOUNCE frames (default: every 10 seconds) by the backbone gateways serve the following purposes: + + * backbone gateways learn about the existence of other backbone gateways (this is important for new gateways) + * when no ANNOUNCE frames are received anymore, we can assume that this backbone gateway is no longer serving the LAN and can remove its claims + * it contains a checksum (the last 2 bytes YY:YY within the Sender HW address) which other backbone gateways can use to check their table consistency. If a table is not consistent, a backbone gateway can ask for the full claim table via the REQUEST frame.

Note: the SRC HW address is a "locally administered address" group address which should not be used by any NIC or protocol, but is not registered with the IEEE

-+Full claim table update+ -TODO: specify table updates. this is done with request claim packets and the normal claim/unclaim packets ++REQUEST frame+ + +A REQUEST frame is sent by a backbone gateway who just received an ANNOUNCE frames and discovers that the CRC is out of sync. + +It then sends a REQUEST frame to the backbone gateway it just received the ANNOUNCE frame from, and deletes all claims it knows from this backbone gateway. + +The asked backbone gateway will send all of its local CLAIM frames again, and send another ANNOUNCE frame afterwards. + +The requesting backbone gateway will add all claims it receives through the CLAIM frames, and can check the CRC another time once it receives the final ANNOUNCE frame. +(If the CRC is still wrong, the process will start again) + +While a request is in flight, the requesting backbone gateway will close down its soft interface for broadcast to avoid loops in this period. + ++group forming+ + +Within the "Target HW address", the last 2 bytes XX:XX are used for as a local group identifier. + +After starting batman, these bytes are initialized with the CRC16 checksum of the local mac address. Once it receives a claim frame from another backbone gateway which is also known through the mesh, the own group identifier is copied from this other backbone gateway when it is bigger than the own one. Due to this mechanism, after a short period all mesh nodes who are participating in the same mesh share the same group id. + +Generally, claim frames are only accepted if they are on the same group (e.g. participating on the same mesh). This helps for some network scenarios, e.g. when multiple different meshes are connected to one shared LAN (see two meshes test setup below).

h2. Discussion:

@@ -190,6 +212,7 @@ TODO: explain groups h2. Test Cases

h3. TODO: Define Roaming Test Cases (LAN -> mesh, mesh -> LAN) + h3. TODO: Define gateway selection test cases (switch gateways)

h3. Two LANs connected by one mesh @@ -229,5 +252,3 @@ h3. discussion 2011-09-30: h3. Agenda/Comments for next discussion

Please add any comments for the next discussion here: - - * \ No newline at end of file