# Wireless Mesh Networking: An IoT-Oriented Perspective Survey on Relevant Technologies
## 3 Mesh in IEEE 802.11 Networks
### Other Solutions
#### 3.2.2. Babel Routing Protocol  
Another routing algorithm developed for mesh networks is Babel, a network layer distance-vector routing protocol based on a distributed version of the Bellman-Ford algorithm [13; 14]. Babel uses a mechanism originally developed for the Enhanced Interior Gateway Routing Protocol (EIGRP) [15], known as \"feasibility\", that avoids routing loops and, therefore, makes counting to infinity impossible. The drawback of the \"feasibility\" mechanism is that it can happen that a route is rejected also if it is loop-free. To avoid this problematic behavior, the \"feasibility\" method is combined together with another mechanism developed in the Destination Sequenced Distance Vector Routing (DSDV) [4], known as \"sequenced routes\". This mechanism avoids the \"starvation\" of a route happening when a router rejects all routes to a given destination, even those that are loop-free. However, in DSDV implementation, the sequenced routes algorithm is slow to react to a starvation episode. In Babel, instead, starvation recovery is accelerated by using explicit requests (known as \"seqno requests\" in the protocol) that signal a starvation episode and cause new sequenced route to be propagated in a periodic way. Babel relies on the computation, made by every pair of neighboring nodes \(A\) and \(B\), of the link cost among \(A\) and \(B\). Given a route between any two nodes, the route metric corresponds to the sum of the costs of all the links connecting \(A\) to \(B\). However, Babel does not specify any algorithm for computing metrics and existing implementations are based on packet-loss metric on wireless links and a simple hop-count metric on all other types of links [16]. The goal of the Babel algorithm is to compute, for each source node \(S\), the routes of lowest cost to \(S\). In detail, a Babel node periodically broadcasts _hello_ messages, embedded in UDP datagrams, to all of its neighbors, together with an _I Heard You_ (IHU) message to every neighbor from which it has recently heard an _hello_. From the information retrieved from _hello_ and IHU messages (whose packets are shown in Figure 3b and Figure 3c, respectively) received from \(B\), node \(A\) computes the cost \(C(A,B)\) of the link from \(A\) to \(B\). A key feature of Babel is its fast reaction to network changes; this is obtained through triggered updates, triggered retractions and explicit requests, in which a Babel node requests an action to be done from another node or a set of nodes. The main Babel packet, shown in Figure 3a, contains the following fields: (i) magic number, set to the arbitrary value 42 and identifying the Babel packet; (ii) version, identifying the adopted version of the Babel routing protocol; and (iii) body length, containing the length (in bytes) of the body following the packet header. The body is basically composed by a sequence of Type-Length-Value (TLV) tuples, each of them composed by the following fields: (i) type of TLV (e.g., _hello_ pr IHU messages); (ii) length of the body, considering only the Type and Length fields; and (iii) the TLV's payload, consisting of a body and, potentially, a list of sub-TLVs. The structure is, thus, somehow modular and the packet can be extended easilly in order to support new functionalities. Among the available TLV types, the two most relevant, being responsible for route creation, are the _hello_ and IHU packets, shown in Figure 3b  
Figure 2: OriGinator Message version 2 (OGMv2) packet format. and Figure 3c, respectively. The _hello_TLV is used for neighbor discovery and for calculating the cost of a link and is, in turn, composed by the following fields: (i) type--corresponding to the value 4 in the case of _hello_TLV; (ii) length of the body; (iii) flags to handle the _hello_TLV, e.g., to determine a unicast or a multicast transmission; (iv) sequence number--which is increased every time an _hello_packet is sent; and (v) time window, after which the originator node will send a new _hello_packet.