Applicability of the Babel Routing ProtocolIRIF, University of Paris-DiderotCase 7014Paris CEDEX 1375205Francejch@irif.frdistance-vectorloopstarvationBellman-Fordroutingrouting protocolwirelessmesh networkIGPBabel 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.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction and Background
. Technical Overview of the Babel Protocol
. Properties of the Babel Protocol
. Simplicity and Implementability
. Robustness
. Extensibility
. Limitations
. Successful Deployments of Babel
. Heterogeneous Networks
. Large-Scale Overlay Networks
. Pure Mesh Networks
. Small Unmanaged Networks
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgments
Author's Address
Introduction and BackgroundBabel 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 .Technical Overview of the Babel ProtocolAt 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 the Enhanced Interior Gateway Routing Protocol (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 the
Destination-Sequenced Distance-Vector Routing Protocol (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 carried 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.Properties of the Babel ProtocolThis section describes the properties of the Babel protocol as well as
its known limitations.Simplicity and ImplementabilityBabel 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.RobustnessThe fairly strong properties of the Babel protocol (convergence, loop
avoidance, and 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, for example, reflecting 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 link costs, etc.) is likely not
to violate the assumptions of the protocol;
robust with respect to novel metrics:
an unusual metric (continuous,
constantly fluctuating, etc.) is likely not to violate the assumptions of
the protocol.
gives examples of successful deployments
of Babel that illustrate these properties.These robustness properties have important consequences for the
applicability of the protocol: Babel works (more or less efficiently) in
a range of circumstances where traditional routing protocols don't work
well (or at all).ExtensibilityBabel's packet format has a number of features that make the protocol
extensible (see ), 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 (also known as Source-Address Dependent
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
in production (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 Type of Service (ToS) marking into account for selected routes without incurring
the full cost of a multi-topology routing protocol.
LimitationsBabel has some undesirable properties that make it suboptimal or even
unusable in some deployments.Periodic UpdatesThe main mechanisms used by Babel to reconverge after a topology change
are reactive: triggered updates, triggered retractions and explicit
requests. However, Babel relies on periodic updates to clear pathologies
after a mobility event or in the presence of heavy packet loss. The use
of periodic updates makes Babel unsuitable in at least two kinds of
environments:
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.
Full Routing TableWhile 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
the Ad hoc On-Demand Distance Vector (AODV) routing protocol ,
the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) , or the
Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) ).Slow AggregationBabel'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
second algorithm described in
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 makes
Babel slow to recover from a topology change in networks that perform
automatic route aggregation.Successful Deployments of BabelThis section gives a few examples of environments where Babel has been
successfully deployed.Heterogeneous NetworksBabel 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 suppress
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.Efficient operation in heterogeneous networks requires the implementation
to distinguish between wired and wireless links, and to perform link quality
estimation on wireless links.Large-Scale Overlay NetworksThe algorithms used by Babel (loop avoidance, hysteresis, delayed
updates) allow it to remain stable 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 .Pure Mesh NetworksWhile Babel is a general-purpose routing protocol, it has been 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 the Optimized Link State Routing Protocol with Expected Transmission Count (OLSR-ETX) and
OLSRv2 (OLSR Version 2) (equipped
e.g., with the Directional Airtime (DAT) metric ), Babel has seen
a moderate amount of successful deployment in pure mesh networks.Small Unmanaged NetworksBecause 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.Security ConsiderationsAs 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.At the time of writing, the Babel protocol is usually 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 Wi-Fi Protected Access 2 (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.
Message Authentication Code (MAC) authentication for Babel (Babel-MAC)
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-MAC should be the preferred security
mechanism in most deployments, with Babel-DTLS available for networks
that require its additional features.In addition to the above, the information that a mobile Babel node
announces to the whole routing domain is often sufficient to determine
a mobile node's physical location with reasonable precision. This might
make Babel unapplicable in scenarios where a node's location is considered
confidential.ReferencesNormative ReferencesThe Babel Routing ProtocolInformative ReferencesDelay-based Metric Extension for the Babel Routing ProtocolENS LyonIRIF, University of Paris-Diderot This document defines an extension to the Babel routing protocol that
uses symmetric delay in metric computation and therefore makes it
possible to prefer lower latency links to higher latency ones.
Work in ProgressSource-Specific Routing in BabelIRIF, University of Paris-DiderotIRIF, University of Paris-Diderot Source-specific routing (also known as Source-Address Dependent
Routing, SADR) is an extension to traditional next-hop routing where
packets are forwarded according to both their destination and their
source address. This document describes an extension for source-
specific routing to the Babel routing protocol.
Work in ProgressTOS-Specific Routing in BabelPPS, University of Paris-DiderotPPS, University of Paris-Diderot This document describes an extension to the Babel routing protocol to
support TOS-specific routing. This version is using mandatory sub-
TLVs.
Work in ProgressDiversity Routing for the Babel Routing Protocol This document defines an extension to the Babel routing protocol that
allows routing updates to carry radio frequency information, and
therefore makes it possible to use radio diversity information for
route selection.
Work in ProgressAn Experimental Comparison of Routing Protocols in Multi Hop Ad Hoc NetworksIn Proceedings of ATNACA delay-based routing metricHighly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile ComputersACM SIGCOMM '94: Proceedings of the Conference on Communications Architectures, Protocols and Applications, pp. 234-244Loop-Free Routing Using Diffusing ComputationsIEEE/ACM Transactions on Networking, Volume 1, Issue 1The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) This document describes the Lightweight Ad hoc On-Demand - Next
Generation (LOADng) distance vector routing protocol, a reactive
routing protocol intended for use in Mobile Ad hoc NETworks (MANETs).
Work in ProgressMetaroutingACM SIGCOMM Computer Communication Review, Volume 35, Issue 4Real-world performance of current proactive multi-hop mesh protocols15th Asia-Pacific Conference on CommunicationsUse of OSI IS-IS for routing in TCP/IP and dual environmentsThis memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]RIP Version 2This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]Ad hoc On-Demand Distance Vector (AODV) RoutingThe Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. This memo defines an Experimental Protocol for the Internet community.OSPF for IPv6This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]RPL: IPv6 Routing Protocol for Low-Power and Lossy NetworksLow-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]The Optimized Link State Routing Protocol Version 2This specification describes version 2 of the Optimized Link State Routing Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs).Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)This document describes the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing protocol based on Distance Vector technology. The specific algorithm used is called "DUAL", a Diffusing Update Algorithm as referenced in "Loop-Free Routing Using Diffusing Computations" (Garcia-Luna-Aceves 1993). The algorithm and procedures were researched, developed, and simulated by SRI International.MAC Authentication for the Babel Routing ProtocolBabel Routing Protocol over Datagram Transport Layer SecuritySource-specific routingIn Proceedings of the IFIP Networking ConferenceAcknowledgmentsThe author is indebted to and
for their input to this document.Author's AddressIRIF, University of Paris-DiderotCase 7014Paris CEDEX 1375205Francejch@irif.fr