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

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

commit 148e66af0e48d7fac9f06a2d517f60b6e607166e Author: Simon Wunderlich sw@simonwunderlich.de Date: Thu Oct 27 19:06:21 2011 +0000

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

148e66af0e48d7fac9f06a2d517f60b6e607166e batman-adv/Bridge-loop-avoidance-Protocol.textile | 71 +++++++++++++++++++++++ 1 file changed, 71 insertions(+)

diff --git a/batman-adv/Bridge-loop-avoidance-Protocol.textile b/batman-adv/Bridge-loop-avoidance-Protocol.textile new file mode 100644 index 00000000..cf8d8b10 --- /dev/null +++ b/batman-adv/Bridge-loop-avoidance-Protocol.textile @@ -0,0 +1,71 @@ +h1. Bridge loop avoidance protocol description + +Further pages on this topic: + + * [[Bridge-loop-avoidance-Testcases]] Test case descriptions + * [[Bridge-loop-avoidance-II]] Technical description + * [[Bridge-loop-avoidance]] User howto + +h3. Claim frames + +!claimtypes.dia.png! + +All claim operations are sent using "special" gratuitous ARP frames. 4 types are used which are illustrated above: + + * 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) + +The claim type is announced within the 4th byte of the Target HW address. + ++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 gratuitous 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 + ++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+ + +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 + +Backbone gateways which receive an UNCLAIM frame (and accept the backbone gateway) must remove the the claim from their tables. + ++ANNOUNCE frames+ + +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 backbone 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 + ++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 once more as soon as 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 backbone (see two meshes test setup below). +