Open-Mesh

For quite some time the term "translation table" keeps showing up in emails, release announcements and patches but why making such a fuzz about it ? The initial translation table release (batman-adv 2011.3.0) appeared a number of months ago and still, code refinements as well as new translation table features find their way into each release. It is about time to shed some light on what makes the translation table a vital component of a batman-adv mesh network.

The translation table¶

In most batman-adv mesh networks you have the mesh nodes building the backbone of your network and a number of ordinary (non-mesh) clients using the mesh network to exchange data amongst each other or to connect to external networks (e.g. the internet). Since the non-mesh clients do not participate in the mesh itself a mechanism is needed to share the information about the client's location within the network. That is the primary task of the translation table: At every given moment it knows which non-mesh client is connected to the mesh network via which batman-adv node. Without this information non-mesh clients would not be able to receive any traffic because no other node would know where to send the packets to.

One of the new concepts introduced with the translation table is the versioning of local changes. All non-mesh clients connecting or disconnecting from a mesh node within an OGM interval belong to the same translation table version. Once the translation table changes the new version is published in the network allowing neighbor nodes to request a translation table diff instead of the whole table, thereby drastically reducing the overhead. It also is possible to ask his direct neighbor for the current translation table of any other mesh node in the network as the tables can be identified using the version number. Large mesh networks do not need to retrieve the translation table from the far end of the mesh but can simply query their neighbors.

More features¶

Due to the extensible nature of the translation table a number of features could be built on top of it. Notable examples are the AP Isolation and fast roaming support. With mobile devices getting more and more popular roaming is an often requested feature. To avoid connection loss while moving from one mesh node to the next it is imperative to sync all involved nodes about the non-mesh client's new location as fast as possible.

In order to illustrate the difficulty and how the translation table code handles this situation it is best to look at an example. Here we have a non-mesh client exchanging data with node1 while being connected to node9.

As soon as the non-mesh client roams from node9 to node10 the stream is disconnected until node1 learns the new location of our client. Depending on various parameters this synchronization can take a long time. This is how the old mechanism (pre translation table) recovered while running a 5sec OGM interval with 25% packet loss between each node (the blue bar marks the roaming event):

The old mechanism needed roughly 65 seconds to recover the stream from the client's roaming. Testing the translation table under the same circumstances looks much better:

Further reading¶

All this merely is the tip of the iceberg. The translation table is the key player when it comes to integrating non-mesh clients as efficiently as possible. A number of documents are available for the curious reader:

• Client announcement - how batman-adv handles non-mesh clients bridged into the mesh
• Client roaming - non-mesh clients moving from one mesh node to the next
• TT Flags - explanation for internal flags used by the translation table code
• Client announcement and Fast roaming in a Layer-2 mesh network

Happy routing,

The B.A.T.M.A.N. team