| RFC 8965 | Babel Protocol Applicability | January 2021 |
| Chroboczek | Informational | [Page] |
Babel is a routing protocol based on the distance-vector algorithmaugmented with mechanisms for loop avoidance and starvation avoidance.This document describes a number of niches where Babel has been foundto be useful and that are arguably not adequately served by more matureprotocols.¶
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 athttps://www.rfc-editor.org/info/rfc8965.¶
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 (https://trustee.ietf.org/license-info) 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.¶
Babel[RFC8966] is a routing protocol based on thefamiliar distance-vector algorithm (sometimes known as distributedBellman-Ford) augmented with mechanisms for loop avoidance (there is no"counting to infinity") and starvation avoidance. This document describesa number of niches where Babel is useful and that are arguably notadequately served by more mature protocols such as OSPF[RFC5340] and IS-IS[RFC1195].¶
At its core, Babel is a distance-vector protocol based on thedistributed Bellman-Ford algorithm, similar in principle to RIP[RFC2453] but with two important extensions: provisions forsensing of neighbour reachability, bidirectional reachability, and linkquality, 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 toimplement, but unfortunately they do not work very well -- theysuffer from "counting to infinity", a case of pathologically slowconvergence in some topologies after a link failure. Babel uses a mechanismpioneered by the Enhanced Interior Gateway Routing Protocol (EIGRP)[DUAL][RFC7868], knownas "feasibility", which avoids routing loops and therefore makes countingto infinity impossible.¶
Feasibility is a conservative mechanism, one that not only avoids alllooping routes but also rejects some loop-free routes. Thus, it can leadto a situation known as "starvation", where a router rejects all routes toa given destination, even those that are loop-free. In order to recoverfrom starvation, Babel uses a mechanism pioneered by theDestination-Sequenced Distance-Vector Routing Protocol (DSDV)[DSDV] and known as "sequenced routes". In Babel, thismechanism is generalised to deal with prefixes of arbitrary length androutes announced at multiple points in a single routing domain (DSDV wasa pure mesh protocol, and only carried host routes).¶
In DSDV, the sequenced routes algorithm is slow to react toa starvation episode. In Babel, starvation recovery is accelerated byusing explicit requests (known as "seqno requests" in the protocol) thatsignal a starvation episode and cause a new sequenced route to bepropagated in a timely manner. In the absence of packet loss, thismechanism is provably complete and clears the starvation in timeproportional to the diameter of the network, at the cost of someadditional signalling traffic.¶
This section describes the properties of the Babel protocol as well asits known limitations.¶
Babel is a conceptually simple protocol. It consists of a familiaralgorithm (distributed Bellman-Ford) augmented with three simple andwell-defined mechanisms (feasibility, sequenced routes, and explicitrequests). Given a sufficiently friendly audience, the principles behindBabel can be explained in 15 minutes, and a full description of theprotocol can be done in 52 minutes (one microcentury).¶
An important consequence is that Babel is easy to implement. At thetime 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, loopavoidance, and starvation avoidance) rely on some reasonably weak propertiesof the network and the metric being used. The most significant are:¶
See[METAROUTING] for more information about theseproperties and their consequences.¶
In particular, Babel does not assume a reliable transport, it does notassume ordered delivery, it does not assume that communication istransitive, and it does not require that the metric be discrete(continuous metrics are possible, for example, reflecting packet lossrates). This is in contrast to link-state routing protocols such as OSPF[RFC5340] or IS-IS[RFC1195], whichincorporate a reliable flooding algorithm and make stronger requirementson the underlying network and metric.¶
These weak requirements make Babel a robust protocol:¶
Section 3 gives examples of successful deploymentsof Babel that illustrate these properties.¶
These robustness properties have important consequences for theapplicability of the protocol: Babel works (more or less efficiently) ina range of circumstances where traditional routing protocols don't workwell (or at all).¶
Babel's packet format has a number of features that make the protocolextensible (seeAppendix D of [RFC8966]), anda number of extensions have been designed to make Babel work better insituations that were not envisioned when the protocol was initiallydesigned. The ease of extensibility is not an accident, but a consequenceof the design of the protocol: it is reasonably easy to check whethera given extension violates the assumptions on which Babel relies.¶
All of the extensions designed to date interoperate with the baseprotocol and with each other. This, again, is a consequence of theprotocol design: in order to check that two extensions to the Babelprotocol are interoperable, it is enough to verify that the interaction ofthe two does not violate the base protocol's assumptions.¶
Notable extensions deployed to date include:¶
Some other extensions have been designed but have not seen deploymentin production (and their usefulness is yet to be demonstrated):¶
Babel has some undesirable properties that make it suboptimal or evenunusable in some deployments.¶
The main mechanisms used by Babel to reconverge after a topology changeare reactive: triggered updates, triggered retractions and explicitrequests. However, Babel relies on periodic updates to clear pathologiesafter a mobility event or in the presence of heavy packet loss. The useof periodic updates makes Babel unsuitable in at least two kinds ofenvironments:¶
While there exist techniques that allow a Babel speaker to functionwith a partial routing table (e.g., by learning just a default route or,more generally, performing route aggregation), Babel is designed aroundthe assumption that every router has a full routing table. In networkswhere some nodes are too constrained to hold a full routing table, itmight be preferable to use a protocol that was designed from the outset towork with a partial routing table (such as the Ad hoc On-Demand Distance Vector (AODV) routing protocol[RFC3561],the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL)[RFC6550], or theLightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)[LOADng]).¶
Babel's loop-avoidance mechanism relies on making a route unreachableafter a retraction until all neighbours have been guaranteed to have actedupon the retraction, even in the presence of packet loss. Unless thesecond algorithm described inSection 3.5.5 of [RFC8966]is implemented, this entails that a node is unreachable for a few minutesafter the most specific route to it has been retracted. This delay makesBabel slow to recover from a topology change in networks that performautomatic route aggregation.¶
This section gives a few examples of environments where Babel has beensuccessfully deployed.¶
Babel is able to deal with both classical, prefix-based("Internet-style") routing and flat ("mesh-style") routing overnon-transitive link technologies. Just like traditional distance-vectorprotocols, Babel is able to carry prefixes of arbitrary length, to suppressredundant announcements by applying the split-horizon optimisation whereapplicable, and can be configured to filter out redundant announcements(manual aggregation). Just like specialised mesh protocols, Babel doesn'tby default assume that links are transitive or symmetric, can dynamicallycompute metrics based on an estimation of link quality, and carries largenumbers of host routes efficiently by omitting common prefixes.¶
Because of these properties, Babel has seen a number of successfuldeployments in medium-sized heterogeneous networks, networks that combinea wired, aggregated backbone with meshy wireless bits at the edges.¶
Efficient operation in heterogeneous networks requires the implementationto distinguish between wired and wireless links, and to perform link qualityestimation on wireless links.¶
The algorithms used by Babel (loop avoidance, hysteresis, delayedupdates) allow it to remain stable in the presence of unstable metrics,even in the presence of a feedback loop. For this reason, it has beensuccessfully deployed in large-scale overlay networks, built out ofthousands of tunnels spanning continents, where it is used with a metriccomputed from links' latencies.¶
This particular application depends on the extension for RTT-sensitiverouting[DELAY-BASED].¶
While Babel is a general-purpose routing protocol, it has been shown tobe competitive with dedicated routing protocols for wireless mesh networks[REAL-WORLD][BRIDGING-LAYERS]. Althoughthis 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)[RFC7181] (equippede.g., with the Directional Airtime (DAT) metric[RFC7779]), Babel has seena moderate amount of successful deployment in pure mesh networks.¶
Because of its small size and simple configuration, Babel has beendeployed in small, unmanaged networks (e.g., home and small officenetworks), where it serves as a more efficient replacement for RIP[RFC2453], over which it has two significant advantages: theability to route multiple address families (IPv6 and IPv4) in a singleprotocol instance and good support for using wireless links fortransit.¶
As is the case in all distance-vector routing protocols, a Babelspeaker receives reachability information from its neighbours, which bydefault is trusted by all nodes in the routing domain.¶
At the time of writing, the Babel protocol is usually run overa network that is secured either at the physical layer (e.g., physicallyprotecting Ethernet sockets) or at the link layer (using a protocol suchas Wi-Fi Protected Access 2 (WPA2)). If Babel is being run over anunprotected network, then the routing traffic needs to be protected usinga sufficiently strong cryptographic mechanism.¶
At the time of writing, two such mechanisms have been defined.Message Authentication Code (MAC) authentication for Babel (Babel-MAC)[RFC8967] is a simple and easy to implementmechanism that only guarantees authenticity, integrity, and replayprotection of the routing traffic and only supports symmetric keying witha small number of keys (typically just one or two). Babel-DTLS[RFC8968] is a more complex mechanism that requiressome minor changes to be made to a typical Babel implementation anddepends on a DTLS stack being available, but inherits all of the featuresof DTLS, notably confidentiality, optional replay protection, and theability to use asymmetric keys.¶
Due to its simplicity, Babel-MAC should be the preferred securitymechanism in most deployments, with Babel-DTLS available for networksthat require its additional features.¶
In addition to the above, the information that a mobile Babel nodeannounces to the whole routing domain is often sufficient to determinea mobile node's physical location with reasonable precision. This mightmake Babel unapplicable in scenarios where a node's location is consideredconfidential.¶
The author is indebted toJean-Paul Smetz andAlexander Vainshtein for their input to this document.¶