draft-ietf-babel-rfc6126bis-16.txt   draft-ietf-babel-rfc6126bis-17.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
Obsoletes: 6126,7557 (if approved) D. Schinazi Obsoletes: 6126,7557 (if approved) D. Schinazi
Intended status: Standards Track Google LLC Intended status: Standards Track Google LLC
Expires: July 2, 2020 December 30, 2019 Expires: August 8, 2020 February 05, 2020
The Babel Routing Protocol The Babel Routing Protocol
draft-ietf-babel-rfc6126bis-16 draft-ietf-babel-rfc6126bis-17
Abstract Abstract
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
robust and efficient both in ordinary wired networks and in wireless robust and efficient both in ordinary wired networks and in wireless
mesh networks. This document describes the Babel routing protocol, mesh networks. This document describes the Babel routing protocol,
and obsoletes RFCs 6126 and 7557. and obsoletes RFCs 6126 and 7557.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 July 2, 2020. This Internet-Draft will expire on August 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 22 skipping to change at page 3, line 22
G.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 67 G.8. Changes since draft-ietf-babel-rfc6126bis-05 . . . . . . 67
G.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 67 G.9. Changes since draft-ietf-babel-rfc6126bis-06 . . . . . . 67
G.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 67 G.10. Changes since draft-ietf-babel-rfc6126bis-07 . . . . . . 67
G.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 67 G.11. Changes since draft-ietf-babel-rfc6126bis-08 . . . . . . 67
G.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 67 G.12. Changes since draft-ietf-babel-rfc6126bis-09 . . . . . . 67
G.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 67 G.13. Changes since draft-ietf-babel-rfc6126bis-10 . . . . . . 67
G.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 67 G.14. Changes since draft-ietf-babel-rfc6126bis-11 . . . . . . 67
G.15. Changes since draft-ietf-babel-rfc6126bis-12 . . . . . . 67 G.15. Changes since draft-ietf-babel-rfc6126bis-12 . . . . . . 67
G.16. Changes since draft-ietf-babel-rfc6126bis-13 . . . . . . 68 G.16. Changes since draft-ietf-babel-rfc6126bis-13 . . . . . . 68
G.17. Changes since draft-ietf-babel-rfc6126bis-14 . . . . . . 68 G.17. Changes since draft-ietf-babel-rfc6126bis-14 . . . . . . 68
G.18. Changes since draft-ietf-babel-rfc6126bis-14 . . . . . . 69 G.18. Changes since draft-ietf-babel-rfc6126bis-15 . . . . . . 68
G.19. Changes since draft-ietf-babel-rfc6126bis-16 . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
Babel is a loop-avoiding distance-vector routing protocol that is Babel is a loop-avoiding distance-vector routing protocol that is
designed to be robust and efficient both in networks using prefix- designed to be robust and efficient both in networks using prefix-
based routing and in networks using flat routing ("mesh networks"), based routing and in networks using flat routing ("mesh networks"),
and both in relatively stable wired networks and in highly dynamic and both in relatively stable wired networks and in highly dynamic
wireless networks. This document describes the Babel routing wireless networks. This document describes the Babel routing
protocol, and obsoletes [RFC6126] and [RFC7557]. protocol, and obsoletes [RFC6126] and [RFC7557].
skipping to change at page 13, line 40 skipping to change at page 13, line 40
Acknowledgements Section 4.6.4), Updates (Section 3.7 and IHUs Acknowledgements Section 4.6.4), Updates (Section 3.7 and IHUs
(Section 3.4.2), then the TLV MUST be sent early enough to meet the (Section 3.4.2), then the TLV MUST be sent early enough to meet the
explicit deadline (with a small margin to allow for propagation explicit deadline (with a small margin to allow for propagation
delays). In all other cases, the TLV SHOULD be sent out within one- delays). In all other cases, the TLV SHOULD be sent out within one-
half of the Multicast Hello interval. half of the Multicast Hello interval.
In order to avoid packet drops (either at the sender or at the In order to avoid packet drops (either at the sender or at the
receiver), a delay SHOULD be introduced between successive packets receiver), a delay SHOULD be introduced between successive packets
sent out on the same interface, within the constraints of the sent out on the same interface, within the constraints of the
previous paragraph. Note however that such packet pacing might previous paragraph. Note however that such packet pacing might
impair the ability of some link layers (e.g., IEEE 802.11) to perform impair the ability of some link layers (e.g., IEEE 802.11
packet aggregation. [IEEE802.11]) to perform packet aggregation.
3.2. Data Structures 3.2. Data Structures
In this section, we give a description of the data structures that In this section, we give a description of the data structures that
every Babel speaker maintains. This description is conceptual: a every Babel speaker maintains. This description is conceptual: a
Babel speaker may use different data structures as long as the Babel speaker may use different data structures as long as the
resulting protocol is the same as the one described in this document. resulting protocol is the same as the one described in this document.
For example, rather than maintaining a single table containing both For example, rather than maintaining a single table containing both
selected and unselected (fallback) routes, as described in selected and unselected (fallback) routes, as described in
Section 3.2.6 below, an actual implementation would probably use two Section 3.2.6 below, an actual implementation would probably use two
skipping to change at page 54, line 22 skipping to change at page 54, line 22
February 1993. February 1993.
[EIGRP] Albrightson, B., Garcia Luna Aceves, J., and J. Boyle, [EIGRP] Albrightson, B., Garcia Luna Aceves, J., and J. Boyle,
"EIGRP -- a Fast Routing Protocol Based on Distance "EIGRP -- a Fast Routing Protocol Based on Distance
Vectors", Proc. Interop 94, 1994. Vectors", Proc. Interop 94, 1994.
[ETX] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A [ETX] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A
high-throughput path metric for multi-hop wireless high-throughput path metric for multi-hop wireless
networks", Proc. MobiCom 2003, 2003. networks", Proc. MobiCom 2003, 2003.
[IEEE802.11]
IEEE, "IEEE Standard for Information technology--
Telecommunications and information exchange between
systems Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications",
IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April
2012.
[IS-IS] Standardization, I. O. F., "Information technology -- [IS-IS] Standardization, I. O. F., "Information technology --
Telecommunications and information exchange between Telecommunications and information exchange between
systems -- Intermediate System to Intermediate System systems -- Intermediate System to Intermediate System
intra-domain routeing information exchange protocol for intra-domain routeing information exchange protocol for
use in conjunction with the protocol for providing the use in conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", ISO/ connectionless-mode network service (ISO 8473)", ISO/
IEC 10589:2002, 2002. IEC 10589:2002, 2002.
[JITTER] Floyd, S. and V. Jacobson, "The synchronization of [JITTER] Floyd, S. and V. Jacobson, "The synchronization of
periodic routing messages", IEEE/ACM Transactions on periodic routing messages", IEEE/ACM Transactions on
skipping to change at page 56, line 43 skipping to change at page 57, line 9
j, such that 0 < k <= j, and the nominal link cost, a constant C >= j, such that 0 < k <= j, and the nominal link cost, a constant C >=
1. A node keeps a history of the last j hellos; if k or more of 1. A node keeps a history of the last j hellos; if k or more of
those have been correctly received, the link is assumed to be up, and those have been correctly received, the link is assumed to be up, and
the rxcost is set to C; otherwise, the link is assumed to be down, the rxcost is set to C; otherwise, the link is assumed to be down,
and the rxcost is set to infinity. and the rxcost is set to infinity.
Since Babel supports two kinds of Hellos, a Babel node performs k- Since Babel supports two kinds of Hellos, a Babel node performs k-
out-of-j twice for each neighbour, once on the Unicast and once on out-of-j twice for each neighbour, once on the Unicast and once on
the Multicast Hello history. If either of the instances of k-out- the Multicast Hello history. If either of the instances of k-out-
of-j indicates that the link is up, then the link is assumed to be of-j indicates that the link is up, then the link is assumed to be
up, and the rxcost is set to K; if both instances indicate that the up, and the rxcost is set to C; if both instances indicate that the
link is down, then the link is assumed to be down, and the rxcost is link is down, then the link is assumed to be down, and the rxcost is
set to infinity. In other words, the resulting rxcost is the minimum set to infinity. In other words, the resulting rxcost is the minimum
of the rxcosts yielded by the two instances of k-out-of-j link of the rxcosts yielded by the two instances of k-out-of-j link
sensing. sensing.
The cost of a link performing k-out-of-j link sensing is defined as The cost of a link performing k-out-of-j link sensing is defined as
follows: follows:
o cost = FFFF hexadecimal if rxcost = FFFF hexadecimal; o cost = FFFF hexadecimal if rxcost = FFFF hexadecimal;
skipping to change at page 57, line 19 skipping to change at page 57, line 32
A.2.2. ETX A.2.2. ETX
Unlike wired links which are bimodal (either up or down), wireless Unlike wired links which are bimodal (either up or down), wireless
links exhibit continuous variation of the link quality. Naive links exhibit continuous variation of the link quality. Naive
application of hop-count routing in networks that use wireless links application of hop-count routing in networks that use wireless links
for transit tends to select long, lossy links in preference to for transit tends to select long, lossy links in preference to
shorter, lossless links, which can dramatically reduce throughput. shorter, lossless links, which can dramatically reduce throughput.
For that reason, a routing protocol designed to support wireless For that reason, a routing protocol designed to support wireless
links must perform some form of link-quality estimation. links must perform some form of link-quality estimation.
ETX [ETX] is a simple link-quality estimation algorithm that is The Expected Transmission Cost algorithm, or ETX [ETX], is a simple
designed to work well with the IEEE 802.11 MAC. By default, the link-quality estimation algorithm that is designed to work well with
IEEE 802.11 MAC performs ARQ and rate adaptation on unicast frames, the IEEE 802.11 MAC [IEEE802.11]. By default, the IEEE 802.11 MAC
but not on multicast frames, which are sent at a fixed rate with no performs Automatic Repeat Query (ARQ) and rate adaptation on unicast
ARQ; therefore, measuring the loss rate of multicast frames yields a frames, but not on multicast frames, which are sent at a fixed rate
useful estimate of a link's quality. with no ARQ; therefore, measuring the loss rate of multicast frames
yields a useful estimate of a link's quality.
A node performing ETX link quality estimation uses a neighbour's A node performing ETX link quality estimation uses a neighbour's
Multicast Hello history to compute an estimate, written beta, of the Multicast Hello history to compute an estimate, written beta, of the
probability that a Hello TLV is successfully received. Beta can be probability that a Hello TLV is successfully received. Beta can be
computed as the fraction of 1 bits within a small number (say, 6) of computed as the fraction of 1 bits within a small number (say, 6) of
the most recent entries in the Multicast Hello history, or it can be the most recent entries in the Multicast Hello history, or it can be
an exponential average, or some combination of both approaches. Let an exponential average, or some combination of both approaches. Let
rxcost be 256 / beta. rxcost be 256 / beta.
Let alpha be MIN(1, 256/txcost), an estimate of the probability of Let alpha be MIN(1, 256/txcost), an estimate of the probability of
skipping to change at page 59, line 33 skipping to change at page 59, line 46
The Hello interval is the most important time constant: an outage or The Hello interval is the most important time constant: an outage or
a mobility event is detected within 1.5 to 3.5 Hello intervals. Due a mobility event is detected within 1.5 to 3.5 Hello intervals. Due
to Babel's use of a redundant route table, and due to its reliance on to Babel's use of a redundant route table, and due to its reliance on
triggered updates and explicit requests, the Update interval has triggered updates and explicit requests, the Update interval has
little influence on the time needed to reconverge after an outage: in little influence on the time needed to reconverge after an outage: in
practice, it only has a significant effect on the time needed to practice, it only has a significant effect on the time needed to
acquire new routes after a mobility event. While the protocol allows acquire new routes after a mobility event. While the protocol allows
intervals as low as 10ms, such low values would cause significant intervals as low as 10ms, such low values would cause significant
amounts of protocol traffic for little practical benefit. amounts of protocol traffic for little practical benefit.
The following values are recommended in a network with little The following values have been found to work well in a variety of
mobility, and where occasional outages of up to 14 seconds are environments, and are therefore RECOMMENDED default values:
acceptable:
Multicast Hello Interval: 4 seconds. Multicast Hello Interval: 4 seconds.
Unicast Hello Interval: infinite (no Unicast Hellos are sent). Unicast Hello Interval: infinite (no Unicast Hellos are sent).
Link cost: estimated using ETX on wireless links; 2-out-of-3 with Link cost: estimated using ETX on wireless links; 2-out-of-3 with
C=96 on wired links. C=96 on wired links.
IHU Interval: the advertised IHU interval is always 3 times the IHU Interval: the advertised IHU interval is always 3 times the
Multicast Hello interval. IHUs are actually sent with each Hello Multicast Hello interval. IHUs are actually sent with each Hello
skipping to change at page 60, line 14 skipping to change at page 60, line 26
Route Expiry Time: 3.5 times the advertised update interval. Route Expiry Time: 3.5 times the advertised update interval.
Request timeout: initially 2 seconds, doubled every time a request Request timeout: initially 2 seconds, doubled every time a request
is resent, up to a maximum of three times. is resent, up to a maximum of three times.
Urgent timeout: 0.2 seconds. Urgent timeout: 0.2 seconds.
Source GC time: 3 minutes. Source GC time: 3 minutes.
The following values are recommended in a network where reconvergence
within 2 seconds after a mobility event is desired:
Multicast Hello Interval: 0.5 seconds.
Unicast Hello Interval: infinite (no Unicast Hellos are sent).
Link cost, IHU Interval, Update Interval, IHU Hold Time, and Route
Expiry Time: computed as in the first case above.
Request Timeout: initially 0.5 seconds, doubled every time a
request is resent, up to a maximum of three times.
Urgent timeout: 0.2 seconds.
Source GC time: 3 minutes.
Appendix C. Route filtering Appendix C. Route filtering
Route filtering is a procedure where an instance of a routing Route filtering is a procedure where an instance of a routing
protocol either discards some of the routes announced by its protocol either discards some of the routes announced by its
neighbours, or learns them with a metric that is higher than what neighbours, or learns them with a metric that is higher than what
would be expected. Like all distance-vector protocols, Babel has the would be expected. Like all distance-vector protocols, Babel has the
ability to apply arbitrary filtering to the routes it learns, and ability to apply arbitrary filtering to the routes it learns, and
implementations of Babel that apply different sets of filtering rules implementations of Babel that apply different sets of filtering rules
will interoperate without causing routing loops. The protocol's will interoperate without causing routing loops. The protocol's
ability to perform route filtering is a consequence of the latitude ability to perform route filtering is a consequence of the latitude
skipping to change at page 69, line 5 skipping to change at page 68, line 47
G.17. Changes since draft-ietf-babel-rfc6126bis-14 G.17. Changes since draft-ietf-babel-rfc6126bis-14
o Added unscheduled Hellos to compatibility considerations. o Added unscheduled Hellos to compatibility considerations.
o Created new appendix about route selection. o Created new appendix about route selection.
o Reworked security considerations. o Reworked security considerations.
o Added some comments about packet pacing and low update intervals. o Added some comments about packet pacing and low update intervals.
G.18. Changes since draft-ietf-babel-rfc6126bis-14 G.18. Changes since draft-ietf-babel-rfc6126bis-15
o Implementing Babel-MAC is now recommended. o Implementing Babel-MAC is now recommended.
G.19. Changes since draft-ietf-babel-rfc6126bis-16
o Make the values in Appendix B normatively recommended defaults.
Authors' Addresses Authors' Addresses
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Case 7014 Case 7014
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: jch@irif.fr Email: jch@irif.fr
 End of changes. 13 change blocks. 
35 lines changed or deleted 32 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/