INTRODUCTION

During the past four years, mesh networking has rapidly moved from a theoretical networking
concept to commercially available devices that promise to create distributed, self-discovering and self-
healing networks. The IEEE recently created the 802.11s working group. This is driven by leading
industry and research institutes to develop a standard for mesh networks and with the objective of
providing interoperability between all mesh network devices.

While the 802.11s standard is still under development, there are a number of network protocols
that are currently available. Mesh network protocols are being developed in both
commercial/proprietary and open source contexts. In the commercial space, several vendors are now
providing mesh networking solutions based on their own proprietary routing solution.

Routing is one of the most central and important areas in the wireless multi hop ad hoc network
architecture. Despite its importance, and the hundreds of different routing protocols proposed over the
past decade, few real world experimental studies have investigated routing.

This study comparison between Optimised Link State Routing (OLSR), Better Approach To
Mobile Ad hoc Networking (B.A.T.M.A.N) and Babel. These protocols represent different approaches
to routing in multi hop ad hoc networks. OLSR is a link state routing protocol and Babel is an advanced
distance vector routing protocol. The BATMAN routing protocol does not fit neatly into pre-existing
routing taxonomies. It can be loosely described as a biologically inspired routing protocol.
Network routing technology: Babel Routing Protocol

Babel routing protocol is a loop-avoiding distance-vector routing protocol for IPv6 and IPv4
with fast convergence properties. It was created based on the ideas of Destination-Sequenced Distance
Vector (DSDV) and Ciscos Enhanced Interior Gateway Routing Protocol (EIGRP). Babel, like RIP,
uses Bellman-Ford algorithm to compute shortest path. It is designed to work well not on just wired
networks and wireless mesh networks but also overlay networks with extended support.

Babel speakers exchange Babel protocol messages. One or more Babel messages are appended
to form a Babel packet, which is sent in a single UDP datagram. The source address of a Babel packet
is always a link-local unicast address. Babel packets may be sent to a well-known link-local multicast
address (this is the usual case) or to a (link-local) unicast address. In normal operation, a Babel speaker
sends both multicast and unicast packets to its neighbors.

With the exception of Hello messages and acknowledgements (An acknowledgement MUST
be sent to a unicast destination), all Babel messages can be sent to either unicast or multicast addresses,
and their semantics does not depend on whether the destination was a unicast or multicast address.
Hence, a Babel speaker does not need to determine the destination address of a packet that it receives
in order to interpret it.

Features of Babel:

1. Suitable for unstable networks

unlike naive distance-vector routing protocols [RIP], Babel strongly limits the
frequency and duration of routing pathologies such as routing loops and black-holes
during reconvergence.
Babel then quickly reconverges to a configuration that preserves the loop-freedom and
connectedness of the network
2. Works efficiently on ordinary wired networks
When wired link is detected by Babel, it enables a number of optimizations that made
it efficient just like traditional routing protocols. On exotic links like point-to-
multipoint VPNs however, these optimizations need to be manually disabled.
3. Robust in the presence of mobility:
in a pure mesh network, Babel never creates a routing loop, and in a prefix-based
network, all routing loops are guaranteed to disappear as soon as one update went
around a loop (there is no "counting to infinity")
4. Fairly fast convergence
Since Babel uses triggered updates and explicit requests for routing information, it
usually converges almost immediately after the link quality measure has completed.
5. Simple to manage on double-stack networks (IPv6 and IPv4)
Babel is a hybrid IPv6 and IPv4 protocol: a single update packet can carry both IPv6
and IPv4 routes (this is similar to how multi-protocol BGP works). This makes Babel
particularly efficient and simple to manage on double stack networks.

Limitations of Babel

1. Not suitable for large, stable networks

Babel relies on periodic routing table updates rather than using a reliable transport
hence, in large, stable networks it generates more traffic than protocols (OSPF, IS-IS,
EIGRP) that only send updates when the network topology changes
Network Routing Technology: OLSR Protocol

The Optimized Link-State Routing Protocol (OLSR) is the IETF standardized routing protocol
for Mobile Ad hoc NETworks (MANET). The protocol is an optimization of the classical link state
algorithm tailored to the requirements of a mobile wireless LAN.

A link state protocol, OLSR (RFC3626) prototyped several innovative techniques and
principles, including the concept of Multi-Point Relays (MPRs). MPRs are selected nodes which
forward broadcast messages during the flooding process. This technique substantially reduces the
message overhead as compared to a classical flooding mechanism, where every node retransmits each
message when it receives the first copy of the message.

