<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPErfc>rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc version='3' docName='draft-ietf-babel-rtt-extension-07' number="9616" updates="" obsoletes="" tocInclude="true" ipr='trust200902' consensus='true' submissionType='IETF' category='std' xml:lang='en' xmlns:xi="http://www.w3.org/2001/XInclude"> <front> <title abbrev="Babel RTTExtension">Delay-basedExtension">Delay-Based Metric Extension for the Babel Routing Protocol</title> <seriesInfo name="RFC" value="9616"/> <author fullname="Baptiste Jonglez" initials="B." surname="Jonglez"> <organization>ENS Lyon</organization> <address> <postal><street></street> <city></city> <region></region> <code></code><country>France</country> </postal> <email>baptiste.jonglez@ens-lyon.org</email> </address> </author> <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"> <organization>IRIF, Université Paris Cité</organization> <address> <postal> <street>Case 7014</street> <city>75205 Paris Cedex 13</city><region></region> <code></code><country>France</country> </postal> <email>jch@irif.fr</email> </address> </author> <dateday="21" month="April"month="July" year="2024"/> <area>RTG</area> <workgroup>babel</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <keyword>example</keyword> <abstract> <t>This document defines an extension to the Babel routing protocol that measures the round-trip time (RTT) between routers and makes it possible to preferlower latencylower-latency links overhigher latencyhigher-latency ones.</t> </abstract> </front> <middle> <section title="Introduction"><t>The Babel routing protocol<t>"<xref target="RFC8966" format="title"/>" <xref target="RFC8966"/> does not mandate a specific algorithm for computing metrics; existing implementations use apacket-loss basedpacket-loss-based metric on wireless links and a simple hop-count metric on all other types of links. While this strategy works reasonably well in many networks, it fails to select reasonable routes in some topologies involving tunnels or VPNs.</t> <figure anchor="fig-diamond"><name>FourroutersRouters in adiamond topology</name>Diamond Topology</name> <artwork><![CDATA[ +------------+ | A (Paris) +---------------+ +------------+ \ / \ / \ / \ +------------+ +------------+ | B (Paris) | | C (Tokyo) | +------------+ +------------+ \ / \ / \ / +------------+ / | D (Paris) +---------------+ +------------+ ]]></artwork> </figure><t>Consider for example<t>For example, consider the topology described in <xref target="fig-diamond"/>, with three routersA, B(A, B, andDD) located in Paris and a fourth routerC(C) located in Tokyo, connected through tunnels in a diamond topology. When routing traffic from A to D, it is obviously preferable to use the local route throughB,B as this is likely to provide better service quality and lower monetary cost than the distant route through C. However, the existing implementations of Babel consider both routes as having the samemetric, andmetric; therefore, they willthereforeroute the traffic through C in roughly half the cases.</t> <t>In the first part of this document (<xref target="rtt-sampling"/>), we specify an extension to the Babel routing protocol that produces a sequence of accurate measurements of the round-trip time (RTT) between two Babel neighbours. These measurements are not directly usable as an input to Babel'sroute selection procedure,route-selection procedure since they tend to be noisy and to cause a negative feedback loop, which might give rise to frequent oscillations. Inathe second part (<xref target="route-selection"/>), we define an algorithm that maps the sequence of RTT samples to a link cost that can be used for route selection.</t> <section title="Applicability"> <t>The extension defined in <xref target="rtt-sampling"/> provides a sequence ofaccurateaccurate, but potentiallynoisynoisy, RTT samples. Since theround-trip timeRTT is a symmetric measure of delay, this protocol is only applicable in environments where the symmetric delay is a good predictor of whether a link should be taken by routing traffic, which might not necessarily be the case in networks built over exotic link technologies.</t> <t>The extension makes minimal requirements on the nodes. In particular, it does not assume synchronisedclocks, butclocks; it only requires that clock drift be negligible during the time interval between two Hello TLVs. Since that is on the order of a few seconds, this requirement is met even with cheap crystaloscillatorsoscillators, such as the ones used in consumer electronics.</t> <t>The algorithm defined in <xref target="route-selection"/>makesis based on a number of assumptions about the network. The assumption with the most severe consequences is that all links below a certain RTT (rtt-min in <xref target="cost-computation"/>) can be grouped in a single category of "good" links. While this is the case in wide-area overlay networks, it makes the algorithm inapplicable in networks where distinguishing between low-latency links is important.</t> <t>There are other assumptions, but they are less likely to limit the algorithm's applicability. The algorithm assumes that all links above a certain RTT (rtt-max in <xref target="cost-computation"/>)can be assumed to beare equally bad, and they will only be used as a last resort. In addition, in order to avoid oscillations, the algorithm is designed to react slowly to RTT variations, thus causing suboptimal routing for seconds or even minutes after an RTTchange; whilechange. While this is a desirable property in fixed networks, as it avoid excessive route oscillations, it might be an issue with networks with high rates of node mobility.</t> </section> </section> <section><name>Specification of Requirements</name><t>The<t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section title="RTTsampling"Sampling" anchor="rtt-sampling"> <section title="Datastructures">Structures"> <t>We assume that every Babel speaker maintains a localclock,clock that counts microseconds from an arbitrary origin. We do not assume that clocks are synchronised: clocks local to distinct nodes need not share a common origin. The protocol will eventually recover if the clock is stepped, so clocks need not persist across node reboots.</t> <t>Every Babel speaker maintains a Neighbour Table, described inSection 3.2.4 of<xreftarget="RFC8966"/>.target="RFC8966" sectionFormat="of" section="3.2.4"/>. This extension extends every entry in the Neighbour Table with the following data:</t> <ul spacing="normal"> <li>the Origin Timestamp, a 32-bit timestamp (modulo2^32)2<sup>32</sup>) according to the neighbour's clock;</li> <li>the Receive Timestamp, a 32-bit timestamp (modulo2^32)2<sup>32</sup>) according to the local clock.</li> </ul> <t>Both values are initially undefined.</t> </section> <section title="Protocoloperation">Operation"> <t>The RTT to a neighbour is estimated using an algorithmdue toby Mills <xreftarget="MILLS"/>,target="RFC891"/>, originally developed for the HELLO routing protocol and later used in NTP <xreftarget="NTP"/>.</t>target="RFC5905"/>.</t> <t>A Babel speaker periodically sends Hello messages to its neighbours(Section 3.4.1 of <xref target="RFC8966"/>).(<xref target="RFC8966" sectionFormat="of" section="3.4.1"/>). Additionally, it occasionally sends a set of IHU ("I Heard You") messages, at most one per neighbour(Section 3.4.2 of <xref target="RFC8966"/>).</t>(<xref target="RFC8966" sectionFormat="of" section="3.4.2"/>).</t> <figureanchor="fig-seq"><name>Mill's algorithm</name>anchor="fig-seq"><name>Mills' Algorithm</name> <artwork><![CDATA[ A B | | t1 + | |\ | | \ | | \ | Hello(t1) | \ | | \ | | \| | + t1' | | | |RTT = (t2 - t1) - (t2' - t1')RTT = (t2 - t1) - (t2' - t1') | | | + t2' | /| | / | | / | | / | Hello(t2') | / | IHU(t1, t1') |/ | t2 + | | | v v ]]></artwork> </figure> <t>In order to enable the computation of RTTs,anode AMUST include<bcp14>MUST</bcp14> include, in every Hello that itsendssends, a timestamp t1 (according to A's local clock), as illustrated in <xref target="fig-seq"/>. Whenanode B receives A's timestamped Hello, it computes the time t1' at which the Hello was received (according to B's local clock). It thenMUST<bcp14>MUST</bcp14> record the value t1 in the Origin Timestamp field of the Neighbour Table entry corresponding toA,A and the value t1' in the Receive Timestamp field of the Neighbour Table entry.</t> <t>When B sends an IHU to A, it checks whether both timestamps are defined in the Neighbour Table. If that is the case, then itMUST<bcp14>MUST</bcp14> ensure that its IHU TLV is sent in a packet that also contains a timestamped Hello TLV (either a normally scheduledHello,Hello or an unscheduled Hello, seeSection 3.4.1 of<xreftarget="RFC8966"/>).target="RFC8966" sectionFormat="of" section="3.4.1"/>). ItMUST<bcp14>MUST</bcp14> include in the IHU both the Origin Timestamp and the Receive Timestamp stored in the Neighbour Table.</t> <t>Upon receiving B's packet, A computes the time t2 (according to its local clock) at which it was received. Then, AMUST then<bcp14>MUST</bcp14> verify that it contains both a Hello TLV with timestamp t2' and an IHU TLV with twotimestampstimestamps: t1 and t1'. If that is the case, A computes thevalue RTT = (t2 - t1) - (t2' - t1') (wherevalue:</t> <artwork>RTT = (t2 - t1) - (t2' - t1')</artwork> <t>(where all computations are done modulo2^32),2<sup>32</sup>), which is a measurement of the RTT between A and B. (A then stores the values t2' and t2 in its Neighbour Table, as B did before.)</t><t>This<!--[rfced] Please review our updates to create a list in Section 3.2. We suggest that you review uses of "it" in the list to ensure clarity for the reader. Original: This algorithm has a number of desirable properties. First, the algorithm is symmetric: A and B use the same procedures for timestamping packets and computing RTT samples, and both nodes produce one RTT sample for each received (Hello, IHU) pair. Second, since there is no requirement that t1' and t2' be equal, the protocol is asynchronous: the only change to Babel's message scheduling is the requirement that a packet containing an IHU also contain a Hello. Third, since it only ever computes differences of timestamps according to a single clock, it does not require synchronised clocks. Fourth, it requires very little additional state: a node only needs to store the two timestamps associated with the last hello received from each neighbour. Finally, since it only requires piggybacking one or two timestamps on each Hello and IHU TLV, it makes efficient use of networkresources.</t>resources. Current: This algorithm has a number of desirable properties. 1. The algorithm is symmetric. A and B use the same procedures for timestamping packets and computing RTT samples; both nodes produce one RTT sample for each received (Hello, IHU) pair. 2. Since there is no requirement that t1' and t2' be equal, the protocol is asynchronous: the only change to Babel's message scheduling is the requirement that a packet containing an IHU also contain a Hello. 3. Since it only ever computes differences of timestamps according to a single clock, it does not require synchronised clocks. 4. It requires very little additional state: a node only needs to store the two timestamps associated with the last hello received from each neighbour. 5. Since it only requires piggybacking one or two timestamps on each Hello and IHU TLV, it makes efficient use of network resources. --> <t>This algorithm has a number of desirable properties.</t> <ol><li>The algorithm is symmetric. A and B use the same procedures for timestamping packets and computing RTT samples; both nodes produce one RTT sample for each received (Hello, IHU) pair.</li> <li>Since there is no requirement that t1' and t2' be equal, the protocol is asynchronous: the only change to Babel's message scheduling is the requirement that a packet containing an IHU also contain a Hello.</li> <li>Since it only ever computes differences of timestamps according to a single clock, it does not require synchronised clocks.</li> <li>It requires very little additional state: a node only needs to store the two timestamps associated with the last hello received from each neighbour.</li> <li>Since it only requires piggybacking one or two timestamps on each Hello and IHU TLV, it makes efficient use of network resources.</li></ol> <t>In principle, this algorithm is inaccurate in the presence of clock drift (i.e., when A's clock and B'sclocksclock are running at different frequencies). However,t2' - t1't2' - t1' is usually on the order of a few seconds, and significant clock drift is unlikely to happen at that time scale.</t> <t>In order for RTT values to be consistent between implementations, timestamps need to be computed at roughly the same point in the network stack. Transmit timestampsSHOULD<bcp14>SHOULD</bcp14> be computed just before the packet is passed to the network stack (i.e., before it is subjected to any queueingdelays), anddelays); receive timestampsSHOULD<bcp14>SHOULD</bcp14> be computed just after the packet is received from the network stack.</t> </section> <sectiontitle="Wrap-aroundtitle="Wrap-Around andnode restart"Node Restart" anchor="wraparound"> <t>Timestamp values are a count of microseconds stored as a 32-bit unsigned integer; thus, they wrap around every 71 minutes or so. What is more, a node may occasionally reboot and restart its clock at an arbitrary origin. For these reasons, very old timestamps or nonsensical timestampsMUST NOT<bcp14>MUST NOT</bcp14> be used to yield RTT samples.</t> <!--[rfced] As this is the first sentence of the paragraph, will the reader easily know what "that" refers to? Original: The following algorithm can be used to achieve that. --> <t>The following algorithm can be used to achieve that. When a node receives a packet containing a Hello and an IHU, it compares the current local time t2 with the Origin Timestamp contained in the IHU; if the Origin Timestamp appears to be in the future, or if it is in the past by more than a time T (the valueT = 3 minutesT = 3 minutes is recommended), then the timestamps are still recorded in the neighbour table, but they are not used for computation of an RTT sample.</t><t>Similary,<t>Similarly, the node compares the Hello's timestamp with the Receive Timestamp recorded in the Neighbour Table; if the Hello's timestamp appears to be older than the recorded timestamp, or if it appears to be more recent by an interval larger than the value T, then the timestamps are not used for computation of an RTT sample.</t> </section> <section title="Implementationnotes">Notes"> <t>The accuracy of the computed RTT samples depends on Transmit Timestamps being computed as late as possible before a packet containing a Hello TLV is passed to the network stack, and Receive Timestamps being computed as early as possible after reception of a packet containing a (Hello, IHU) pair. We have found the following implementation strategy to be useful.</t> <t>When a Hello TLV is buffered for transmission, we insert a PadN sub-TLV(Section 4.7.2(Section 4.7.2 of <xref target="RFC8966"/>) with a length of 4 octets within the TLV. When the packet is ready to be sent, we check whether it contains a 4-octet PadN sub-TLV; if that's the case, we overwrite the PadN sub-TLV with a Timestamp sub-TLV with the current time, and send out the packet.</t> <t>Conversely, when a packet is received, we immediately compute the current time and record it with the received packet. We then process the packet asusual,usual and use the recorded timestamp in order to compute an RTT sample.</t> <t>The protocol is designed to survive the clock being reset when a node reboots; on POSIX systems, this makes it possible to use the CLOCK_MONOTONIC clock for computing timestamps. If CLOCK_MONOTONIC is not available, CLOCK_REALTIME may be used, since the protocol is able to survive the clock being occasionally stepped.</t> </section> </section> <sectiontitle="RTT-based route selection"title="RTT-Based Route Selection" anchor="route-selection"> <t>The protocol described above yields a series of RTT samples. While these samples are fairly accurate, they are not directly usable as an input to theroute selectionroute-selection procedure, for at least threereasons.</t> <t>First of all, inreasons:</t> <ol><li>In the presence of bursty traffic, routers experience transient congestion, which causes occasional spikes in the measured RTT. Thus, the RTT signal may benoisy,noisy andrequiresrequire smoothing before it can be used for routeselection.</t> <t>Second, usingselection.</li> <li>Using the RTT signal for route selection gives rise to a negative feedbackloop: whenloop. When a route has a low RTT, it is deemed to be moredesirable, whichdesirable: this causes it to be used for more data traffic, which may lead to congestion, which in turn increases the RTT. Without some form of hysteresis, using RTT for route selection would lead to oscillations between parallel routes, which would lead to packet reordering and negatively affect upper-layer protocols (such asTCP).</t> <t>Third, evenTCP).</li> <li>Even in the absence of congestion, the RTT tends to exhibit some variation. If the RTTs of two parallel routes oscillate around a common value, using the RTT as input to route selection will cause frequent routing oscillations, which, again, indicates the need for some form ofhysteresis.</t>hysteresis.</li></ol> <t>In this section, we describe an algorithm that integrates smoothing andhysteresis andhysteresis. It has also been shown to behave well both in simulation and experimentally over the Internet <xreftarget="DELAY-BASED"/>,target="DELAY-BASED"/> and isRECOMMENDED<bcp14>RECOMMENDED</bcp14> when RTT information is being used for route selection. The algorithm is structured as follows:</t> <ul> <li>the RTT values are first smoothed in order to avoid instabilities due to outliers (<xref target="smoothing"/>);</li> <li>the resulting smoothed samples are mapped to a cost using a bounded, non-linear mapping, which avoids instabilities at the lower andat theupper end of the RTT range (<xref target="cost-computation"/>);</li><li>finally, a<li>a hysteresis filter is applied in order to limit the amount of oscillation in the middle of the RTT range (<xref target="hysteresis"/>).</li> </ul> <section title="Smoothing" anchor="smoothing"> <t>The RTT samples provided by Mills' algorithm are fairly accurate, but noisy: experiments indicate the occasional presence of individual samples that are much larger than the expected value. Thus, some form of smoothingSHOULD<bcp14>SHOULD</bcp14> be applied in order to avoid instabilities due to occasional outliers.</t> <t>An implementationMAY<bcp14>MAY</bcp14> use the exponential average algorithm, which is simple to implement and appears to yield good results in practice <xref target="DELAY-BASED"/>. The algorithm is parameterised by a constant α, where0 < α < 1,0 < α < 1, which controls the amount of smoothing being applied.FrFor each neighbour, it maintains a smoothed valueRTTRTT, which is initially undefined. When the first sample RTT0 is measured, the smoothed value is set to the value of RTT0. At each new sample RTTn, the smoothed value is set to a weighted average of the previous smoothed value and the new sample:</t> <!-- [rfced] Please review each artwork element in the xml file. Specifically, should the following artwork element be tagged as sourcecode or another element? <artwork> RTT := α RTT + (1 - α) RTTn</artwork> --> <artwork> RTT := α RTT + (1 - α) RTTn</artwork> <t>The smoothing constant αSHOULD<bcp14>SHOULD</bcp14> be between 0.8 and 0.9; the value 0.836 is theRECOMMENDED<bcp14>RECOMMENDED</bcp14> default.</t> </section> <section title="Costcomputation"Computation" anchor="cost-computation"> <t>The smoothed RTT value obtained in the previous step needs to be mapped to a link cost, suitable for input to the metric computation procedure(Section 3.5.2 of <xref target="RFC8966"/>).(<xref target="RFC8966" section="3.5.2" sectionFormat="of"/>). Obviously, the mapping should be monotonic (larger RTTs imply larger costs). In addition, the mapping should be constant beyond a certain value (all very bad links are equallybad),bad) so that congested links do not contribute to routing instability. The mapping should also be constant around0,0; this is sothatsmall oscillations in the RTT of low-RTT links do not contribute to routing instability.</t> <figure anchor="fig-mapping"><name>Mapping from RTT tolink cost</name>Link Cost</name> <artwork><![CDATA[ cost ^ | | | C + max-rtt-penalty | +--------------------------- | /. | / . | / . | / . | / . | / . | / . | / . | / . | / . C +------------+ . | . . | . . | . . | . . 0 +----------------------------------------------------> 0 rtt-min rtt-max RTT ]]></artwork> </figure> <t>ImplementationsSHOULD<bcp14>SHOULD</bcp14> use the mapping described infigure<xref target="fig-mapping"/>, which is parameterised by threeparametersparameters: rtt-min, rtt-max, and max-rtt-penalty. For RTT values below rtt-min, the link cost is just the nominal cost C of a single hop. Between rtt-min and rtt-max, the cost increases linearly; above rtt-max, the constant value max-rtt-penalty is added to the nominal cost.</t> <!--[rfced] Please confirm "ms" or some other unit of measure should not follow 150 in the following. Original: The default values rtt-min = 10ms, rtt-max = 120ms, and max-rtt-penalty = 150 are RECOMMENDED. --> <t>The value rtt-min should be slightly larger than the RTT of a local, uncongested link. The value rtt-max should be the RTT above which a link should be avoided if possible, either because it is a long-distance link or because it is congested; reducing the value of rtt-max improves stability, but prevents the protocol from discriminating between high-latency links. Astofor max-rtt-penalty, it controls how much the protocol will penalise long-distance links. The default valuesrtt-min = 10ms, rtt-max = 120ms,rtt-min = 10 ms, rtt-max = 120 ms, andmax-rtt-penalty = 150max-rtt-penalty = 150 areRECOMMENDED.</t><bcp14>RECOMMENDED</bcp14>.</t> </section> <section title="Hysteresis" anchor="hysteresis"> <t>Even after applying a bounded mapping from smoothed RTT to a cost value, the cost may fluctuate when a link's RTT is between rtt-min and rtt-max. ImplementationsSHOULD<bcp14>SHOULD</bcp14> use a robust hysteresis algorithm, such as the one described inAppendix A.3 of<xreftarget="RFC8966"/>.</t>target="RFC8966" sectionFormat="of" section="A.3"/>.</t> </section> </section> <section title="Backwards andforwards compatibility">Forwards Compatibility"> <t>This protocol extension stores the data that it requires within sub-TLVs of Babel's Hello and IHU TLVs. As discussed inAppendix D of<xreftarget="RFC8966"/>,target="RFC8966" sectionFormat="of" section="D"/>, implementations that do not understand this extension will silently ignore the sub-TLVs while parsing the rest of the TLVs that they contain. In effect, this extension supports building hybrid networks consisting of extended and unextendedrouters, androuters; while such networks might suffer from sub-optimal routing, they will not suffer from blackholes or routing loops.</t> <t>If a sub-TLV defined in this extension is longer than expected, the additional data is silently ignored. This provision is made in order to allow a future version of this protocol to extend the packet format with additional data, forexampleexample, high-precision or absolute timestamps.</t> </section> <section title="Packetformat">Format"> <t>This extension defines the Timestamp sub-TLV whose Type field has a value of 3. This sub-TLV can be contained within a Hello sub-TLV, in which case it carries a single timestamp, or within an IHU sub-TLV, in which case it carries two timestamps.</t> <t>Timestamps are encoded as 32-bit unsigned integers (modulo2^32),2<sup>32</sup>), expressed in units of one microsecond, counting from an arbitrary origin. Timestamps wrap around every 4295 seconds, orrouglyroughly 71 minutes (see also <xref target="wraparound"/>).</t> <section title="Timestampsub-TLVSub-TLV in Hello TLVs"> <t>When contained within a Hello TLV, the Timestamp sub-TLV has the following format:</t> <artwork><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length | Transmit timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork><t>Fields:</t><dl newline="false" spacing="normal" indent="10"><dt>Type</dt><dd>Set<dt>Type:</dt><dd>Set to 3 to indicate a Timestamp sub-TLV.</dd><dt>Length</dt><dd>The<dt>Length:</dt><dd>The length of the body in octets, exclusive of the Type and Length fields.</dd> <dt>Transmittimestamp</dt><dd>Thetimestamp:</dt><dd>The time at which the packet containing this sub-TLV was sent, according to the sender's clock.</dd> </dl> <t>If the Length field is larger than the expected 4 octets, the sub-TLVMUST<bcp14>MUST</bcp14> be processed normally (the first 4 octets are interpreted as describedabove),above) and any extra data contained in this sub-TLVMUST<bcp14>MUST</bcp14> be silently ignored. If the Length field is smaller than the expected 4 octets, then this sub-TLVMUST<bcp14>MUST</bcp14> be ignored (and the remainder of the enclosing TLV processed as usual).</t> </section> <section title="Timestampsub-TLVSub-TLV in IHU TLVs"> <t>When contained in an IHU TLV, the Timestamp sub-TLV has the following format:</t> <artwork><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length | Origin timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (continued) | Receive timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork><t>Fields:</t><dl newline="false" spacing="normal" indent="10"><dt>Type</dt><dd>Set<dt>Type:</dt><dd>Set to 3 to indicate a Timestamp sub-TLV.</dd><dt>Length</dt><dd>The<dt>Length:</dt><dd>The length of the body in octets, exclusive of the Type and Length fields.</dd> <dt>Origintimestamp</dt><dd>Atimestamp:</dt><dd>A copy of the transmit timestamp of the last Timestamp sub-TLV contained in a Hello TLV received from the node to which the enclosing IHU TLV applies.</dd> <dt>Receivetimestamp</dt><dd>Thetimestamp:</dt><dd>The time, according to the sender's clock, at which the last timestamped Hello TLV was received from the node to which the enclosing IHU TLV applies.</dd> </dl> <t>If the Length field is larger than the expected 8 octets, the sub-TLVMUST<bcp14>MUST</bcp14> be processed normally (the first 8 octets are interpreted as described above), and any extra data contained in this sub-TLVMUST<bcp14>MUST</bcp14> be silently ignored. If the Length field is smaller than the expected 8 octets, then this sub-TLVMUST<bcp14>MUST</bcp14> be ignored (and the remainder of the enclosing TLV processed as usual).</t> </section> </section> <section title="IANA Considerations"> <t>IANA has added the following entry to the "Babel Sub-TLV Types" registry:</t> <table align="center"> <thead> <tr><th>Type</th><th>Name</th><th>Reference</th></tr> </thead> <tbody><tr><td>3</td><td>Timestamp</td><td>(this document)</td></tr><tr><td>3</td><td>Timestamp</td><td>RFC 9616</td></tr> </tbody> </table> </section> <section title="Security Considerations"> <!--[rfced] In the following, will the antecedent of "they" be easily clear to the reader? Original: By broadcasting the value of a reasonably accurate local clock, they might make a node more susceptible to timing attacks. --> <t>This extension adds additional timestamping data to two of the TLVs sent by a Babel router. By broadcasting the value of a reasonably accurate local clock, they might make a node more susceptible to timing attacks.</t> <t>Broadcasting an accurate time raises privacy issues. The timestamps used by this protocol have an arbitraryorigin, and thereforeorigin; therefore, they do not leak a node's boot time ortimezone.time zone. However, having access to accurate timestamps could allow an attacker to determine the physical location of a node. Nodes might avoid disclosure of location information by not including timestamp sub-TLVs in the TLVs that they send, which will cause their neighbours to fall back to hop-count routing.</t> </section><section title="Acknowledgements"> <t>The authors are indebted to Jean-Paul Smets, who prompted</middle> <!-- [rfced] We had theinvestigation that originally leadfollowing questions related to the references in thisprotocol. We are also gratefuldocument: a) Would you like the references toDonald Eastlake, Toke Høiland-Jørgensen, Maria Matejka, David Schinazi, Pacal Thubert, Steffen Vogel,be alphabetized or left in their current order? b) We see a mix of citation tags for RFCs. Should [MILLS] andOndřej Zajiček.</t> </section> </middle>[NTP] be [RFC891] and [RFC5905], respectively? --> <back> <displayreference target="RFC891" to="MILLS"/> <displayreference target="RFC5905" to="NTP"/> <references><name>References</name> <references><name>Normative References</name><reference anchor="RFC8966" target="https://www.rfc-editor.org/info/rfc8966"> <front> <title>The Babel Routing Protocol</title> <author initials="J." surname="Chroboczek" fullname="J. Chroboczek"/> <author initials="D." surname="Schinazi" fullname="D. Schinazi"/> <date year="2021" month="January"/> </front> <seriesInfo name="RFC" value="8966"/> <seriesInfo name="DOI" value="10.17487/RFC8966"/> </reference> <reference anchor="RFC2119"><front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author initials="S." surname="Bradner" fullname="S. Bradner"/> <date year="1997" month="March"/> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"><front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author initials="B." surname="Leiba" fullname="B. Leiba"/> <date year="2017" month="May"/> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8966.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references><name>Informative References</name> <referenceanchor="DELAY-BASED"><front>anchor="DELAY-BASED" target="http://arxiv.org/abs/1403.3488"> <front> <title>A delay-based routing metric</title> <author fullname="Baptiste Jonglez" initials="B." surname="Jonglez"/> <author fullname="M. Boutier" initials="M." surname="Boutier"/> <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/> <date month="March" year="2014"/> </front><annotation>Available online from http://arxiv.org/abs/1403.3488</annotation> </reference> <reference anchor="MILLS"><front> <title>DCN Local-Network Protocols</title> <author fullname="David L. Mills" initials="D. L." surname="Mills"/> <date month="December" year="1983"/> </front> <seriesInfo name="RFC" value="891"/> </reference> <reference anchor="NTP"><front> <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title> <author initials='D.' surname='Mills' fullname='D. Mills'/> <author initials='J.' surname='Martin' fullname='J. Martin'/> <author initials='J.' surname='Burbank' fullname='J. Burbank'/> <author initials='W.' surname='Kasch' fullname='W. Kasch'/> <date year='2010' month='June' /> </front><seriesInfoname='RFC' value='5905' />name="DOI" value="10.48550/arXiv.1403.3488"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.891.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/> </references> </references> <section title="Acknowledgements" numbered="false"> <t>The authors are indebted to <contact fullname="Jean-Paul Smets"/>, who prompted the investigation that originally lead to this protocol. We are also grateful to <contact fullname="Donald Eastlake, 3rd"/>, <contact fullname="Toke Høiland-Jørgensen"/>, <contact fullname="Maria Matejka"/>, <contact fullname="David Schinazi"/>, <contact fullname="Pacal Thubert"/>, <contact fullname="Steffen Vogel"/>, and <contact fullname="Ondřej Zajiček"/>.</t> </section> <!--[rfced] We had the following questions related to terminology in this document: a) We will update to use the form on the right throughout the document unless we hear objection: neighbour table v. Neighbour Table timestamp sub-TLV v. Timestamp sub-TLV receive timestamp v Receive timestamp v. Receive Timestamp transmit timestamp v. Transmit timestamp v. Transmit Timestamp b) We see both "Mill's algorithm" and "Mills' algorithm". We have adopted the latter for consistency (though we note Chicago Manual of Style does not use this formation). --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. For example, please consider whether the following should be updated: ...from blackholes or routing loops. Note - We often see blackhole updated to "infinite loop" or "packet losses". --> </back> </rfc>