Applicability of the Babel routing protocol

Babel is a routing protocol based on the familiar distance-vector algorithm (sometimes known as distributed Bellman-Ford) augmented with mechanisms for loop avoidance (there is no "counting to infinity") and starvation avoidance. In this document, we argue that there exist niches where Babel is useful and that are not adequately served by more mature protocols such as OSPF and IS-IS .

At its core, Babel is a distance-vector protocol based on the distributed Bellman-Ford algorithm, similar in principle to RIP , but with two important extensions: provisions for sensing of neighbour reachability, bidirectional reachability and link quality, and support for multiple address families (e.g., IPv6 and IPv4) in a single protocol instance. Algorithms of this class are simple to understand and simple to implement, but unfortunately they do not work very well — they suffer from "counting to infinity", a case of pathologically slow convergence in some topologies after a link failure. Babel uses a mechanism pioneered by EIGRP , known as "feasibility", which avoids routing loops and therefore makes counting to infinity impossible. Feasibility is a conservative mechanism, one that not only avoids all looping routes but also rejects some loop-free routes. Thus, it can lead to a situation known as "starvation", where a router rejects all routes to a given destination, even those that are loop-free. In order to recover from starvation, Babel uses a mechanism pioneered by DSDV and known as "sequenced routes". In Babel, this mechanism is generalised to deal with prefixes of arbitrary length and routes announced at multiple points in a single routing domain (DSDV was a pure mesh protocol, and only dealt with host routes). In DSDV, the sequenced routes algorithm is slow to react to a starvation episode. In Babel, starvation recovery is accelerated by using explicit requests (known as "seqno requests" in the protocol) that signal a starvation episode and cause a new sequenced route to be propagated in a timely manner. In the absence of packet loss, this mechanism is provably complete and clears the starvation in time proportional to the diameter of the network, at the cost of some additional signalling traffic.

In this section, we describe the properties of the Babel protocol as well as its known limitations.

Babel is a conceptually simple protocol. It consists of a familiar algorithm (distributed Bellman-Ford) augmented with three simple and well-defined mechanisms (feasibility, sequenced routes and explicit requests). Given a sufficiently friendly audience, the principles behind Babel can be explained in 15 minutes, and a full description of the protocol can be done in 52 minutes (one microcentury). An important consequence is that Babel is easy to implement. At the time of writing, there exist four independent implementations, including one that was reportedly written and debugged in just two nights.

The fairly strong properties of the Babel protocol (convergence, loop avoidance, starvation avoidance) rely on some rather weak properties of the network and the metric being used. The most significant are: causality: a control message is not received before it has been sent (more precisely, the "happens-before" relation is acyclic); strict monotonicity of the metric: for any metric M and link cost C, < C + M; left-distributivity of the metric: for any metrics M and M' and cost C, if M ≤ M', then C + M ≤ C + M'. In particular, Babel does not assume a reliable transport, it does not assume ordered delivery, it does not assume that communication is transitive, and it does not require that the metric be discrete (continuous metrics are possible, reflecting for example packet loss rates). This is in contrast to link-state routing protocols such as OSPF or IS-IS , which incorporate a reliable flooding algorithm and make stronger requirements on the underlying network and metric. These weak requirements make Babel a robust protocol: robust with respect to bugs: an implementation bug does most likely not violate the properties on which Babel relies; in our (extensive) experience, bugs tend to slow down convergence or cause sub-optimal routing, but do not cause the network to collapse; robust with respect to unusual networks: an unusual network (non-transitive links, unstable metrics, etc.) does most likely not violate the assumptions of the protocol; robust with respect to novel metrics: no matter how strange your metric (continuous, constantly fluctuating, etc.), it does most likely not violate the assumptions of the protocol. These robustness properties have important consequences for the applicability of the protocol: Babel works (more or less efficiently) in a wide range of circumstances where traditional routing protocols give up.