In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second
optimization is achieved by minimizing the number of control messages flooded in the network. As a
third optimization, an MPR node may choose to report only links between itself and its MPR selectors.
Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the
network. This information is then used for route calculation. OLSR provides optimal routes (in terms
of number of hops). The protocol is particularly suitable for large and dense networks as the technique
of MPRs works well in this context.

Multipoint Relays of the OLSR network

Features of OLSR:

1. High scalability in dense networks by way of Flooding Reduction and Topology Reduction.
2. A Modular plug-in security architecture.
3. Flexible, multi-metric routing.
4. Compressed (aggregated) addresses for significantly smaller control messages.
5. Built-in extensibility mechanisms, preserving forward and backwards compatibility.
6. Native and efficient IPv6 support.
7. Flexible and extensive gateway support, for attached networks as well as for global Internet
connectivity.
A Protocol of World Firsts

1. OLSR was the first IETF routing protocol to introduce topology reduction and flooding
reduction proving their viability and immense benefit, and being the impulse for introducing
these concepts to OSPFv3 by way of OSPF4MANET.
2. OLSR was the first IETF routing protocol to introduce topology reduction and flooding
reduction proving their viability and immense benefit, and being the impulse for introducing
these concepts to OSPFv3 by way of OSPF4MANET.
3. OLSR was the first IETF routing protocol to introduce topology reduction and flooding
reduction proving their viability and immense benefit, and being the impulse for introducing
these concepts to OSPFv3 by way of OSPF4MANET.

Advantages and Limitations:

OLSR is a flat routing protocol and it does not need central administrative system to handle its
routing process. The link is reliable for the control messages, since the messages are sent periodically
and the delivery does not have to be sequential. This protocol is best suitable for high density network
and does not allows long delays in the transmission of the packets.

However, as a limitation this protocol needs that each node periodically sends the updated
topology information throughout the entire network, this increase the protocols bandwidth usage. But
the flooding is minimized by the MPRs, which are only allowed to forward the topological messages.
Network Routing Technology: B.A.T.M.A.N

The Better Approach To Mobile Adhoc Networking (B.A.T.M.A.N.) is a routing protocol for
multi-hop mobile ad hoc networks which is under development by the German "Freifunk" community.
It was basically developed to overcome the shortcomings of Optimized Link-State Routing (OLSR).

In early 2007, the B.A.T.M.A.N. developers started experimenting with the idea of routing
on layer 2 (Ethernet layer) instead of layer 3. To differentiate from the layer 3 routing daemon, the suffix
"adv" (for: advanced) was chosen. Instead of sending UDP packets and manipulating routing tables, it
provides a virtual network interface and transparently transports packets on its own.

B.A.T.M.A.N. does have elements of classical routing protocols: It detects other B.A.T.M.A.N.
nodes and finds the best way (route) to these. It also keeps track of new nodes and informs its neighbors
about their existence. On a regular basis, every node sends out a broadcast, thereby informing all its
neighbors about its existence. The neighbors then relay this message to their neighbors, and so on. This
carries the information to every node in the network. In order to find the best way to a certain node,
B.A.T.M.A.N. counts the originator-messages received and logs which neighbor the message came in
through.

Like distance-vector protocols, B.A.T.M.A.N. does not try to determine the entire route, but,
by using the originator-messages(OGM), only the packet's first step in the right direction. The data is
handed over to the next neighbor in that direction, which in turn uses the same mechanism. This
process is repeated until the data reaches its destination. In addition to radio networks, B.A.T.M.A.N.
can also be used with common wired cable connections, such as ethernet.

