Applicability of the Babel
routing protocol
IRIF, University of Paris-Diderot
Case 7014
75205 Paris Cedex 13
France
jch@irif.fr
Babel is a routing protocol based on the distance-vector algorithm
augmented with mechanisms for loop avoidance and starvation avoidance.
This document describes a number of niches where Babel has been found
to be useful and that are arguably not adequately served by more mature
protocols.
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. This document describes
a number of niches where Babel is useful and that are arguably 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.
This section describes 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, interoperable 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 reasonably weak properties
of the network and the metric being used. The most significant are:
causality: the "happens-before" relation is acyclic (intuitively,
a control message is not received before it has been sent);
strict monotonicity of the metric: for any metric M and link cost C,
M < C + M (intuitively, this implies that cycles
have a strictly positive metric);
left-distributivity of the metric: for any metrics M and M'
and cost C, if M ≤ M', then
C + M ≤ C + M' (intuitively, this implies
that a good choice made by a neighbour B of a node A is also a good choice
for A).
See for more information about these
properties and their consequences.
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 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.
In addition to the above, our implementation experience indicates that
Babel tends to be robust with respect to bugs: more often than not, an
implementation bug does not violate the properties on which Babel relies,
and therefore slows down convergence or causes sub-optimal routing rather
than causing the network to collapse.
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 that two extensions to the Babel
protocol are interoperable, it is enough to verify that the interaction of
the two does not violate the base 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.
This section gives 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. Just like traditional distance-vector
protocols, Babel is able to carry prefixes of arbitrary length, to supress
redundant announcements by applying the split-horizon optimisation where
applicable, and can be configured to filter out redundant announcements
(manual aggregation). Just like specialised mesh protocols, Babel doesn't
by default assume that links are transitive or symmetric, can dynamically
compute metrics based on an estimation of link quality, and carries large
numbers of host routes efficiently by omitting common prefixes.
Because of these properties, Babel has seen a number of successful
deployments in medium-sized heterogeneous 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 heterogeneous networks requires the implementation
to distinguish between 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 by all nodes in the routing domain.
In most deployments, the Babel protocol is run over a network that is
secured either at the physical layer (e.g., physically protecting Ethernet
sockets) or at the link layer (using a protocol such as WiFi Protected
Access (WPA2)). If Babel is being run over an unprotected network, then
the routing traffic needs to be protected using a sufficiently strong
cryptographic mechanism.
At the time of writing, two such mechanisms have been defined.
Babel-HMAC is a simple and easy to implement
mechanism that only guarantees authenticity, integrity and replay
protection of the routing traffic, and only supports symmetric keying with
a small number of keys (typically just one or two). Babel-DTLS
is a more complex mechanism, that requires some minor
changes to be made to a typical Babel implementation and depends on a DTLS
stack being available, but inherits all of the features of DTLS, notably
confidentiality, optional replay protection, and the ability to use
asymmetric keys.
Due to its simplicity, Babel-HMAC should be the preferred security
mechanism in most deployments, with Babel-DTLS available for networks
that require its additional features.
The author is indebted to Jean-Paul Smetz and Alexander Vainshtein for
their input to this document.
The Babel Routing Protocol
A delay-based routing metric
RIP Version 2
The Optimized Link State Routing Protocol Version 2
Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)
OSPF for IPv6
Loop-Free Routing Using Diffusing Computations
Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
Highly Dynamic Destination-Sequenced Distance-Vector Routing
(DSDV) for Mobile Computers
Use of OSI IS-IS for routing in TCP/IP and dual environments
Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)
Real-world performance of current proactive multi-hop mesh
protocols
An Experimental Comparison of Routing Protocols in Multi Hop Ad Hoc
Networks
Source-Specific Routing in Babel
Delay-based Metric Extension for the Babel Routing Protocol
TOS-Specific Routing in Babel
Diversity Routing for the Babel Routing Protocol
Source-Specific Routing
In Proc. IFIP Networking 2015.
HMAC authentication for the Babel routing protocol
Babel Routing Protocol over Datagram Transport Layer Security
Metarouting
In Proceedings of the 2005 conference on Applications,
technologies, architectures, and protocols for computer communications
(SIGCOMM'05).