Internet Engineering Task Force (IETF) B. Jonglez
Request for Comments: 9616 ENS Lyon
Category: Standards Track J. Chroboczek
ISSN: 2070-1721 IRIF, Université Paris Cité
September 2024
This document defines an extension to the Babel routing protocol that measures the round-trip time (RTT) between routers and makes it possible to prefer lower-latency links over higher-latency ones.
このドキュメントでは、ルーター間の往復時間（RTT）を測定し、より高い低下のリンクよりも低い遅延リンクを好むことを可能にするBABELルーティングプロトコルの拡張機能を定義します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9616.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9616で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Applicability
2. Specification of Requirements
3. RTT Sampling
3.1. Data Structures
3.2. Protocol Operation
3.3. Wrap-Around and Node Restart
3.4. Implementation Notes
4. RTT-Based Route Selection
4.1. Smoothing
4.2. Cost Computation
4.3. Hysteresis
5. Backwards and Forwards Compatibility
6. Packet Format
6.1. Timestamp Sub-TLV in Hello TLVs
6.2. Timestamp Sub-TLV in IHU TLVs
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses
The Babel routing protocol [RFC8966] does not mandate a specific algorithm for computing metrics; existing implementations use a packet-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.
BABELルーティングプロトコル[RFC8966]は、メトリックを計算するための特定のアルゴリズムを義務付けていません。既存の実装は、ワイヤレスリンクでパケットロスベースのメトリックと、他のすべてのタイプのリンクでシンプルなホップカウントメトリックを使用します。この戦略は多くのネットワークで合理的にうまく機能しますが、トンネルまたはVPNを含む一部のトポロジで合理的なルートを選択することはできません。
+------------+
| A (Paris) +---------------+
+------------+ \
/ \
/ \
/ \
+------------+ +------------+
| B (Paris) | | C (Tokyo) |
+------------+ +------------+
\ /
\ /
\ /
+------------+ /
| D (Paris) +---------------+
+------------+
Figure 1: Four Routers in a Diamond Topology
図1：ダイヤモンドトポロジの4つのルーター
For example, consider the topology described in Figure 1, with three routers A, B, and D located in Paris and a fourth router 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 through 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 same metric; therefore, they will route the traffic through C in roughly half the cases.
たとえば、図1に記載されているトポロジーを考えてみましょう。3つのルーターA、B、およびDはパリに位置し、ダイヤモンドトポロジーのトンネルを介して接続された東京にある4番目のルーターCを備えています。AからDへのトラフィックをルーティングする場合、Bを通るローカルルートを使用することが明らかに好ましいです。これにより、Cを通る遠隔ルートよりもサービス品質と金銭的コストが低くなる可能性が高いため、Babelの既存の実装は両方のルートを考慮します。同じメトリックを持っています。したがって、彼らは約半分のケースでCを介してトラフィックをルーティングします。
In the first part of this document (Section 3), 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's route selection procedure since they tend to be noisy and to cause a negative feedback loop, which might give rise to frequent oscillations. In the second part (Section 4), we define an algorithm that maps the sequence of RTT samples to a link cost that can be used for route selection.
このドキュメントの最初の部分（セクション3）では、2人のバベル隣人の間で往復時間（RTT）の一連の正確な測定値を生成するバベルルーティングプロトコルの拡張を指定します。これらの測定値は、騒々しく、負のフィードバックループを引き起こす傾向があるため、バベルのルート選択手順への入力として直接使用できません。2番目の部分（セクション4）では、RTTサンプルのシーケンスをルート選択に使用できるリンクコストにマップするアルゴリズムを定義します。
The extension defined in Section 3 provides a sequence of accurate but potentially noisy RTT samples. Since the RTT 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.
セクション3で定義されている拡張機能は、正確ではあるが潜在的に騒々しいRTTサンプルのシーケンスを提供します。RTTは遅延の対称尺度であるため、このプロトコルは、対称的な遅延がルーティングトラフィックによってリンクを取得する必要があるかどうかの適切な予測因子である環境でのみ適用可能です。。
The extension makes minimal requirements on the nodes. In particular, it does not assume synchronised clocks, and 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 crystal oscillators, such as the ones used in consumer electronics.
拡張機能は、ノードの要件を最小限に抑えます。特に、同期されたクロックを想定せず、2つのHello TLV間の時間間隔中にクロックドリフトが無視できることのみを必要とします。それは数秒程度であるため、この要件は、家電で使用されているような安価なクリスタル発振器でも満たされます。
The algorithm defined in Section 4 depends 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 Section 4.2) 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.
セクション4で定義されているアルゴリズムは、ネットワークに関する多くの仮定に依存します。最も深刻な結果をもたらす仮定は、特定のRTT以下のすべてのリンク（セクション4.2のRTT-Min）を「良い」リンクの単一カテゴリにグループ化できることです。これは、広いエリアオーバーレイネットワークの場合ですが、低遅延リンクを区別することが重要なネットワークではアルゴリズムが適用できなくなります。
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 Section 4.2) are 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 RTT change; 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.
他の仮定はありますが、アルゴリズムの適用性を制限する可能性は低くなります。このアルゴリズムは、特定のRTT（セクション4.2のRTT-Max）を超えるすべてのリンクも同様に悪いことを想定しており、最後の手段としてのみ使用されます。さらに、振動を回避するために、アルゴリズムはRTTの変動にゆっくりと反応するように設計されているため、RTTの変更後数秒または数分間、最適ではないルーティングを引き起こします。これは、過度のルート振動を避けるため、固定ネットワークでは望ましいプロパティですが、ノードモビリティのレートが高いネットワークの問題になる可能性があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
We assume that every Babel speaker maintains a local 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.
すべてのバベルスピーカーが、任意の起源からマイクロ秒をカウントするローカルクロックを維持していると仮定します。クロックが同期されているとは想定していません。個別のノードにローカルにローカルするクロックは、共通の起源を共有する必要はありません。クロックがステップされた場合、プロトコルは最終的に回復するため、ノードの再起動全体でクロックが持続する必要はありません。
Every Babel speaker maintains a Neighbour Table, described in Section 3.2.4 of [RFC8966]. This extension extends every entry in the Neighbour Table with the following data:
すべてのバベルスピーカーは、[RFC8966]のセクション3.2.4で説明されている隣接テーブルを維持しています。この拡張機能は、次のデータを使用して、近隣テーブル内のすべてのエントリを拡張します。
* the Origin Timestamp, a 32-bit timestamp (modulo 2^32) according to the neighbour's clock;
* Origin Timestamp、隣人の時計に応じた32ビットタイムスタンプ（Modulo 2^32）。
* the Receive Timestamp, a 32-bit timestamp (modulo 2^32) according to the local clock.
* ローカル時計に応じて、32ビットタイムスタンプ（Modulo 2^32）を受信するタイムスタンプ。
Both values are initially undefined.
両方の値は最初は未定義です。
The RTT to a neighbour is estimated using an algorithm due to Mills [RFC891], originally developed for the HELLO routing protocol and later used in NTP [RFC5905].
隣人へのRTTは、ミルズ[RFC891]によるアルゴリズムを使用して推定され、元々ハロールーティングプロトコル用に開発され、後にNTP [RFC5905]で使用されます。
A Babel speaker periodically sends Hello messages to its neighbours (Section 3.4.1 of [RFC8966]). Additionally, it occasionally sends a set of IHU ("I Heard You") messages, at most one per neighbour (Section 3.4.2 of [RFC8966]).
バベルスピーカーは定期的に隣人にハローメッセージを送信します（[RFC8966]のセクション3.4.1）。さらに、隣人ごとに最大1つ（[RFC8966]のセクション3.4.2）のIHU（「私はあなたを聞いた」）メッセージのセットを送信することがあります。
A B
| |
t1 + |
|\ |
| \ |
| \ | Hello(t1)
| \ |
| \ |
| \|
| + t1'
| |
| | RTT = (t2 - t1) - (t2' - t1')
| |
| + t2'
| /|
| / |
| / |
| / | Hello(t2')
| / | IHU(t1, t1')
|/ |
t2 + |
| |
v v
Figure 2: Mills' Algorithm
図2：ミルズのアルゴリズム
In order to enable the computation of RTTs, a node A MUST include, in every Hello that it sends, a timestamp t1 (according to A's local clock), as illustrated in Figure 2. When a node B receives A's timestamped Hello, it computes the time t1' at which the Hello was received (according to B's local clock). It then MUST record the value t1 in the Origin Timestamp field of the Neighbour Table entry corresponding to A and the value t1' in the Receive Timestamp field of the Neighbour Table entry.
RTTSの計算を有効にするために、図2に示すように、ノードAにはタイムスタンプT1（Aのローカルクロックに従って）を含める必要があります。Helloを受け取ったT1 '（Bのローカル時計による）。次に、Aに対応する隣接テーブルエントリのオリジンタイムスタンプフィールドに値T1と、隣のテーブルエントリの受信タイムスタンプフィールドの値T1 'を記録する必要があります。
When B sends an IHU to A, it checks whether both timestamps are defined in the Neighbour Table. If that is the case, then it MUST ensure that its IHU TLV is sent in a packet that also contains a timestamped Hello TLV (either a normally scheduled Hello or an unscheduled Hello, see Section 3.4.1 of [RFC8966]). It MUST include in the IHU both the Origin Timestamp and the Receive Timestamp stored in the Neighbour Table.
BがIHUをAに送信すると、両方のタイムスタンプが隣のテーブルで定義されているかどうかを確認します。その場合、IHU TLVがタイムスタンプのHello TLV（通常スケジュールされたHelloまたは予定外のHelloのいずれかを含むパケットに送信されるようにする必要があります。IHUには、隣接テーブルに保存されているオリジンタイムスタンプと受信タイムスタンプの両方を含める必要があります。
Upon receiving B's packet, A computes the time t2 (according to its local clock) at which it was received. Node A MUST then verify that it contains both a Hello TLV with timestamp t2' and an IHU TLV with two timestamps t1 and t1'. If that is the case, A computes the value:
Bのパケットを受信すると、Aは受信されたT2（ローカル時計に従って）を計算します。ノードAは、タイムスタンプT2 'を備えたHello TLVと2つのタイムスタンプT1とT1'を備えたIHU TLVの両方が含まれていることを確認する必要があります。その場合、値を計算します。
RTT = (t2 - t1) - (t2' - t1')
(where all computations are done modulo 2^32), 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.)
（すべての計算が行われる場合）、これはAとBの間のRTTの測定です（Aは、Bが以前に行ったように、隣のテーブルに値T2 'とT2を保存します。）
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, and both nodes produce one RTT sample for each received (Hello, IHU) pair.
1. アルゴリズムは対称です。AとBは、タイムスタンプパケットとコンピューティングRTTサンプルに同じ手順を使用し、両方のノードは受信（Hello、IHU）ペアごとに1つのRTTサンプルを生成します。
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.
2. T1 'とT2'が等しいという要件はないため、プロトコルは非同期です。BABELのメッセージスケジューリングの唯一の変更は、IHUを含むパケットにもHelloを含むという要件です。
3. Since the algorithm only ever computes differences of timestamps according to a single clock, it does not require synchronised clocks.
3. アルゴリズムは、単一のクロックに応じてタイムスタンプの違いのみを計算するため、同期されたクロックは必要ありません。
4. The algorithm requires very little additional state: a node only needs to store the two timestamps associated with the last hello received from each neighbour.
4. アルゴリズムには、追加の状態がほとんど必要ありません。ノードは、各隣人から受け取った最後のHelloに関連付けられた2つのタイムスタンプを保存する必要があります。
5. Since the algorithm only requires piggybacking one or two timestamps on each Hello and IHU TLV, it makes efficient use of network resources.
5. アルゴリズムは、各HelloとIHU TLVの1つまたは2つのタイムスタンプをピギーバックする必要があるため、ネットワークリソースを効率的に使用します。
In principle, this algorithm is inaccurate in the presence of clock drift (i.e., when A's clock and B's clock are running at different frequencies). However, t2' - t1' is usually on the order of a few seconds, and significant clock drift is unlikely to happen at that time scale.
原則として、このアルゴリズムは、クロックドリフトの存在下では不正確です（つまり、AのクロックとBのクロックが異なる周波数で実行されている場合）。ただし、T2 '-T1'は通常数秒の順序であり、その時点で大きなクロックドリフトが発生する可能性は低いです。
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 timestamps SHOULD be computed just before the packet is passed to the network stack (i.e., before it is subjected to any queueing delays); receive timestamps SHOULD be computed just after the packet is received from the network stack.
RTT値が実装間で一貫しているためには、タイムスタンプをネットワークスタックのほぼ同じポイントで計算する必要があります。送信タイムスタンプは、パケットがネットワークスタックに渡される直前（つまり、キューイングの遅延にさらされる前に）に計算する必要があります。受信タイムスタンプは、ネットワークスタックからパケットが受信された直後に計算する必要があります。
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 timestamps MUST NOT be used to yield RTT samples.
タイムスタンプの値は、32ビットの符号なし整数として保存されているマイクロ秒のカウントです。したがって、彼らは71分ごとに包みます。さらに、ノードは時折再起動して任意の起源で時計を再起動する場合があります。これらの理由により、非常に古いタイムスタンプまたは無意味なタイムスタンプを使用してRTTサンプルを生成してはなりません。
The following algorithm can be used to discard obsolete samples. 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 value T = 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.
次のアルゴリズムを使用して、時代遅れのサンプルを破棄できます。ノードがHelloとIHUを含むパケットを受信すると、現在の現地時間T2とIHUに含まれるOrigin Timestampを比較します。Origin Timestampが将来的にあるように見える場合、または過去に時間t（値t = 3分が推奨されます）以上である場合、タイムスタンプはまだ隣のテーブルに記録されていますが、そうではありませんが、RTTサンプルの計算に使用されます。
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.
同様に、ノードは、Helloのタイムスタンプと隣のテーブルに記録された受信タイムスタンプを比較します。Helloのタイムスタンプが記録されたタイムスタンプよりも古いように見える場合、または値Tよりも大きな間隔で最近のように見える場合、タイムスタンプはRTTサンプルの計算には使用されません。
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.
計算されたRTTサンプルの精度は、ハローTLVを含むパケットがネットワークスタックに渡される前に、可能な限り遅く計算される送信タイムスタンプに依存し、（ハロー、ハロー、パケットの受信後、できるだけ早く計算されるタイムスタンプを受け取ります。ihu）ペア。次の実装戦略が役立つことがわかりました。
When a Hello TLV is buffered for transmission, we insert a PadN sub-TLV (Section 4.7.2 of [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.
Hello TLVが送信用にバッファリングされると、TLV内に長さ4オクテットのPADN Sub-TLV（[RFC8966]のセクション4.7.2）を挿入します。パケットを送信する準備ができたら、4-OCTET PADN SUB-TLVが含まれているかどうかを確認します。その場合、PADN Sub-TLVを現在の時刻でタイムスタンプサブTLVで上書きし、パケットを送信します。
Conversely, when a packet is received, we immediately compute the current time and record it with the received packet. We then process the packet as usual and use the recorded timestamp in order to compute an RTT sample.
逆に、パケットが受信されたら、すぐに現在の時間を計算し、受信したパケットで記録します。次に、通常どおりパケットを処理し、RTTサンプルを計算するために記録されたタイムスタンプを使用します。
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.
このプロトコルは、ノードが再起動するときにリセットされているクロックを生き残るように設計されています。POSIXシステムでは、タイムスタンプを計算するためにClock_monotonicクロックを使用することができます。Clock_monotonicが利用できない場合、Protocolは時々段階的になっている時計を生き残ることができるため、clock_realtimeを使用できます。
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 the route selection procedure, for at least three reasons:
上記のプロトコルは、一連のRTTサンプルを生成します。これらのサンプルはかなり正確ですが、少なくとも3つの理由により、ルート選択手順への入力として直接使用できません。
1. In the presence of bursty traffic, routers experience transient congestion, which causes occasional spikes in the measured RTT. Thus, the RTT signal may be noisy and require smoothing before it can be used for route selection.
1. 破裂したトラフィックの存在下で、ルーターは一時的な混雑を経験し、測定されたRTTに時折スパイクを引き起こします。したがって、RTT信号は騒々しいものであり、ルート選択に使用する前に滑らかにする必要があります。
2. Using the RTT signal for route selection gives rise to a negative feedback loop. When a route has a low RTT, it is deemed to be more desirable; 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 as TCP).
2. ルート選択にRTT信号を使用すると、負のフィードバックループが生じます。ルートのRTTが低い場合、それはより望ましいとみなされます。これにより、より多くのデータトラフィックに使用されるため、輻輳が発生する可能性があり、RTTが増加します。何らかの形のヒステリシスがなければ、ルート選択にRTTを使用すると、平行ルート間の振動が発生し、パケットの再注文につながり、上層層プロトコル（TCPなど）に悪影響を及ぼします。
3. 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 of hysteresis.
3. 混雑がない場合でも、RTTはいくつかのバリエーションを示す傾向があります。2つの並列ルートのRTTが共通の値の周りで振動する場合、RTTをルーティングに選択するためにRTTを使用すると、頻繁なルーティング振動が発生します。これは、何らかの形のヒステリシスの必要性を示します。
In this section, we describe an algorithm that integrates smoothing and hysteresis. It has been shown to behave well both in simulation and experimentally over the Internet [DELAY-BASED] and is RECOMMENDED when RTT information is being used for route selection. The algorithm is structured as follows:
このセクションでは、スムージングとヒステリシスを統合するアルゴリズムについて説明します。シミュレーションと実験的にインターネットを介して[遅延ベース]の両方で適切に動作することが示されており、RTT情報がルート選択に使用されている場合に推奨されます。アルゴリズムは次のように構成されています。
* the RTT values are first smoothed in order to avoid instabilities due to outliers (Section 4.1);
* RTT値は、外れ値による不安定性を回避するために最初に滑らかになります（セクション4.1）。
* the resulting smoothed samples are mapped to a cost using a bounded, non-linear mapping, which avoids instabilities at the lower and upper end of the RTT range (Section 4.2);
* 結果として得られる平滑化されたサンプルは、RTT範囲の下端と上端での不安定性を回避する境界のない非線形マッピングを使用してコストにマッピングされます（セクション4.2）。
* a hysteresis filter is applied in order to limit the amount of oscillation in the middle of the RTT range (Section 4.3).
* RTT範囲の中央の振動量を制限するために、ヒステリシスフィルターが適用されます（セクション4.3）。
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 smoothing SHOULD be applied in order to avoid instabilities due to occasional outliers.
Millsのアルゴリズムによって提供されるRTTサンプルはかなり正確ですが、うるさい：実験は、期待値よりもはるかに大きい個々のサンプルが時折存在することを示しています。したがって、時折外れ値のために不安定性を避けるために、何らかの形のスムージングを適用する必要があります。
An implementation MAY use the exponential average algorithm, which is simple to implement and appears to yield good results in practice [DELAY-BASED]. The algorithm is parameterised by a constant α, where 0 < α < 1, which controls the amount of smoothing being applied. For each neighbour, it maintains a smoothed value RTT, 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:
実装では、指数平均アルゴリズムを使用する場合があります。これは、実装が簡単で、実践で良い結果が得られるように見える[遅延ベース]。アルゴリズムは、一定のαによってパラメーター化されます。ここで、0 <α<1は、適用されるスムージングの量を制御します。各隣人については、最初は未定義のスムーズな値RTTを維持します。最初のサンプルRTT0を測定すると、平滑化された値はRTT0の値に設定されます。新しいサンプルRTTNごとに、平滑化された値は、以前のスムーズな値と新しいサンプルの加重平均に設定されます。
RTT := α RTT + (1 - α) RTTn
The smoothing constant α SHOULD be between 0.8 and 0.9; the value 0.836 is the RECOMMENDED default.
平滑化定数αは0.8〜0.9でなければなりません。値0.836が推奨されるデフォルトです。
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 [RFC8966]). 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 equally bad) so that congested links do not contribute to routing instability. The mapping should also be constant around 0, so that small oscillations in the RTT of low-RTT links do not contribute to routing instability.
前のステップで得られたスムーズなRTT値は、メトリック計算手順への入力に適したリンクコストにマッピングする必要があります（[RFC8966]のセクション3.5.2）。明らかに、マッピングは単調である必要があります（RTTが大きいほど、コストが大きいことを意味します）。さらに、マッピングは特定の値を超えて一定である必要があります（非常に悪いリンクはすべて等しく悪い）ため、混雑したリンクがルーティングの不安定性に寄与しないようにします。また、マッピングは0前後である必要があります。そのため、低RTTリンクのRTTの小さな振動がルーティングの不安定性に寄与しないようにします。
cost
^
|
|
| C + max-rtt-penalty
| +---------------------------
| /.
| / .
| / .
| / .
| / .
| / .
| / .
| / .
| / .
| / .
C +------------+ .
| . .
| . .
| . .
| . .
0 +---------------------------------------------------->
0 rtt-min rtt-max RTT
Figure 3: Mapping from RTT to Link Cost
図3：RTTからコストをリンクするためのマッピング
Implementations SHOULD use the mapping described in Figure 3, which is parameterised by three parameters: 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.
実装は、図3で説明したマッピングを使用する必要があります。これは、RTT-Min、RTT-Max、およびMax-RTT-Penaltyの3つのパラメーターでパラメーターされています。RTT-Min未満のRTT値の場合、リンクコストは単一ホップの名目コストCにすぎません。RTT-MinとRTT-Maxの間で、コストは直線的に増加します。RTT-Maxを超えると、一定の値max-rtt-penaltyが公称コストに追加されます。
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. As for max-rtt-penalty, it controls how much the protocol will penalise long-distance links. The default values rtt-min = 10 ms, rtt-max = 120 ms, and max-rtt-penalty = 150 are RECOMMENDED.
値RTT-Minは、ローカルで充実したリンクのRTTよりもわずかに大きくする必要があります。値RTT-Maxは、長距離リンクであるか、混雑しているため、可能であればリンクを避ける必要があるRTTである必要があります。RTT-Maxの値を減らすと安定性が向上しますが、プロトコルが高層リンクを区別するのを防ぎます。Max-RTT-Penaltyについては、プロトコルが長距離リンクをペナルティに罰する量を制御します。デフォルト値rtt-min = 10 ms、rtt-max = 120 ms、およびmax-rtt-penalty = 150が推奨されます。
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. Implementations SHOULD use a robust hysteresis algorithm, such as the one described in Appendix A.3 of [RFC8966].
滑らかなRTTからコスト値に境界マッピングを適用した後でも、リンクのRTTがRTT-MinとRTT-Maxの間にある場合、コストが変動する場合があります。実装は、[RFC8966]の付録A.3に記載されているような堅牢なヒステリシスアルゴリズムを使用する必要があります。
This protocol extension stores the data that it requires within sub-TLVs of Babel's Hello and IHU TLVs. As discussed in Appendix D of [RFC8966], 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 unextended routers; while such networks might suffer from sub-optimal routing, they will not suffer from routing loops or other pathologies.
このプロトコル拡張機能は、バベルのHelloとIhu TLVのサブTLV内で必要なデータを保存します。[RFC8966]の付録Dで説明したように、この拡張機能を理解していない実装は、含まれているTLVの残りの部分を解析しながら、サブTLVを静かに無視します。実際には、この拡張機能は、拡張および拡張されていないルーターで構成される構築ハイブリッドネットワークをサポートします。そのようなネットワークは、最適下のルーティングに悩まされる可能性がありますが、ルーティングループやその他の病理に悩まされることはありません。
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, for example high-precision or absolute timestamps.
この拡張機能で定義されているサブTLVが予想よりも長い場合、追加データは静かに無視されます。この規定は、このプロトコルの将来のバージョンが、高精度や絶対タイムスタンプなどの追加データを使用してパケット形式を拡張できるようにするために作成されています。
This extension defines the Timestamp sub-TLV whose Type field has the value 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.
この拡張機能は、タイプフィールドが値3にあるタイムスタンプサブTLVを定義します。このサブTLVは、Hello Sub-TLVに含めることができます。2つのタイムスタンプを運びます。
Timestamps are encoded as 32-bit unsigned integers (modulo 2^32), expressed in units of one microsecond, counting from an arbitrary origin. Timestamps wrap around every 4295 seconds, or roughly 71 minutes (see also Section 3.3).
タイムスタンプは、任意の起源からカウントされる1マイクロ秒の単位で表される32ビットの符号なし整数（Modulo 2^32）としてエンコードされています。タイムスタンプは、4295秒ごと、または約71分ごとにラップします（セクション3.3も参照）。
When contained within a Hello TLV, the Timestamp sub-TLV has the following format:
Hello TLVに含まれる場合、Timestamp Sub-TLVには次の形式があります。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
Set to 3 to indicate a Timestamp sub-TLV.
タイムスタンプサブTLVを示すために3に設定します。
Length:
長さ：
The length of the body in octets, exclusive of the Type and Length fields.
タイプと長さのフィールドを除く、オクテットの体の長さ。
Transmit Timestamp:
タイムスタンプを送信：
The time at which the packet containing this sub-TLV was sent, according to the sender's clock.
送信者の時計に従って、このサブTLVを含むパケットが送信された時間。
If the Length field is larger than the expected 4 octets, the sub-TLV MUST be processed normally (the first 4 octets are interpreted as described above) and any extra data contained in this sub-TLV MUST be silently ignored. If the Length field is smaller than the expected 4 octets, then this sub-TLV MUST be ignored (and the remainder of the enclosing TLV processed as usual).
長さフィールドが予想される4オクテットよりも大きい場合、サブTLVを正常に処理する必要があり（最初の4オクテットは上記のように解釈されます）、このサブTLVに含まれる追加のデータは静かに無視する必要があります。長さのフィールドが予想される4オクテットよりも小さい場合、このサブTLVは無視する必要があります（そして、囲まれたTLVの残りの部分は通常どおり処理されます）。
When contained in an IHU TLV, the Timestamp sub-TLV has the following format:
IHU TLVに含まれる場合、Timestamp Sub-TLVには次の形式があります。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
Set to 3 to indicate a Timestamp sub-TLV.
タイムスタンプサブTLVを示すために3に設定します。
Length:
長さ：
The length of the body in octets, exclusive of the Type and Length fields.
タイプと長さのフィールドを除く、オクテットの体の長さ。
Origin Timestamp:
オリジンタイムスタンプ：
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.
IHU TLVを囲むノードから受け取ったHello TLVに含まれる最後のタイムスタンプSub-TLVの送信タイムスタンプのコピー。
Receive Timestamp:
タイムスタンプを受け取る：
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.
送信者の時計によると、最後にタイムスタンプしたHello TLVがIHU TLVを囲むノードから受信しました。
If the Length field is larger than the expected 8 octets, the sub-TLV MUST be processed normally (the first 8 octets are interpreted as described above), and any extra data contained in this sub-TLV MUST be silently ignored. If the Length field is smaller than the expected 8 octets, then this sub-TLV MUST be ignored (and the remainder of the enclosing TLV processed as usual).
長さフィールドが予想される8オクテットよりも大きい場合、サブTLVは正常に処理する必要があり（最初の8オクテットは上記のように解釈されます）、このサブTLVに含まれる追加のデータは静かに無視する必要があります。長さのフィールドが予想される8オクテットよりも小さい場合、このサブTLVは無視する必要があります（そして、通常どおり処理される囲まれたTLVの残りの部分）。
IANA has added the following entry to the "Babel Sub-TLV Types" registry:
IANAは、「Babel Sub-TLVタイプ」レジストリに次のエントリを追加しました。
+======+===========+===========+
| Type | Name | Reference |
+======+===========+===========+
| 3 | Timestamp | RFC 9616 |
+------+-----------+-----------+
Table 1
This extension adds timestamping data to two of the TLVs sent by a Babel router. By broadcasting the value of a reasonably accurate local clock, these additional data might make a node more susceptible to timing attacks.
この拡張機能は、タイムスタンプデータをバベルルーターから送信した2つのTLVに追加します。適度に正確なローカルクロックの値を放送することにより、これらの追加データにより、ノードがタイミング攻撃の影響を受けやすくなる可能性があります。
Broadcasting an accurate time raises privacy issues. The timestamps used by this protocol have an arbitrary origin; therefore, they do not leak a node's boot time or 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.
ブロードキャスト正確な時間をとると、プライバシーの問題が発生します。このプロトコルで使用されるタイムスタンプには、任意の起源があります。したがって、ノードのブートタイムまたはタイムゾーンをリークしません。ただし、正確なタイムスタンプにアクセスできると、攻撃者がノードの物理的位置を決定できるようになります。ノードは、送信するTLVにタイムスタンプサブTLVを含めないことにより、位置情報の開示を回避する可能性があります。これにより、隣人がホップカウントルーティングに戻ります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8966] Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", RFC 8966, DOI 10.17487/RFC8966, January 2021,
<https://www.rfc-editor.org/info/rfc8966>.
[DELAY-BASED]
Jonglez, B., Boutier, M., and J. Chroboczek, "A delay-
based routing metric", DOI 10.48550/arXiv.1403.3488, March
2014, <http://arxiv.org/abs/1403.3488>.
[RFC891] Mills, D., "DCN Local-Network Protocols", STD 44, RFC 891,
DOI 10.17487/RFC0891, December 1983,
<https://www.rfc-editor.org/info/rfc891>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
The authors are indebted to Jean-Paul Smets, who prompted the investigation that originally lead to this protocol. We are also grateful to Donald Eastlake, 3rd, Toke Høiland-Jørgensen, Maria Matejka, David Schinazi, Pascal Thubert, Steffen Vogel, and Ondřej Zajiček.
著者はジャン・ポール・スメットに感謝しており、ジャン・ポール・スメットはもともとこのプロトコルにつながる調査を促した。また、ドナルド・イーストレイク（3位）、トケ・ホイランド・ヨルゲンセン、マリア・マテイカ、デビッド・シナジ、パスカル・シュベルト、ステフェン・ヴォーゲル、およびオンド・ザジ・ザジチェクにも感謝しています。
Baptiste Jonglez
ENS Lyon
France
Email: baptiste.jonglez@ens-lyon.org
Juliusz Chroboczek
IRIF, Université Paris Cité
Case 7014
75205 Paris Cedex 13
France
Email: jch@irif.fr