Babel's packet format has a number of features that make the protocol extensible (see Appendix C of ), and a number of extensions have been designed to make Babel work better in situations that were not envisioned when the protocol was initially designed. The ease of extensibility is not an accident, but a consequence of the design of the protocol: it is reasonably easy to check whether a given extension violates the assumptions on which Babel relies. All of the extensions designed to date interoperate with the base protocol and with each other. This, again, is a consequence of the protocol design: in order to check the interoperability of two implementations of Babel, it is enough to verify that the interaction of the two does not violate the protocol's assumptions. Notable extensions deployed to date include: source-specific routing (SADR) allows forwarding to take a packet's source address into account, thus enabling a cheap form of multihoming ; RTT-based routing minimises link delay, which is useful in overlay network (where both hop count and packet loss are poor metrics). Some other extensions have been designed, but have not seen deployment yet (and their usefulness is yet to be demonstrated): frequency-aware routing aims to minimise radio interference in wireless networks; ToS-aware routing allows routing to take a packet's ToS marking into account for selected routes without incurring the full cost of a multi-topology routing protocol.

Babel has some undesirable properties that make it suboptimal or even unusable in some deployments.

The main mechanisms used by Babel to reconverge after a topology change are reactive: triggered updates, triggered retractions and explicit requests. However, in the presence of heavy packet loss, Babel relies on periodic updates to clear pathologies. This reliance on periodic updates makes Babel unsuitable in at least two kinds of deployments: large, stable networks: since Babel sends periodic updates even in the absence of topology changes, in well-managed, large, stable networks the amount of control traffic will be reduced by using a protocol that uses a reliable transport (such as OSPF, IS-IS or EIGRP); low-power networks: the periodic updates use up battery power even when there are no topology changes and no user traffic, which makes Babel wasteful in low-power networks.

While there exist techniques that allow a Babel speaker to function with a partial routing table (e.g., by learning just a default route or, more generally, performing route aggregation), Babel is designed around the assumption that every router has a full routing table. In networks where some nodes are too constrained to hold a full routing table, it might be preferable to use a protocol that was designed from the outset to work with a partial routing table (such as AODVv2 , RPL or LOADng ).

Babel's loop-avoidance mechanism relies on making a route unreachable after a retraction until all neighbours have been guaranteed to have acted upon the retraction, even in the presence of packet loss. Unless the optional algorithm described in Section 3.5.5 of is implemented, this entails that a node is unreachable for a few minutes after the most specific route to it has been retracted. This delay may make Babel slow to recover from a topology change in networks that perform automatic route aggregation.

In this section, we give a few examples of environments where Babel has been successfully deployed.

Babel is able to deal with both classical, prefix-based ("Internet-style") routing and flat ("mesh-style") routing over non-transitive link technologies. Because of that, it has seen a number of succesful deployments in medium-sized hybrid networks, networks that combine a wired, aggregated backbone with meshy wireless bits at the edges. No other routing protocol known to us is similarly robust and efficient in this particular kind of topology. Efficient operation in hybrid networks requires the implementation to distinguish wired and wireless links, and to perform link quality estimation on wireless links.

The algorithms used by Babel (loop avoidance, hysteresis, delayed updates) allow it to remain stable and efficient in the presence of unstable metrics, even in the presence of a feedback loop. For this reason, it has been successfully deployed in large scale overlay networks, built out of thousands of tunnels spanning continents, where it is used with a metric computed from links' latencies. This particular application depends on the extension for RTT-sensitive routing .

While Babel is a general-purpose routing protocol, it has been repeatedly shown to be competitive with dedicated routing protocols for wireless mesh networks . Although this particular niche is already served by a number of mature protocols, notably OLSR-ETX and OLSRv2 (equipped e.g. with the DAT metric ), Babel has seen a moderate amount of successful deployment in pure mesh networks.

Because of its small size and simple configuration, Babel has been deployed in small, unmanaged networks (e.g., home and small office networks), where it serves as a more efficient replacement for RIP , over which it has two significant advantages: the ability to route multiple address families (IPv6 and IPv4) in a single protocol instance, and good support for using wireless links for transit.

This document requires no IANA actions. [RFC Editor: please remove this section before publication.]

As is the case in all distance-vector routing protocols, a Babel speaker receives reachability information from its neighbours, which by default is trusted. A number of attacks are possible if this information is not suitably protected, either by a lower-layer mechanism or by an extension to the protocol itself (e.g. ). Implementors and deployers must be aware of the insecure nature of the base protocol, and must take suitable measures to ensure that the protocol is deployed as securely as required by the application.