idnits 2.17.1 draft-ietf-babel-applicability-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 5, 2019) is 1698 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-20) exists of draft-ietf-babel-rfc6126bis-07 == Outdated reference: A later version (-02) exists of draft-jonglez-babel-rtt-extension-01 == Outdated reference: A later version (-08) exists of draft-ietf-babel-source-specific-04 == Outdated reference: A later version (-10) exists of draft-ietf-babel-dtls-07 == Outdated reference: A later version (-12) exists of draft-ietf-babel-hmac-07 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Chroboczek 3 Internet-Draft IRIF, University of Paris-Diderot 4 Intended status: Informational August 5, 2019 5 Expires: February 6, 2020 7 Applicability of the Babel routing protocol 8 draft-ietf-babel-applicability-08 10 Abstract 12 Babel is a routing protocol based on the distance-vector algorithm 13 augmented with mechanisms for loop avoidance and starvation 14 avoidance. This document describes a number of niches where Babel 15 has been found to be useful and that are arguably not adequately 16 served by more mature protocols. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 6, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction and background . . . . . . . . . . . . . . . . . 2 53 1.1. Technical overview of the Babel protocol . . . . . . . . 2 54 2. Properties of the Babel protocol . . . . . . . . . . . . . . 3 55 2.1. Simplicity and implementability . . . . . . . . . . . . . 3 56 2.2. Robustness . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4 58 2.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Successful deployments of Babel . . . . . . . . . . . . . . . 6 60 3.1. Heterogeneous networks . . . . . . . . . . . . . . . . . 6 61 3.2. Large scale overlay networks . . . . . . . . . . . . . . 7 62 3.3. Pure mesh networks . . . . . . . . . . . . . . . . . . . 7 63 3.4. Small unmanaged networks . . . . . . . . . . . . . . . . 7 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 7.2. Informational References . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction and background 74 Babel [RFC6126bis] is a routing protocol based on the familiar 75 distance-vector algorithm (sometimes known as distributed Bellman- 76 Ford) augmented with mechanisms for loop avoidance (there is no 77 "counting to infinity") and starvation avoidance. This document 78 describes a number of niches where Babel is useful and that are 79 arguably not adequately served by more mature protocols such as OSPF 80 [RFC5340] and IS-IS [RFC1195]. 82 1.1. Technical overview of the Babel protocol 84 At its core, Babel is a distance-vector protocol based on the 85 distributed Bellman-Ford algorithm, similar in principle to RIP 86 [RFC2453], but with two important extensions: provisions for sensing 87 of neighbour reachability, bidirectional reachability and link 88 quality, and support for multiple address families (e.g., IPv6 and 89 IPv4) in a single protocol instance. 91 Algorithms of this class are simple to understand and simple to 92 implement, but unfortunately they do not work very well -- they 93 suffer from "counting to infinity", a case of pathologically slow 94 convergence in some topologies after a link failure. Babel uses a 95 mechanism pioneered by EIGRP [DUAL] [RFC7868], known as 96 "feasibility", which avoids routing loops and therefore makes 97 counting to infinity impossible. 99 Feasibility is a conservative mechanism, one that not only avoids all 100 looping routes but also rejects some loop-free routes. Thus, it can 101 lead to a situation known as "starvation", where a router rejects all 102 routes to a given destination, even those that are loop-free. In 103 order to recover from starvation, Babel uses a mechanism pioneered by 104 DSDV [DSDV] and known as "sequenced routes". In Babel, this 105 mechanism is generalised to deal with prefixes of arbitrary length 106 and routes announced at multiple points in a single routing domain 107 (DSDV was a pure mesh protocol, and only dealt with host routes). 109 In DSDV, the sequenced routes algorithm is slow to react to a 110 starvation episode. In Babel, starvation recovery is accelerated by 111 using explicit requests (known as "seqno requests" in the protocol) 112 that signal a starvation episode and cause a new sequenced route to 113 be propagated in a timely manner. In the absence of packet loss, 114 this mechanism is provably complete and clears the starvation in time 115 proportional to the diameter of the network, at the cost of some 116 additional signalling traffic. 118 2. Properties of the Babel protocol 120 This section describes the properties of the Babel protocol as well 121 as its known limitations. 123 2.1. Simplicity and implementability 125 Babel is a conceptually simple protocol. It consists of a familiar 126 algorithm (distributed Bellman-Ford) augmented with three simple and 127 well-defined mechanisms (feasibility, sequenced routes and explicit 128 requests). Given a sufficiently friendly audience, the principles 129 behind Babel can be explained in 15 minutes, and a full description 130 of the protocol can be done in 52 minutes (one microcentury). 132 An important consequence is that Babel is easy to implement. At the 133 time of writing, there exist four independent, interoperable 134 implementations, including one that was reportedly written and 135 debugged in just two nights. 137 2.2. Robustness 139 The fairly strong properties of the Babel protocol (convergence, loop 140 avoidance, starvation avoidance) rely on some reasonably weak 141 properties of the network and the metric being used. The most 142 significant are: 144 o causality: the "happens-before" relation is acyclic (intuitively, 145 a control message is not received before it has been sent); 147 o strict monotonicity of the metric: for any metric M and link 148 cost C, M < C + M (intuitively, this implies that cycles have a 149 strictly positive metric); 151 o left-distributivity of the metric: for any metrics M and M' and 152 cost C, if M <= M', then C + M <= C + M' (intuitively, this 153 implies that a good choice made by a neighbour B of a node A is 154 also a good choice for A). 156 See [METAROUTING] for more information about these properties and 157 their consequences. 159 In particular, Babel does not assume a reliable transport, it does 160 not assume ordered delivery, it does not assume that communication is 161 transitive, and it does not require that the metric be discrete 162 (continuous metrics are possible, reflecting for example packet loss 163 rates). This is in contrast to link-state routing protocols such as 164 OSPF [RFC5340] or IS-IS [RFC1195], which incorporate a reliable 165 flooding algorithm and make stronger requirements on the underlying 166 network and metric. 168 These weak requirements make Babel a robust protocol: 170 o robust with respect to unusual networks: an unusual network (non- 171 transitive links, unstable metrics, etc.) does most likely not 172 violate the assumptions of the protocol; 174 o robust with respect to novel metrics: no matter how strange your 175 metric (continuous, constantly fluctuating, etc.), it does most 176 likely not violate the assumptions of the protocol. 178 In addition to the above, our implementation experience indicates 179 that Babel tends to be robust with respect to bugs: more often than 180 not, an implementation bug does not violate the properties on which 181 Babel relies, and therefore slows down convergence or causes sub- 182 optimal routing rather than causing the network to collapse. 184 These robustness properties have important consequences for the 185 applicability of the protocol: Babel works (more or less efficiently) 186 in a wide range of circumstances where traditional routing protocols 187 give up. 189 2.3. Extensibility 191 Babel's packet format has a number of features that make the protocol 192 extensible (see Appendix C of [RFC6126bis]), and a number of 193 extensions have been designed to make Babel work better in situations 194 that were not envisioned when the protocol was initially designed. 196 The ease of extensibility is not an accident, but a consequence of 197 the design of the protocol: it is reasonably easy to check whether a 198 given extension violates the assumptions on which Babel relies. 200 All of the extensions designed to date interoperate with the base 201 protocol and with each other. This, again, is a consequence of the 202 protocol design: in order to check that two extensions to the Babel 203 protocol are interoperable, it is enough to verify that the 204 interaction of the two does not violate the base protocol's 205 assumptions. 207 Notable extensions deployed to date include: 209 o source-specific routing (SADR) [BABEL-SS] allows forwarding to 210 take a packet's source address into account, thus enabling a cheap 211 form of multihoming [SS-ROUTING]; 213 o RTT-based routing [BABEL-RTT] minimises link delay, which is 214 useful in overlay network (where both hop count and packet loss 215 are poor metrics). 217 Some other extensions have been designed, but have not seen 218 deployment yet (and their usefulness is yet to be demonstrated): 220 o frequency-aware routing [BABEL-Z] aims to minimise radio 221 interference in wireless networks; 223 o ToS-aware routing [BABEL-TOS] allows routing to take a packet's 224 ToS marking into account for selected routes without incurring the 225 full cost of a multi-topology routing protocol. 227 2.4. Limitations 229 Babel has some undesirable properties that make it suboptimal or even 230 unusable in some deployments. 232 2.4.1. Periodic updates 234 The main mechanisms used by Babel to reconverge after a topology 235 change are reactive: triggered updates, triggered retractions and 236 explicit requests. However, in the presence of heavy packet loss, 237 Babel relies on periodic updates to clear pathologies. This reliance 238 on periodic updates makes Babel unsuitable in at least two kinds of 239 deployments: 241 o large, stable networks: since Babel sends periodic updates even in 242 the absence of topology changes, in well-managed, large, stable 243 networks the amount of control traffic will be reduced by using a 244 protocol that uses a reliable transport (such as OSPF, IS-IS or 245 EIGRP); 247 o low-power networks: the periodic updates use up battery power even 248 when there are no topology changes and no user traffic, which 249 makes Babel wasteful in low-power networks. 251 2.4.2. Full routing table 253 While there exist techniques that allow a Babel speaker to function 254 with a partial routing table (e.g., by learning just a default route 255 or, more generally, performing route aggregation), Babel is designed 256 around the assumption that every router has a full routing table. In 257 networks where some nodes are too constrained to hold a full routing 258 table, it might be preferable to use a protocol that was designed 259 from the outset to work with a partial routing table (such as AODVv2 260 [AODVv2], RPL [RFC6550] or LOADng [LOADng]). 262 2.4.3. Slow aggregation 264 Babel's loop-avoidance mechanism relies on making a route unreachable 265 after a retraction until all neighbours have been guaranteed to have 266 acted upon the retraction, even in the presence of packet loss. 267 Unless the optional algorithm described in Section 3.5.5 of 268 [RFC6126bis] is implemented, this entails that a node is unreachable 269 for a few minutes after the most specific route to it has been 270 retracted. This delay may make Babel slow to recover from a topology 271 change in networks that perform automatic route aggregation. 273 3. Successful deployments of Babel 275 This section gives a few examples of environments where Babel has 276 been successfully deployed. 278 3.1. Heterogeneous networks 280 Babel is able to deal with both classical, prefix-based ("Internet- 281 style") routing and flat ("mesh-style") routing over non-transitive 282 link technologies. Just like traditional distance-vector protocols, 283 Babel is able to carry prefixes of arbitrary length, to supress 284 redundant announcements by applying the split-horizon optimisation 285 where applicable, and can be configured to filter out redundant 286 announcements (manual aggregation). Just like specialised mesh 287 protocols, Babel doesn't by default assume that links are transitive 288 or symmetric, can dynamically compute metrics based on an estimation 289 of link quality, and carries large numbers of host routes efficiently 290 by omitting common prefixes. 292 Because of these properties, Babel has seen a number of successful 293 deployments in medium-sized heterogeneous networks, networks that 294 combine a wired, aggregated backbone with meshy wireless bits at the 295 edges. No other routing protocol known to us is similarly robust and 296 efficient in this particular kind of topology. 298 Efficient operation in heterogeneous networks requires the 299 implementation to distinguish between wired and wireless links, and 300 to perform link quality estimation on wireless links. 302 3.2. Large scale overlay networks 304 The algorithms used by Babel (loop avoidance, hysteresis, delayed 305 updates) allow it to remain stable and efficient in the presence of 306 unstable metrics, even in the presence of a feedback loop. For this 307 reason, it has been successfully deployed in large scale overlay 308 networks, built out of thousands of tunnels spanning continents, 309 where it is used with a metric computed from links' latencies. 311 This particular application depends on the extension for RTT- 312 sensitive routing [DELAY-BASED]. 314 3.3. Pure mesh networks 316 While Babel is a general-purpose routing protocol, it has been 317 repeatedly shown to be competitive with dedicated routing protocols 318 for wireless mesh networks [REAL-WORLD] [BRIDGING-LAYERS]. Although 319 this particular niche is already served by a number of mature 320 protocols, notably OLSR-ETX and OLSRv2 [RFC7181] (equipped e.g. with 321 the DAT metric [RFC7779]), Babel has seen a moderate amount of 322 successful deployment in pure mesh networks. 324 3.4. Small unmanaged networks 326 Because of its small size and simple configuration, Babel has been 327 deployed in small, unmanaged networks (e.g., home and small office 328 networks), where it serves as a more efficient replacement for RIP 329 [RFC2453], over which it has two significant advantages: the ability 330 to route multiple address families (IPv6 and IPv4) in a single 331 protocol instance, and good support for using wireless links for 332 transit. 334 4. IANA Considerations 336 This document requires no IANA actions. [RFC Editor: please remove 337 this section before publication.] 339 5. Security Considerations 341 As is the case in all distance-vector routing protocols, a Babel 342 speaker receives reachability information from its neighbours, which 343 by default is trusted by all nodes in the routing domain. 345 In most deployments, the Babel protocol is run over a network that is 346 secured either at the physical layer (e.g., physically protecting 347 Ethernet sockets) or at the link layer (using a protocol such as WiFi 348 Protected Access (WPA2)). If Babel is being run over an unprotected 349 network, then the routing traffic needs to be protected using a 350 sufficiently strong cryptographic mechanism. 352 At the time of writing, two such mechanisms have been defined. 353 Babel-HMAC [HMAC] is a simple and easy to implement mechanism that 354 only guarantees authenticity, integrity and replay protection of the 355 routing traffic, and only supports symmetric keying with a small 356 number of keys (typically just one or two). Babel-DTLS [DTLS] is a 357 more complex mechanism, that requires some minor changes to be made 358 to a typical Babel implementation and depends on a DTLS stack being 359 available, but inherits all of the features of DTLS, notably 360 confidentiality, optional replay protection, and the ability to use 361 asymmetric keys. 363 Due to its simplicity, Babel-HMAC should be the preferred security 364 mechanism in most deployments, with Babel-DTLS available for networks 365 that require its additional features. 367 6. Acknowledgments 369 The author is indebted to Jean-Paul Smetz and Alexander Vainshtein 370 for their input to this document. 372 7. References 374 7.1. Normative References 376 [RFC6126bis] 377 Chroboczek, J. and D. Schinazi, "The Babel Routing 378 Protocol", Internet Draft draft-ietf-babel-rfc6126bis-07, 379 November 2018. 381 7.2. Informational References 383 [AODVv2] Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and 384 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 385 (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in 386 progress), May 2016. 388 [BABEL-RTT] 389 Jonglez, B. and J. Chroboczek, "Delay-based Metric 390 Extension for the Babel Routing Protocol", draft-jonglez- 391 babel-rtt-extension-01 (work in progress), May 2015. 393 [BABEL-SS] 394 Boutier, M. and J. Chroboczek, "Source-Specific Routing in 395 Babel", draft-ietf-babel-source-specific-04 (work in 396 progress), October 2018. 398 [BABEL-TOS] 399 Chouasne, G. and J. Chroboczek, "TOS-Specific Routing in 400 Babel", draft-chouasne-babel-tos-specific-00 (work in 401 progress), July 2017. 403 [BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing 404 Protocol", draft-chroboczek-babel-diversity-routing-01 405 (work in progress), February 2016. 407 [BRIDGING-LAYERS] 408 Murray, D., Dixon, M., and T. Koziniec, "An Experimental 409 Comparison of Routing Protocols in Multi Hop Ad Hoc 410 Networks", Proc. ATNAC 2010, 2010. 412 [DELAY-BASED] 413 Jonglez, B. and J. Chroboczek, "A delay-based routing 414 metric", March 2014, . 416 [DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- 417 Sequenced Distance-Vector Routing (DSDV) for Mobile 418 Computers", ACM SIGCOMM'94 Conference on Communications 419 Architectures, Protocols and Applications 234-244, 1994. 421 [DTLS] Decimo, A., Schinazi, D., and J. Chroboczek, "Babel 422 Routing Protocol over Datagram Transport Layer Security", 423 draft-ietf-babel-dtls-07 (work in progress), July 2019. 425 [DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing 426 Computations", IEEE/ACM Transactions on Networking 1:1, 427 February 1993. 429 [HMAC] Do, C., Kolodziejak, W., and J. Chroboczek, "HMAC 430 authentication for the Babel routing protocol", draft- 431 ietf-babel-hmac-07 (work in progress), June 2019. 433 [LOADng] Clausen, T., Verdiere, A., Yi, J., Niktash, A., Igarashi, 434 Y., Satoh, H., Herberg, U., Lavenu, C., Lys, T., and J. 435 Dean, "The Lightweight On-demand Ad hoc Distance-vector 436 Routing Protocol - Next Generation (LOADng)", draft- 437 clausen-lln-loadng-15 (work in progress), January 2017. 439 [METAROUTING] 440 Griffin, T. and J. Sobrinho, "Metarouting", 2005. 442 In Proceedings of the 2005 conference on Applications, 443 technologies, architectures, and protocols for computer 444 communications (SIGCOMM'05). 446 [REAL-WORLD] 447 Abolhasan, M., Hagelstein, B., and J. Wang, "Real-world 448 performance of current proactive multi-hop mesh 449 protocols", Asia-Pacific Conference on Communication 2009, 450 2009. 452 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 453 dual environments", RFC 1195, December 1990. 455 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 456 1998. 458 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 459 for IPv6", RFC 5340, July 2008. 461 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 462 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 463 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 464 Low-Power and Lossy Networks", RFC 6550, March 2012. 466 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 467 "The Optimized Link State Routing Protocol Version 2", 468 RFC 7181, April 2014. 470 [RFC7779] Rogge, H. and E. Baccelli, "Directional Airtime Metric 471 Based on Packet Sequence Numbers for Optimized Link State 472 Routing Version 2 (OLSRv2)", RFC 7779, 473 DOI 10.17487/RFC7779, April 2016. 475 [RFC7868] Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and 476 R. White, "Cisco's Enhanced Interior Gateway Routing 477 Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, May 478 2016. 480 [SS-ROUTING] 481 Boutier, M. and J. Chroboczek, "Source-Specific Routing", 482 August 2014, . 484 In Proc. IFIP Networking 2015. 486 Author's Address 488 Juliusz Chroboczek 489 IRIF, University of Paris-Diderot 490 Case 7014 491 75205 Paris Cedex 13 492 France 494 Email: jch@irif.fr