Features of B.A.T.M.A.N:
1. Link Estimation
Every node estimates one-hop link qualities towards every visible neighbor.
To estimate the quality of a link, batman-adv queries the rate control algorithm of the
wireless subsystem, which already keeps track of the estimated throughput.
2. Route Propagation
3. Client Announcement
4. Client Roaming
When clients roam from the access point of one node, to the access point of another
node
The new serving node sees a client from the global list
The new node notifies the previous serving node.
The previous node now reroutes the client-traffic to the new node.
The both nodes advertises the change within the next OGM message.
5. Distributed ARP Table
When using IPv4 on top of batman-adv, clients resolves addresses with ARP.
Requests are broadcasted, and thus vulnerable to packet loss, which leads to ARP
timeouts.
batman-adv features a Distributed ARP Table that snoops ARP messages and caches
the responses in the mesh network.
6. Bridge Loop Avoidance
7. Multi-Link Optimizations
To exploit paths with alternating channels, batman-adv nodes broadcast distinct
OGMs on each available. When forwarding OGMs from other nodes, a penalty is
added when forwarding onto the interface, on which the OGM arrived.
8. AP Isolation
With a single access point, clients can be isolated from one another by the means of
AP Isolation. With batman-adv, multiple access points are used and thus AP isolation
needs to be handled within batman-adv.
With AP isolation in batman-adv, unicast traffic between isolated clients is dropped at
the first node and broadcast traffic from isolated nodes can be dropped at outgoing
interfaces.
9. Fragmentation
Since batman-adv encapsulates entire ethernet frames, the size is increased with
protocol data.
When the MTU of the ad-hoc interfaces cannot be increased accordingly,
fragmentation is needed.
With fragmentation, the encapsulated frame is transmitted in fragments, which are
merged at the receiver. This is also used for information about clients in the network.
10. Multicast Optimizations
No listeners - Multicast packets are dropped at the gateway.
Single listener - Multicast packets are forwarded as unicast.
Multiple listeners - Multicast packets are flooded as broadcast.
11. VLAN Support
batman-adv supports VLAN throughout the mesh, meaning clients are separated in
two distinct LANs, e.g. public internet access, and corporate intranet access.
Many settings in batman-adv are supported on a per-VLAN-basis. E.g. having public
clients isolated, while corporate clients can communicate.
12. Information Distribution
Often one wishes to collect data from the network, e.g. network links, hostnames, gps
locations, etc. To avoid having every node broadcasting all the information to all
nodes, A.L.F.R.E.D. supports distributed collecting of information.
Information is locally passed to slaves through a UNIX socket.
Slaves reports information to the closest master (using info from batman-adv).
Masters synchronize information with each other.
Any slave or master can request the full information from a master.
Conclusion

Optimised Link State Routing (OLSR), Better Approach To Mobile Ad hoc Networking
(B.A.T.M.A.N) and Babel are the protocols that represent different approaches to routing. However,
they do not come without weaknesses. Babel for example, is a completely insecure protocol. Any
attacker can attract data traffic by advertising routes with a low metric. This particular issue though,
can be solved either by lower-layer security mechanisms (e.g., IPsec or link-layer security), or by
appending a cryptographic key to Babel packets. Babel redeem this weakness by being the most
efficient routing protocol for unstable networks.

In conclusion, all of the protocols discussed in this study do not overwhelm each other
completely and depending on the scenario and network setup, one protocol could be more efficient than
the other. It is up to the vendors to determine which protocol suit their target consumer best.
References

Chroboczek J. (2010 October). The Babel Routing Protocol. IETF. Retrieved from
https://tools.ietf.org/id/draft-chroboczek-babel-routing-protocol-05.html.
Perkins, Charles E.; Bhagwat, Pravin (1994). "Highly Dynamic Destination-Sequenced
Distance-Vector Routing (DSDV) for Mobile Computers" (pdf). Retrieved from
http://www.cs.virginia.edu/~cl7v/cs851-papers/dsdv-sigcomm94.pdf.
Murray D., Dixon M., and Kozinniec T., An Experimental Comparison of Routing Protocols
in Multihop Ad Hoc Networks, in 2008 Australasian Telecommunications Networks and
Applications Conference, 2008.
Thomas Heide Clausen, 30th December 2015, OLSR Optimized Link-State Routing.
Retrieved from https://www.epizeuxis.net/index.php/topics/olsr-optimized-link-state-routing/.
OLSR, Optimized Link State Routing. Retrieved from
http://www.networksorcery.com/enp/protocol/olsr.htm.
Hrituparna Paul & Priyanka Sarkar, August 2013, A STUDY AND COMPARISON OF
OLSR, AODV AND ZRP ROUTING PROTOCOLS IN AD HOC NETWORKS (PDF).
Retrieved from http://esatjournals.net/ijret/2013v02/i08/IJRET20130208058.pdf.
Axel Neumann, Corinna (Elektra) Aichele, Marek Lindner, Simon Wunderlich (March
30,2008) Better Approach To Mobile Adhoc Networking (B.A.T.M.A.N.)
https://tools.ietf.org/html/draft-openmesh-b-a-t-m-a-n-00