< draft-ietf-babel-applicability-06.txt   draft-ietf-babel-applicability-07.txt >
Network Working Group J. Chroboczek Network Working Group J. Chroboczek
Internet-Draft IRIF, University of Paris-Diderot Internet-Draft IRIF, University of Paris-Diderot
Intended status: Informational April 26, 2019 Intended status: Informational July 7, 2019
Expires: October 28, 2019 Expires: January 8, 2020
Applicability of the Babel routing protocol Applicability of the Babel routing protocol
draft-ietf-babel-applicability-06 draft-ietf-babel-applicability-07
Abstract Abstract
Babel is a routing protocol based on the distance-vector algorithm Babel is a routing protocol based on the distance-vector algorithm
augmented with mechanisms for loop avoidance and starvation augmented with mechanisms for loop avoidance and starvation
avoidance. In this document, we argue that there exist niches where avoidance. In this document, we describe a number of niches where
Babel is useful and that are not adequately served by more mature Babel has been found to be useful and that are arguably not
protocols. adequately served by more mature protocols.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction and background . . . . . . . . . . . . . . . . . 2 1. Introduction and background . . . . . . . . . . . . . . . . . 2
1.1. Technical overview of the Babel protocol . . . . . . . . 2 1.1. Technical overview of the Babel protocol . . . . . . . . 2
2. Properties of the Babel protocol . . . . . . . . . . . . . . 3 2. Properties of the Babel protocol . . . . . . . . . . . . . . 3
2.1. Simplicity and implementability . . . . . . . . . . . . . 3 2.1. Simplicity and implementability . . . . . . . . . . . . . 3
2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5
3. Successful deployments of Babel . . . . . . . . . . . . . . . 6 3. Successful deployments of Babel . . . . . . . . . . . . . . . 6
3.1. Hybrid networks . . . . . . . . . . . . . . . . . . . . . 6 3.1. Hybrid networks . . . . . . . . . . . . . . . . . . . . . 6
3.2. Large scale overlay networks . . . . . . . . . . . . . . 6 3.2. Large scale overlay networks . . . . . . . . . . . . . . 7
3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7 3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7
3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7 3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Informational References . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informational References . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction and background 1. Introduction and background
Babel [RFC6126bis] is a routing protocol based on the familiar Babel [RFC6126bis] is a routing protocol based on the familiar
distance-vector algorithm (sometimes known as distributed Bellman- distance-vector algorithm (sometimes known as distributed Bellman-
Ford) augmented with mechanisms for loop avoidance (there is no Ford) augmented with mechanisms for loop avoidance (there is no
"counting to infinity") and starvation avoidance. In this document, "counting to infinity") and starvation avoidance. In this document,
we argue that there exist niches where Babel is useful and that are we describe a number of niches where Babel is useful and that are
not adequately served by more mature protocols such as OSPF [RFC5340] arguably not adequately served by more mature protocols such as OSPF
and IS-IS [RFC1195]. [RFC5340] and IS-IS [RFC1195].
1.1. Technical overview of the Babel protocol 1.1. Technical overview of the Babel protocol
At its core, Babel is a distance-vector protocol based on the At its core, Babel is a distance-vector protocol based on the
distributed Bellman-Ford algorithm, similar in principle to RIP distributed Bellman-Ford algorithm, similar in principle to RIP
[RFC2453], but with two important extensions: provisions for sensing [RFC2453], but with two important extensions: provisions for sensing
of neighbour reachability, bidirectional reachability and link of neighbour reachability, bidirectional reachability and link
quality, and support for multiple address families (e.g., IPv6 and quality, and support for multiple address families (e.g., IPv6 and
IPv4) in a single protocol instance. IPv4) in a single protocol instance.
skipping to change at page 3, line 39 skipping to change at page 3, line 39
2.1. Simplicity and implementability 2.1. Simplicity and implementability
Babel is a conceptually simple protocol. It consists of a familiar Babel is a conceptually simple protocol. It consists of a familiar
algorithm (distributed Bellman-Ford) augmented with three simple and algorithm (distributed Bellman-Ford) augmented with three simple and
well-defined mechanisms (feasibility, sequenced routes and explicit well-defined mechanisms (feasibility, sequenced routes and explicit
requests). Given a sufficiently friendly audience, the principles requests). Given a sufficiently friendly audience, the principles
behind Babel can be explained in 15 minutes, and a full description behind Babel can be explained in 15 minutes, and a full description
of the protocol can be done in 52 minutes (one microcentury). of the protocol can be done in 52 minutes (one microcentury).
An important consequence is that Babel is easy to implement. At the An important consequence is that Babel is easy to implement. At the
time of writing, there exist four independent implementations, time of writing, there exist four independent, interoperable
including one that was reportedly written and debugged in just two implementations, including one that was reportedly written and
nights. debugged in just two nights.
2.2. Robustness 2.2. Robustness
The fairly strong properties of the Babel protocol (convergence, loop The fairly strong properties of the Babel protocol (convergence, loop
avoidance, starvation avoidance) rely on some rather weak properties avoidance, starvation avoidance) rely on some reasonably weak
of the network and the metric being used. The most significant are: properties of the network and the metric being used. The most
significant are:
o causality: a control message is not received before it has been o causality: the "happens-before" relation is acyclic (intuitively,
sent (more precisely, the "happens-before" relation is acyclic); a control message is not received before it has been sent);
o strict monotonicity of the metric: for any metric M and link o strict monotonicity of the metric: for any metric M and link
cost C, M < C + M; cost C, M < C + M (intuitively, this implies that cycles have a
strictly positive metric);
o left-distributivity of the metric: for any metrics M and M' and o left-distributivity of the metric: for any metrics M and M' and
cost C, if M <= M', then C + M <= C + M'. 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 [METAROUTING] for more information about these properties and
their consequences.
In particular, Babel does not assume a reliable transport, it does In particular, Babel does not assume a reliable transport, it does
not assume ordered delivery, it does not assume that communication is not assume ordered delivery, it does not assume that communication is
transitive, and it does not require that the metric be discrete transitive, and it does not require that the metric be discrete
(continuous metrics are possible, reflecting for example packet loss (continuous metrics are possible, reflecting for example packet loss
rates). This is in contrast to link-state routing protocols such as rates). This is in contrast to link-state routing protocols such as
OSPF [RFC5340] or IS-IS [RFC1195], which incorporate a reliable OSPF [RFC5340] or IS-IS [RFC1195], which incorporate a reliable
flooding algorithm and make stronger requirements on the underlying flooding algorithm and make stronger requirements on the underlying
network and metric. network and metric.
skipping to change at page 4, line 47 skipping to change at page 5, line 4
applicability of the protocol: Babel works (more or less efficiently) applicability of the protocol: Babel works (more or less efficiently)
in a wide range of circumstances where traditional routing protocols in a wide range of circumstances where traditional routing protocols
give up. give up.
2.3. Extensibility 2.3. Extensibility
Babel's packet format has a number of features that make the protocol Babel's packet format has a number of features that make the protocol
extensible (see Appendix C of [RFC6126bis]), and a number of extensible (see Appendix C of [RFC6126bis]), and a number of
extensions have been designed to make Babel work better in situations extensions have been designed to make Babel work better in situations
that were not envisioned when the protocol was initially designed. that were not envisioned when the protocol was initially designed.
The ease of extensibility is not an accident, but a consequence of 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 the design of the protocol: it is reasonably easy to check whether a
given extension violates the assumptions on which Babel relies. given extension violates the assumptions on which Babel relies.
All of the extensions designed to date interoperate with the base All of the extensions designed to date interoperate with the base
protocol and with each other. This, again, is a consequence of the protocol and with each other. This, again, is a consequence of the
protocol design: in order to check the interoperability of two protocol design: in order to check that two extensions to the Babel
implementations of Babel, it is enough to verify that the interaction protocol are interoperable, it is enough to verify that the
of the two does not violate the protocol's assumptions. interaction of the two does not violate the base protocol's
assumptions.
Notable extensions deployed to date include: Notable extensions deployed to date include:
o source-specific routing (SADR) [BABEL-SS] allows forwarding to o source-specific routing (SADR) [BABEL-SS] allows forwarding to
take a packet's source address into account, thus enabling a cheap take a packet's source address into account, thus enabling a cheap
form of multihoming [SS-ROUTING]; form of multihoming [SS-ROUTING];
o RTT-based routing [BABEL-RTT] minimises link delay, which is o RTT-based routing [BABEL-RTT] minimises link delay, which is
useful in overlay network (where both hop count and packet loss useful in overlay network (where both hop count and packet loss
are poor metrics). are poor metrics).
skipping to change at page 8, line 15 skipping to change at page 8, line 22
the absence of persistent state. Babel-DTLS [DTLS] is a more complex the absence of persistent state. Babel-DTLS [DTLS] is a more complex
mechanism, that requires some minor changes to be made to a typical mechanism, that requires some minor changes to be made to a typical
Babel implementation and depends on a DTLS stack being available, but Babel implementation and depends on a DTLS stack being available, but
inherits all of the features of DTLS, notably confidentiality and the inherits all of the features of DTLS, notably confidentiality and the
ability to use asymmetric keys. ability to use asymmetric keys.
Due to its simplicity, Babel-HMAC should be the preferred security Due to its simplicity, Babel-HMAC should be the preferred security
mechanism in most deployments, with Babel-DTLS available for networks mechanism in most deployments, with Babel-DTLS available for networks
that require its additional features. that require its additional features.
6. References 6. Acknowledgments
6.1. Normative References The author is indebted to Jean-Paul Smetz and Alexander Vainshtein
for their input to this document.
7. References
7.1. Normative References
[RFC6126bis] [RFC6126bis]
Chroboczek, J. and D. Schinazi, "The Babel Routing Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", Internet Draft draft-ietf-babel-rfc6126bis-07, Protocol", Internet Draft draft-ietf-babel-rfc6126bis-07,
November 2018. November 2018.
6.2. Informational References 7.2. Informational References
[AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and [AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and
V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2
(AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in
progress), May 2016. progress), May 2016.
[BABEL-RTT] [BABEL-RTT]
Jonglez, B. and J. Chroboczek, "Delay-based Metric Jonglez, B. and J. Chroboczek, "Delay-based Metric
Extension for the Babel Routing Protocol", draft-jonglez- Extension for the Babel Routing Protocol", draft-jonglez-
babel-rtt-extension-01 (work in progress), May 2015. babel-rtt-extension-01 (work in progress), May 2015.
skipping to change at page 9, line 21 skipping to change at page 9, line 30
Jonglez, B. and J. Chroboczek, "A delay-based routing Jonglez, B. and J. Chroboczek, "A delay-based routing
metric", March 2014, <http://arxiv.org/abs/1403.3488>. metric", March 2014, <http://arxiv.org/abs/1403.3488>.
[DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination-
Sequenced Distance-Vector Routing (DSDV) for Mobile Sequenced Distance-Vector Routing (DSDV) for Mobile
Computers", ACM SIGCOMM'94 Conference on Communications Computers", ACM SIGCOMM'94 Conference on Communications
Architectures, Protocols and Applications 234-244, 1994. Architectures, Protocols and Applications 234-244, 1994.
[DTLS] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel [DTLS] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security", Routing Protocol over Datagram Transport Layer Security",
draft-ietf-babel-dtls-04 (work in progress), February draft-ietf-babel-dtls-07 (work in progress), July 2019.
2019.
[DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing [DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing
Computations", IEEE/ACM Transactions on Networking 1:1, Computations", IEEE/ACM Transactions on Networking 1:1,
February 1993. February 1993.
[HMAC] Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC [HMAC] Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC
authentication for the Babel routing protocol", draft- authentication for the Babel routing protocol", draft-
ietf-babel-hmac-04 (work in progress), March 2019. ietf-babel-hmac-07 (work in progress), June 2019.
[LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, [LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi,
Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J.
Dean, "The Lightweight On-demand Ad hoc Distance-vector Dean, "The Lightweight On-demand Ad hoc Distance-vector
Routing Protocol - Next Generation (LOADng)", draft- Routing Protocol - Next Generation (LOADng)", draft-
clausen-lln-loadng-15 (work in progress), January 2017. clausen-lln-loadng-15 (work in progress), January 2017.
[METAROUTING]
Griffin, T. and J. Sobrinho, "Metarouting", 2005.
In Proceedings of the 2005 conference on Applications,
technologies, architectures, and protocols for computer
communications (SIGCOMM'05).
[REAL-WORLD] [REAL-WORLD]
Abolhasan, M., Hagelstein, B., and J. Wang, "Real-world Abolhasan, M., Hagelstein, B., and J. Wang, "Real-world
performance of current proactive multi-hop mesh performance of current proactive multi-hop mesh
protocols", Asia-Pacific Conference on Communication 2009, protocols", Asia-Pacific Conference on Communication 2009,
2009. 2009.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
 End of changes. 20 change blocks. 
32 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/