[要約] RFC 8966は、Babelルーティングプロトコルに関する文書で、多様なリンクタイプとネットワークトポロジーに適応可能な距離ベクトル型ルーティングプロトコルを定義しています。その目的は、自動的にルーティング情報を更新し、ネットワークの変更に迅速に対応することで、インターネット接続の効率と信頼性を高めることです。利用場面としては、有線および無線ネットワークの混在環境、急速に変化するトポロジーを持つモバイルネットワーク、および小規模から大規模までのさまざまなネットワークがあります。
Internet Engineering Task Force (IETF) J. Chroboczek
Request for Comments: 8966 IRIF, University of Paris-Diderot
Obsoletes: 6126, 7557 D. Schinazi
Category: Standards Track Google LLC
ISSN: 2070-1721 January 2021
The Babel Routing Protocol
ベイビルルーティングプロトコル
Abstract
概要
Babel is a loop-avoiding, distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol and obsoletes RFC 6126 and RFC 7557.
Babelは、通常の有線ネットワークと無線メッシュネットワークの両方で堅牢で効率的なループ回避、距離 - ベクトルルーティングプロトコルです。この文書では、Babelルーティングプロトコルと廃止されたRFC 6126とRFC 7557について説明します。
Status of This Memo
本文書の位置付け
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/rfc8966.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8966で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Features
1.2. Limitations
1.3. Specification of Requirements
2. Conceptual Description of the Protocol
2.1. Costs, Metrics, and Neighbourship
2.2. The Bellman-Ford Algorithm
2.3. Transient Loops in Bellman-Ford
2.4. Feasibility Conditions
2.5. Solving Starvation: Sequencing Routes
2.6. Requests
2.7. Multiple Routers
2.8. Overlapping Prefixes
3. Protocol Operation
3.1. Message Transmission and Reception
3.2. Data Structures
3.3. Acknowledgments and Acknowledgment Requests
3.4. Neighbour Acquisition
3.5. Routing Table Maintenance
3.6. Route Selection
3.7. Sending Updates
3.8. Explicit Requests
4. Protocol Encoding
4.1. Data Types
4.2. Packet Format
4.3. TLV Format
4.4. Sub-TLV Format
4.5. Parser State and Encoding of Updates
4.6. Details of Specific TLVs
4.7. Details of specific sub-TLVs
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Cost and Metric Computation
A.1. Maintaining Hello History
A.2. Cost Computation
A.3. Route Selection and Hysteresis
Appendix B. Protocol Parameters
Appendix C. Route Filtering
Appendix D. Considerations for Protocol Extensions
Appendix E. Stub Implementations
Appendix F. Compatibility with Previous Versions
Acknowledgments
Authors' Addresses
Babel is a loop-avoiding distance-vector routing protocol that is designed to be robust and efficient both in networks using prefix-based routing and in networks using flat routing ("mesh networks"), and both in relatively stable wired networks and in highly dynamic wireless networks. This document describes the Babel routing protocol and obsoletes [RFC6126] and [RFC7557].
Babelは、プレフィックスベースのルーティングを使用したネットワーク内の両方で、平らなルーティング（「メッシュネットワーク」）を使用してネットワーク内で、そして比較的安定した有線ネットワークで、そして非常に安定した有線ネットワークの両方で、堅牢で効率的に設計されたループ回避距離 - ベクトルルーティングプロトコルです。動的無線ネットワークこの文書では、Babelルーティングプロトコルと廃止[RFC6126]と[RFC7557]について説明します。
The main property that makes Babel suitable for unstable networks is that, unlike naive distance-vector routing protocols [RIP], it strongly limits the frequency and duration of routing pathologies such as routing loops and black-holes during reconvergence. Even after a mobility event is detected, a Babel network usually remains loop-free. Babel then quickly reconverges to a configuration that preserves the loop-freedom and connectedness of the network, but is not necessarily optimal; in many cases, this operation requires no packet exchanges at all. Babel then slowly converges, in a time on the scale of minutes, to an optimal configuration. This is achieved by using sequenced routes, a technique pioneered by Destination-Sequenced Distance-Vector routing [DSDV].
バベルが不安定なネットワークに適した主な財産は、ナイーブ距離 - ベクトルルーティングプロトコル[RIP]とは異なり、再契機中のルーティングループやブラックホールなどのルーティングパスロジーの周波数と持続時間を強く制限することです。モビリティイベントが検出された後でさえ、ベイベルネットワークは通常ループフリーのままです。その後、Babelはすぐにネットワークのループ自由とつながりを保持する構成に再び走りますが、必ずしも最適ではありません。多くの場合、この操作にはパケット交換がまったく必要ありません。その後、Babelは、分のスケールで、最適な構成にゆっくりと収束します。これは、順序付けられた経路を使用することによって達成され、宛先順序距離 - ベクトルルーティング[DSDV]によって先駆的な技法。
More precisely, Babel has the following properties:
より正確には、Babelには以下の特性があります。
* when every prefix is originated by at most one router, Babel never suffers from routing loops;
* すべての接頭辞が最大1つのルーターによって発信されると、Babelはルーティングループを損なうことはありません。
* when a single prefix is originated by multiple routers, Babel may occasionally create a transient routing loop for this particular prefix; this loop disappears in time proportional to the loop's diameter, and never again (up to an arbitrary garbage-collection (GC) time) will the routers involved participate in a routing loop for the same prefix;
* 単一の接頭辞が複数のルータによって発生されると、Babelはこの特定のプレフィックスのための一時的なルーティングループを作成することがあります。このループはループの直径に比例し、再び（任意のガベージコレクション（GC）時間）には消えます（任意のガベージコレクション（GC）時間）、関係するルーターは同じプレフィックスのルーティングループに参加します。
* assuming bounded packet loss rates, any routing black-holes that may appear after a mobility event are corrected in a time at most proportional to the network's diameter.
* バラドされたパケット損失率を想定して、モビリティイベントの後に現れることができるルーティングブラックホールは、ネットワークの直径に比例して一度に修正されます。
Babel has provisions for link quality estimation and for fairly arbitrary metrics. When configured suitably, Babel can implement shortest-path routing, or it may use a metric based, for example, on measured packet loss.
Babelは、リンク品質推定とかなり恣意的な測定基準のための規定を持っています。適切に構成されている場合、Babelは最短経路のルーティングを実装することができ、あるいは例えば測定されたパケット損失に基づいてメトリックを使用することができる。
Babel nodes will successfully establish an association even when they are configured with different parameters. For example, a mobile node that is low on battery may choose to use larger time constants (hello and update intervals, etc.) than a node that has access to wall power. Conversely, a node that detects high levels of mobility may choose to use smaller time constants. The ability to build such heterogeneous networks makes Babel particularly adapted to the unmanaged or wireless environment.
バベルノードは、異なるパラメータで構成されている場合でも、協会を正常に確立します。例えば、バッテリ上で低いモバイルノードは、壁電力にアクセスするノードよりも大きな時間定数（Helloおよび更新間隔など）を使用することを選択することができる。逆に、高レベルのモビリティを検出するノードは、より小さな時間定数を使用することを選択できます。そのような異種ネットワークを構築する能力は、特に管理されていない環境または無線環境に特に適合されている。
Finally, Babel is a hybrid routing protocol, in the sense that it can carry routes for multiple network-layer protocols (IPv4 and IPv6), regardless of which protocol the Babel packets are themselves being carried over.
最後に、Babelはハイブリッドルーティングプロトコルで、どのプロトコルがどのプロトコルにかかわらず、Babelパケットが持ち越されているのかにかかわらず、複数のネットワーク層プロトコル（IPv4とIPv6）の経路を運ぶことができるという意味で。
Babel has two limitations that make it unsuitable for use in some environments. First, Babel relies on periodic routing table updates rather than using a reliable transport; hence, in large, stable networks it generates more traffic than protocols that only send updates when the network topology changes. In such networks, protocols such as OSPF [OSPF], IS-IS [IS-IS], or the Enhanced Interior Gateway Routing Protocol (EIGRP) [EIGRP] might be more suitable.
Babelには、一部の環境での使用には不適切な2つの制限があります。まず、Babelは信頼できるトランスポートを使用するのではなく、定期的なルーティングテーブルの更新に依存しています。したがって、大規模で安定したネットワークでは、ネットワークトポロジーが変更されたときにのみ更新のみを送信するプロトコルよりも多くのトラフィックが発生します。そのようなネットワークでは、OSPF [OSPF]、IS-IS（IS-IS]などのプロトコル、または拡張インテリアゲートウェイルーティングプロトコル（EIGRP）[EIGRP]がより適している可能性があります。
Second, unless the second algorithm described in Section 3.5.4 is implemented, Babel does impose a hold time when a prefix is retracted. While this hold time does not apply to the exact prefix being retracted, and hence does not prevent fast reconvergence should it become available again, it does apply to any shorter prefix that covers it. This may make those implementations of Babel that do not implement the optional algorithm described in Section 3.5.4 unsuitable for use in networks that implement automatic prefix aggregation.
第二に、セクション3.5.4で説明されている2番目のアルゴリズムが実装されていない限り、Babelはプレフィックスが引き込まれるときにホールドタイムを課します。このホールドタイムが退避する正確な接頭辞には適用されませんが、したがって高速再縮小を妨げない場合は、それが再び利用可能になるべきであれば、それを覆うより短い接頭辞に適用されます。これにより、セクション3.5.4で説明されているオプションのアルゴリズムを実装していないBabelの実装は、自動プレフィックス集計を実装するネットワークでの使用には不適切です。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Babel is a loop-avoiding distance-vector protocol: it is based on the Bellman-Ford algorithm, just like the venerable RIP [RIP], but includes a number of refinements that either prevent loop formation altogether, or ensure that a loop disappears in a timely manner and doesn't form again.
Babelはループ回避距離 - ベクトルプロトコルです。タイムリーな方法で再び形成されません。
Conceptually, Bellman-Ford is executed in parallel for every source of routing information (destination of data traffic). In the following discussion, we fix a source S; the reader will recall that the same algorithm is executed for all sources.
概念的には、Bellman-Fordはルーティング情報のすべてのソース（データトラフィックの宛先）に対して並行して実行されます。以下の説明では、送信元Sを修正します。リーダーはすべてのソースに対して同じアルゴリズムが実行されることを思い出します。
For every pair of neighbouring nodes A and B, Babel computes an abstract value known as the cost of the link from A to B, written C(A, B). Given a route between any two (not necessarily neighbouring) nodes, the metric of the route is the sum of the costs of all the links along the route. The goal of the routing algorithm is to compute, for every source S, the tree of routes of lowest metric to S.
隣接ノードAとBのすべてのペアについて、Babelは、AからBへのリンクのコストとして知られる抽象値を計算し、C（A、B）。任意の2つの（必ずしも隣接する）ノードの間の経路を考えると、経路の測定基準は、経路に沿ったすべてのリンクのコストの合計です。ルーティングアルゴリズムの目的は、Sの最低メトリックのルートのツリーをSにするすべてのソースSに対して計算することです。
Costs and metrics need not be integers. In general, they can be values in any algebra that satisfies two fairly general conditions (Section 3.5.2).
コストとメトリックは整数である必要はありません。一般に、それらは2つのかなり一般的な条件を満たす任意の代数の値であり得る（セクション3.5.2）。
A Babel node periodically sends Hello messages to all of its neighbours; it also periodically sends an IHU ("I Heard You") message to every neighbour from which it has recently heard a Hello. From the information derived from Hello and IHU messages received from its neighbour B, a node A computes the cost C(A, B) of the link from A to B.
Babelノードは定期的にhelloメッセージをそのすべての隣接者に送信します。また、それは最近Helloを聞いたすべての隣人にIHU（「聞いた」というメッセージを定期的に送信します。隣接Bから受信されたHelloおよびIHUメッセージから派生した情報から、ノードAは、AからBへのリンクのコストC（a、b）を計算する。
Every node A maintains two pieces of data: its estimated distance to S, written D(A), and its next-hop router to S, written NH(A). Initially, D(S) = 0, D(A) is infinite, and NH(A) is undefined.
すべてのノードAは2つのデータを保持します。最初に、D（S）= 0、D（A）は無限大、NH（A）は未定義です。
Periodically, every node B sends to all of its neighbours a route update, a message containing D(B). When a neighbour A of B receives the route update, it checks whether B is its selected next hop; if that is the case, then NH(A) is set to B, and D(A) is set to C(A, B) + D(B). If that is not the case, then A compares C(A, B) + D(B) to its current value of D(A). If that value is smaller, meaning that the received update advertises a route that is better than the currently selected route, then NH(A) is set to B, and D(A) is set to C(A, B) + D(B).
定期的に、すべてのノードBは、その隣接のすべての隣接ルートアップデート、D（B）を含むメッセージを送信します。Bの隣接Aがルートアップデートを受信すると、Bが選択されたネクストホップかをチェックします。そうであれば、NH（a）がbに設定され、d（a）はc（a、b）d（b）に設定される。そうでなければ、C（a、b）d（b）をその現在の値d（a）に比較する。その値が小さい場合、受信した更新は現在選択されている経路よりも優れた経路を広告していることを示し、NH（a）がbに設定され、d（a）はc（a、b）dに設定されている（b）。）。
A number of refinements to this algorithm are possible, and are used by Babel. In particular, convergence speed may be increased by sending unscheduled "triggered updates" whenever a major change in the topology is detected, in addition to the regular, scheduled updates. Additionally, a node may maintain a number of alternate routes, which are being advertised by neighbours other than its selected neighbour, and which can be used immediately if the selected route were to fail.
このアルゴリズムに対するいくつかの改良が可能であり、Babelによって使用されます。特に、定期的なスケジュールされた更新に加えて、トポロジーの大きな変化が検出されるたびに、予定外の「トリガされた更新」を送信することによって、収束速度が向上する可能性があります。さらに、ノードは、選択された隣人以外の隣接者によってアドバタイズされているいくつかの代替ルートを維持することができ、選択された経路が失敗した場合にすぐに使用することができる。
It is well known that a naive application of Bellman-Ford to distributed routing can cause transient loops after a topology change. Consider for example the following topology:
分散ルーティングにBellman-Fordのナイーブアプリケーションがトポロジ変更後に一時的なループを引き起こす可能性があることはよく知られています。次のトポロジを考慮してください。
B
1 /|
1 / |
S --- A |1
\ |
1 \|
C
After convergence, D(B) = D(C) = 2, with NH(B) = NH(C) = A.
収束後、D（B）= D（C）= 2、NH（B）= NH（C）= Aである。
Suppose now that the link between S and A fails:
SとAの間のリンクが失敗したことを確認します。
B
1 /|
/ |
S A |1
\ |
1 \|
C
When it detects the failure of the link, A switches its next hop to B (which is still advertising a route to S with metric 2), and advertises a metric equal to 3, and then advertises a new route with metric 3. This process of nodes changing selected neighbours and increasing their metric continues until the advertised metric reaches "infinity", a value larger than all the metrics that the routing protocol is able to carry.
リンクの障害を検出すると、次のホップをBに切り替え（依然としてメトリック2のルートを広告しています）、3に等しいメトリックをアドバタイズしてから、メトリック3を持つ新しいルートをアドバタイズします。このプロセス選択された隣接者を変更し、それらのメトリックを増加させるノードのうち、アドバタイズされたメトリックが「Infinity」に達するまで続き、ルーティングプロトコルが持ち運ぶことができるすべてのメトリックよりも大きい値。
Bellman-Ford is a very robust algorithm: its convergence properties are preserved when routers delay route acquisition or when they discard some updates. Babel routers discard received route announcements unless they can prove that accepting them cannot possibly cause a routing loop.
Bellman-Fordは非常に堅牢なアルゴリズムです：ルーターがルートの取得を遅らせるとき、またはそれらがいくつかの更新を破棄するときにその収束性プロパティは保持されます。彼らがそれらを受け入れることができることを証明することができない限り、Babelルーターは受信されたルートアナウンスを破棄します。
More formally, we define a condition over route announcements, known as the "feasibility condition", that guarantees the absence of routing loops whenever all routers ignore route updates that do not satisfy the feasibility condition. In effect, this makes Bellman-Ford into a family of routing algorithms, parameterised by the feasibility condition.
より正式には、すべてのルーターが実現可能性条件を満たさないルート更新を無視するときはいつでもルーティングループがないことを保証する、「実現可能性状態」として知られているルートアナウンスの状態を定義します。実際には、これはベルマンフォードを実現可能性の状態によってパラメータ化されたルーティングアルゴリズムのファミリにします。
Many different feasibility conditions are possible. For example, BGP can be modelled as being a distance-vector protocol with a (rather drastic) feasibility condition: a routing update is only accepted when the receiving node's AS number is not included in the update's AS_PATH attribute (note that BGP's feasibility condition does not ensure the absence of transient "micro-loops" during reconvergence).
多くの異なる実現可能性条件が可能です。たとえば、BGPは、（むしろ大幅な）実現可能性条件を持つ距離 - ベクトルプロトコルであるとモデル化することができます。受信ノードがアップデートのAS_PATH属性に含まれていない場合にのみルーティングアップデートは承認されます（BGPの実現可能性状態が行います。再交換中に一過性の「マイクロループ」がないことを確認してください）。
Another simple feasibility condition, used in the Destination-Sequenced Distance-Vector (DSDV) routing protocol [DSDV] and in the Ad hoc On-Demand Distance Vector (AODV) protocol [RFC3561], stems from the following observation: a routing loop can only arise after a router has switched to a route with a larger metric than the route that it had previously selected. Hence, one may define that a route is feasible when its metric at the local node would be no larger than the metric of the currently selected route, i.e., an announcement carrying a metric D(B) is accepted by A when C(A, B) + D(B) <= D(A). If all routers obey this constraint, then the metric at every router is nonincreasing, and the following invariant is always preserved: if A has selected B as its next hop, then D(B) < D(A), which implies that the forwarding graph is loop-free.
宛先シーケンス距離 - ベクトル（DSDV）ルーティングプロトコル[DSDV]およびアドホックオンデマンド距離ベクトル（AODV）プロトコル（RFC3561]で使用される別の簡単な実現可能性条件[RFC3561]は、次の観察からの幹部化：ルーティングループルータが以前に選択されていた経路よりも大きいメトリックを持つルートに切り替えられた後にのみ発生します。したがって、ローカルノードでのそのメトリックが現在選択されている経路のメトリックより大きくない場合、すなわちC（A、およびB）が承認されているアナウンスが許可される場合、経路が実行可能であることを定義することができる。b）d（b）≦d（a）。すべてのルーターがこの制約に従う場合、すべてのルータのメトリックは不要で、次の不変量は常に保存されます.aがそのネクストホップとしてBを選択した場合、D（B）<d（a）では、転送があることを意味します。グラフはループフリーです。
Babel uses a slightly more refined feasibility condition, derived from EIGRP [DUAL]. Given a router A, define the feasibility distance of A, written FD(A), as the smallest metric that A has ever advertised for S to any of its neighbours. An update sent by a neighbour B of A is feasible when the metric D(B) advertised by B is strictly smaller than A's feasibility distance, i.e., when D(B) < FD(A).
Babelは、EIGRP [デュアル]から派生したやや洗練された実現可能性状態を使用しています。ルータAを考えると、A、FD（a）の実現可能性距離を定義して、Aがその隣人のいずれかにSを宣伝したことがある最小のメトリックとして。BによってアドバタイズされたメトリックD（B）がAの実現可能性距離、すなわちD（B）<FD（a）よりも厳密に小さいときに、Aの隣接Bによって送信される更新が可能である。
It is easy to see that this latter condition is no more restrictive than DSDV-feasibility. Suppose that node A obeys DSDV-feasibility; then D(A) is nonincreasing, hence at all times D(A) <= FD(A). Suppose now that A receives a DSDV-feasible update that advertises a metric D(B). Since the update is DSDV-feasible, C(A, B) + D(B) <= D(A), hence D(B) < D(A), and since D(A) <= FD(A), D(B) < FD(A).
この後者の状態はDSDV実現可能性よりも制限的ではないことがわかります。ノードAがDSDV実現可能性に従わないとします。次にD（a）が不明であるため、常にd（a）<= fd（a）である。これで、Metric D（B）をアドバタイズするDSDV-実現可能なアップデートを受信するとします。更新はDSDV実行可能であるので、C（a、b）d（b）≦d（a）、したがってd（b）<d（a）、およびd（a）<= fd（a）、dからなるので、（b）<fd（a）。
To see that it is strictly less restrictive, consider the following diagram, where A has selected the route through B, and D(A) = FD(A) = 2. Since D(C) = 1 < FD(A), the alternate route through C is feasible for A, although its metric C(A, C) + D(C) = 5 is larger than that of the currently selected route:
厳密に制限的ではないことを確認するには、次の図を考慮してください。ここで、AはBからBまでの経路を選択し、D（a）= fd（a）= 2であるため、d（c）= 1 <fd（a）Cを介した代替経路は、そのメトリックC（A、C）D（C）= 5が現在選択されている経路のそれよりも大きいです。
B
1 / \ 1
/ \
S A
\ /
1 \ / 4
C
To show that this feasibility condition still guarantees loop-freedom, recall that at the time when A accepts an update from B, the metric D(B) announced by B is no smaller than FD(B); since it is smaller than FD(A), at that point in time FD(B) < FD(A). Since this property is preserved when A sends updates and also when it picks a different next hop, it remains true at all times, which ensures that the forwarding graph has no loops.
この実現可能性条件がループフリーダムを保証することを示すために、AがBからの更新を受け入れる時点で、BによってアナウンスされたメトリックD（B）はFD（B）よりも小さいことを思い出してください。その時点でFD（a）よりも小さいので、fd（b）<fd（a）である。このプロパティは、送信が更新されたとき、およびそれが別のネクストホップを選択したときにも保持されているので、それは常に真のままです。これにより、転送グラフにはループがないことが保証されます。
Obviously, the feasibility conditions defined above cause starvation when a router runs out of feasible routes. Consider the following diagram, where both A and B have selected the direct route to S:
明らかに、上で定義された実現可能性条件は、ルータが実行可能なルートから実行されるときに飢餓を引き起こす。AとBの両方がSへの直接経路を選択した次の図を考えてください。
A
1 /| D(A) = 1
/ | FD(A) = 1
S |1
\ | D(B) = 2
2 \| FD(B) = 2
B
Suppose now that the link between A and S breaks:
AとSの折り目の間のリンクが次のとおりです。
A
|
| FD(A) = 1
S |1
\ | D(B) = 2
2 \| FD(B) = 2
B
The only route available from A to S, the one that goes through B, is not feasible: A suffers from spurious starvation. At that point, the whole subtree suffering from starvation must be reset, which is essentially what EIGRP does when it performs a global synchronisation of all the routers in the starving subtree (the "active" phase of EIGRP).
aからs、bを通過するものは可能ではない唯一のルートが実行可能ではありません。その時点で、飢餓に苦しんでいるサブツリー全体をリセットする必要があります。これは、飢餓サブツリー（EIGRPの「アクティブな」フェーズ）内のすべてのルータのグローバルな同期を実行するときに、本質的にEIGRPを実行する必要があります。
Babel reacts to starvation in a less drastic manner, by using sequenced routes, a technique introduced by DSDV and adopted by AODV. In addition to a metric, every route carries a sequence number, a nondecreasing integer that is propagated unchanged through the network and is only ever incremented by the source; a pair (s, m), where s is a sequence number and m a metric, is called a distance.
ベイベルは、シーケンスされた経路を使用することによって、DSDVによって導入された技術を使用し、AODVによって採用された技術を使用することによって、より短い方法で飢餓に反応する。メトリックに加えて、すべてのルートはシーケンス番号を搭載しており、ネットワークを介して変更されずに伝播され、ソースによってのみインクリメントされます。ここで、Sはシーケンス番号とM個のメトリックを距離と呼ぶペア（S、M）。
A received update is feasible when either it is more recent than the
feasibility distance maintained by the receiving node, or it is
equally recent and the metric is strictly smaller. More formally, if
FD(A) = (s, m), then an update carrying the distance (s', m') is
feasible when either s' > s, or s = s' and m' < m.
Assuming the sequence number of S is 137, the diagram above becomes:
Sのシーケンス番号が137であると仮定すると、上記の図は次のようになります。
A
|
| FD(A) = (137, 1)
S |1
\ | D(B) = (137, 2)
2 \| FD(B) = (137, 2)
B
After S increases its sequence number, and the new sequence number is propagated to B, we have:
■シーケンス番号を増加させ、新しいシーケンス番号がBに伝播されます。
A
|
| FD(A) = (137, 1)
S |1
\ | D(B) = (138, 2)
2 \| FD(B) = (138, 2)
B
at which point the route through B becomes feasible again.
その時点で、Bを介した経路は再び実現可能になる。
Note that while sequence numbers are used for determining feasibility, they are not used in route selection: a node ignores the sequence number when selecting the best route to a given destination (Section 3.6). Doing otherwise would cause route oscillation while a sequence number propagates through the network, and might even cause persistent black-holes with some exotic metrics.
なお、実行可能性を判断するためにシーケンス番号が使用されている間は、ルート選択では使用されません。ノードは、特定の宛先への最適なルートを選択するときにシーケンス番号を無視します（セクション3.6）。さもなければ経路の振動はネットワークを通過する間、経路の振動を引き起こし、いくつかのエキゾチックな測定基準で持続的なブラックホールを引き起こす可能性があります。
In DSDV, the sequence number of a source is increased periodically. A route becomes feasible again after the source increases its sequence number, and the new sequence number is propagated through the network, which may, in general, require a significant amount of time.
DSDVでは、ソースのシーケンス番号が定期的に増加します。ソースがそのシーケンス番号を増加させた後、ルートが再び実行可能になり、新しいシーケンス番号がネットワークを通して伝播されます。これは、一般に、かなりの時間を必要とします。
Babel takes a different approach. When a node detects that it is suffering from a potentially spurious starvation, it sends an explicit request to the source for a new sequence number. This request is forwarded hop by hop to the source, with no regard to the feasibility condition. Upon receiving the request, the source increases its sequence number and broadcasts an update, which is forwarded to the requesting node.
Babelは異なるアプローチを取ります。ノードがそれが潜在的にスプリアスの飢餓に苦しんでいることを検出すると、新しいシーケンス番号のためにソースに明示的な要求を送信します。この要求は、実現可能性の状態に関してはない状態でホップでホップされます。要求を受信すると、ソースはそのシーケンス番号を増加させ、要求元ノードに転送される更新をブロードキャストする。
Note that after a change in network topology not all such requests will, in general, reach the source, as some will be sent over links that are now broken. However, if the network is still connected, then at least one among the nodes suffering from spurious starvation has an (unfeasible) route to the source; hence, in the absence of packet loss, at least one such request will reach the source. (Resending requests a small number of times compensates for packet loss.)
ネットワークトポロジの変更がすべて、一般に、現在壊れているリンクを介して送信されるため、一般的にはソースにアクセスします。しかしながら、ネットワークがまだ接続されている場合、スプリアス飢餓に苦しんでいるノードのうちの少なくとも1つは、送信元への（実行不可能な）経路を有する。したがって、パケット損失がない場合、少なくとも1つのそのような要求はソースに到達するであろう。（繰り出された要求は少数の回数をパケット損失を補償します。）
Since requests are forwarded with no regard to the feasibility condition, they may, in general, be caught in a forwarding loop; this is avoided by having nodes perform duplicate detection for the requests that they forward.
要求は実現可能性の状態に関しては転送されるので、それらは一般に、転送ループに捕捉される可能性があります。これは、ノードが転送された要求に対して重複検出を実行することによって回避されます。
The above discussion assumes that each prefix is originated by a single router. In real networks, however, it is often necessary to have a single prefix originated by multiple routers: for example, the default route will be originated by all of the edge routers of a routing domain.
上記の説明では、各接頭辞が単一のルータによって発生したことを前提としています。しかし実際のネットワークでは、複数のルータによって発生された単一のプレフィックスを持つことがしばしば必要です。たとえば、デフォルトルートはルーティングドメインのすべてのエッジルータによって発生します。
Since synchronising sequence numbers between distinct routers is problematic, Babel treats routes for the same prefix as distinct entities when they are originated by different routers: every route announcement carries the router-id of its originating router, and feasibility distances are not maintained per prefix, but per source, where a source is a pair of a router-id and a prefix. In effect, Babel guarantees loop-freedom for the forwarding graph to every source; since the union of multiple acyclic graphs is not in general acyclic, Babel does not in general guarantee loop-freedom when a prefix is originated by multiple routers, but any loops will be broken in a time at most proportional to the diameter of the loop -- as soon as an update has "gone around" the routing loop.
異なるルータ間でシーケンス番号を同期することは問題があるため、バベルは異なるルータによって発信されたときに異なるエンティティと同じプレフィックスのルートを扱います。しかし、ソースごと、ソースはルータIDとプレフィックスのペアです。実際には、Babelはすべてのソースへの転送グラフのループフリーダムを保証します。複数の非環式グラフの連合は一般的な非環式ではないので、プレフィックスが複数のルータによって発生したときに、一般的な保証ループフリーダムではありませんが、ループの直径に比例しています。 - アップデートがルーティングループを「終わり」とすぐに
Consider for example the following topology, where A has selected the default route through S, and B has selected the one through S':
次のトポロジは、次のトポロジを考慮して、AはSを介してデフォルトルートを選択し、Bは1からS 'を選択しました。
1 1 1
::/0 -- S --- A --- B --- S' -- ::/0
Suppose that both default routes fail at the same time; then nothing prevents A from switching to B, and B simultaneously switching to A. However, as soon as A has successfully advertised the new route to B, the route through A will become unfeasible for B. Conversely, as soon as B will have advertised the route through A, the route through B will become unfeasible for A.
両方のデフォルトルートが同時に失敗するとします。そして、Aが同時にBに切り替わるのを防ぎます。Aを介した経路は、Aのために実行不可能になるでしょう。
In effect, the routing loop disappears at the latest when routing information has gone around the loop. Since this process can be delayed by lost packets, Babel makes certain efforts to ensure that updates are sent reliably after a router-id change (Section 3.7.2).
実際には、ルーティング情報がループの周囲に発生したときにルーティングループが最新の場合に消えます。このプロセスは紛失したパケットによって遅れることができるので、BabelはルータIDの変更後に更新が確実に送信されることを確実にするために特定の努力をします（セクション3.7.2）。
Additionally, after the routers have advertised the two routes, both sources will be in their source tables, which will prevent them from ever again participating in a routing loop involving routes from S and S' (up to the source GC time, which, available memory permitting, can be set to arbitrarily large values).
さらに、ルータが2つのルートをアドバタイズした後、両方のソースはソーステーブルにあります。これは、SとS 'からのルーティングループ（ソースGC時間まで）を含むルーティングループに再び参加するのを防ぎます。メモリ許可は任意の大きな値に設定できます）。
In the above discussion, we have assumed that all prefixes are disjoint, as is the case in flat ("mesh") routing. In practice, however, prefixes may overlap: for example, the default route overlaps with all of the routes present in the network.
上記の説明では、フラット（ "メッシュ"）ルーティングの場合と同様に、すべての接頭辞が互いに素であると仮定しました。ただし、実際には、プレフィックスが重なっている可能性があります。たとえば、デフォルトのルートはネットワーク内に存在するすべてのルートと重なります。
After a route fails, it is not correct in general to switch to a route that subsumes the failed route. Consider for example the following configuration:
経路が失敗した後、故障した経路を包含するルートに切り替えることは正しくありません。次のような設定について考察してください。
1 1
::/0 -- A --- B --- C
Suppose that node C fails. If B forwards packets destined to C by following the default route, a routing loop will form, and persist until A learns of B's retraction of the direct route to C. B avoids this pitfall by installing an "unreachable" route after a route is retracted; this route is maintained until it can be guaranteed that the former route has been retracted by all of B's neighbours (Section 3.5.4).
ノードCが失敗したとします。デフォルトルートに従ってC宛てのパケットを転送する場合、ルーティングループはフォームになり、Cへの直接経路のリククークリクションの学習が永続的になるまで持続します。;このルートは、前のルートがすべてのBの隣人によって引き込まれたことが保証されるまで維持されます（セクション3.5.4）。
Every Babel speaker is assigned a router-id, which is an arbitrary string of 8 octets that is assumed unique across the routing domain. For example, router-ids could be assigned randomly, or they could be derived from a link-layer address. (The protocol encoding is slightly more compact when router-ids are assigned in the same manner as the IPv6 layer assigns host IDs; see the definition of the "R" flag in Section 4.6.9.)
すべてのBabelスピーカーにはルータIDが割り当てられています。これは、ルーティングドメイン全体で一意に想定されている8オクテットの任意の文字列です。たとえば、Router-IDはランダムに割り当てることもできます。または、リンク層アドレスから派生することもできます。（IPv6レイヤーと同じ方法でrouter-idsが割り当てられている場合、プロトコルエンコードはわずかにコンパクトです。セクション4.6.9）の "R"フラグの定義を参照してください。）
Babel protocol packets are sent in the body of a UDP datagram (as described in Section 4). Each Babel packet consists of zero or more TLVs. Most TLVs may contain sub-TLVs.
Babelプロトコルパケットは、（セクション4で説明されているように）UDPデータグラムの本文で送信されます。各ベイヤーパケットは、0個以上のTLVで構成されています。ほとんどのTLVにはサブTLVを含めることができます。
Babel's control traffic can be carried indifferently over IPv6 or over IPv4, and prefixes of either address family can be announced over either protocol. Thus, there are at least two natural deployment models: using IPv6 exclusively for all control traffic, or running two distinct protocol instances, one for each address family. The exclusive use of IPv6 for all control traffic is RECOMMENDED, since using both protocols at the same time doubles the amount of traffic devoted to neighbour discovery and link quality estimation.
Babelの制御トラフィックはIPv6またはIPv4を介して無関心に実行でき、どちらのアドレスファミリのプレフィックスもどちらかのプロトコルを介して発表できます。したがって、少なくとも2つのNatural展開モデルがあります。すべての制御トラフィック専用のIPv6を使用するか、または2つの異なるプロトコルインスタンスを実行します。同じ時点で両方のプロトコルを使用すると、近隣の発見とリンク品質推定に専念するトラフィック量が2倍になるため、すべての制御トラフィックのIPv6の排他的使用が推奨されます。
The source address of a Babel packet is always a unicast address, link-local in the case of IPv6. Babel packets may be sent to a well-known (link-local) multicast address or to a (link-local) unicast address. In normal operation, a Babel speaker sends both multicast and unicast packets to its neighbours.
Babelパケットの送信元アドレスは常にIPv6の場合にリンクローカルであるユニキャストアドレスです。Babelパケットは、よく知られている（リンクローカル）マルチキャストアドレスまたは（Link-Local）ユニキャストアドレスに送信されます。通常の操作では、Babel Speakerはマルチキャストパケットとユニキャストパケットの両方をその隣接者に送信します。
With the exception of acknowledgments, all Babel TLVs can be sent to either unicast or multicast addresses, and their semantics does not depend on whether the destination is a unicast or a multicast address. Hence, a Babel speaker does not need to determine the destination address of a packet that it receives in order to interpret it.
確認応答を除いて、すべてのBabel TLVSをユニキャストアドレスまたはマルチキャストアドレスに送信することができ、それらのセマンティクスは、宛先がユニキャストまたはマルチキャストアドレスかによって異なります。したがって、Babelスピーカーは、それを解釈するために受信したパケットの宛先アドレスを決定する必要はありません。
A moderate amount of jitter may be applied to packets sent by a Babel speaker: outgoing TLVs are buffered and SHOULD be sent with a random delay. This is done for two purposes: it avoids synchronisation of multiple Babel speakers across a network [JITTER], and it allows for the aggregation of multiple TLVs into a single packet.
中程度の量のジッタをBabel Speakerによって送信されたパケットに適用することができます。発信TLVはバッファリングされ、ランダムな遅延で送信されるべきです。これは2つの目的で行われます。ネットワークを介して複数のBabelスピーカーの同期を回避し、それは複数のTLVを単一のパケットに集約することを可能にします。
The maximum amount of delay a TLV can be subjected to depends on the TLV. When the protocol description specifies that a TLV is urgent (as in Section 3.7.2 and Section 3.8.1), then the TLV MUST be sent within a short time known as the urgent timeout (see Appendix B for recommended values). When the TLV is governed by a timeout explicitly included in a previous TLV, such as in the case of Acknowledgments (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 explicit deadline (with a small margin to allow for propagation delays). In all other cases, the TLV SHOULD be sent out within one-half of the Multicast Hello interval.
最大遅延量TLVはTLVに依存する可能性があります。プロトコルの説明がTLVが緊急の（セクション3.7.2と3.8.1項のように）、TLVは緊急のタイムアウトと呼ばれる短い時間内に送信されなければなりません（推奨値については付録Bを参照）。確認応答の場合（セクション3.7）、更新（セクション3.7）、およびIHUS（3.4.2）など、TLVが前のTLVに管理されているタイムアウトによって管理されている場合（セクション3.7）、TLVを送信する必要があります。明示的な締め切りを満たすのに十分早く（伝播遅延を可能にするために小さなマージンがあります）。他のすべての場合において、TLVはマルチキャストHello間隔の半分以内に送信されるべきです。
In order to avoid packet drops (either at the sender or at the receiver), a delay SHOULD be introduced between successive packets sent out on the same interface, within the constraints of the previous paragraph. Note, however, that such packet pacing might impair the ability of some link layers (e.g., IEEE 802.11 [IEEE802.11]) to perform packet aggregation.
パケット損失を（送信者または受信機で）を回避するために、前の段落の制約内で同じインターフェイスに送信された連続パケット間に遅延を導入する必要があります。しかしながら、そのようなパケットペーシングは、パケット集約を実行するために、リンク層（例えば、IEEE802.11 [IEEE802.11]）の能力を損なう可能性があることに注意してください。
In this section, we describe the data structures that every Babel speaker maintains. This description is conceptual: a Babel speaker may use different data structures as long as the resulting protocol is the same as the one described in this document. For example, rather than maintaining a single table containing both selected and unselected (fallback) routes, as described in Section 3.2.6, an actual implementation would probably use two tables, one with selected routes and one with fallback routes.
このセクションでは、すべてのBabelスピーカーが維持するデータ構造について説明します。この説明は概念的なものである。結果のプロトコルがこの文書に記載されているものと同じである限り、Babelスピーカーは異なるデータ構造を使用することができる。たとえば、セクション3.2.6で説明されているように、選択されていない（フォールバック）ルートの両方を含む単一のテーブルを維持するのではなく、実際の実装はおそらく2つのテーブルを使用します。これは選択されたルートとフォールバックルートを持つ1つです。
Sequence numbers (seqnos) appear in a number of Babel data structures, and they are interpreted as integers modulo 2^(16). For the purposes of this document, arithmetic on sequence numbers is defined as follows.
シーケンス番号（SEQNOS）は、いくつかのBabelデータ構造に現れ、それらは整数として解釈されます2 ^（16）。この文書の目的のために、シーケンス番号に対する算術演算は次のように定義されます。
Given a seqno s and a non-negative integer n, the sum of s and n is defined by the following:
SEQNO Sと負の非負整数Nを考えると、SとNの合計は次のように定義されます。
s + n (modulo 2^(16)) = (s + n) MOD 2^(16)
or, equivalently,
または等価的に、
s + n (modulo 2^(16)) = (s + n) AND 65535
where MOD is the modulo operation yielding a non-negative integer, and AND is the bitwise conjunction operation.
MODはモジュロ動作でない整数をもたらすモジュロ動作であり、ビット単位の接続操作です。
Given two sequence numbers s and s', the relation s is less than s' (s < s') is defined by the following:
2つのシーケンス番号SおよびS 'が与えられると、関係SはS'より小さい（S <s '）は以下によって定義される。
s < s' (modulo 2^(16)) when 0 < ((s' - s) MOD 2^(16)) < 32768
or, equivalently,
または等価的に、
s < s' (modulo 2^(16)) when s /= s' and ((s' - s) AND 32768) = 0.
S <S '（モジュロ2 ^（16））S / = S'のとき（（s ' - s）、32768）= 0。
A node's sequence number is a 16-bit integer that is included in route updates sent for routes originated by this node.
ノードのシーケンス番号は、このノードによって発信されたルート用に送信されたルートアップデートに含まれる16ビット整数です。
A node increments its sequence number (modulo 2^(16)) whenever it receives a request for a new sequence number (Section 3.8.1.2). A node SHOULD NOT increment its sequence number (seqno) spontaneously, since increasing seqnos makes it less likely that other nodes will have feasible alternate routes when their selected routes fail.
ノードは、新しいシーケンス番号の要求を受け取るときはいつでもシーケンス番号（Modulo 2 ^（16））をインクリメントします（セクション3.8.1.2）。SEQNOSを増やすと、選択されたルートが失敗したときに他のノードが実行可能な代替ルートがある可能性が低くなるため、ノードはそのシーケンス番号（seqno）を自発的に増やすべきではありません。
The interface table contains the list of interfaces on which the node speaks the Babel protocol. Every interface table entry contains the interface's outgoing Multicast Hello seqno, a 16-bit integer that is sent with each Multicast Hello TLV on this interface and is incremented (modulo 2^(16)) whenever a Multicast Hello is sent. (Note that an interface's Multicast Hello seqno is unrelated to the node's seqno.)
インターフェイステーブルには、ノードがBabelプロトコルを話すインターフェイスのリストが含まれています。すべてのインターフェイステーブルエントリには、インターフェイスの発信マルチキャストHello SEQNOが含まれており、このインターフェイス上の各マルチキャストHello TLVとともに送信され、マルチキャストHelloが送信されるたびにインクリメントされます（モジュロ2 ^（16））。（インターフェイスのマルチキャストHello SeqnoはノードのSEQNOとは無関係です。）
There are two timers associated with each interface table entry. The periodic multicast hello timer governs the sending of scheduled Multicast Hello and IHU packets (Section 3.4). The periodic Update timer governs the sending of periodic route updates (Section 3.7.1). See Appendix B for suggested time constants.
各インタフェーステーブルエントリに関連付けられている2つのタイマーがあります。周期的なマルチキャストHello Timerは、スケジュールされたマルチキャストHelloとIHUパケットの送信を管理します（セクション3.4）。定期的なアップデートタイマーは、定期的なルート更新の送信を管理します（セクション3.7.1）。推奨される時間定数については付録Bを参照してください。
The neighbour table contains the list of all neighbouring interfaces from which a Babel packet has been recently received. The neighbour table is indexed by pairs of the form (interface, address), and every neighbour table entry contains the following data:
隣接テーブルには、Babelパケットが最近受信されたすべての隣接インタフェースのリストが含まれています。隣接テーブルはフォームのペア（インターフェイス、アドレス）、およびすべての隣接テーブルエントリに次のデータが含まれています。
* the local node's interface over which this neighbour is reachable;
* このネイバーが到達可能なローカルノードのインタフェース。
* the address of the neighbouring interface;
* 隣接インタフェースのアドレス。
* a history of recently received Multicast Hello packets from this neighbour; this can, for example, be a sequence of n bits, for some small value n, indicating which of the n hellos most recently sent by this neighbour have been received by the local node;
* 最近受信したマルチキャストハローパケットの履歴。これは、例えば、いくつかの小さな値nのために、nビットのシーケンスであり得、この隣接によって最後に送信されたn hellosがローカルノードによって受信されたことを示すことができる。
* a history of recently received Unicast Hello packets from this neighbour;
* この隣人から最近受信したユニキャストHelloパケットの履歴。
* the "transmission cost" value from the last IHU packet received from this neighbour, or FFFF hexadecimal (infinity) if the IHU hold timer for this neighbour has expired;
* このネイバーから受信した最後のIHUパケットからの「送信コスト」値、またはこのネイバーのIHUホールドタイマが期限切れになっている場合は、FFFF 16進数（無限大）です。
* the expected incoming Multicast Hello sequence number for this neighbour, an integer modulo 2^(16).
* この隣接の着信マルチキャストHelloシーケンス番号、整数モジュロ2 ^（16）。
* the expected incoming Unicast Hello sequence number for this neighbour, an integer modulo 2^(16).
* この隣接のための受信ユニキャストHelloシーケンス番号、整数モジュロ2 ^（16）。
* the outgoing Unicast Hello sequence number for this neighbour, an integer modulo 2^(16) that is sent with each Unicast Hello TLV to this neighbour and is incremented (modulo 2^(16)) whenever a Unicast Hello is sent. (Note that the outgoing Unicast Hello seqno for a neighbour is distinct from the interface's outgoing Multicast Hello seqno.)
* この隣接のための送信ユニキャストHelloシーケンス番号、各ユニキャストHello TLVをこの隣接に送信され、ユニキャストHelloが送信されるたびにインクリメントされます（モジュロ2 ^（16））。（隣人のための発信ユニキャストHello Seqnoは、インターフェイスの発信マルチキャストHello Seqnoとは異なります。）
There are three timers associated with each neighbour entry -- the multicast hello timer, which is set to the interval value carried by scheduled Multicast Hello TLVs sent by this neighbour, the unicast hello timer, which is set to the interval value carried by scheduled Unicast Hello TLVs, and the IHU timer, which is set to a small multiple of the interval carried in IHU TLVs (see "IHU Hold time" in Appendix B for suggested values).
各隣接エントリに関連する3つのタイマがあります。この隣接によって送信されたスケジュールされたマルチキャストHello TLVによって運ばれる間隔値に設定されているマルチキャストハロータイマ、スケジュールされたユニキャストによって運ばれる間隔の値に設定されるユニキャストHello TimerHello TLVS、およびIHUタイマーは、IHU TLVSで運ばれる間隔の小さな倍数に設定されています（推奨値については付録Bの「IHUホールドタイム」を参照）。
Note that the neighbour table is indexed by IP addresses, not by router-ids: neighbourship is a relationship between interfaces, not between nodes. Therefore, two nodes with multiple interfaces can participate in multiple neighbourship relationships, a situation that can notably arise when wireless nodes with multiple radios are involved.
隣接テーブルは、router-idsではなくIPアドレスによってインデックスされています.NEIEBOURSHIPは、ノード間ではなくインターフェイス間の関係です。したがって、複数のインタフェースを持つ2つのノードが複数の近隣の関係に参加できます。複数のラジオを持つワイヤレスノードが含まれている場合には、このような状況が注目すべきです。
The source table is used to record feasibility distances. It is indexed by triples of the form (prefix, plen, router-id), and every source table entry contains the following data:
ソーステーブルは、実現可能性距離を記録するために使用されます。フォームのトリプル（プレフィックス、プレー、ルータID）、およびすべてのソーステーブルエントリに次のデータが含まれています。
* the prefix (prefix, plen), where plen is the prefix length in bits, that this entry applies to;
* プレフィックス（プレフィックス、PLEN）。ここで、PLENはビット内のプレフィックス長で、このエントリは適用されます。
* the router-id of a router originating this prefix;
* このプレフィックスを発信するルータのルータID。
* a pair (seqno, metric), this source's feasibility distance.
* ペア（seqno、metric）、このソースの実現可能性距離。
There is one timer associated with each entry in the source table -- the source garbage-collection timer. It is initialised to a time on the order of minutes and reset as specified in Section 3.7.3.
ソース表の各エントリに関連付けられているタイマーが1つあります。 - ソースガベージコレクションタイマー。3.7.3項で指定されているように、数分程度の時間に初期化され、リセットされます。
The route table contains the routes known to this node. It is indexed by triples of the form (prefix, plen, neighbour), and every route table entry contains the following data:
ルートテーブルには、このノードに既知のルートが含まれています。フォームのトリプル（プレフィックス、プレス、ネイバー）によってインデックスされ、すべてのルートテーブルエントリに次のデータが含まれています。
* the source (prefix, plen, router-id) for which this route is advertised;
* このルートがアドバタイズされているソース（プレフィックス、プレー、ルータID）。
* the neighbour (an entry in the neighbour table) that advertised this route;
* このルートをアドバタイズしたネイバー（隣接テーブルのエントリ）。
* the metric with which this route was advertised by the neighbour, or FFFF hexadecimal (infinity) for a recently retracted route;
* 最近退避したルートの隣接またはFFFF 16進数（無限大）によって、このルートが隣接またはFFFF 16進数（無限大）に掲載したメトリック。
* the sequence number with which this route was advertised;
* このルートが宣伝されたシーケンス番号。
* the next-hop address of this route;
* このルートのネクストホップアドレス。
* a boolean flag indicating whether this route is selected, i.e., whether it is currently being used for forwarding and is being advertised.
* この経路が選択されているかどうか、すなわちそれが現在転送および宣伝されているかどうかを示すブールフラグ。
There is one timer associated with each route table entry -- the route expiry timer. It is initialised and reset as specified in Section 3.5.3.
各ルートテーブルエントリ - ルート有効期限タイマーに関連付けられているタイマーが1つあります。セクション3.5.3で指定されているように初期化してリセットされます。
Note that there are two distinct (seqno, metric) pairs associated with each route: the route's distance, which is stored in the route table, and the feasibility distance, which is stored in the source table and shared between all routes with the same source.
各経路に関連する2つの異なる（SEQNO、メトリック）ペアがあることに注意して、ルートテーブルに格納されているルートの距離、およびソーステーブルに格納され、同じソースを持つすべてのルート間で共有される実現可能性距離。
The table of pending seqno requests contains a list of seqno requests that the local node has sent (either because they have been originated locally, or because they were forwarded) and to which no reply has been received yet. This table is indexed by triples of the form (prefix, plen, router-id), and every entry in this table contains the following data:
保留中のSEQNO要求の表には、ローカルノードが送信されたSEQNO要求のリストが含まれています（ローカルに発信されているため、または転送されたため）、まだ返信が受信されていないためです。このテーブルはフォームのトリプル（プレフィックス、PLEN、ROUTER-ID）によって索引付けされ、この表のすべてのエントリには次のデータが含まれています。
* the prefix, plen, router-id, and seqno being requested;
* 要求されているプレフィックス、PLEN、Router-ID、およびSEQNOがあります。
* the neighbour, if any, on behalf of which we are forwarding this request;
* この要求を転送しているために、隣人があれば、
* a small integer indicating the number of times that this request will be resent if it remains unsatisfied.
* この要求が満たされていない場合にこの要求が再送信される回数を示す小さな整数。
There is one timer associated with each pending seqno request; it governs both the resending of requests and their expiry.
保留中のSEQNO要求に関連する各タイマーがあります。リクエストの再送信とその有効期限の両方を管理します。
A Babel speaker may request that a neighbour receiving a given packet reply with an explicit acknowledgment within a given time. While the use of acknowledgment requests is optional, every Babel speaker MUST be able to reply to such a request.
ベイヤースピーカーは、特定の時間内に明示的な確認応答を使用して、特定のパケットの返信を受け取る隣接を要求することができます。確認応答要求の使用はオプションですが、すべてのBabelスピーカーはそのような要求に応えることができなければなりません。
An acknowledgment MUST be sent to a unicast destination. On the other hand, acknowledgment requests may be sent to either unicast or multicast destinations, in which case they request an acknowledgment from all of the receiving nodes.
確認応答はユニキャスト先に送信されなければなりません。他方、確認応答要求は、ユニキャストまたはマルチキャスト宛先のいずれかに送信されてもよい。その場合、それらはすべての受信ノードから確認応答を要求する。
When to request acknowledgments is a matter of local policy; the simplest strategy is to never request acknowledgments and to rely on periodic updates to ensure that any reachable routes are eventually propagated throughout the routing domain. In order to improve convergence speed and to reduce the amount of control traffic, acknowledgment requests MAY be used in order to reliably send urgent updates (Section 3.7.2) and retractions (Section 3.5.4), especially when the number of neighbours on a given interface is small. Since Babel is designed to deal gracefully with packet loss on unreliable media, sending all packets with acknowledgment requests is not necessary and NOT RECOMMENDED, as the acknowledgments cause additional traffic and may force additional Address Resolution Protocol (ARP) or Neighbour Discovery (ND) exchanges.
承認を要求するときは、ローカルポリシーの問題です。最も簡単な戦略は、承認を要求し、到達可能なルートが最終的にルーティングドメイン全体に伝播されるように定期的な更新に依存することは決してないことです。コンバージェンス速度を向上させ、制御トラフィックの量を削減するために、特に隣接する場合は、緊急アップデート（セクション3.7.2）と後退（セクション3.5.4）、Aの隣接者数（セクション3.5.4）を確実に送信するために承認要求を使用することができます。与えられたインターフェースは小さいです。Babelは信頼性の低いメディアのパケット損失で優雅に対応するように設計されているので、確認応答要求を使用してすべてのパケットを送信する必要はなく、承認が追加のトラフィックを引き起こし、追加のアドレス解決プロトコル（ARP）またはネイバーディスカバリ（ND）交換を強制することができます。。
Neighbour acquisition is the process by which a Babel node discovers the set of neighbours heard over each of its interfaces and ascertains bidirectional reachability. On unreliable media, neighbour acquisition additionally provides some statistics that may be useful for link quality computation.
近隣取得は、Babelノードがそのインタフェースのそれぞれについて聞いた一組の隣接者を検出し、双方向到達可能性を確定するプロセスです。信頼できないメディアでは、隣接取得はさらにリンク品質計算に役立つかもしれないいくつかの統計を提供します。
Before it can exchange routing information with a neighbour, a Babel node MUST create an entry for that neighbour in the neighbour table. When to do that is implementation-specific; suitable strategies include creating an entry when any Babel packet is received, or creating an entry when a Hello TLV is parsed. Similarly, in order to conserve system resources, an implementation SHOULD discard an entry when it has been unused for long enough; suitable strategies include dropping the neighbour after a timeout, and dropping a neighbour when the associated Hello histories become empty (see Appendix A.2).
それが隣接でルーティング情報を交換することができる前に、Babelノードはネイバーテーブルにそのネイバーのエントリを作成する必要があります。そのことをするときは実装固有です。適切な戦略には、任意のBabelパケットが受信されたとき、またはHello TLVが解析されたときにエントリを作成するためのエントリを作成することが含まれます。同様に、システムリソースを節約するために、実装は十分に使用されていないときにエントリを廃棄する必要があります。適切な戦略には、タイムアウト後に隣人を落とし、関連するHello履歴が空になると隣接を落とします（付録A.2を参照）。
Every Babel node sends Hello TLVs to its neighbours, at regular or irregular intervals, to indicate that it is alive. Each Hello TLV carries an increasing (modulo 2^(16)) sequence number and an upper bound on the time interval until the next Hello of the same type (see below). If the time interval is set to 0, then the Hello TLV does not establish a new promise: the deadline carried by the previous Hello of the same type still applies to the next Hello (if the most recent scheduled Hello of the right kind was received at time t0 and carried interval i, then the previous promise of sending another Hello before time t0 + i still holds). We say that a Hello is "scheduled" if it carries a nonzero interval, and "unscheduled" otherwise.
すべてのベイビルノードは、それが生きていることを示すために、隣接する隣人に、隣接する隣人に隣接している。各Hello TLVは、同じタイプの次のhelloまでの時間間隔の上限（Modulo 2 ^（16））シーケンス番号と上限が増加します（下記参照）。時間間隔が0に設定されている場合、Hello TLVは新しい約束を確立していません。同じタイプの前のこんにちはの締め切りはまだ次のHelloに適用されます（正しい種類の最新のスケジュールされたこんにちが時刻t0と搬送された間隔Iは、時間t0の前に別のHelloを送信することの前回の約束です。私たちは、ゼロ以外の間隔を持つ場合は「スケジュールされている」と言っています。
There are two kinds of Hellos: Multicast Hellos, which use a per-interface Hello counter (the Multicast Hello seqno), and Unicast Hellos, which use a per-neighbour counter (the Unicast Hello seqno). A Multicast Hello with a given seqno MUST be sent to all neighbours on a given interface, either by sending it to a multicast address or by sending it to one unicast address per neighbour (hence, the term "Multicast Hello" is a slight misnomer). A Unicast Hello carrying a given seqno should normally be sent to just one neighbour (over unicast), since the sequence numbers of different neighbours are not in general synchronised.
2種類のhellos：マルチキャストHellosがあります。これは、インターフェースごとのハローカウンター（マルチキャストHello Seqno）を使用しています。隣接するカウンター（ユニキャストHello Seqno）を使用しているユニキャストHellos。特定のSEQNOを持つマルチキャストHelloは、それをマルチキャストアドレスに送信することによって、またはそれを近隣あたり1つのユニキャストアドレスに送信することによって、特定のインターフェイス上のすべての隣接者に送信されなければなりません（したがって、「マルチキャストhello」という用語はわずかなミスノマーです）。。特定のSEQNOを運ぶユニキャストHelloは通常、異なる隣接者のシーケンス番号は一般的に同期されていないため、1つの隣接（Unicast）に送信されるべきです。
Multicast Hellos sent over multicast can be used for neighbour discovery; hence, a node SHOULD send periodic (scheduled) Multicast Hellos unless neighbour discovery is performed by means outside of the Babel protocol. A node MAY send Unicast Hellos or unscheduled Hellos of either kind for any reason, such as reducing the amount of multicast traffic or improving reliability on link technologies with poor support for link-layer multicast.
マルチキャストを介して送信されたマルチキャストHelloは、近隣探索に使用できます。したがって、ノードは、Babelプロトコルの外部で近隣検出が実行されていない限り、周期的（スケジュールされた）マルチキャストHellosを送信する必要があります。ノードは、マルチキャストトラフィックの量を減らすこと、またはリンク層マルチキャストのサポートが悪いリンク技術の信頼性を向上させるなど、いかなる理由でも、いかなる理由でも、ノードがどちらの種類のいずれかの種類のいずれかの種類のいずれかのhellosを送ることができます。
A node MAY send a scheduled Hello ahead of time. A node MAY change its scheduled Hello interval. The Hello interval MAY be decreased at any time; it MAY be increased immediately before sending a Hello TLV, but SHOULD NOT be increased at other times. (Equivalently, a node SHOULD send a scheduled Hello immediately after increasing its Hello interval.)
ノードは予定されているhelloを前に送信することができます。ノードはそのスケジュールされたHello間隔を変更することができます。hello間隔はいつでも減少させることができます。Hello TLVを送信する直前に増加するかもしれませんが、他の時に増やすべきではありません。（等価的に、ノードはそのHello間隔を増やした直後にスケジュールされたhelloを送信する必要があります。）
How to deal with received Hello TLVs and what statistics to maintain are considered local implementation matters; typically, a node will maintain some sort of history of recently received Hellos. An example of a suitable algorithm is described in Appendix A.1.
受信したhello TLVと維持する統計をどのように対処するかは、地域の実装事項と見なされます。通常、ノードは最近受信したhellosのある種の履歴を維持します。適切なアルゴリズムの例は付録A.1に記載されている。
After receiving a Hello, or determining that it has missed one, the node recomputes the association's cost (Section 3.4.3) and runs the route selection procedure (Section 3.6).
helloを受け取った後、またはそれが見逃したと判断した後、そのノードは協会のコストを再計算し（3.4.3項）、経路選択手順を実行します（セクション3.6）。
In order to establish bidirectional reachability, every node sends periodic IHU ("I Heard You") TLVs to each of its neighbours. Since IHUs carry an explicit interval value, they MAY be sent less often than Hellos in order to reduce the amount of routing traffic in dense networks; in particular, they SHOULD be sent less often than Hellos over links with little packet loss. While IHUs are conceptually unicast, they MAY be sent to a multicast address in order to avoid an ARP or Neighbour Discovery exchange and to aggregate multiple IHUs into a single packet.
双方向の到達可能性を確立するために、すべてのノードは周期的なIHU（「聞いた」）TLVをその隣人に送信します。IHUSは明示的な間隔値を持ち運ぶため、密集ネットワークでのルーティングトラフィックの量を減らすために、それらはHellosよりも頻繁に送信される可能性があります。特に、パケット損失が少ないリンクを越えてhellosよりも頻繁に送信されるべきです。IHUSは概念的にユニキャストですが、ARPまたはNoiby Discovery Exchangeを回避し、複数のIHUを単一のパケットに集約するためにマルチキャストアドレスに送信されます。
In addition to the periodic IHUs, a node MAY, at any time, send an unscheduled IHU packet. It MAY also, at any time, decrease its IHU interval, and it MAY increase its IHU interval immediately before sending an IHU, but SHOULD NOT increase it at any other time. (Equivalently, a node SHOULD send an extra IHU immediately after increasing its Hello interval.)
周期的なIHUSに加えて、ノードはいつでも、予定外のIHUパケットを送信することができる。また、いつでもIHUの間隔を小さくすることができ、IHUを送信する直前のIHU間隔を増やすことができますが、それ以外の時間にはそれを増やすべきではありません。（等価的に、ノードはそのhello間隔を増やした直後に追加のIHUを送信する必要があります。）
Every IHU TLV contains two pieces of data: the link's rxcost (reception cost) from the sender's perspective, used by the neighbour for computing link costs (Section 3.4.3), and the interval between periodic IHU packets. A node receiving an IHU sets the value of the txcost (transmission cost) maintained in the neighbour table to the value contained in the IHU, and resets the IHU timer associated to this neighbour to a small multiple of the interval value received in the IHU (see "IHU Hold time" in Appendix B for suggested values). When a neighbour's IHU timer expires, the neighbour's txcost is set to infinity.
すべてのIHU TLVには2つのデータが含まれています。リンクコスト（セクション3.4.3）、および周期的IHUパケット間の間隔で使用される送信者の観点からのリンクのRXCOST（受信コスト）、および周期的IHUパケット間の間隔。IHUを受信したノードは、ネイバーテーブルに維持されているTXCOST（送信コスト）の値をIHUに含まれる値に設定し、この隣接に関連付けられたIHUタイマをIHUで受信した間隔値の小さい倍数にリセットします（推奨値については付録Bの「IHUホールドタイム」を参照してください。隣人のIHUタイマーが期限切れになると、隣人のTXCOSTは無限大に設定されています。
After updating a neighbour's txcost, the receiving node recomputes the neighbour's cost (Section 3.4.3) and runs the route selection procedure (Section 3.6).
隣接のTXCOSTを更新した後、受信側ノードは隣接コスト（セクション3.4.3）を再計算し、経路選択手順を実行します（セクション3.6）。
A neighbourship association's link cost is computed from the values maintained in the neighbour table: the statistics kept in the neighbour table about the reception of Hellos, and the txcost computed from received IHU packets.
近隣の協会のリンクコストは、隣接テーブルに維持されている値から計算されます。統計は、hellosの受信に関する隣接テーブル、および受信したIHUパケットから計算されたTXCOSTを保持します。
For every neighbour, a Babel node computes a value known as this neighbour's rxcost. This value is usually derived from the Hello history, which may be combined with other data, such as statistics maintained by the link layer. The rxcost is sent to a neighbour in each IHU.
すべての隣接について、Babelノードはこの隣のrxcostとして知られている値を計算します。この値は通常、リンク層によって維持されている統計などの他のデータと組み合わせることができるHello履歴から派生しています。RXCOSTは各IHUの隣接に送信されます。
Since nodes do not necessarily send periodic Unicast Hellos but do usually send periodic Multicast Hellos (Section 3.4.1), a node SHOULD use an algorithm that yields a finite rxcost when only Multicast Hellos are received, unless interoperability with nodes that only send Multicast Hellos is not required.
ノードは必ずしも定期ユニキャストHellosを送信するわけではありませんが、通常は周期的なマルチキャストHellos（セクション3.4.1）を送信します。必須ではありません。
How the txcost and rxcost are combined in order to compute a link's cost is a matter of local policy; as far as Babel's correctness is concerned, only the following conditions MUST be satisfied:
リンクの費用を計算するためにTXCOSTとRXCOSTがどのように組み合わされるかは、ローカルポリシーの問題です。Babelの正確さに関する限り、以下の条件を満たす必要があります。
* the cost is strictly positive;
* コストは厳密に肯定的です。
* if no Hello TLVs of either kind were received recently, then the cost is infinite;
* どちらの種類のHello TLVが最近受信されなかったら、コストは無限大です。
* if the txcost is infinite, then the cost is infinite.
* txcostが無限の場合、コストは無限大です。
See Appendix A.2 for RECOMMENDED strategies for computing a link's cost.
リンクのコストを計算するための推奨戦略については、付録A.2を参照してください。
Conceptually, a Babel update is a quintuple (prefix, plen, router-id, seqno, metric), where (prefix, plen) is the prefix for which a route is being advertised, router-id is the router-id of the router originating this update, seqno is a nondecreasing (modulo 2^(16)) integer that carries the originating router seqno, and metric is the announced metric.
概念的には、Babel UpdateはQuintuple（プレフィックス、PLEN、Router-ID、SEQNO、メトリック）です。（プレフィックス、PLEN）はルートがアドバタイズされているプレフィックスです.ROURTER-IDはルータのルーターIDです。このアップデートを発信すると、SEQNOはノンシリエーションです（モジュロ2 ^（16））発信元のルータSEQNOを搭載し、メトリックは発表されたメトリックです。
Before being accepted, an update is checked against the feasibility condition (Section 3.5.1), which ensures that the route does not create a routing loop. If the feasibility condition is not satisfied, the update is either ignored or prevents the route from being selected, as described in Section 3.5.3. If the feasibility condition is satisfied, then the update cannot possibly cause a routing loop.
受け入れられる前に、更新が実現可能性条件（セクション3.5.1）に対してチェックされ、ルートはルーティングループを作成しません。実現可能性条件が満たされない場合、3.5.3項で説明されているように、更新は無視されるか、または経路が選択されるのを防ぎます。実現可能性条件が満たされている場合、更新はおそらくルーティングループを引き起こすことはできません。
The feasibility condition is applied to all received updates. The feasibility condition compares the metric in the received update with the metrics of the updates previously sent by the receiving node; updates that fail the feasibility condition, and therefore have metrics large enough to cause a routing loop, are either ignored or prevent the resulting route from being selected.
実現可能性条件は、すべての受信更新プログラムに適用されます。実現可能性条件は、受信した更新におけるメトリックを、受信ノードによって以前に送信された更新のメトリックと比較する。実現可能性状態に違反している更新、したがって、ルーティングループを引き起こすのに十分なメトリックを持ち、結果のルートが選択されているのを防ぎます。
A feasibility distance is a pair (seqno, metric), where seqno is an integer modulo 2^(16) and metric is a positive integer. Feasibility distances are compared lexicographically, with the first component inverted: we say that a distance (seqno, metric) is strictly better than a distance (seqno', metric'), written
実現可能性距離はペア（SEQNO、メトリック）で、SEQNOは整数モジュロ2 ^（16）で、メトリックは正の整数です。実現可能性の距離は辞書的に比較され、最初の部品が反転されています。
(seqno, metric) < (seqno', metric')
（seqno、メトリック）<（seqno '、メトリック'）
when
いつ
seqno > seqno' or (seqno = seqno' and metric < metric')
where sequence numbers are compared modulo 2^(16).
シーケンス番号がモジュロ2 ^（16）と比較される場所。
Given a source (prefix, plen, router-id), a node's feasibility distance for this source is the minimum, according to the ordering defined above, of the distances of all the finite updates ever sent by this particular node for the prefix (prefix, plen) and the given router-id. Feasibility distances are maintained in the source table, the exact procedure is given in Section 3.7.3.
ソース（プレフィックス、PLEN、ROUTER-ID）を考えると、このソースのノードの実現可能性距離は、上で定義された順序に従って、この特定のノードからこの特定のノードが送信するすべての有限更新の距離（プレフィックス）の距離が最小です。、プレス）と与えられたルータID。実際の距離はソース表に維持されているため、正確な手順はセクション3.7.3に示されています。
A received update is feasible when either it is a retraction (its metric is FFFF hexadecimal), or the advertised distance is strictly better, in the sense defined above, than the feasibility distance for the corresponding source. More precisely, a route advertisement carrying the quintuple (prefix, plen, router-id, seqno, metric) is feasible if one of the following conditions holds:
受信された更新は、それが後退であるとき（そのメトリックはFFFF 16進数である）、または宣伝された距離は、対応するソースの実現可能性距離よりも厳密によりよく優れている。より正確には、次のいずれかの条件が保持されている場合、Quintuple（プレフィックス、プレス、ルータID、SEQNO、メトリック）を搭載したルート広告が実行可能です。
* metric is infinite; or
* メトリックは無限大です。または
* no entry exists in the source table indexed by (prefix, plen, router-id); or
* 索引付けされたソース表にエントリが存在しません（プレフィックス、PLEN、Router-ID）。または
* an entry (prefix, plen, router-id, seqno', metric') exists in the source table, and either
* エントリ（プレフィックス、PLEN、Router-ID、SEQNO '、メトリック'、メトリック '）はソーステーブルに存在します。
- seqno' < seqno or
- Seqno '<seqnoまたは
- seqno = seqno' and metric < metric'.
- seqno = seqno 'およびメトリック<メトリック'。
Note that the feasibility condition considers the metric advertised by the neighbour, not the route's metric; hence, a fluctuation in a neighbour's cost cannot render a selected route unfeasible. Note further that retractions (updates with infinite metric) are always feasible, since they cannot possibly cause a routing loop.
実現可能性の条件は、隣人によって広告されているメトリックを経路のメトリックではなく、隣接しています。したがって、近隣のコストの変動は、選択された経路を実行できない。さらに、リトラクティブ（Infiniteメトリックを含む更新）は、ルーティングループを引き起こす可能性があるため、常に実行可能です。
A route's metric is computed from the metric advertised by the neighbour and the neighbour's link cost. Just like cost computation, metric computation is considered a local policy matter; as far as Babel is concerned, the function M(c, m) used for computing a metric from a locally computed link cost c and the metric m advertised by a neighbour MUST only satisfy the following conditions:
ルートのメトリックは、隣人と隣人のリンクコストによって広告されているメトリックから計算されます。コスト計算と同じように、メトリック計算は地域のポリシー問題と見なされます。Babelに関する限り、局所的に計算されたリンクコストCからメトリックを計算するために使用される関数m（c、m）は、次の条件を満たすだけである必要があります。
* if c is infinite, then M(c, m) is infinite;
* Cが無限である場合、M（C、M）は無限大です。
* M is strictly monotonic: M(c, m) > m.
* Mは厳密に単調なものです：M（C、M）> M。
Additionally, the metric SHOULD satisfy the following condition:
さらに、メトリックは次の条件を満たすべきです。
* M is left-distributive: if m <= m', then M(c, m) <= M(c, m').
* M <= m 'の場合、m（c、m）<= m（c、m'）の場合。
While strict monotonicity is essential to the integrity of the network (persistent routing loops may arise if it is not satisfied), left-distributivity is not: if it is not satisfied, Babel will still converge to a loop-free configuration, but might not reach a global optimum (in fact, a global optimum may not even exist).
厳密な単調性はネットワークの整合性にとって不可欠です（持続的なルーティングループが満たされていない場合は永続的なルーティングループが発生する可能性があります）、左分布率は満足していない場合、Babelはまだループフリーの設定に収束しますが、そうでない地球規模の最適値に達する（実際、世界的な最適値さえ存在しないかもしれません）。
The conditions above are easily satisfied by using the additive metric, i.e., by defining M(c, m) = c + m. Since the additive metric is useful with a large range of cost computation strategies, it is the RECOMMENDED default. See also Appendix C, which describes a technique that makes it possible to tweak the values of individual metrics without running the risk of creating routing loops.
上記の条件は、添加剤測定基準、すなわちM（C、M）= C mを定義することによって容易に満たされる。添加剤メトリックは、大幅なコスト計算戦略に役立ちますので、推奨されるデフォルトです。付録Cは、ルーティングループを作成するリスクを実行せずに個々のメトリックの値を微調整することを可能にする手法を説明します。
When a Babel node receives an update (prefix, plen, router-id, seqno, metric) from a neighbour neigh, it checks whether it already has a route table entry indexed by (prefix, plen, neigh).
BableDノードが隣接ネイからの更新（プレフィックス、PLEN、Router-ID、SEQNO、メトリック）を受信すると、（プレフィックス、PLEN、ネイ）によって索引付けされたルートテーブルエントリがすでにあるかどうかをチェックします。
If no such entry exists:
そのようなエントリが存在しない場合
* if the update is unfeasible, it MAY be ignored;
* 更新が実行不可能な場合は、無視されます。
* if the metric is infinite (the update is a retraction of a route we do not know about), the update is ignored;
* メトリックが無限大の場合（アップデートは私たちが知らない経路の後退です）、更新は無視されます。
* otherwise, a new entry is created in the route table, indexed by (prefix, plen, neigh), with source equal to (prefix, plen, router-id), seqno equal to seqno, and an advertised metric equal to the metric carried by the update.
* それ以外の場合、新しいエントリは、（プレフィックス、PLEN、NEIH）によって索引付けされたルートテーブルに（プレフィックス、PLEN、NEWH）、SEQNOに等しいSEQNO、および携帯されたメトリックに等しいアドバタイズされたメトリックが作成されます。更新によって。
If such an entry exists:
そのようなエントリが存在する場合
* if the entry is currently selected, the update is unfeasible, and the router-id of the update is equal to the router-id of the entry, then the update MAY be ignored;
* エントリが現在選択されている場合、更新プログラムは実行不可能であり、更新のルータIDはエントリのルータIDと等しく、更新は無視されます。
* otherwise, the entry's sequence number, advertised metric, metric, and router-id are updated, and if the advertised metric is not infinite, the route's expiry timer is reset to a small multiple of the interval value included in the update (see "Route Expiry time" in Appendix B for suggested values). If the update is unfeasible, then the (now unfeasible) entry MUST be immediately unselected. If the update caused the router-id of the entry to change, an update (possibly a retraction) MUST be sent in a timely manner as described in Section 3.7.2.
* それ以外の場合は、エントリのシーケンス番号、アドバタイズされたメトリック、メトリック、およびルーターIDが更新され、アドバタイズされたメトリックが無限大の場合、ルートの有効期限タイマーは更新に含まれる間隔値の小数にリセットされます（ルートを参照）。推奨値については付録Bの有効期限。アップデートが実行不可能な場合は、（現在実行不可能な）エントリをすぐに選択されていなければなりません。更新がエントリのルータIDを変更すると、セクション3.7.2で説明されているように、更新（おそらく後退）をタイムリーに送信する必要があります。
Note that the route table may contain unfeasible routes, either because they were created by an unfeasible update or due to a metric fluctuation. Such routes are never selected, since they are not known to be loop-free. Should all the feasible routes become unusable, however, the unfeasible routes can be made feasible and therefore possible to select by sending requests along them (see Section 3.8.2).
ルートテーブルには、実行不可能なアップデートによって作成されたため、またはメートルメートルの変動が原因で発生するため、実行可能なルートを含めることができます。そのような経路は、ループフリーであることが知られていないため、決して選択されません。実行可能なすべてのルートが使用不可能になる場合は、実行不可能なルートを実行でき、したがってそれらに沿って要求を送信することによって選択することが可能です（セクション3.8.2を参照）。
When a route's expiry timer triggers, the behaviour depends on whether the route's metric is finite. If the metric is finite, it is set to infinity and the expiry timer is reset. If the metric is already infinite, the route is flushed from the route table.
ルートの有効期限タイマーがトリガーされると、ルートのメトリックが有限かどうかによって異なります。メトリックが有限の場合は、Infinityに設定され、有効期限タイマーがリセットされます。メトリックが既に無限である場合、ルートはルートテーブルからフラッシュされます。
After the route table is updated, the route selection procedure (Section 3.6) is run.
ルートテーブルが更新された後、ルート選択手順（セクション3.6）が実行されます。
When a prefix P is retracted (because all routes are unfeasible or have an infinite metric, whether due to the expiry timer or for other reasons), and a shorter prefix P' that covers P is reachable, P' cannot in general be used for routing packets destined to P without running the risk of creating a routing loop (Section 2.8).
プレフィックスPが引き込まれると（すべての経路が実行不可能であるか、有効期限のあるタイマーの場合、または他の理由で無限のメトリックがあるため）、およびPをカバーする短いプレフィックスP 'が到達可能であるため、一般に使用できません。ルーティングループを作成するリスクを実行せずにP宛てのルーティングパケットをルーティングします（セクション2.8）。
To avoid this issue, whenever a prefix P is retracted, a route table entry with infinite metric is maintained as described in Section 3.5.3. As long as this entry is maintained, packets destined to an address within P MUST NOT be forwarded by following a route for a shorter prefix. This entry is removed as soon as a finite-metric update for prefix P is received and the resulting route selected. If no such update is forthcoming, the infinite metric entry SHOULD be maintained at least until it is guaranteed that no neighbour has selected the current node as next hop for prefix P. This can be achieved by either:
この問題を回避するために、接頭辞Pが引き込まれるたびに、Infiniteメトリックを持つルートテーブルエントリはセクション3.5.3で説明されているように維持されます。このエントリが維持されている限り、P内のアドレス宛てのパケットは、短いプレフィックスのルートに従って転送されてはなりません。このエントリは、プレフィックスPの有限メトリック更新が受信され、結果のルートが選択されたらすぐに削除されます。そのような更新が最初にある場合、無限のメトリックエントリは少なくともネイバーがプレフィックスPのネクストホップとして現在のノードを選択していないことが保証されるまで維持される必要があります。これは次のいずれかで実現できます。
* waiting until the route's expiry timer has expired (Section 3.5.3); or
* ルートの有効期限が期限切れになるまで待っている（セクション3.5.3）。または
* sending a retraction with an acknowledgment request (Section 3.3) to every reachable neighbour that has not explicitly retracted prefix P, and waiting for all acknowledgments.
* プレフィックスPを明示的に後退させず、すべての確認応答を待っていないすべての到達可能な隣接に遡及依頼（セクション3.3）に到着を送信します。
The former option is simpler and ensures that, at that point, any routes for prefix P pointing at the current node have expired. However, since the expiry time can be as high as a few minutes, doing that prevents automatic aggregation by creating spurious black-holes for aggregated routes. The latter option is RECOMMENDED as it dramatically reduces the time for which a prefix is unreachable in the presence of aggregated routes.
前のオプションはより単純であり、その時点で、現在のノードを指すプレフィックスPのためのルートが期限切れになっていることを保証します。しかし、有効期限は数分ほど高くなる可能性があるため、集約経路のためのスプリアスブラックホールを作成することによって自動集約を防ぎます。後者のオプションは、集約されたルートの存在下でプレフィックスが到達できない時間を劇的に短縮するためです。
Route selection is the process by which a single route for a given prefix is selected to be used for forwarding packets and to be re-advertised to a node's neighbours.
ルート選択は、与えられたプレフィックスの単一経路がパケットの転送に使用され、ノードの隣接者に再アドバタイズされるように選択されるプロセスです。
Babel is designed to allow flexible route selection policies. As far as the algorithm's correctness is concerned, the route selection policy MUST only satisfy the following properties:
Babelは柔軟な経路選択ポリシーを可能にするように設計されています。アルゴリズムの正当性に関する限り、ルート選択ポリシーは次のプロパティを満たすだけでよい。
* a route with infinite metric (a retracted route) is never selected;
* 無限メトリック（退避経路）を持つ経路が選択されていません。
* an unfeasible route is never selected.
* 実行不可能なルートが選択されません。
Babel nodes using different route selection strategies will interoperate and will not create routing loops as long as these two properties hold.
さまざまなルート選択戦略を使用したBabelノードは、相互運用し、これら2つのプロパティが保持されている限り、ルーティングループを作成しません。
Route selection MUST NOT take seqnos into account: a route MUST NOT be preferred just because it carries a higher (more recent) seqno. Doing otherwise would cause route oscillation while a new seqno propagates across the network, and might create persistent black-holes if the metric being used is not left-distributive (Section 3.5.2).
ルート選択はSEQNOを考慮に入れるべきではありません。それ以外のことをすると、新しいseqnoがネットワーク全体を伝播している間、ルートの発振を引き起こし、使用されているメトリックが残っていない場合は持続的なブラックホールを作成することがあります（セクション3.5.2）。
The obvious route selection strategy is to pick, for every destination, the feasible route with minimal metric. When all metrics are stable, this approach ensures convergence to a tree of shortest paths (assuming that the metric is left-distributive, see Section 3.5.2). There are two reasons, however, why this strategy may lead to instability in the presence of continuously varying metrics. First, if two parallel routes oscillate around a common value, then the smallest metric strategy will keep switching between the two. Second, the selection of a route increases congestion along it, which might increase packet loss, which in turn could cause its metric to increase; this kind of feedback loop is prone to causing persistent oscillations.
明らかな経路選択戦略は、最小限のメトリックを持つ実行可能なルートをすべての宛先で選択することです。すべてのメトリックが安定している場合、このアプローチは最短パスのツリーへの収束を保証します（メトリックが残っていると仮定すると、セクション3.5.2を参照）。しかしながら、この戦略が継続的に変化する測定基準の存在下で不安定性をもたらすかもしれない理由は2つの理由がある。まず、2つの並列ルートが共通の値の周りを振動すると、最小のメトリック戦略は2つの間の切り替えを続けます。第二に、経路の選択はそれに沿って輻輳を増加させ、それはパケット損失を増加させるかもしれず、それはそのメトリックが増加する可能性がある。この種のフィードバックループは持続的な振動を引き起こす傾向があります。
In order to limit these kinds of instabilities, a route selection strategy SHOULD include some form of hysteresis, i.e., be sensitive to a route's history: the strategy should only switch from the currently selected route to a different route if the latter has been consistently good for some period of time. A RECOMMENDED hysteresis algorithm is given in Appendix A.3.
これらの種類の不安定性を制限するためには、経路選択戦略には何らかの形のヒステリシス、すなわちルートの履歴に敏感であるべきです。しばらくの間。推奨ヒステリシスアルゴリズムは付録A.3に記載されています。
After the route selection procedure is run, triggered updates (Section 3.7.2) and requests (Section 3.8.2) are sent.
ルート選択手順が実行された後、トリガされた更新（セクション3.7.2）と要求（セクション3.8.2）が送信されます。
A Babel speaker advertises to its neighbours its set of selected routes. Normally, this is done by sending one or more multicast packets containing Update TLVs on all of its connected interfaces; however, on link technologies where multicast is significantly more expensive than unicast, a node MAY choose to send multiple copies of updates in unicast packets, especially when the number of neighbours is small.
ベイヤースピーカーは、その隣人にその選択されたルートのセットに広がっています。通常、これは、接続されているすべてのインターフェイスに更新TLVを含む1つ以上のマルチキャストパケットを送信することによって行われます。ただし、マルチキャストがユニキャストよりもかなり高価なリンクテクノロジでは、ノードはユニキャストパケットに複数の更新コピーを送信することを選択できます。特に、隣接者数が少ない場合
Additionally, in order to ensure that any black-holes are reliably cleared in a timely manner, a Babel node may send retractions (updates with an infinite metric) for any recently retracted prefixes.
さらに、ブラックホールが確実にタイムリーにクリアされるようにするために、ベイビルノードは、最近退避されたプレフィックスに対して格納（無限メトリックを有する更新）を送信することができる。
If an update is for a route injected into the Babel domain by the local node (e.g., it carries the address of a local interface, the prefix of a directly attached network, or a prefix redistributed from a different routing protocol), the router-id is set to the local node's router-id, the metric is set to some arbitrary finite value (typically 0), and the seqno is set to the local router's sequence number.
更新がローカルノードによってBabelドメインに挿入された経路のためのものである場合（例えば、ローカルインターフェースのアドレス、直接接続されているネットワークのプレフィックス、または異なるルーティングプロトコルから再配布されたプレフィックス）、ルータ - IDはローカルノードのルータIDに設定され、メトリックは任意の有限値（通常は0）に設定され、SEQNOはローカルルータのシーケンス番号に設定されます。
If an update is for a route learnt from another Babel speaker, the router-id and sequence number are copied from the route table entry, and the metric is computed as specified in Section 3.5.2.
更新が別のBabelスピーカーから学習されたルートの場合、ルータIDとシーケンス番号はルートテーブルエントリからコピーされ、メトリックはセクション3.5.2で指定されているように計算されます。
Every Babel speaker MUST advertise each of its selected routes on every interface, at least once every Update interval. Since Babel doesn't suffer from routing loops (there is no "counting to infinity") and relies heavily on triggered updates (Section 3.7.2), this full dump only needs to happen infrequently (see Appendix B for suggested intervals).
すべてのBabelスピーカーは、少なくとも一度更新間隔ごとに、選択したすべてのルートをすべてのインターフェイスに宣伝する必要があります。Babelはルーティングループに悩まされていないため、トリガーされたアップデートに大きく依存しています（セクション3.7.2）、このフルダンプはめったに起こる必要があります（推奨間隔については付録Bを参照）。
In addition to periodic routing updates, a Babel speaker sends unscheduled, or triggered, updates in order to inform its neighbours of a significant change in the network topology.
定期的なルーティングアップデートに加えて、Babelスピーカーは、ネットワークトポロジの大幅な変更の隣接者に通知するために、予定外の、またはトリガされた更新を送信します。
A change of router-id for the selected route to a given prefix may be indicative of a routing loop in formation; hence, whenever it changes the selected router-id for a given destination, a node MUST send an update as an urgent TLV (as defined in Section 3.1). Additionally, it SHOULD make a reasonable attempt at ensuring that all reachable neighbours receive this update.
特定のプレフィックスへの選択された経路に対するルータIDの変更は、形成におけるルーティングループを示すことができる。したがって、特定の宛先の選択されたルータIDを変更するたびに、ノードは更新を緊急TLVとして送信する必要があります（セクション3.1で定義されているように）。さらに、すべての到達可能な隣人がこのアップデートを受け取ることを確認することを合理的な試みをしてください。
There are two strategies for ensuring that. If the number of neighbours is small, then it is reasonable to send the update together with an acknowledgment request; the update is resent until all neighbours have acknowledged the packet, up to some number of times. If the number of neighbours is large, however, requesting acknowledgments from all of them might cause a non-negligible amount of network traffic; in that case, it may be preferable to simply repeat the update some reasonable number of times (say, 3 for wireless and 2 for wired links). The number of copies MUST NOT exceed 5, and the copies SHOULD be separated by a small delay, as described in Section 3.1.
それを確実にするための2つの戦略があります。隣接者数が小さい場合は、確認応答要求と一緒にアップデートを送信することが合理的です。更新は、すべての隣接者がパケットを何度も何回確認したまで再送されます。ただし、隣接者数が多い場合は、すべての承認を要求すると、無視できないネットワークトラフィックが発生する可能性があります。その場合、単に更新されたものを繰り返すことは、妥当な回数（例えば、ワイヤレスのための3つ、有線リンクのための2つ）を繰り返すことが好ましいかもしれない。コピー数は5を超えてはならず、セクション3.1で説明されているように、コピーは小さな遅延で区切る必要があります。
A route retraction is somewhat less worrying: if the route retraction doesn't reach all neighbours, a black-hole might be created, which, unlike a routing loop, does not endanger the integrity of the network. When a route is retracted, a node SHOULD send a triggered update and SHOULD make a reasonable attempt at ensuring that all neighbours receive this retraction.
ルートの後退はやや心配しています。ルートの後退がすべての隣人に到達しない場合、ブラックホールが作成され、ルーティングループとは異なり、ネットワークの完全性を危険にさらさない。経路が後退すると、ノードはトリガされた更新を送信する必要があり、すべての隣人がこの退避を受けることを確実にするために合理的な試みをする必要があります。
Finally, a node MAY send a triggered update when the metric for a given prefix changes in a significant manner, due to a received update, because a link's cost has changed or because a different next hop has been selected. A node SHOULD NOT send triggered updates for other reasons, such as when there is a minor fluctuation in a route's metric, when the selected next hop changes without inducing a significant change to the route's metric, or to propagate a new sequence number (except to satisfy a request, as specified in Section 3.8).
最後に、リンクのコストが変更されたため、または異なるネクストホップが選択されているため、受信された更新のために、与えられたプレフィックスのメトリックが大きな方法で変化すると、ノードがトリガされた更新を送信することができます。ルートのメトリックに大きな変更を招くことなく、または新しいシーケンス番号を伝播させることなく、選択されたネクストホップが変更された場合、ノードがルートのメトリックに軽微な変動がある場合など、ノードは他の理由でトリガされたアップデートを送信しないでください。セクション3.8で指定されているように、要求を満たします。
Before sending an update (prefix, plen, router-id, seqno, metric) with finite metric (i.e., not a route retraction), a Babel node updates the feasibility distance maintained in the source table. This is done as follows.
有限メトリック（すなわち、ルート後退ではない）を有する更新（プレフィックス、プレス、ルータID、SEQNO、メトリック）を送信する前に、Babelノードは、ソーステーブル内に維持されている実現可能性距離を更新する。これは次のようにして行われます。
If no entry indexed by (prefix, plen, router-id) exists in the source table, then one is created with value (prefix, plen, router-id, seqno, metric).
（プレフィックス、PLEN、Router-ID）がソース表に存在しないエントリが存在しない場合は、値（プレフィックス、PLEN、ROUTER-ID、SEQNO、メトリック）で作成されます。
If an entry (prefix, plen, router-id, seqno', metric') exists, then it is updated as follows:
エントリ（プレフィックス、PLEN、Router-ID、SEQNO '、METRIC'）が存在する場合、次のように更新されます。
* if seqno > seqno', then seqno' := seqno, metric' := metric;
* seqno> seqno 'の場合、seqno'：= seqno、メトリック '：=メトリック;
* if seqno = seqno' and metric' > metric, then metric' := metric;
* seqno = seqno 'とmetric'> metric 'の場合、メトリック'：=メトリック。
* otherwise, nothing needs to be done.
* それ以外の場合は、何もしていません。
The garbage-collection timer for the entry is then reset. Note that the feasibility distance is not updated and the garbage-collection timer is not reset when a retraction (an update with infinite metric) is sent.
その後、エントリのガベージコレクションタイマーがリセットされます。なお、実現可能性距離は更新されず、退避（無限メトリックの更新）が送信されたときにガベージコレクションタイマがリセットされないことに注意してください。
When the garbage-collection timer expires, the entry is removed from the source table.
ガベージコレクションタイマが期限切れになると、エントリはソーステーブルから削除されます。
When running over a transitive, symmetric link technology, e.g., a point-to-point link or a wired LAN technology such as Ethernet, a Babel node SHOULD use an optimisation known as split horizon. When split horizon is used on a given interface, a routing update for prefix P is not sent on the particular interface over which the selected route towards prefix P was learnt.
推移的な対称リンク技術、例えば、イーサネットなどのポイントツーポイントリンクまたは有線LAN技術を越えて実行すると、ベイビルノードはスプリットホライズンとして知られる最適化を使用する必要があります。特定のインタフェースでスプリットホライズンが使用されている場合、プレフィックスPのルーティングアップデートは、プレフィックスPへの選択されたルートが学習された特定のインターフェイスでは送信されません。
Split horizon SHOULD NOT be applied to an interface unless the interface is known to be symmetric and transitive; in particular, split horizon is not applicable to decentralised wireless link technologies (e.g., IEEE 802.11 in ad hoc mode) when routing updates are sent over multicast.
インタフェースが対称的かつ推移的であることがわからない限り、スプリットホライズンはインターフェイスに適用しないでください。特に、ルーティング更新がマルチキャストを介して送信されるときに、分割地平線は分散無線リンク技術（例えば、アドホックモードのIEEE802.11）には適用されない。
In normal operation, a node's route table is populated by the regular and triggered updates sent by its neighbours. Under some circumstances, however, a node sends explicit requests in order to cause a resynchronisation with the source after a mobility event or to prevent a route from spuriously expiring.
通常の操作では、ノードのルートテーブルには、その隣接者によって送信された通常の更新プログラムが入力されます。ただし、状況によっては、モビリティイベントの後にソースとの再同期を発生させるため、またはルートが失効するのを防ぐために、ノードは明示的な要求を送信します。
The Babel protocol provides two kinds of explicit requests: route requests, which simply request an update for a given prefix, and seqno requests, which request an update for a given prefix with a specific sequence number. The former are never forwarded; the latter are forwarded if they cannot be satisfied by the receiver.
Babelプロトコルは、特定の手形番号を指定して特定のシーケンス番号の更新を要求する特定のプレフィックスのアップデートを単純に要求するルート要求、およびseqno要求を要求します。前者は決して転送されません。後者は受信機によって満たされない場合に転送されます。
Upon receiving a request, a node either forwards the request or sends an update in reply to the request, as described in the following sections. If this causes an update to be sent, the update is either sent to a multicast address on the interface on which the request was received, or to the unicast address of the neighbour that sent the request.
要求を受信すると、以下のセクションで説明するように、要求を転送するか、要求に応答して更新を送信するか。これにより更新が送信されると、更新は、要求が受信されたインターフェイス上のマルチキャストアドレス、または要求を送信したネイバーのユニキャストアドレスに送信されます。
The exact behaviour is different for route requests and seqno requests.
正確な動作は、経路要求およびSEQNO要求によって異なります。
When a node receives a route request for a given prefix, it checks its route table for a selected route to this exact prefix. If such a route exists, it MUST send an update (over unicast or over multicast); if such a route does not exist, it MUST send a retraction for that prefix.
ノードが特定のプレフィックスのルート要求を受信すると、この正確なプレフィックスへの選択されたルートのルートテーブルをチェックします。そのようなルートが存在する場合は、更新（ユニキャストまたはオーバーマルチキャスト）を送信する必要があります。そのようなルートが存在しない場合は、そのプレフィックスの後退を送信する必要があります。
When a node receives a wildcard route request, it SHOULD send a full route table dump. Full route dumps SHOULD be rate-limited, especially if they are sent over multicast.
ノードがワイルドカードルート要求を受信すると、フルルートテーブルダンプを送信する必要があります。フルルートダンプは、特にマルチキャストを介して送信されている場合は、rate-limitsでなければなりません。
When a node receives a seqno request for a given router-id and sequence number, it checks whether its route table contains a selected entry for that prefix. If a selected route for the given prefix exists and has finite metric, and either the router-ids are different or the router-ids are equal and the entry's sequence number is no smaller (modulo 2^(16)) than the requested sequence number, the node MUST send an update for the given prefix. If the router-ids match, but the requested seqno is larger (modulo 2^(16)) than the route entry's, the node compares the router-id against its own router-id. If the router-id is its own, then it increases its sequence number by 1 (modulo 2^(16)) and sends an update. A node MUST NOT increase its sequence number by more than 1 in reaction to a single seqno request.
ノードが特定のルータIDとシーケンス番号に対してSEQNO要求を受信すると、そのルートテーブルにその接頭辞の選択されたエントリが含まれているかどうかを確認します。指定されたプレフィックスの選択されたルートが存在し、有限のメトリックがある場合、およびRouter-IDが異なるか、またはRouter-IDが等しく、要求されたシーケンス番号よりも小さい（モジュロ2 ^（16））のいずれかが必要です。、ノードは与えられたプレフィックスの更新を送信する必要があります。ルータIDが一致しているが、要求されたSEQNOが経路エントリよりも大きい（モジュロ2 ^（16））、そのノードは、ルータIDとそれ自身のルータIDとを比較します。ルータIDが独自の場合は、シーケンス番号が1だけ増加し（Modulo 2 ^（16））、更新を送信します。ノードは、単一のSEQNO要求に反応して、そのシーケンス番号を1以上増加させてはなりません。
Otherwise, if the requested router-id is not its own, the received node consults the Hop Count field of the request. If the hop count is 2 or more, and the node is advertising the prefix to its neighbours, the node selects a neighbour to forward the request to as follows:
それ以外の場合、要求されたルータIDがそれ自身ではない場合、受信ノードは要求のホップカウントフィールドを調べます。ホップ数が2以上で、ノードがその近隣にプレフィックスをアドバタイズしている場合、ノードは次のように要求を転送するためのネイバーを選択します。
* if the node has one or more feasible routes towards the requested prefix with a next hop that is not the requesting node, then the node MUST forward the request to the next hop of one such route;
* ノードが要求されているノードではないネクストホップを使用して要求されたプレフィックスに向かって1つ以上の実現可能なルートを持つ場合、ノードはそのようなルートの1つの次のホップに要求を転送する必要があります。
* otherwise, if the node has one or more (not feasible) routes to the requested prefix with a next hop that is not the requesting node, then the node SHOULD forward the request to the next hop of one such route.
* それ以外の場合、ノードが要求されているノードではないネクストホップを使用して要求されたプレフィックスに1つ以上のルートを持つ場合、そのノードはそのようなルートの次のホップに要求を転送する必要があります。
In order to actually forward the request, the node decrements the hop count and sends the request in a unicast packet destined to the selected neighbour. The forwarded request SHOULD be sent as an urgent TLV (as defined in Section 3.1).
要求を実際に転送するために、ノードはホップ数を縮小し、選択されたネイバー宛てのユニキャストパケットで要求を送信します。転送された要求は緊急のTLVとして送信されます（セクション3.1で定義されているように）。
A node SHOULD maintain a list of recently forwarded seqno requests and forward the reply (an update with a seqno sufficiently large to satisfy the request) as an urgent TLV (as defined in Section 3.1). A node SHOULD compare every incoming seqno request against its list of recently forwarded seqno requests and avoid forwarding the request if it is redundant (i.e., if the node has recently sent a request with the same prefix, router-id, and a seqno that is not smaller modulo 2^(16)).
ノードは最近転送されたSEQNO要求のリストを維持し、返信を維持する必要があります（リクエストを満たすためには、要求を満たすために十分に大きい更新）は（セクション3.1で定義されているように）。ノードは、その最近転送されたSEQNO要求のリストに対してすべての着信SEQNO要求を比較し、それが冗長である場合（すなわち、ノードが最近同じ接頭辞、router-id、およびseqnoを持つ要求を送信した場合）要求を転送しないようにする必要があります。より小さなモジュロ2 ^（16））。
Since the request-forwarding mechanism does not necessarily obey the feasibility condition, it may get caught in routing loops; hence, requests carry a hop count to limit the time during which they remain in the network. However, since requests are only ever forwarded as unicast packets, the initial hop count need not be kept particularly low, and performing an expanding horizon search is not necessary. A single request MUST NOT be duplicated: it MUST NOT be forwarded to a multicast address, and it MUST NOT be forwarded to multiple neighbours. However, if a seqno request is resent by its originator, the subsequent copies may be forwarded to a different neighbour than the initial one.
リクエスト転送メカニズムは必ずしも実現可能性状態に従うわけではないので、ルーティングループに巻き込まれる可能性があります。したがって、要求はホップ数を運び、それらがネットワーク内に残る時間を制限する。ただし、リクエストはユニキャストパケットとしてのみ転送されるため、初期ホップ数を特に低く保つ必要はなく、地平線の拡大を行う必要はありません。単一の要求を複製してはいけません。マルチキャストアドレスに転送しないでください。マルチネイバーに転送しないでください。ただし、SEQNO要求がその発信者によって憤慨している場合は、後続のコピーを最初のコピーとは異なるネイバーに転送できます。
A Babel node MAY send a route or seqno request at any time to a multicast or a unicast address; there is only one case when originating requests is required (Section 3.8.2.1).
Babelノードは、マルチキャストまたはユニキャストアドレスにいつでもルートまたはSEQNO要求を送信することができます。発信要求が必要な場合は1つだけです（セクション3.8.2.1）。
When a route is retracted or expires, a Babel node usually switches to another feasible route for the same prefix. It may be the case, however, that no such routes are available.
経路が後退または期限切れになると、ベイベルノードは通常、同じ接頭辞のための別の実現可能な経路に切り替わります。ただし、そのようなルートが利用できない場合があります。
A node that has lost all feasible routes to a given destination but still has unexpired unfeasible routes to that destination MUST send a seqno request; if it doesn't have any such routes, it MAY still send a seqno request. The router-id of the request is set to the router-id of the route that it has just lost, and the requested seqno is the value contained in the source table plus 1. The request carries a hop count, which is used as a last-resort mechanism to ensure that it eventually vanishes from the network; it MAY be set to any value that is larger than the diameter of the network (64 is a suitable default value).
特定の宛先に実現可能なルートをすべて失ったがそれでもその宛先への実行されていない実行可能なルートがあるノードは、SEQNO要求を送信する必要があります。そのようなルートがない場合は、seqno要求を送信することがあります。要求のルータIDは、紛失したルートのルータIDに設定され、要求されたSEQNOはソース表Plus 1に含まれている値です。それが最終的にネットワークから消滅することを確実にするための最新のリゾートメカニズム。ネットワークの直径よりも大きい任意の値に設定されてもよい（64は適切なデフォルト値です）。
If the node has any (unfeasible) routes to the requested destination, then it MUST send the request to at least one of the next-hop neighbours that advertised these routes, and SHOULD send it to all of them; in any case, it MAY send the request to any other neighbours, whether they advertise a route to the requested destination or not. A simple implementation strategy is therefore to unconditionally multicast the request over all interfaces.
ノードに要求された宛先への任意の（実行不可能な）ルートがある場合は、これらのルートをアドバタイズしたネクストホップネイバーの少なくとも1つに要求を送信し、それらのすべてに送信する必要があります。いずれにせよ、それは要求された宛先へのルートをアドバタイズするかどうかにかかわらず、他の隣接者に要求を送信することができる。したがって、単純な実装戦略は無条件にすべてのインターフェイスを介して要求をマルチキャストすることです。
Similar requests will be sent by other nodes that are affected by the route's loss. If the network is still connected, and assuming no packet loss, then at least one of these requests will be forwarded to the source, resulting in a route being advertised with a new sequence number. (Due to duplicate suppression, only a small number of such requests are expected to actually reach the source.)
同様の要求は、ルートの損失の影響を受ける他のノードによって送信されます。ネットワークがまだ接続されている場合、およびパケット損失がないと仮定すると、これらの要求のうちの少なくとも1つがソースに転送され、その結果、新しいシーケンス番号でアドバタイズされます。（重複抑制のため、このような要求の数だけが実際にソースに到達すると予想されます。）
In order to compensate for packet loss, a node SHOULD repeat such a request a small number of times if no route becomes feasible within a short time (see "Request timeout" in Appendix B for suggested values). In the presence of heavy packet loss, however, all such requests might be lost; in that case, the mechanism in the next section will eventually ensure that a new seqno is received.
パケット損失を補償するために、短時間内に経路が不可能になると、そのような要求を少数回繰り返すべきである（推奨値については付録Bの「要求タイムアウト」を参照）。しかしながら、重いパケット損失の存在下では、そのような要求はすべて失われる可能性があります。その場合、次のセクションのメカニズムは最終的に新しいSEQNOを受信することを保証します。
When a route's metric increases, a node might receive an unfeasible update for a route that it has currently selected. As specified in Section 3.5.1, the receiving node will either ignore the update or unselect the route.
ルートのメトリックが増加すると、ノードは現在選択されているルートに対して実行不可能なアップデートを受け取ることがあります。セクション3.5.1で指定されているように、受信ノードは更新を無視するか、ルートの選択を解除します。
In order to keep routes from spuriously expiring because they have become unfeasible, a node SHOULD send a unicast seqno request when it receives an unfeasible update for a route that is currently selected. The requested sequence number is computed from the source table as in Section 3.8.2.1.
ルートが実行不可能になっているため、ルートが失効し続けるために、現在選択されているルートの実行不可能なアップデートを受信したときにノードはユニキャストSEQNO要求を送信する必要があります。要求されたシーケンス番号は、セクション3.8.2.1のようにソース表から計算されます。
Additionally, since metric computation does not necessarily coincide with the delay in propagating updates, a node might receive an unfeasible update from a currently unselected neighbour that is preferable to the currently selected route (e.g., because it has a much smaller metric); in that case, the node SHOULD send a unicast seqno request to the neighbour that advertised the preferable update.
さらに、メトリック計算は必ずしも伝播された更新の遅延と一致しないので、ノードは現在選択されている経路よりも好ましい現在選択されている隣接から実行不可能な更新を受け取ることができる（例えば、それははるかに小さいメトリックを有するから）。その場合、ノードは好ましい更新をアドバタイズしたネイバーにユニキャストSEQNO要求を送信する必要があります。
In normal operation, a route's expiry timer never triggers: since a route's hold time is computed from an explicit interval included in Update TLVs, a new update (possibly a retraction) should arrive in time to prevent a route from expiring.
通常の操作では、ルートの有効期限がトリガされません。ルートのホールドタイムはアップデートTLVSに含まれる明示的な間隔から計算されているため、ルートが期限切れになるのを防ぐために新しいアップデート（おそらく後退）が時間内に到着する必要があります。
In the presence of packet loss, however, it may be the case that no update is successfully received for an extended period of time, causing a route to expire. In order to avoid such spurious expiry, shortly before a selected route expires, a Babel node SHOULD send a unicast route request to the neighbour that advertised this route; since nodes always send either updates or retractions in response to non-wildcard route requests (Section 3.8.1.1), this will usually result in the route being either refreshed or retracted.
しかしながら、パケット損失の存在下では、更新が長期間にわたって正常に受信されない場合であり得、経路が期限切れになる。選択された経路が期限切れになる直後にこのようなスプリアスの有効期限を回避するために、Babelノードはこのルートをアドバタイズしたネイバーにユニキャストルート要求を送信する必要があります。ノードは常にワイルドカード以外のルート要求に応答して常に更新または後退を送信する（セクション3.8.1.1）、これにより、ルートが更新または後退していることがあります。
A Babel packet MUST be sent as the body of a UDP datagram, with network-layer hop count set to 1, destined to a well-known multicast address or to a unicast address, over IPv4 or IPv6; in the case of IPv6, these addresses are link-local. Both the source and destination UDP port are set to a well-known port number. A Babel packet MUST be silently ignored unless its source address is either a link-local IPv6 address or an IPv4 address belonging to the local network, and its source port is the well-known Babel port. It MAY be silently ignored if its destination address is a global IPv6 address.
Babelパケットは、IPv4またはIPv6を介して、ネットワーク層ホップ数を1に設定し、ネットワーク層ホップ数を1に設定し、1に設定されている必要があります。IPv6の場合、これらのアドレスはリンクローカルです。ソースおよび宛先UDPポートの両方が、よく知られているポート番号に設定されています。そのソースアドレスがローカルネットワークに属するリンクローカルIPv6アドレスまたはIPv4アドレスのいずれかでない限り、Babelパケットは静止して無視されなければならず、その送信元ポートは有名なBabelポートです。宛先アドレスがグローバルIPv6アドレスである場合は、静かに無視される可能性があります。
In order to minimise the number of packets being sent while avoiding lower-layer fragmentation, a Babel node SHOULD maximise the size of the packets it sends, up to the outgoing interface's MTU adjusted for lower-layer headers (28 octets for UDP over IPv4, 48 octets for UDP over IPv6). It MUST NOT send packets larger than the attached interface's MTU adjusted for lower-layer headers or 512 octets, whichever is larger, but not exceeding 2^(16) - 1 adjusted for lower-layer headers. Every Babel speaker MUST be able to receive packets that are as large as any attached interface's MTU adjusted for lower-layer headers or 512 octets, whichever is larger. Babel packets MUST NOT be sent in IPv6 jumbograms [RFC2675].
下位層の断片化を回避しながら送信されているパケットの数を最小限に抑えるために、Babelノードは、それが送信するパケットのサイズを最大化する必要があります（IPv4上のUDPのための28オクテット）。IPv6を介したUDPの48オクテット）。下位レイヤーのヘッダーまたは512オクテットに調整された添付のインターフェースのMTUよりも大きいパケットを送信してはいけません。どちらか大きい方が、2 ^（16） - 1を超えない、下位レイヤーのヘッダーで調整されていません。すべてのBabelスピーカーは、下位のヘッダーまたは512オクテットのどちらか大きい方が、添付のインターフェースのMTUと同じくらい大きいパケットを受け取ることができなければなりません。BabelパケットはIPv6のザンバグラム[RFC2675]で送信してはいけません。
All multi-octet fields that represent integers are encoded with the most significant octet first (in Big-Endian format [IEN137], also called network order). The base protocol only carries unsigned values; if an extension needs to carry signed values, it will need to specify their encoding (e.g., two's complement).
整数を表すすべてのマルチオクテットフィールドは、最初に最も重要なオクテットでエンコードされます（Big-Endian Format [IEN137]、ネットワーク順序とも呼ばれます）。基本プロトコルは符号なし値のみを担当します。拡張子が符号付き値を伝送する必要がある場合は、それらのエンコード（例えば、2の補数）を指定する必要があります。
Relative times are carried as 16-bit values specifying a number of centiseconds (hundredths of a second). This allows times up to roughly 11 minutes with a granularity of 10 ms, which should cover all reasonable applications of Babel (see also Appendix B).
相対時間は、センチ秒を指定する16ビット値（100分の1秒）として運ばれます。これにより、10ミリ秒の粒度で約11分まで約11分、これはBabelのすべての合理的なアプリケーションをカバーする必要があります（付録Bも参照）。
A router-id is an arbitrary 8-octet value. A router-id MUST NOT consist of either all binary zeroes (0000000000000000 hexadecimal) or all binary ones (FFFFFFFFFFFFFFFF hexadecimal).
ルータIDは任意の8オクテット値です。router-idは、すべてのバイナリゼロ（00000000000000 00000000000000 16進数）またはすべてのバイナリ1（FFFFFFFFFFFFFFF 16進数）で構成されてはなりません。
Since the bulk of the protocol is taken by addresses, multiple ways of encoding addresses are defined. Additionally, within Update TLVs a common subnet prefix may be omitted when multiple addresses are sent in a single packet -- this is known as address compression (Section 4.6.9).
プロトコルの大部分はアドレスによって取られるので、アドレスの複数の方法が定義されています。さらに、アップデートTLVS内では、複数のアドレスが単一のパケットで送信されたときに共通のサブネットプレフィックスを省略することができます。これはアドレス圧縮として知られています（セクション4.6.9）。
Address encodings (AEs):
アドレスエンコーディング（AES）：
AE 0: Wildcard address. The value is 0 octets long.
AE 0：ワイルドカードアドレス。値は0オクテットの長さです。
AE 1: IPv4 address. Compression is allowed. 4 octets or less.
AE 1：IPv4アドレス。圧縮は許可されています。4オクテット以下。
AE 2: IPv6 address. Compression is allowed. 16 octets or less.
AE 2：IPv6アドレス。圧縮は許可されています。16オクテット以下。
AE 3: Link-local IPv6 address. Compression is not allowed. The value is 8 octets long, a prefix of fe80::/64 is implied.
AE 3：Link-Local IPv6アドレス。圧縮は許可されていません。値は8オクテットの長さで、FE80 :: / 64の接頭辞が暗示されます。
The address family associated with an address encoding is either IPv4 or IPv6: it is undefined for AE 0, IPv4 for AE 1, and IPv6 for AEs 2 and 3.
アドレスエンコードに関連付けられているアドレスファミリはIPv4またはIPv6のいずれかです.Ae 0、AE 1のIPv4、およびAES 2と3のIPv6に対して未定義です。
A network prefix is encoded just like a network address, but it is stored in the smallest number of octets that are enough to hold the significant bits (up to the prefix length).
ネットワークプレフィックスはネットワークアドレスと同じようにエンコードされますが、有効ビットを保持するのに十分な最小数のオクテットに格納されます（プレフィックス長まで）。
A Babel packet consists of a 4-octet header, followed by a sequence of TLVs (the packet body), optionally followed by a second sequence of TLVs (the packet trailer). The format is designed to be extensible; see Appendix D for extensibility considerations.
Babelパケットは、4オクテットヘッダ、続いて一連のTLV（パケット本体）、任意選択で第2のシーケンス（パケットトレーラ）で構成されている。フォーマットは拡張可能になるように設計されています。拡張性の考慮事項については付録Dを参照してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic | Version | Body length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Packet Trailer...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
田畑：
Magic The arbitrary but carefully chosen value 42 (decimal); packets with a first octet different from 42 MUST be silently ignored.
任意の任意ですが慎重に選択された値42（10進数）;42とは異なる最初のオクテットを持つパケットは黙って無視されなければなりません。
Version This document specifies version 2 of the Babel protocol. Packets with a second octet different from 2 MUST be silently ignored.
バージョンこのドキュメントはBabelプロトコルのバージョン2を指定します。2つと異なる2番目のオクテットを持つパケットは黙って無視されなければなりません。
Body length The length in octets of the body following the packet header (excluding the Magic, Version, and Body length fields, and excluding the packet trailer).
ボディ長パケットヘッダーに続く本体のオクテットの長さ（マジック、バージョン、およびボディ長フィールドを除く、パケットトレーラを除く）。
Packet Body The packet body; a sequence of TLVs.
パケットボディパケット本体。一連のTLVS
Packet Trailer The packet trailer; another sequence of TLVs.
パケットトレーラーパケットトレーラー。TLVの別のシーケンス
The packet body and trailer are both sequences of TLVs. The packet body is the normal place to store TLVs; the packet trailer only contains specialised TLVs that do not need to be protected by cryptographic security mechanisms. When parsing the trailer, the receiver MUST ignore any TLV unless its definition explicitly states that it is allowed to appear there. Among the TLVs defined in this document, only Pad1 and PadN are allowed in the trailer; since these TLVs are ignored in any case, an implementation MAY silently ignore the packet trailer without even parsing it, unless it implements at least one protocol extension that defines TLVs that are allowed to appear in the trailer.
パケット本体とトレーラは両方ともTLVのシーケンスです。パケット本体はTLVSを保存するための通常の場所です。パケットトレーラは、暗号化セキュリティメカニズムによって保護される必要がない特殊なTLVのみを含みます。トレーラを解析するとき、レシーバは、その定義が明示的にそこに表示されることを明示的に述べない限り、どのTLVを無視する必要があります。この文書で定義されているTLVの中には、TrailerではPAD1とPADNのみが許可されています。これらのTLVはいずれにせよ無視されているので、トレーラに表示されるTLVを定義する少なくとも1つのプロトコル拡張を実装していない限り、パケットトレーラを解析することなく、パケットトレーラを無視することができます。
With the exception of Pad1, all TLVs have the following structure:
PAD1を除いて、すべてのTLVSには次の構造があります。
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 | Length | Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
田畑：
Type The type of the TLV.
TLVの型を入力します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
Payload The TLV payload, which consists of a body and, for selected TLV types, an optional list of sub-TLVs.
ペイロードPayloadは、ボディで構成される、選択されたTLVタイプの場合は、サブTLVのオプションのリストです。
TLVs with an unknown type value MUST be silently ignored.
値が不明のTLVSは黙って無視される必要があります。
Every TLV carries an explicit length in its header; however, most TLVs are self-terminating, in the sense that it is possible to determine the length of the body without reference to the explicit Length field. If a TLV has a self-terminating format, then the space between the natural size of the TLV and the size announced in the Length field may be used to store a sequence of sub-TLVs.
すべてのTLVはそのヘッダーに明示的な長さを伝えます。しかしながら、ほとんどのTLVは、明示的な長さフィールドを参照することなく本体の長さを決定することが可能であるという意味で、自己終了である。TLVが自己終端フォーマットを有する場合、TLVの自然サイズと長さフィールドで発表されたサイズとの間のスペースを使用して、一連のサブTLVを格納することができる。
Sub-TLVs have the same structure as TLVs. With the exception of Pad1, all TLVs have the following structure:
サブTLVSはTLVSと同じ構造を持ちます。PAD1を除いて、すべてのTLVSには次の構造があります。
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 | Length | Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
田畑：
Type The type of the sub-TLV.
サブTLVの型を入力します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
Body The sub-TLV body, the interpretation of which depends on both the type of the sub-TLV and the type of the TLV within which it is embedded.
BODY SUB-TLV本体、解釈は、それが埋め込まれているサブTLVの種類とTLVのタイプの両方に依存します。
The most significant bit of the sub-TLV type (the bit with value 80 hexadecimal), is called the mandatory bit; in other words, sub-TLV types 128 through 255 have the mandatory bit set. This bit indicates how to handle unknown sub-TLVs. If the mandatory bit is not set, then an unknown sub-TLV MUST be silently ignored, and the rest of the TLV is processed normally. If the mandatory bit is set, then the whole enclosing TLV MUST be silently ignored (except for updating the parser state by a Router-Id, Next Hop, or Update TLV, as described in the next section).
サブTLVタイプの最上位ビット（値80の16進数のビット）は必須ビットと呼ばれます。言い換えれば、サブTLVタイプ128から255は必須のビットセットを有する。このビットは、未知のサブTLVを処理する方法を示します。必須ビットが設定されていない場合は、未知のサブTLVを静止して無視しなければならず、TLVの残りの部分は正常に処理されます。必須ビットが設定されている場合、次のセクションで説明されているように、ルータID、ネクストホップ、またはアップデートTLVによってパーサー状態を更新する場合を除いて、除去されたTLV全体を無視する必要があります。
In a large network, the bulk of Babel traffic consists of route updates; hence, some care has been given to encoding them efficiently. The data conceptually contained in an update (Section 3.5) is split into three pieces:
大規模ネットワークでは、Babelトラフィックのバルクはルートアップデートで構成されています。したがって、それらを効率的に符号化するために注意が払われている。更新（3.5項）に概念的に含まれているデータは、3つの部分に分割されています。
* the prefix, seqno, and metric are contained in the Update TLV itself (Section 4.6.9);
* プレフィックス、seqno、およびmetricは、更新TLV自体に含まれています（セクション4.6.9）。
* the router-id is taken from the Router-Id TLV that precedes the Update TLV and may be shared among multiple Update TLVs (Section 4.6.7);
* ルータIDは、更新TLVの前にあるルータID TLVから取得され、複数の更新TLVSの間で共有されることがあります（セクション4.6.7）。
* the next hop is taken either from the source address of the network-layer packet that contains the Babel packet or from an explicit Next Hop TLV (Section 4.6.8).
* ネクストホップは、Babelパケットを含むネットワーク層パケットの送信元アドレスまたは明示的なネクストホップTLVから行われる（セクション4.6.8）。
In addition to the above, an Update TLV can omit a prefix of the prefix being announced, which is then extracted from the preceding Update TLV in the same address family (IPv4 or IPv6). Finally, as a special optimisation for the case when a router-id coincides with the interface-id part of an IPv6 address, the Router-Id TLV itself may be omitted, and the router-id is derived from the low-order bits of the advertised prefix (Section 4.6.9).
上記に加えて、アップデートTLVはアナウンスされているプレフィックスの接頭辞を省略することができ、それは同じアドレスファミリ（IPv4またはIPv6）内の前の更新TLVから抽出されます。最後に、ルータIDがIPv6アドレスのインタフェースID部分と一致した場合の特別な最適化として、ルータID TLV自体を省略し、ルータIDは下位ビットから導出されることがあります。アドバタイズされたプレフィックス（4.6.9項）。
In order to implement these compression techniques, Babel uses a stateful parser: a TLV may refer to data from a previous TLV. The parser state consists of the following pieces of data:
これらの圧縮技術を実装するために、Babelはステートフルパーサを使用します.TLVは前のTLVからのデータを参照することがあります。パーサー状態は、以下のデータで構成されています。
* for each address encoding that allows compression, the current default prefix: this is undefined at the start of the packet and is updated by each Update TLV with the Prefix flag set (Section 4.6.9);
* 圧縮を許可する各アドレスエンコーディングでは、現在のデフォルトのプレフィックス：これはパケットの開始時に未定義であり、プレフィックスフラグセットを使用して各更新TLVによって更新されます（セクション4.6.9）。
* for each address family (IPv4 or IPv6), the current next hop: this is the source address of the enclosing packet for the matching address family at the start of a packet, and it is updated by each Next Hop TLV (Section 4.6.8);
* 各アドレスファミリ（IPv4またはIPv6）について、現在のネクストホップ：これはパケットの開始時に一致するアドレスファミリの囲みパケットの送信元アドレスであり、各ネクストホップTLVによって更新されます（セクション4.6.8）;
* the current router-id: this is undefined at the start of the packet, and it is updated by each Router-Id TLV (Section 4.6.7) and by each Update TLV with Router-Id flag set.
* 現在のルータID：パケットの開始時には未定義であり、各Router-ID TLV（セクション4.6.7）、およびRouter-IDフラグセットを使用して各更新TLVによって更新されます。
Since the parser state must be identical across implementations, it is updated before checking for mandatory sub-TLVs: parsing a TLV MUST update the parser state even if the TLV is otherwise ignored due to an unknown mandatory sub-TLV or for any other reason.
パーサー状態は実装間で同一でなければならないため、必須のSUB-TLVをチェックする前に更新されます。義務的な義務的なサブTLVまたはその他の理由で、TLVが無視された場合でも、TLVの解析はパーサー状態を更新する必要があります。
None of the TLVs that modify the parser state are allowed in the packet trailer; hence, an implementation may choose to use a dedicated stateless parser to parse the packet trailer.
パーサー状態を変更するTLVはどれもパケットトレーラーで許可されていません。したがって、実装は、パケットのトレーラを解析するために専用のステートレスパーサーを使用することを選択できます。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type Set to 0 to indicate a Pad1 TLV.
PAD1 TLVを示すには、0に設定します。
This TLV is silently ignored on reception. It is allowed in the packet trailer.
この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 = 1 | Length | MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
田畑：
Type Set to 1 to indicate a PadN TLV.
PADN TLVを示すには、1に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
MBZ Must be zero, set to 0 on transmission.
MBZはゼロでなければなりません。送信時に0に設定してください。
This TLV is silently ignored on reception. It is allowed in the packet trailer.
この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 = 2 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV requests that the receiver send an Acknowledgment TLV within the number of centiseconds specified by the Interval field.
このTLVは、intervalフィールドで指定されたセンサ数内で受信側が確認応答TLVを送信することを要求します。
Fields:
田畑：
Type Set to 2 to indicate an Acknowledgment Request TLV.
確認応答要求TLVを示すには、2に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
Reserved Sent as 0 and MUST be ignored on reception.
予約済みは0として送信され、受信時に無視されなければなりません。
Opaque An arbitrary value that will be echoed in the receiver's Acknowledgment TLV.
不透明受信機の確認応答TLVでエコーされる任意の値。
Interval A time interval in centiseconds after which the sender will assume that this packet has been lost. This MUST NOT be 0. The receiver MUST send an Acknowledgment TLV before this time has elapsed (with a margin allowing for propagation time).
間隔送信者がこのパケットが失われたと仮定した後の時間間隔。これは0にしてはいけません。受信機は、この時間が経過した前に（マージンが伝播時間を可能にする）前に確認応答TLVを送信する必要があります。
This TLV is self-terminating and allows sub-TLVs.
このTLVは自己終了し、サブ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 | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is sent by a node upon receiving an Acknowledgment Request TLV.
このTLVは、確認応答要求TLVを受信したときにノードによって送信されます。
Fields:
田畑：
Type Set to 3 to indicate an Acknowledgment TLV.
確認応答TLVを示すには、3に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
Opaque Set to the Opaque value of the Acknowledgment Request that prompted this Acknowledgment.
この確認応答を促した確認応答要求の不透明値に不透明に設定されています。
Since Opaque values are not globally unique, this TLV MUST be sent to a unicast address.
不透明な値はグローバルに一意ではないので、このTLVはユニキャストアドレスに送信されなければなりません。
This TLV is self-terminating and allows sub-TLVs.
このTLVは自己終了し、サブ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 = 4 | Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used for neighbour discovery and for determining a neighbour's reception cost.
このTLVは、近隣探索に使用され、隣人の受信コストを決定するために使用されます。
Fields:
田畑：
Type Set to 4 to indicate a Hello TLV.
hello tlvを示すために4に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
Flags The individual bits of this field specify special handling of this TLV (see below).
flagsこのフィールドの個々のビットはこのTLVの特別な処理を指定します（下記参照）。
Seqno If the Unicast flag is set, this is the value of the sending node's outgoing Unicast Hello seqno for this neighbour. Otherwise, it is the sending node's outgoing Multicast Hello seqno for this interface.
seqnoユニキャストフラグが設定されている場合、これはこのネイバーの送信ノードの送信ユニキャストHello SEQNOの値です。それ以外の場合は、このインターフェイスの送信ノードの発信マルチキャストHello SEQNOです。
Interval If nonzero, this is an upper bound, expressed in centiseconds, on the time after which the sending node will send a new scheduled Hello TLV with the same setting of the Unicast flag. If this is 0, then this Hello represents an unscheduled Hello and doesn't carry any new information about times at which Hellos are sent.
間隔ゼロ以外の場合、これは、送信ノードがユニキャストフラグの同じ設定で新しいスケジュールされたHello TLVを送信した後、センセンサー秒単位で表されます。これが0の場合、このHelloは予定外のこんにちはを表し、Hellosが送信される時間に関する新しい情報を持ちません。
The Flags field is interpreted as follows:
flagsフィールドは次のように解釈されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U (Unicast) flag (8000 hexadecimal): if set, then this Hello represents a Unicast Hello, otherwise it represents a Multicast Hello;
U（ユニキャスト）フラグ（80006進数）：設定されている場合、このhelloはユニキャストハローを表し、そうでなければマルチキャストハローを表します。
X: all other bits MUST be sent as 0 and silently ignored on reception.
X：他のすべてのビットは0として送信され、受信時に静かに無視されなければなりません。
Every time a Hello is sent, the corresponding seqno counter MUST be incremented. Since there is a single seqno counter for all the Multicast Hellos sent by a given node over a given interface, if the Unicast flag is not set, this TLV MUST be sent to all neighbours on this link, which can be achieved by sending to a multicast destination or by sending multiple packets to the unicast addresses of all reachable neighbours. Conversely, if the Unicast flag is set, this TLV MUST be sent to a single neighbour, which can achieved by sending to a unicast destination. In order to avoid large discontinuities in link quality, multiple Hello TLVs SHOULD NOT be sent in the same packet.
Helloが送信されるたびに、対応するSEQNOカウンタをインクリメントする必要があります。特定のインタフェースを介して特定のノードによって送信されたすべてのマルチキャストHelloには単一のSEQNOカウンタがあるため、ユニキャストフラグが設定されていない場合、このTLVはこのリンクのすべてのネイバーに送信されなければなりません。マルチキャスト先、または複数のパケットをすべての到達可能な隣接者のユニキャストアドレスに送信することによって。逆に、ユニキャストフラグが設定されている場合、このTLVは単一の隣接に送信されなければならず、ユニキャスト先への送信によって達成されます。リンク品質の大きな不連続性を避けるために、同じパケットに複数のHello TLVを送信しないでください。
This TLV is self-terminating and allows sub-TLVs.
このTLVは自己終了し、サブ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 = 5 | Length | AE | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rxcost | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address...
+-+-+-+-+-+-+-+-+-+-+-+-
An IHU ("I Heard You") TLV is used for confirming bidirectional reachability and carrying a link's transmission cost.
IHU（「聞いた」）TLVは双方向到達可能性を確認し、リンクの伝送費用を携行するために使用されます。
Fields:
田畑：
Type Set to 5 to indicate an IHU TLV.
IHU TLVを示すには、5に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
AE The encoding of the Address field. This should be 1 or 3 in most cases. As an optimisation, it MAY be 0 if the TLV is sent to a unicast address, if the association is over a point-to-point link, or when bidirectional reachability is ascertained by means outside of the Babel protocol.
AEアドレスフィールドのエンコーディング。これはほとんどの場合1または3になります。最適化として、関連付けがポイントツーポイントリンクを介して、またはBabelプロトコルの外側で双方向到達可能性が確かめられている場合、TLVがユニキャストアドレスに送信される場合は0になることがあります。
Reserved Sent as 0 and MUST be ignored on reception.
予約済みは0として送信され、受信時に無視されなければなりません。
Rxcost The rxcost according to the sending node of the interface whose address is specified in the Address field. The value FFFF hexadecimal (infinity) indicates that this interface is unreachable.
rxcostアドレスフィールドにアドレスが指定されているインターフェイスの送信ノードに従ってRXCOSTを参照してください。値FFFF 16進数（infinity）は、このインターフェイスが到達不能であることを示します。
Interval An upper bound, expressed in centiseconds, on the time after which the sending node will send a new IHU; this MUST NOT be 0. The receiving node will use this value in order to compute a hold time for this symmetric association.
間隔送信ノードが新しいIHUを送信する間に、中心秒単位で表される上限。これは0にしてはいけません。受信ノードはこの対称関連のためのホールド時間を計算するためにこの値を使用します。
Address The address of the destination node, in the format specified by the AE field. Address compression is not allowed.
宛先ノードのアドレスをAEフィールドで指定された形式でアドレス指定します。アドレス圧縮は許可されていません。
Conceptually, an IHU is destined to a single neighbour. However, IHU TLVs contain an explicit destination address, and MAY be sent to a multicast address, as this allows aggregation of IHUs destined to distinct neighbours into a single packet and avoids the need for an ARP or Neighbour Discovery exchange when a neighbour is not being used for data traffic.
概念的には、IHUは単一の隣人に運ばれています。しかしながら、IHU TLVSは明示的な宛先アドレスを含み、これにより、異なる隣接者宛てのIHUSの集約が単一のパケットに集約され、隣人が存在しないときにARPまたは近隣の検出の必要性を回避するので、マルチキャストアドレスに送信され得る。データトラフィックに使用されます。
IHU TLVs with an unknown value in the AE field MUST be silently ignored.
AEフィールドに未知の値を持つIHU TLVSは黙って無視されなければなりません。
This TLV is self-terminating and allows sub-TLVs.
このTLVは自己終了し、サブ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 = 6 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Router-Id +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Router-Id TLV establishes a router-id that is implied by subsequent Update TLVs, as described in Section 4.5. This TLV sets the router-id even if it is otherwise ignored due to an unknown mandatory sub-TLV.
Router-ID TLVは、セクション4.5で説明されているように、後続の更新TLVによって暗黙的に示されるルータIDを確立します。このTLVは、不明な必須のサブTLVのために無視されていても、ルータIDを設定します。
Fields:
田畑：
Type Set to 6 to indicate a Router-Id TLV.
ルータID TLVを示すには、6に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
Reserved Sent as 0 and MUST be ignored on reception.
予約済みは0として送信され、受信時に無視されなければなりません。
Router-Id The router-id for routes advertised in subsequent Update TLVs. This MUST NOT consist of all zeroes or all ones.
router-id後続の更新TLVでアドバタイズされたルートのルータID。これはすべてのゼロやすべてのもので構成されてはいけません。
This TLV is self-terminating and allows sub-TLVs.
このTLVは自己終了し、サブ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 = 7 | Length | AE | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next hop...
+-+-+-+-+-+-+-+-+-+-+-+-
A Next Hop TLV establishes a next-hop address for a given address family (IPv4 or IPv6) that is implied in subsequent Update TLVs, as described in Section 4.5. This TLV sets up the next hop for subsequent Update TLVs even if it is otherwise ignored due to an unknown mandatory sub-TLV.
ネクストホップTLVは、セクション4.5で説明されているように、後続の更新TLVで暗黙的に示されている特定のアドレスファミリ（IPv4またはIPv6）のネクストホップアドレスを確立します。このTLVは、不明な必須のSUB-TLVのために無視されていても、後続の更新TLVの次のホップを設定します。
Fields:
田畑：
Type Set to 7 to indicate a Next Hop TLV.
次のホップTLVを示すには、7に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
AE The encoding of the Address field. This SHOULD be 1 (IPv4) or 3 (link-local IPv6), and MUST NOT be 0.
AEアドレスフィールドのエンコーディング。これは1（IPv4）または3（Link-Local IPv6）で、0にしてはいけません。
Reserved Sent as 0 and MUST be ignored on reception.
予約済みは0として送信され、受信時に無視されなければなりません。
Next hop The next-hop address advertised by subsequent Update TLVs for this address family.
次のホップこのアドレスファミリの後続のアップデートTLVSによってアドバタイズされたネクストホップアドレス。
When the address family matches the network-layer protocol over which this packet is transported, a Next Hop TLV is not needed: in the absence of a Next Hop TLV in a given address family, the next-hop address is taken to be the source address of the packet.
アドレスファミリがこのパケットが転送されるネットワーク層プロトコルと一致すると、次のホップTLVが必要とされない。パケットのアドレス。
Next Hop TLVs with an unknown value for the AE field MUST be silently ignored.
AEフィールドの値が不明になっているネクストホップTLVSは黙って無視されなければなりません。
This TLV is self-terminating, and allows sub-TLVs.
このTLVは自己終了し、サブ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 = 8 | Length | AE | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Plen | Omitted | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
An Update TLV advertises or retracts a route. As an optimisation, it can optionally have the side effect of establishing a new implied router-id and a new default prefix, as described in Section 4.5.
アップデートTLVはルートをアドバタイズまたはリトークします。最適化として、セクション4.5で説明されているように、新しい暗黙のルータIDと新しいデフォルトプレフィックスを確立することの副作用を任意に持たせることができます。
Fields:
田畑：
Type Set to 8 to indicate an Update TLV.
更新TLVを示すには、8に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
AE The encoding of the Prefix field.
prefixフィールドのエンコーディング。
Flags The individual bits of this field specify special handling of this TLV (see below).
flagsこのフィールドの個々のビットはこのTLVの特別な処理を指定します（下記参照）。
Plen The length in bits of the advertised prefix. If AE is 3 (link-local IPv6), the Omitted field MUST be 0.
広告付きプレフィックスのビットの長さをプレゼンします。AEが3（Link-Local IPv6）の場合、省略フィールドは0にする必要があります。
Omitted The number of octets that have been omitted at the beginning of the advertised prefix and that should be taken from a preceding Update TLV in the same address family with the Prefix flag set.
アドバタイズされたプレフィックスの先頭で省略されているオクテット数を省略し、プレフィックスフラグセットを使用して同じアドレスファミリ内の前の更新TLVから取得する必要があります。
Interval An upper bound, expressed in centiseconds, on the time after which the sending node will send a new update for this prefix. This MUST NOT be 0. The receiving node will use this value to compute a hold time for the route table entry. The value FFFF hexadecimal (infinity) expresses that this announcement will not be repeated unless a request is received (Section 3.8.2.3).
間隔上限は、送信ノードがこのプレフィックスの新しいアップデートを送信するまでの間、センサー秒単位で表されます。これは0にしてはいけません。受信ノードはこの値を使用してルートテーブルエントリのホールドタイムを計算します。値FFFF 16進数（無限大）は、要求が受信されない限り、このアナウンスが繰り返されないことを表します（3.8.2.3項）。
Seqno The originator's sequence number for this update.
seqnoこの更新プログラムの発信者のシーケンス番号。
Metric The sender's metric for this route. The value FFFF hexadecimal (infinity) means that this is a route retraction.
メトリックこのルートの送信者のメトリック。値FFFF 16進数（無限大）は、これが経路退避であることを意味します。
Prefix The prefix being advertised. This field's size is (Plen/8 - Omitted) rounded upwards.
プレフィックスが宣伝されているプレフィックス。このフィールドのサイズは（PLEN / 8省略）丸みを帯びています。
The Flags field is interpreted as follows:
flagsフィールドは次のように解釈されます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P|R|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+
P (Prefix) flag (80 hexadecimal): if set, then this Update TLV establishes a new default prefix for subsequent Update TLVs with a matching address encoding within the same packet, even if this TLV is otherwise ignored due to an unknown mandatory sub-TLV;
P（Prefix）フラグ（80時間）：設定されている場合、この更新プログラムは、未知の必須サブのためにこのTLVが無視されている場合でも、同じパケット内で一致するアドレスエンコーディングを持つ、後続のアップデートTLVの新しいデフォルトプレフィックスを確立します。TLV;
R (Router-Id) flag (40 hexadecimal): if set, then this TLV establishes a new default router-id for this TLV and subsequent Update TLVs in the same packet, even if this TLV is otherwise ignored due to an unknown mandatory sub-TLV. This router-id is computed from the first address of the advertised prefix as follows:
R（Router-ID）フラグ（40桁の16進数）：設定されている場合、このTLVは、未知の必須サブのためにこのTLVが無視されている場合でも、同じパケット内の新しいパケット内の新しいデフォルトのルーターIDを確立します。-tlv。このルータIDは、アドバタイズされたプレフィックスの最初のアドレスから次のように計算されます。
* if the length of the address is 8 octets or more, then the new router-id is taken from the 8 last octets of the address;
* アドレスの長さが8オクテット以上の場合、新しいルータIDはアドレスの8つの最後のオクテットから取得されます。
* if the length of the address is smaller than 8 octets, then the new router-id consists of the required number of zero octets followed by the address, i.e., the address is stored on the right of the router-id. For example, for an IPv4 address, the router-id consists of 4 octets of zeroes followed by the IPv4 address.
* アドレスの長さが8オクテットより小さい場合、新しいルータIDは必要な数のゼロオクテットの後にアドレス、すなわちアドレスがルータIDの右側に格納される。たとえば、IPv4アドレスの場合、router-idは4オクテットのゼロのオクテットとそれに続くIPv4アドレスで構成されています。
X: all other bits MUST be sent as 0 and silently ignored on reception.
X：他のすべてのビットは0として送信され、受信時に静かに無視されなければなりません。
The prefix being advertised by an Update TLV is computed as follows:
更新TLVによってアドバタイズされているプレフィックスは次のように計算されます。
* the first Omitted octets of the prefix are taken from the previous Update TLV with the Prefix flag set and the same address encoding, even if it was ignored due to an unknown mandatory sub-TLV; if the Omitted field is not zero and there is no such TLV, then this Update MUST be ignored;
* 接頭辞の最初の省略されたオクテットは、未知の必須のSUB-TLVのために無視されていても、プレフィックスフラグセットおよび同じアドレスエンコーディングを使用して前の更新TLVから取得されます。省略フィールドがゼロでなく、そのようなTLVがない場合、この更新プログラムは無視されなければなりません。
* the next (Plen/8 - Omitted) rounded upwards octets are taken from the Prefix field;
* 次の（プレーン/ 8省略）丸みを帯びた上向きのオクテットはプレフィックスフィールドから取得されます。
* if Plen is not a multiple of 8, then any bits beyond Plen (i.e., the low-order (8 - Plen MOD 8) bits of the last octet) are cleared;
* PLENが8の倍数ではない場合、プレスを超える任意のビット（すなわち、最後のオクテットの下位（8 - プレテレンMOD 8）ビット）がクリアされる。
* the remaining octets are set to 0.
* 残りのオクテットは0に設定されています。
If the Metric field is finite, the router-id of the originating node for this announcement is taken from the prefix advertised by this Update if the Router-Id flag is set, computed as described above. Otherwise, it is taken either from the preceding Router-Id TLV, or the preceding Update TLV with the Router-Id flag set, whichever comes last, even if that TLV is otherwise ignored due to an unknown mandatory sub-TLV; if there is no suitable TLV, then this update is ignored.
メトリックフィールドが有限である場合、このアナウンスの発信ノードのルータIDは、Router-IDフラグが設定されている場合には、この更新によって広告されているプレフィックスから取得され、上記のように計算されます。それ以外の場合は、前述のRouter-ID TLV、またはRouter-IDフラグが設定された上記の更新TLVが、未知の必須サブTLVのためにその他の場合は最後に行われます。適切なTLVがない場合、この更新プログラムは無視されます。
The next-hop address for this update is taken from the last preceding Next Hop TLV with a matching address family (IPv4 or IPv6) in the same packet even if it was otherwise ignored due to an unknown mandatory sub-TLV; if no such TLV exists, it is taken from the network-layer source address of this packet if it belongs to the same address family as the prefix being announced; otherwise, this Update MUST be ignored.
この更新のネクストホップアドレスは、不明な必須のサブTLVのために無視されていても、同じパケット内の一致するアドレスファミリ（IPv4またはIPv6）を持つ最後の先行ネクストホップTLVから取得されます。そのようなTLVが存在しない場合、それがアナウンスされているプレフィックスと同じアドレスファミリに属する場合、このパケットのネットワーク層の送信元アドレスから取得されます。それ以外の場合は、このアップデートは無視されなければなりません。
If the metric field is FFFF hexadecimal, this TLV specifies a retraction. In that case, the router-id, next hop, and seqno are not used. AE MAY then be 0, in which case this Update retracts all of the routes previously advertised by the sending interface. If the metric is finite, AE MUST NOT be 0; Update TLVs with finite metric and AE equal to 0 MUST be ignored. If the metric is infinite and AE is 0, Plen and Omitted MUST both be 0; Update TLVs that do not satisfy this requirement MUST be ignored.
メトリックフィールドがFFFF 16進数の場合、このTLVは退避を指定します。その場合、ルータID、ネクストホップ、およびSEQNOは使用されません。その場合、AEは0になり、その場合、この更新プログラムは送信インターフェイスによって以前にアドバタイズされたすべてのルートを後退します。メトリックが有限の場合、AEは0にしてはいけません。有限メトリックを使用したTLVを更新すると、0に等しいAEは無視されます。メトリックがInfiniteとAEが0の場合、PLEN、および省略は両方とも0になります。この要件を満たさないTLVを更新する必要があります。
Update TLVs with an unknown value in the AE field MUST be silently ignored.
AEフィールドに未知の値でTLVを更新する必要があります。
This TLV is self-terminating and allows sub-TLVs.
このTLVは自己終了し、サブ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 = 9 | Length | AE | Plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
A Route Request TLV prompts the receiver to send an update for a given prefix, or a full route table dump.
ルートリクエストTLVは、与えられたプレフィックスまたはフルルートテーブルダンプのアップデートを送信するように受信側にプロンプトされます。
Fields:
田畑：
Type Set to 9 to indicate a Route Request TLV.
ルートリクエストTLVを示すには、9に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
AE The encoding of the Prefix field. The value 0 specifies that this is a request for a full route table dump (a wildcard request).
prefixフィールドのエンコーディング。値0は、これがフルルートテーブルダンプ（ワイルドカード要求）の要求であることを指定します。
Plen The length in bits of the requested prefix.
要求されたプレフィックスのビットの長さをプレーします。
Prefix The prefix being requested. This field's size is Plen/8 rounded upwards.
プレフィックスが要求されているプレフィックス。このフィールドのサイズはPLEN / 8を丸めます。
A Request TLV prompts the receiver to send an update message (possibly a retraction) for the prefix specified by the AE, Plen, and Prefix fields, or a full dump of its route table if AE is 0 (in which case Plen must be 0 and Prefix is of length 0). A Request TLV with AE set to 0 and Plen not set to 0 MUST be ignored.
要求TLVは、AE、PLENフィールド、およびPrefixフィールドによって指定されたプレフィックスの更新メッセージ（おそらく後退）、またはAEが0の場合は、そのルートテーブルのフルダンプの更新メッセージ（おそらく後退）を求めます（PLENが0にする必要があります。プレフィックスは長さ0です）。AEが0に設定された要求TLV、PLENが0に設定されていないPLENは無視されなければなりません。
This TLV is self-terminating and allows sub-TLVs.
このTLVは自己終了し、サブ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 = 10 | Length | AE | Plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Hop Count | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Router-Id +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix...
+-+-+-+-+-+-+-+-+-+-+
A Seqno Request TLV prompts the receiver to send an Update for a given prefix with a given sequence number, or to forward the request further if it cannot be satisfied locally.
seqno要求TLVは、与えられたプレフィックスの更新を与えられたシーケンス番号と共に更新を送信するか、または要求をローカルに満たすことができない場合には、要求をさらに転送するように求められます。
Fields:
田畑：
Type Set to 10 to indicate a Seqno Request TLV.
SEQNO要求TLVを示すには、10に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
AE The encoding of the Prefix field. This MUST NOT be 0.
prefixフィールドのエンコーディング。これは0にする必要があります。
Plen The length in bits of the requested prefix.
要求されたプレフィックスのビットの長さをプレーします。
Seqno The sequence number that is being requested.
seqno要求されているシーケンス番号。
Hop Count The maximum number of times that this TLV may be forwarded, plus 1. This MUST NOT be 0.
ホップ数このTLVが転送される可能性がある最大回数、プラス1.これは0にしてはいけません。
Reserved Sent as 0 and MUST be ignored on reception.
予約済みは0として送信され、受信時に無視されなければなりません。
Router-Id The Router-Id that is being requested. This MUST NOT consist of all zeroes or all ones.
router-id要求されているルータID。これはすべてのゼロやすべてのもので構成されてはいけません。
Prefix The prefix being requested. This field's size is Plen/8 rounded upwards.
プレフィックスが要求されているプレフィックス。このフィールドのサイズはPLEN / 8を丸めます。
A Seqno Request TLV prompts the receiving node to send a finite-metric Update for the prefix specified by the AE, Plen, and Prefix fields, with either a router-id different from what is specified by the Router-Id field, or a Seqno no less (modulo 2^(16)) than what is specified by the Seqno field. If this request cannot be satisfied locally, then it is forwarded according to the rules set out in Section 3.8.1.2.
SEQNO要求TLVは、Router-IDフィールドで指定されているルータID、またはseqnoによって異なるルータIDを指定して、AE、PLENフィールド、プレフィックスフィールドの有限メトリックスアップデートを受信ノードに送信するように求められます。SEQNOフィールドで指定されているものよりも少なく（モジュロ2 ^（16））。この要求をローカルに満たすことができない場合は、セクション3.8.1.2に記載されている規則に従って転送されます。
While a Seqno Request MAY be sent to a multicast address, it MUST NOT be forwarded to a multicast address and MUST NOT be forwarded to more than one neighbour. A request MUST NOT be forwarded if its Hop Count field is 1.
SEQNO要求はマルチキャストアドレスに送信されてもよいが、マルチキャストアドレスに転送されてはならず、複数のネイバーに転送しないでください。ホップカウントフィールドが1の場合、リクエストを転送しないでください。
This TLV is self-terminating and allows sub-TLVs.
このTLVは自己終了し、サブTLVを許可しています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
Fields:
田畑：
Type Set to 0 to indicate a Pad1 sub-TLV.
PAD1 SUB-TLVを示すには、0に設定します。
This sub-TLV is silently ignored on reception. It is allowed within any TLV that allows sub-TLVs.
このサブTLVは受信時に静かに無視されます。サブTLVを許可する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 = 1 | Length | MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields:
田畑：
Type Set to 1 to indicate a PadN sub-TLV.
PADNサブTLVを示すには、1に設定します。
Length The length of the body in octets, exclusive of the Type and Length fields.
長さは、オクテット内の体の長さ、タイプと長さのフィールドを除く。
MBZ Must be zero, set to 0 on transmission.
MBZはゼロでなければなりません。送信時に0に設定してください。
This sub-TLV is silently ignored on reception. It is allowed within any TLV that allows sub-TLVs.
このサブTLVは受信時に静かに無視されます。サブTLVを許可するTLV内で許可されています。
IANA has registered the UDP port number 6696, called "babel", for use by the Babel protocol.
IANAは、Babelプロトコルで使用するために、「Babel」と呼ばれるUDPポート番号6696を登録しました。
IANA has registered the IPv6 multicast group ff02::1:6 and the IPv4 multicast group 224.0.0.111 for use by the Babel protocol.
IANAは、Babelプロトコルで使用するためにIPv6マルチキャストグループFF02 :: 1：6、およびIPv4マルチキャストグループ224.0.0.111を登録しました。
IANA has created a registry called "Babel TLV Types". The allocation policy for this registry is Specification Required [RFC8126] for Types 0-223 and Experimental Use for Types 224-254. The values in this registry are as follows:
IANAは「Babel TLV Types」というレジストリを作成しました。このレジストリの割り当てポリシーは、タイプ0~223のための[RFC8126]とタイプ224-254の実験的使用に必要です。このレジストリの値は次のとおりです。
+=========+==========================================+===========+
| Type | Name | Reference |
+=========+==========================================+===========+
| 0 | Pad1 | RFC 8966 |
+---------+------------------------------------------+-----------+
| 1 | PadN | RFC 8966 |
+---------+------------------------------------------+-----------+
| 2 | Acknowledgment Request | RFC 8966 |
+---------+------------------------------------------+-----------+
| 3 | Acknowledgment | RFC 8966 |
+---------+------------------------------------------+-----------+
| 4 | Hello | RFC 8966 |
+---------+------------------------------------------+-----------+
| 5 | IHU | RFC 8966 |
+---------+------------------------------------------+-----------+
| 6 | Router-Id | RFC 8966 |
+---------+------------------------------------------+-----------+
| 7 | Next Hop | RFC 8966 |
+---------+------------------------------------------+-----------+
| 8 | Update | RFC 8966 |
+---------+------------------------------------------+-----------+
| 9 | Route Request | RFC 8966 |
+---------+------------------------------------------+-----------+
| 10 | Seqno Request | RFC 8966 |
+---------+------------------------------------------+-----------+
| 11 | TS/PC | [RFC7298] |
+---------+------------------------------------------+-----------+
| 12 | HMAC | [RFC7298] |
+---------+------------------------------------------+-----------+
| 13 | Reserved | |
+---------+------------------------------------------+-----------+
| 14 | Reserved | |
+---------+------------------------------------------+-----------+
| 15 | Reserved | |
+---------+------------------------------------------+-----------+
| 224-254 | Reserved for Experimental Use | RFC 8966 |
+---------+------------------------------------------+-----------+
| 255 | Reserved for expansion of the type space | RFC 8966 |
+---------+------------------------------------------+-----------+
Table 1
表1
IANA has created a registry called "Babel Sub-TLV Types". The allocation policy for this registry is Specification Required for Types 0-111 and 128-239, and Experimental Use for Types 112-126 and 240-254. The values in this registry are as follows:
IANAは「Babel Sub-TLV Types」というレジストリを作成しました。このレジストリの割り当てポリシーは、タイプ0~111および128-239に必要な仕様、およびタイプ112-126および240-254の実験的使用です。このレジストリの値は次のとおりです。
+=========+===============================+===================+
| Type | Name | Reference |
+=========+===============================+===================+
| 0 | Pad1 | RFC 8966 |
+---------+-------------------------------+-------------------+
| 1 | PadN | RFC 8966 |
+---------+-------------------------------+-------------------+
| 2 | Diversity | [BABEL-DIVERSITY] |
+---------+-------------------------------+-------------------+
| 3 | Timestamp | [BABEL-RTT] |
+---------+-------------------------------+-------------------+
| 4-111 | Unassigned | |
+---------+-------------------------------+-------------------+
| 112-126 | Reserved for Experimental Use | RFC 8966 |
+---------+-------------------------------+-------------------+
| 127 | Reserved for expansion of the | RFC 8966 |
| | type space | |
+---------+-------------------------------+-------------------+
| 128 | Source Prefix | [BABEL-SS] |
+---------+-------------------------------+-------------------+
| 129-239 | Unassigned | |
+---------+-------------------------------+-------------------+
| 240-254 | Reserved for Experimental Use | RFC 8966 |
+---------+-------------------------------+-------------------+
| 255 | Reserved for expansion of the | RFC 8966 |
| | type space | |
+---------+-------------------------------+-------------------+
Table 2
表2.
IANA has created a registry called "Babel Address Encodings". The allocation policy for this registry is Specification Required for Address Encodings (AEs) 0-223, and Experimental Use for AEs 224-254. The values in this registry are as follows:
IANAは「Babel Address Encodings」というレジストリを作成しました。このレジストリの割り当てポリシーは、アドレスエンコーディング（AES）0~223、およびAES 224-254の実験的使用に必要な仕様です。このレジストリの値は次のとおりです。
+=========+========================================+===========+
| AE | Name | Reference |
+=========+========================================+===========+
| 0 | Wildcard address | RFC 8966 |
+---------+----------------------------------------+-----------+
| 1 | IPv4 address | RFC 8966 |
+---------+----------------------------------------+-----------+
| 2 | IPv6 address | RFC 8966 |
+---------+----------------------------------------+-----------+
| 3 | Link-local IPv6 address | RFC 8966 |
+---------+----------------------------------------+-----------+
| 4-223 | Unassigned | |
+---------+----------------------------------------+-----------+
| 224-254 | Reserved for Experimental Use | RFC 8966 |
+---------+----------------------------------------+-----------+
| 255 | Reserved for expansion of the AE space | RFC 8966 |
+---------+----------------------------------------+-----------+
Table 3
表3.
IANA has renamed the registry called "Babel Flags Values" to "Babel Update Flags Values". The allocation policy for this registry is Specification Required. The values in this registry are as follows:
IANAは「Babel Flags Values」というレジストリを「Babel Update Flags値」に変更しました。このレジストリの割り当てポリシーは必須です。このレジストリの値は次のとおりです。
+=====+===================+===========+
| Bit | Name | Reference |
+=====+===================+===========+
| 0 | Default prefix | RFC 8966 |
+-----+-------------------+-----------+
| 1 | Default router-id | RFC 8966 |
+-----+-------------------+-----------+
| 2-7 | Unassigned | |
+-----+-------------------+-----------+
Table 4
表4.
IANA has created a new registry called "Babel Hello Flags Values". The allocation policy for this registry is Specification Required. The initial values in this registry are as follows:
IANAは「Babel Hello Flags Values」という新しいレジストリを作成しました。このレジストリの割り当てポリシーは必須です。このレジストリの初期値は次のとおりです。
+======+============+===========+
| Bit | Name | Reference |
+======+============+===========+
| 0 | Unicast | RFC 8966 |
+------+------------+-----------+
| 1-15 | Unassigned | |
+------+------------+-----------+
Table 5
表5.
IANA has replaced all references to RFCs 6126 and 7557 in all of the registries mentioned above with references to this document.
IANAは、この文書への参照で上記のすべてのレジストリでRFCS 6126と7557への参照をすべて交換しました。
As defined in this document, Babel is a completely insecure protocol. Without additional security mechanisms, Babel trusts any information it receives in plaintext UDP datagrams and acts on it. An attacker that is present on the local network can impact Babel operation in a variety of ways; for example they can:
この文書で定義されているように、Babelは完全に安全でないプロトコルです。追加のセキュリティメカニズムがなくても、Babelはそれが受信した情報を平文UDPデータグラムに信頼し、それに行動します。ローカルネットワーク上に存在する攻撃者は、さまざまな方法でBabel操作に影響を与える可能性があります。たとえば、それらは次のことができます。
* spoof a Babel packet, and redirect traffic by announcing a route with a smaller metric, a larger sequence number, or a longer prefix;
* Baberパケットを偽装し、小さいメトリック、より大きなシーケンス番号、またはより長い接頭辞を持つルートをアナウンスすることによってトラフィックをリダイレクトします。
* spoof a malformed packet, which could cause an insufficiently robust implementation to crash or interfere with the rest of the network;
* 不正な形式のパケットを偽装すると、不十分な堅牢な実装がクラッシュまたは残りのネットワークを妨害する可能性があります。
* replay a previously captured Babel packet, which could cause traffic to be redirected, black-holed, or otherwise interfere with the network.
* 以前にキャプチャされたBabelパケットを再生します。これにより、トラフィックをリダイレクト、ブラックホール、またはその他の方法でネットワークを妨害する可能性があります。
When carried over IPv6, Babel packets are ignored unless they are sent from a link-local IPv6 address; since routers don't forward link-local IPv6 packets, this mitigates the attacks outlined above by restricting them to on-link attackers. No such natural protection exists when Babel packets are carried over IPv4, which is one of the reasons why it is recommended to deploy Babel over IPv6 (Section 3.1).
IPv6を介して伝送すると、リンクローカルIPv6アドレスから送信されない限り、Babelパケットは無視されます。ルータはリンクローカルのIPv6パケットを転送しないので、これは上記の攻撃を攻撃してリンクをオンリンク攻撃者に制限することによって軽減します。BabelパケットがIPv4を介して運ばれるとき、そのような自然保護は存在しません。
It is usually difficult to ensure that packets arriving at a Babel node are trusted, even in the case where the local link is believed to be secure. For that reason, it is RECOMMENDED that all Babel traffic be protected by an application-layer cryptographic protocol. There are currently two suitable mechanisms, which implement different trade-offs between implementation simplicity and security:
ローカルリンクが安全であると考えられている場合でも、バベルノードに到着するパケットが信頼できるようにするのは通常困難です。そのため、すべてのBabelトラフィックをアプリケーションレイヤ暗号プロトコルで保護することをお勧めします。現在、実装の単純さとセキュリティの間で異なるトレードオフを実装する2つの適切なメカニズムがあります。
* Babel over DTLS [RFC8968] runs the majority of Babel traffic over DTLS and leverages DTLS to authenticate nodes and provide confidentiality and integrity protection;
* DTLS上のBabel [RFC8968]は、DTLSを介してBABELトラフィックの大部分を実行し、DTLSを活用してノードを認証し、機密性と整合性保護を提供します。
* MAC authentication [RFC8967] appends a message authentication code (MAC) to every Babel packet to prove that it originated at a node that knows a shared secret, and includes sufficient additional information to prove that the packet is fresh (not replayed).
* MAC認証[RFC8967]は、共有された秘密を知っているノードで発生したことを証明するために、メッセージ認証コード（MAC）をあらゆるBabelパケットに追加し、パケットが新鮮であることを証明するのに十分な追加情報を含む（再生されない）。
Both mechanisms enable nodes to ignore packets generated by attackers without the proper credentials. They also ensure integrity of messages and prevent message replay. While Babel-DTLS supports asymmetric keying and ensures confidentiality, Babel-MAC has a much more limited scope (see Sections 1.1, 1.2, and 7 of [RFC8967]). Since Babel-MAC is simpler and more lightweight, it is recommended in preference to Babel-DTLS in deployments where its limitations are acceptable, i.e., when symmetric keying is sufficient and where the routing information is not considered confidential.
どちらのメカニズムでも、ノードが適切な資格情報なしで攻撃者によって生成されたパケットを無視することができます。彼らはまたメッセージの完全性を確実にし、メッセージの再生を防ぐことができます。Babel-DTLSは非対称キーイングをサポートし、機密性を保証しますが、Babel-Macにははるかに限られた範囲があります（[RFC8967]のセクション1.1,1.2、および7を参照）。Babel-Macはより単純でより軽量なので、その制限が許容される展開において、すなわち対称的なキーイングが十分であり、ルーティング情報が機密と見なされない場合には、BABEL-DTLSを好むことを推奨されます。
Every implementation of Babel SHOULD implement BABEL-MAC.
Babelのすべての実装はBabel-Macを実装する必要があります。
One should be aware that the information that a mobile Babel node announces to the whole routing domain is sufficient to determine the mobile node's physical location with reasonable precision, which might cause privacy concerns even if the control traffic is protected from unauthenticated attackers by a cryptographic mechanism such as Babel-DTLS. This issue may be mitigated somewhat by using randomly chosen router-ids and randomly chosen IP addresses, and changing them often enough.
モバイルベイビルノードがルーティングドメイン全体をアナウンスする情報は、コントロールトラフィックが非認証メカニズムによって保護されていなくてもプライバシーに関する懸念を引き起こす可能性があります。Babel-DTLSなど。この問題は、ランダムに選択されたルータIDを使用し、ランダムに選択されたIPアドレスを使用して、それらを十分に変更することによって、やや軽減されます。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https：//www.rfc-editor.org/info/rfc793>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8967] Dô, C., Kolodziejak, W., and J. Chroboczek, "MAC Authentication for the Babel Routing Protocol", RFC 8967, DOI 10.17487/RFC8967, January 2021, <https://www.rfc-editor.org/info/rfc8967>.
[RFC8967]Dô、C.、Kolodziejak、W.およびJ.Chroboczek、「BabelルーティングプロトコルのMAC認証」、RFC 8967、DOI 10.17487 / RFC8967、2021年1月、<https：//www.rfc-編集者。ORG / INFO / RFC8967>。
[BABEL-DIVERSITY] Chroboczek, J., "Diversity Routing for the Babel Routing Protocol", Work in Progress, Internet-Draft, draft-chroboczek-babel-diversity-routing-01, 15 February 2016, <https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-01>.
[ベイビルダイバーシティ] Chroboczek、J.、「Babelルーティングプロトコルのためのダイバーシティルーティング」、進行中の作業、インターネットドラフト、ドラフト - Chroboczek-Babel-Dical-Routing-01,15月15日、<https：//ツール.ietf.org / html / draft-chroboczek-babel-divel-routing-01>。
[BABEL-RTT] Jonglez, B. and J. Chroboczek, "Delay-based Metric Extension for the Babel Routing Protocol", Work in Progress, Internet-Draft, draft-ietf-babel-rtt-extension-00, 26 April 2019, <https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00>.
[BABEL-RTT] Jonglez、B.およびJ.Chroboczek、「Babelルーティングプロトコルのための遅延ベースのメトリック拡張」、進行中の作業、インターネットドラフト、ドラフト - IETF-BABEL-RTT-extension-00,26 4月26日、<https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00>。
[BABEL-SS] Boutier, M. and J. Chroboczek, "Source-Specific Routing in Babel", Work in Progress, Internet-Draft, draft-ietf-babel-source-specific-07, 28 October 2020, <https://tools.ietf.org/html/draft-ietf-babel-source-specific-07>.
[Babel-SS] Boutier、M.およびJ.Chroboczek、「Babelのソース固有のルーティング」、進行中の作業、インターネットドラフト、ドラフト - Babel-Source-Seconde-Seconde-Seconde-07,2020、<https：//tools.ietf.org/html/draft-ietf-babel-Source-Specific-07>。
[DSDV] Perkins, C. and P. Bhagwat, "Highly dynamic Destination-Sequenced Distance-Vector routing (DSDV) for mobile computers", ACM SIGCOMM '94: Proceedings of the conference on Communications architectures, protocols and applications, 234-244, DOI 10.1145/190314.190336, October 1994, <https://doi.org/10.1145/190314.190336>.
[DSDV] Perkins、C、P.Bhagwat、「モバイルコンピュータのための高動的な宛先順序距離 - ベクトルルーティング（DSDV）」、ACM SIGCOMM '94：通信アーキテクチャ、プロトコル、およびアプリケーションに関する会議の手続き234-244、Doi 10.1145 / 190314.190336、1994年10月、<https：//doi.org/10.1145/190314.190336>。
[DUAL] Garcia Luna Aceves, J. J., "Loop-free routing using diffusing computations", IEEE/ACM Transactions on Networking, 1:1, DOI 10.1109/90.222913, February 1993, <https://doi.org/10.1109/90.222913>.
[デュアル] Garcia Luna Aceves、JJ、「拡散計算を使用したループフリールーティング」、ネットワーキング、1：1、DOI 10.1109 / 90.222913、1993年2月、<https：//doi.org/10.1109/90.22913>。
[EIGRP] Albrightson, B., Garcia Luna Aceves, J. J., and J. Boyle, "EIGRP -- a Fast Routing Protocol Based on Distance Vectors", Proc. Networld/Interop 94, 1994.
[EIGRP] Albrightson、B.、Garcia Luna Aceves、J.J.、およびJ.Boy、「EIGRP - 距離ベクトルに基づく高速ルーティングプロトコル」、Proc。NetWorld / Interop 94,1994。
[ETX] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A high-throughput path metric for multi-hop wireless networks", MobiCom '03: Proceedings of the 9th annual international conference on Mobile computing and networking, 134-146, DOI 10.1145/938985.939000, September 2003, <https://doi.org/10.1145/938985.939000>.
[ETX] De Couto、D.、Aguayo、D.、Bicket、J.、およびR. Morris、MobiCom '03：第9回国際会議の手続き2003年9月、<https：//doi.org/10.1145/938985.939000>。
[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, <https://doi.org/10.1109/ieeestd.2012.6178212>.
[IEEE802.11] IEEE、「IEEE標準情報技術情報技術標準 - システム間の電気通信と情報交換」ネットワーク - 特定の要件部11：無線LAN媒体アクセス制御（MAC）および物理層（PHY）仕様）IEEE 802.11-2012、DOI 10.1109 / IEEESTD.2012.6178212、<https：//doi.org/10.1109/ieeeestd.2012.6178212>。
[IEN137] Cohen, D., "On Holy Wars and a Plea for Peace", IEN 137, 1 April 1980.
[IEN137]コーエン、D.、「聖戦では、平和のための嘆願」、IEN 137、1980年1月1日。
[IS-IS] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, 2002.
[IS-IS]標準化のための国際機関、「システム間の電気通信と情報交換」コネクションレスモードネットワークサービスを提供するためのプロトコルと組み合わせて使用するためのイントラドメイン内ルーティング情報交換プロトコル（ISO 8473） "、ISO / IEC 10589：2002,2002。
[JITTER] Floyd, S. and V. Jacobson, "The Synchronization of Periodic Routing Messages", IEEE/ACM Transactions on Networking, 2, 2, 122-136, DOI 10.1109/90.298431, April 1994, <https://doi.org/10.1109/90.298431>.
[Jitter] Floyd、S.およびV. Jacobson、「定期的なルーティングメッセージの同期」、NetWorking、2,2,122-136、DOI 10.1109 / 90.298431、1994年4月、<https：// doi.ORG / 10.1109 / 90.298431>。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[OSPF] MOY、J。、「OSPF版2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[PACKETBB] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <https://www.rfc-editor.org/info/rfc5444>.
[PacketBB] Chrausen、T.、Dearlove、C、Dean、J.、およびC。ADJIH、「一般化モバイルアドホックネットワーク（MANET）パケット/メッセージフォーマット」、RFC 5444、DOI 10.17487 / RFC5444、2009年2月、<https://www.rfc-editor.org/info/rfc5444>。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, <https://www.rfc-editor.org/info/rfc2675>.
[RFC2675] Borman、D.、Theering、S.、R.hinden、 "IPv6 Jumbograms"、RFC 2675、DOI 10.17487 / RFC2675、1999年8月、<https：//www.rfc-editor.org/info/rfc2675>。
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, <https://www.rfc-editor.org/info/rfc3561>.
[RFC3561] Perkins、C、Belding-Royer、E.、S.DAS、「アドホックオンデマンド距離ベクトル（AODV）ルーティング」、RFC 3561、DOI 10.17487 / RFC3561、2003年7月、<https：//www.rfc-editor.org/info/rfc3561>。
[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, DOI 10.17487/RFC6126, April 2011, <https://www.rfc-editor.org/info/rfc6126>.
[RFC6126] Chroboczek、J.、「Babel Routing Protocol」、RFC 6126、DOI 10.17487 / RFC6126、2011年4月、<https：//www.rfc-editor.org/info/rfc6126>。
[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, DOI 10.17487/RFC7298, July 2014, <https://www.rfc-editor.org/info/rfc7298>.
[RFC7298] Ovsienko、D.、 "Babel Hasedメッセージ認証コード（HMAC）暗号認証"、RFC 7298、DOI 10.17487 / RFC7298、2014年7月、<https://www.rfc-editor.org/info/rfc7298>。
[RFC7557] Chroboczek, J., "Extension Mechanism for the Babel Routing Protocol", RFC 7557, DOI 10.17487/RFC7557, May 2015, <https://www.rfc-editor.org/info/rfc7557>.
[RFC7557] Chroboczek、J.、「Babelルーティングプロトコルの拡張メカニズム」、RFC 7557、DOI 10.17487 / RFC7557、2015年5月、<https：//www.rfc-editor.org/info/rfc7557>。
[RFC8968] Décimo, A., Schinazi, D., and J. Chroboczek, "Babel Routing Protocol over Datagram Transport Layer Security", RFC 8968, DOI 10.17487/RFC8968, January 2021, <https://www.rfc-editor.org/info/rfc8968>.
[RFC8968]Décimo、A.、Schinazi、D.、およびJ.Chroboczek、「データグラムトランスポート層のセキュリティ上の「Babelルーティングプロトコル」、RFC 8968、DOI 10.17487 / RFC8968、2021年1月、<https：//www.rfc-編集者.org / info / rfc8968>。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.
[RIP] Malkin、G.、「RIPバージョン2」、STD 56、RFC 2453、DOI 10.17487 / RFC2453、1998年11月、<https：//www.rfc-editor.org/info/rfc2453>。
The strategy for computing link costs and route metrics is a local matter; Babel itself only requires that it comply with the conditions given in Section 3.4.3 and Section 3.5.2. Different nodes may use different strategies in a single network and may use different strategies on different interface types. This section describes a set of strategies that have been found to work well in actual networks.
リンクコストとルートメトリックを計算するための戦略は地域の問題です。Babel自体は、セクション3.4.3および3.5.2項で与えられた条件に準拠するだけである。異なるノードは、単一のネットワークで異なる戦略を使用することができ、異なるインターフェイスタイプに対して異なる戦略を使用することができます。このセクションでは、実際のネットワークでうまく機能することが判明した一連の戦略について説明します。
In summary, a node maintains per-neighbour statistics about the last 16 received Hello TLVs of each kind (Appendix A.1), it computes costs by using the 2-out-of-3 strategy (Appendix A.2.1) on wired links and Expected Transmission Cost (ETX) (Appendix A.2.2) on wireless links. It uses an additive algebra for metric computation (Section 3.5.2).
要約すると、ノードは各種類の最後の16回の受信Hello TLV（付録A.1）に関する隣接統計を維持し、有線リンクに関する2-OUT-3戦略（付録A.2.1）を使用することでコストを計算します。無線リンクにおける予想される送信コスト（ETX）（付録A.2.2）。それはメトリック計算のための加法代数を使用します（セクション3.5.2）。
For each neighbour, a node maintains two sets of Hello history, one for each kind of Hello, and an expected sequence number, one for Multicast and one for Unicast Hellos. Each Hello history is a vector of 16 bits, where a 1 value represents a received Hello, and a 0 value a missed Hello. For each kind of Hello, the expected sequence number, written ne, is the sequence number that is expected to be carried by the next received Hello from this neighbour.
各隣接について、ノードは、helloの種類のhello履歴を1つずつ、マルチキャスト、ユニキャストHellosのための1つは予想されるシーケンス番号を1つずつ維持します。各Hello履歴は16ビットのベクトルです。ここで、1値は受信したhelloを表し、0の値は逃したこんにちは。helloの各種のために、NEの予想されるシーケンス番号は、この隣接から次の受信されたhelloによって持ち運ばれると予想されるシーケンス番号です。
Whenever it receives a Hello packet of a given kind from a neighbour, a node compares the received sequence number nr for that kind of Hello with its expected sequence number ne. Depending on the outcome of this comparison, one of the following actions is taken:
近隣から所与の種類のhelloパケットを受信するたびに、ノードはその種のHelloの受信シーケンス番号NRをその予想されるシーケンス番号NEと比較する。この比較の結果に応じて、以下のいずれかの処置が行われます。
* if the two differ by more than 16 (modulo 2^(16)), then the sending node has probably rebooted and lost its sequence number; the whole associated neighbour table entry is flushed and a new one is created;
* 2が16を超えて異なる場合（Modulo 2 ^（16））、送信ノードはおそらく再起動し、そのシーケンス番号を失いました。関連付けられている隣接テーブルエントリ全体がフラッシュされ、新しいものが作成されます。
* otherwise, if the received nr is smaller (modulo 2^(16)) than the expected sequence number ne, then the sending node has increased its Hello interval without our noticing; the receiving node removes the last (ne - nr) entries from this neighbour's Hello history (we "undo history");
* それ以外の場合、受信したNRが予想されるシーケンス番号NEよりも小さい（モジュロ2 ^（16））場合、送信ノードは私たちのノート化なしにそのhello間隔を増加させました。受信側ノードは、このネイバーのhello履歴から最後の（NE - NR）エントリを削除します（履歴履歴を「元に戻す」）。
* otherwise, if nr is larger (modulo 2^(16)) than ne, then the sending node has decreased its Hello interval, and some Hellos were lost; the receiving node adds (nr - ne) 0 bits to the Hello history (we "fast-forward").
* それ以外の場合、NRがNEより大きい場合（モジュロ2 ^（16））、送信ノードはそのhello間隔を減らし、いくつかのhellosが失われました。受信ノードはHello履歴に（NR - NE）0ビットを追加します（早送り」）。
The receiving node then appends a 1 bit to the Hello history and sets ne to (nr + 1). If the Interval field of the received Hello is not zero, it resets the neighbour's hello timer to 1.5 times the advertised Interval (the extra margin allows for delay due to jitter).
次に、受信ノードは1ビットをhello履歴に追加し、NEを（NR 1）に設定する。受信したhelloの間隔フィールドがゼロではない場合は、隣人のHelloタイマーをアドバタイズされた間隔の1.5倍にリセットします（追加のマージンはジッタによる遅延を可能にします）。
Whenever either hello timer associated with a neighbour expires, the local node adds a 0 bit to the corresponding Hello history, and increments the expected Hello number. If both Hello histories are empty (they contain 0 bits only), the neighbour entry is flushed; otherwise, the relevant hello timer is reset to the value advertised in the last Hello of that kind received from this neighbour (no extra margin is necessary in this case, since jitter was already taken into account when computing the timeout that has just expired).
隣接に関連するHello Timerが有効期限が切れるときはいつでも、ローカルノードは対応するhello履歴に0ビットを追加し、予想されるHello番号をインクリメントします。両方のHello履歴が空の場合（それらは0ビットのみを含みます）、隣接エントリはフラッシュされます。それ以外の場合、関連するHello Timerは、この隣接から受信したその種の最後のHelloでアドバタイズされた値にリセットされます（この場合、期限が切れたタイムアウトを計算するときにジッタがすでに考慮されているため、追加のマージンは必要ありません）。
This section describes two algorithms suitable for computing costs (Section 3.4.3) based on Hello history. Appendix A.2.1 applies to wired links and Appendix A.2.2 to wireless links. RECOMMENDED default values of the parameters that appear in these algorithms are given in Appendix B.
こちらの履歴に基づくコストの計算に適した2つのアルゴリズム（セクション3.4.3）について説明します。付録A.2.1は、有線リンクと付録A.2.2にワイヤレスリンクに適用されます。これらのアルゴリズムに表示されるパラメータの推奨デフォルト値は付録Bに記載されています。
K-out-of-j link sensing is suitable for wired links that are either up, in which case they only occasionally drop a packet, or down, in which case they drop all packets.
k-out-of-jリンクセンシングは、どちらかの上にある有線リンクに適しています。その場合、それらは時々パケットを落とします。その場合、それらはすべてのパケットを削除します。
The k-out-of-j strategy is parameterised by two small integers k and 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 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, and the rxcost is set to infinity.
k out-of-jの戦略は、0 <k <= j、および公称リンクコスト、定数C> = 1となるように、2つの小整数kとjによってパラメータ化されます。ノードは最後のjの歴史を保ちますこんにちは;K以上が正しく受信された場合は、リンクがアップし、RXCOSTがCに設定されていると見なされます。それ以外の場合は、リンクがダウンしていると想定され、RXCOSTは無限大に設定されています。
Since Babel supports two kinds of Hellos, a Babel node performs k-out-of-j twice for each neighbour, once on the Unicast Hello history and once on 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 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 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 sensing.
Babelは2種類のhellosをサポートしているので、ベイビルノードは、ユニキャストHello履歴に1回、マルチキャストHelloの履歴に1回、各隣人ごとにK-Out-Jのkを2回実行します。k out-jのインスタンスのいずれかがリンクが上がっていることを示している場合、リンクは上にあると見なされ、Rxcostはcに設定されています。両方のインスタンスがリンクが停止していることを示している場合、リンクはダウンしていると見なされ、RXCOSTは無限大に設定されています。言い換えれば、結果のRXCOSTは、k-out-jリンクセンシングの2つのインスタンスによって生じるRXcostの最小値です。
The cost of a link performing k-out-of-j link sensing is defined as follows:
k out-jリンクセンシングを実行するリンクのコストは次のように定義されています。
* cost = FFFF hexadecimal if rxcost = FFFF hexadecimal;
* rxcost = ffff 16進数の場合、cost = ffff 16進数。
* cost = txcost otherwise.
* そうでなければ費用= TXCOST。
Unlike wired links which are bimodal (either up or down), wireless links exhibit continuous variation of the link quality. Naive application of hop-count routing in networks that use wireless links for transit tends to select long, lossy links in preference to shorter, lossless links, which can dramatically reduce throughput. For that reason, a routing protocol designed to support wireless links must perform some form of link quality estimation.
バイモーダル（上下）の有線リンクとは異なり、無線リンクはリンク品質の連続的な変動を示します。輸送のための無線リンクを使用するネットワークにおけるホップカウントルーティングのナイーブアプリケーションは、スループットを劇的に低減することができる、より短いロスレスリンクを好む、長く損失のないリンクを選択する傾向がある。そのため、無線リンクをサポートするように設計されたルーティングプロトコルは、リンク品質推定の形式を実行する必要があります。
The Expected Transmission Cost algorithm, or ETX [ETX], is a simple link quality estimation algorithm that is designed to work well with the IEEE 802.11 MAC [IEEE802.11]. By default, the IEEE 802.11 MAC performs Automatic Repeat Query (ARQ) and rate adaptation on unicast frames, but not on multicast frames, which are sent at a fixed rate with no ARQ; therefore, measuring the loss rate of multicast frames yields a useful estimate of a link's quality.
予想される伝送コストアルゴリズム、またはETX [ETX]は、IEEE 802.11 MAC [IEEE802.11]とうまく機能するように設計された簡単なリンク品質推定アルゴリズムです。デフォルトでは、IEEE 802.11 MACはユニキャストフレームで自動リピートクエリ（ARQ）とレート適応を実行しますが、マルチキャストフレームではなく、ARQのない定数で送信されます。したがって、マルチキャストフレームの損失率を測定すると、リンクの品質の有用な見積もりが得られます。
A node performing ETX link quality estimation uses a neighbour's Multicast Hello history to compute an estimate, written beta, of the 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 the most recent entries in the Multicast Hello history, or it can be an exponential average, or some combination of both approaches. Let rxcost be 256/beta.
ETX Link品質推定を実行するノードは、隣人のマルチキャストhello履歴を使用して、hello TLVが正常に受信された確率の推定値を計算します。ベータは、マルチキャストHello履歴の最新のエントリの小さい数（a、6）内の1ビットの小数として計算できます。またはそれは指数関数的平均、または両方のアプローチの組み合わせであり得る。RXCOSTを256 /ベータにすることができます。
Let alpha be MIN(1, 256/txcost), an estimate of the probability of successfully sending a Hello TLV. The cost is then computed by
Alpha Be Min（1,256 / TXCOST）、Hello TLVを正常に送信する確率の推定値。その後、コストが計算されます
cost = 256/(alpha * beta)
or, equivalently,
または等価的に、
cost = (MAX(txcost, 256) * rxcost) / 256.
Since the IEEE 802.11 MAC performs ARQ on unicast frames, unicast frames do not provide a useful measure of link quality, and therefore ETX ignores the Unicast Hello history. Thus, a node performing ETX link quality estimation will not route through neighbouring nodes unless they send periodic Multicast Hellos (possibly in addition to Unicast Hellos).
IEEE 802.11 MACはユニキャストフレームでARQを実行するので、ユニキャストフレームはリンク品質の有用な尺度を提供しないため、ETXはユニキャストHello履歴を無視します。したがって、ETXリンク品質推定を実行するノードは、周期的なマルチキャストHellos（おそらくユニキャストHellosに加えて）を送信しない限り、隣接ノードを通過しません。
Route selection (Section 3.6) is the process by which a node selects a single route among the routes that it has available towards a given destination. With Babel, any route selection procedure that only ever chooses feasible routes with a finite metric will yield a set of loop-free routes; however, in the presence of continuously variable metrics such as ETX (Appendix A.2.2), a naive route selection procedure might lead to persistent oscillations. Such oscillations can be limited or avoided altogether by implementing hysteresis within the route selection algorithm, i.e., by making the route selection algorithm sensitive to a route's history. Any reasonable hysteresis algorithm should yield good results; the following algorithm is simple to implement and has been successfully deployed in a variety of environments.
ルート選択（セクション3.6）は、ノードが、特定の宛先に向かって利用可能なルート間で単一の経路を選択するプロセスです。Babelでは、有限メトリックを持つ実現可能なルートを選択するだけであれば、ループフリールートのセットが生成されます。しかしながら、ETX（付録A.2.2）のような連続可変の測定基準が存在する場合、ナイーブ経路選択手順は持続的な振動をもたらす可能性がある。そのような振動は、経路選択アルゴリズム内のヒステリシスを実施することによって、すなわち経路選択アルゴリズムを経路の履歴に敏感にすることによって限定的または回避することができる。合理的なヒステリシスアルゴリズムは良い結果をもたらすはずです。次のアルゴリズムは実装が簡単で、さまざまな環境で展開されました。
For every route R, in addition to the route's metric m(R), maintain a smoothed version of m(R) written ms(R) (we RECOMMEND computing ms(R) as an exponentially smoothed average (see Section 3.7 of [RFC793]) of m(R) with a time constant equal to the Hello interval multiplied by a small number such as 3). If no route to a given destination is selected, then select the route with the smallest metric, ignoring the smoothed metric. If a route R is selected, then switch to a route R' only when both m(R') < m(R) and ms(R') < ms(R).
ルートのメトリックM（R）に加えて、すべてのルートRの場合、MS（R）の滑らかなバージョンを維持します（R）（R）、指数関数的に平滑化された平均としてMS（R）を計算することをお勧めします（RFC793のセクション3.7を参照）。】M（R）のM（R）のhello間隔に等しい時間定数を3）のような少数である。特定の宛先へのルートが選択されていない場合は、スムージングメトリックを無視して、最小のメトリックを持つルートを選択します。経路Rが選択されている場合は、M（R '）<M（R）およびMS（R'）<MS（R）の両方の場合にのみ、経路R 'に切り替える。
Intuitively, the smoothed metric is a long-term estimate of the quality of a route. The algorithm above works by only switching routes when both the instantaneous and the long-term estimates of the route's quality indicate that switching is profitable.
直感的には、平滑化されたメトリックは経路の品質の長期的な見積もりです。上記のアルゴリズムは、ルートの品質の瞬間的および長期推定値の両方がスイッチングが有益であることを示したときにルートのスイッチングルートだけによって機能します。
The choice of time constants is a trade-off between fast detection of mobility events and protocol overhead. Two instances of Babel running with different time constants will interoperate, although the resulting worst-case convergence time will be dictated by the slower of the two.
時間定数の選択は、モビリティイベントとプロトコルオーバーヘッドの高速検出の間のトレードオフです。異なる時定数で実行されているBabelの2つのインスタンスは相互運用しますが、結果として得られる最悪のコンバージェンス時間は2つの遅いことによって決まります。
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 to Babel's use of a redundant route table, and due to its reliance on triggered updates and explicit requests, the Update interval has little influence on the time needed to reconverge after an outage: in practice, it only has a significant effect on the time needed to acquire new routes after a mobility event. While the protocol allows intervals as low as 10 ms, such low values would cause significant amounts of protocol traffic for little practical benefit.
Hello間隔は最も重要な時定数です。停止またはモビリティイベントが1.5から3.5のhello間隔で検出されます。冗長ルートテーブルの使用、およびトリガされた更新および明示的要求への依存のために、更新間隔は停止後の再揺れに必要な時間にほとんど影響を及ぼしていません。実際には、時間に大きな影響を与えます。モビリティイベントの後に新しいルートを取得する必要があります。プロトコルは10ミリ秒ほどの間隔を可能にするが、そのような低い値はほとんど実用的な利益のためにかなりの量のプロトコルトラフィックを引き起こすであろう。
The following values have been found to work well in a variety of environments and are therefore RECOMMENDED default values:
次の値はさまざまな環境でうまく機能することがわかっているため、デフォルト値を推奨しています。
Multicast Hello interval: 4 seconds.
マルチキャストHello間隔：4秒。
Unicast Hello interval: infinite (no Unicast Hellos are sent).
ユニキャストHello Interval：Infinite（ユニキャストHellosは送信されません）。
Link cost: estimated using ETX on wireless links; 2-out-of-3 with C=96 on wired links.
リンクコスト：無線リンクでETXを使用した推定。有線リンクのC = 96で2 - OUT - 3。
IHU interval: the advertised IHU interval is always 3 times the Multicast Hello interval. IHUs are actually sent with each Hello on lossy links (as determined from the Hello history), but only with every third Multicast Hello on lossless links.
IHU間隔：アドバタイズされたIHU間隔は常にマルチキャストHello間隔の3倍です。IHUSは実際には紛失したリンクで各Helloとともに送信されますが、（Helloの歴史から決定されるように）は、ロスレスリンクに関する3番目のマルチキャストこんにちはごとにのみ。
Update interval: 4 times the Multicast Hello interval.
更新間隔：マルチキャストHello間隔の4倍。
IHU Hold time: 3.5 times the advertised IHU interval.
IHUホールドタイム：アドバタイズされたIHU間隔の3.5倍。
Route Expiry time: 3.5 times the advertised update interval.
経路満了時間：アドバタイズされた更新間隔の3.5倍。
Request timeout: initially 2 seconds, doubled every time a request is resent, up to a maximum of three times.
リクエストタイムアウト：最初は2秒、リクエストが再送信されるたびに、最大3回まで2倍になりました。
Urgent timeout: 0.2 seconds.
緊急のタイムアウト：0.2秒。
Source GC time: 3 minutes.
ソースGC時間：3分。
Route filtering is a procedure where an instance of a routing protocol either discards some of the routes announced by its neighbours or learns them with a metric that is higher than what would be expected. Like all distance-vector protocols, Babel has the ability to apply arbitrary filtering to the routes it learns, and implementations of Babel that apply different sets of filtering rules will interoperate without causing routing loops. The protocol's ability to perform route filtering is a consequence of the latitude given in Section 3.5.2: Babel can use any metric that is strictly monotonic, including one that assigns an infinite metric to a selected subset of routes. (See also Section 3.8.1, where requests for nonexistent routes are treated in the same way as requests for routes with infinite metric.)
ルートフィルタリングは、ルーティングプロトコルのインスタンスが、その隣接者によって発表されたルートの一部を破棄するか、またはそれらを予想されるものよりも高いメトリックで学習します。すべての距離 - ベクトルプロトコルと同様に、Babelはそれが学習するルートに任意のフィルタリングを適用することができ、異なるセットのフィルタリングルールを適用するBabelの実装はルーティングループを引き起こすことなく相互運用するでしょう。ルートフィルタリングを実行するプロトコルの機能は、セクション3.5.2で示されている緯度の結果です.BABELは、無限のメトリックをルートの選択されたサブセットに割り当てるものを含め、厳密に単調なメトリックを使用できます。（3.8.1項も参照してください。存在しないルートの要求は、Infinite Metricを使用したルートの要求と同じ方法で扱われます。）
It is not in general correct to learn a route with a metric smaller than the one it was announced with, or to replace a route's destination prefix with a more specific (longer) one. Doing either of these may cause persistent routing loops.
一般的に、それが発表されたものよりも小さいメトリックを小さくするか、またはルートの目的地プレフィックスをより具体的な（より長い）1つのルートを習得することは一般的ではありません。どちらかを実行すると、持続的なルーティングループが発生する可能性があります。
Route filtering is a useful tool, since it allows fine-grained tuning of the routing decisions made by the routing protocol. Accordingly, some implementations of Babel implement a rich configuration language that allows applying filtering to sets of routes defined, for example, by incoming interface and destination prefix.
ルートフィルタリングは、ルーティングプロトコルによって行われたルーティング決定のきめ細かいチューニングを可能にするので、便利なツールです。したがって、Babelのいくつかの実装形態は、例えば着信インターフェースおよび宛先プレフィックスによって定義されたルートのセットにフィルタリングを適用することを可能にするリッチ構成言語を実装する。
In order to limit the consequences of misconfiguration, Babel implementations provide a reasonable set of default filtering rules even when they don't allow configuration of filtering by the user. At a minimum, they discard routes with a destination prefix in fe80::/64, ff00::/8, 127.0.0.1/32, 0.0.0.0/32, and 224.0.0.0/8.
誤構成の結果を制限するために、Babel実装は、ユーザーによるフィルタリングの設定を許可しない場合でも、デフォルトのフィルタリングルールの合理的なセットを提供します。最低限、それらはFE80 :: / 64、FF00 :: / 8,127.0.0.1 / 32,0.0.0.0 / 32、および224.0.0.0/8の宛先プレフィックスでルートを破棄します。
Babel is an extensible protocol, and this document defines a number of mechanisms that can be used to extend the protocol in a backwards compatible manner:
Babelは拡張可能なプロトコルであり、この文書は、プロトコルを後方互換性のある方法で拡張するために使用できるメカニズムの数を定義します。
* increasing the version number in the packet header;
* パケットヘッダー内のバージョン番号を増やす。
* defining new TLVs;
* 新しいTLVを定義する。
* defining new sub-TLVs (with or without the mandatory bit set);
* 新しいサブTLVを定義する（必須のビットセットの有無にかかわらず）。
* defining new AEs;
* 新しいAESを定義する。
* using the packet trailer.
* パケットトレーラを使用する。
This appendix is intended to guide designers of protocol extensions in choosing a particular encoding.
この付録は、特定の符号化を選択する際にプロトコル拡張の設計者を導くことを目的としています。
The version number in the Babel header should only be increased if the new version is not backwards compatible with the original protocol.
新しいバージョンが元のプロトコルと互換性がない場合にのみ、Babelヘッダーのバージョン番号を増やす必要があります。
In many cases, an extension could be implemented either by defining a new TLV or by adding a new sub-TLV to an existing TLV. For example, an extension whose purpose is to attach additional data to route updates can be implemented either by creating a new "enriched" Update TLV, by adding a nonmandatory sub-TLV to the Update TLV, or by adding a mandatory sub-TLV.
多くの場合、拡張子は新しいTLVを定義するか、既存のTLVに新しいSUB-TLVを追加することによって実装できます。たとえば、目的のデータをルートアップデートに添付する拡張機能は、Update TLVに非マンデトリーSUB-TLVを追加することによって、または必須のサブTLVを追加することによって、新しい「充実した」アップデートTLVを作成することによって実装できます。
The various encodings are treated differently by implementations that do not understand the extension. In the case of a new TLV or of a sub-TLV with the mandatory bit set, the whole TLV is ignored by implementations that do not implement the extension, while in the case of a nonmandatory sub-TLV, the TLV is parsed and acted upon, and only the unknown sub-TLV is silently ignored. Therefore, a nonmandatory sub-TLV should be used by extensions that extend the Update in a compatible manner (the extension data may be silently ignored), while a mandatory sub-TLV or a new TLV must be used by extensions that make incompatible extensions to the meaning of the TLV (the whole TLV must be thrown away if the extension data is not understood).
さまざまなエンコーディングは、拡張機能を理解していない実装によって異なります。必須のビットセットを持つ新しいTLVまたはSUB-TLVの場合、非マンダトリー・サブTLVの場合、TLVは解析され、行動する実装によってTLV全体が無視されます。際、未知のサブTLVだけが黙って無視されます。したがって、非マンダティブSUB-TLVは、互換性のある方法で更新を拡張する拡張（拡張データが黙って無視される可能性があります）、必須のサブTLVまたは新しいTLVを互換性のない拡張機能を持つ拡張機能で使用する必要があります。延長データが理解されていない場合は、TLVの意味（TLV全体を捨てなければなりません）。
Experience shows that the need for additional data tends to crop up in the most unexpected places. Hence, it is recommended that extensions that define new TLVs should make them self-terminating and allow attaching sub-TLVs to them.
経験は、追加のデータの必要性が最も予想外の場所で切り取る傾向があることを示しています。したがって、新しいTLVを定義する拡張機能は、それらを自己終了させ、サブTLVをそれらに添付することを許可することをお勧めします。
Adding a new AE is essentially equivalent to adding a new TLV: Update TLVs with an unknown AE are ignored, just like unknown TLVs. However, adding a new AE is more involved than adding a new TLV, since it creates a new set of compression state. Additionally, since the Next Hop TLV creates state specific to a given address family, as opposed to a given AE, a new AE for a previously defined address family must not be used in the Next Hop TLV if backwards compatibility is required. A similar issue arises with Update TLVs with unknown AEs establishing a new router-id (due to the Router-Id flag being set). Therefore, defining new AEs must be done with care if compatibility with unextended implementations is required.
新しいAEを追加するのは、不明なTLVと同じように、Update TLVを新しいTLVを追加するのに基本的に同じです。ただし、新しいTLVを追加するよりも新しいAEを追加することは、新しい圧縮状態のセットを作成するためです。さらに、次のホップTLVは、特定のAEとは対照的に、特定のアドレスファミリに固有の状態を作成するので、前後に定義されたアドレスファミリのための新しいAEを次のホップTLVで使用しないでください。新しいRouter-IDを設定した不明なAESを備えたアップデートTLVSを使用すると、（ルータIDフラグが設定されているため）という同様の問題が発生します。したがって、非拡張型実装との互換性が必要な場合は、新しいAESを定義する必要があります。
The packet trailer is intended to carry cryptographic signatures that only cover the packet body; storing the cryptographic signatures in the packet trailer avoids clearing the signature before computing a hash of the packet body, and makes it possible to check a cryptographic signature before running the full, stateful TLV parser. Hence, only TLVs that don't need to be protected by cryptographic security protocols should be allowed in the packet trailer. Any such TLVs should be easy to parse and, in particular, should not require stateful parsing.
パケットトレーラは、パケット本体のみを覆う暗号署名を持つことを目的としています。パケットトレーラ内の暗号署名を格納することは、パケット本体のハッシュを計算する前に署名のクリアを回避し、完全なステートフルTLVパーサを実行する前に暗号署名をチェックすることを可能にする。したがって、暗号化セキュリティプロトコルによって保護される必要がないTLVだけをパケットトレーラに許可する必要があります。そのようなTLVはあらゆるTLVが解析が容易であるべきであり、特にステートフル解析を必要としないはずです。
Babel is a fairly economic protocol. Updates take between 12 and 40 octets per destination, depending on the address family and how successful compression is; in a dual-stack flat network, an average of less than 24 octets per update is typical. The route table occupies about 35 octets per IPv6 entry. To put these values into perspective, a single full-size Ethernet frame can carry some 65 route updates, and a megabyte of memory can contain a 20,000-entry route table and the associated source table.
Babelはかなり経済的なプロトコルです。更新先は、アドレスファミリとどの程度成功したかによって、宛先ごとに12~40オクテットがかかります。デュアルスタックフラットネットワークでは、更新ごとに24オクテット未満の平均が典型的です。ルートテーブルはIPv6エントリごとに約35オクテットを占めます。これらの値をパースペクティブにするために、単一のフルサイズのイーサネットフレームはいくつかの65ルートアップデートを伝送でき、メガバイトのメモリには20,000エントリのルートテーブルと関連するソーステーブルを含めることができます。
Babel is also a reasonably simple protocol. One complete implementation consists of less than 12,000 lines of C code, and it compiles to less than 120 KB of text on a 32-bit CISC architecture; about half of this figure is due to protocol extensions and user-interface code.
Babelはまたかなり単純なプロトコルです。1つの完全な実装は12,000行以内のCコードで構成され、32ビットCISCアーキテクチャ上の120 KB未満のテキストにコンパイルされます。この図の約半数は、プロトコル拡張機能とユーザーインターフェイスコードによるものです。
Nonetheless, in some very constrained environments, such as PDAs, microwave ovens, or abacuses, it may be desirable to have subset implementations of the protocol.
それにもかかわらず、PDA、電子レンジ、または不安定ないくつかの非常に拘束された環境では、プロトコルのサブセット実装を有することが望ましいかもしれない。
There are many different definitions of a stub router, but for the needs of this section, a stub implementation of Babel is one that announces one or more directly attached prefixes into a Babel network but doesn't re-announce any routes that it has learnt from its neighbours, and always prefers the direct route to a directly attached prefix to a route learnt over the Babel protocol, even when the prefixes are the same. It may either maintain a full routing table or simply select a default gateway through any one of its neighbours that announces a default route. Since a stub implementation never forwards packets except from or to a directly attached link, it cannot possibly participate in a routing loop, and hence it need not evaluate the feasibility condition or maintain a source table.
スタブルータのさまざまな定義がさまざまですが、このセクションのニーズに応じて、Babelのスタブ実装は1つ以上の直接接続されているプレフィックスをBabelネットワークに発表するものですが、それが学んだルートを再発表しないものです。その隣人から、そして常にプレフィックスが同じであっても、Babelプロトコルを介して学んだ経路への直接的なルートを好む。それは完全なルーティングテーブルを維持するか、デフォルトのルートを発表するその隣接のいずれかを介してデフォルトゲートウェイを単に選択することができます。スタブ実装は、直接接続されているリンク以外または直接接続されたリンクを除くパケットを転送することは決してないので、ルーティングループに参加することはできません。したがって、実現可能性状態を評価するか、またはソース表を維持する必要はありません。
No matter how primitive, a stub implementation must parse sub-TLVs attached to any TLVs that it understands and check the mandatory bit. It must answer acknowledgment requests and must participate in the Hello/IHU protocol. It must also be able to reply to seqno requests for routes that it announces, and it should be able to reply to route requests.
どんなにプリミティブであっても、スタブ実装は、それが理解しているすべてのTLVに添付されたサブTLVを解析し、必須ビットをチェックする必要があります。確認応答要求に応答し、Hello / IHUプロトコルに参加する必要があります。また、発表したルートのSEQNO要求に返信できる必要があります。ルートリクエストに返信できるはずです。
Experience shows that an IPv6-only stub implementation of Babel can be written in less than 1,000 lines of C code and compile to 13 KB of text on 32-bit CISC architecture.
経験は、BabelのIPv6専用スタブ実装を1,000行以内のCコードで書くことができ、32ビットCISCアーキテクチャ上で13 KBのテキストにコンパイルできることを示しています。
The protocol defined in this document is a successor to the protocol defined in [RFC6126] and [RFC7557]. While the two protocols are not entirely compatible, the new protocol has been designed so that it can be deployed in existing RFC 6126 networks without requiring a flag day.
この文書で定義されているプロトコルは、[RFC6126]と[RFC7557]で定義されているプロトコルの後継です。2つのプロトコルは完全に互換性がないが、新しいプロトコルはフラグの日を必要とせずに既存のRFC 6126ネットワークに展開できるように設計されています。
There are three optional features that make this protocol incompatible with its predecessor. First of all, RFC 6126 did not define Unicast Hellos (Section 3.4.1), and an implementation of RFC 6126 will misinterpret a Unicast Hello for a Multicast one; since the sequence number space of Unicast Hellos is distinct from the sequence number space of Multicast Hellos, sending a Unicast Hello to an implementation of RFC 6126 will confuse its link quality estimator. Second, RFC 6126 did not define unscheduled Hellos, and an implementation of RFC 6126 will mis-parse Hellos with an interval equal to 0. Finally, RFC 7557 did not define mandatory sub-TLVs (Section 4.4), and thus an implementation of RFCs 6126 and 7557 will not correctly ignore a TLV that carries an unknown mandatory sub-TLV; depending on the sub-TLV, this might cause routing pathologies.
このプロトコルをその先行者と互換性がないようにするための3つのオプション機能があります。まず第一に、RFC 6126はユニキャストHellos（セクション3.4.1）を定義しておらず、RFC 6126の実装はマルチキャスト1のユニキャストHelloを誤って解釈します。ユニキャストHellosのシーケンス番号スペースはマルチキャストHelloのシーケンス番号スペースとは異なり、ユニキャストHelloをRFC 6126の実装に送信すると、そのリンク品質推定量が混乱します。第二に、RFC 6126は予定外のhelloを定義していませんでした、そしてRFC 6126の実装は0に等しい間隔でhellosを誤って解析します。最後に、RFC 7557は必須のサブTLV（セクション4.4）を定義していませんでした6126と7557は、未知の必須のサブTLVを搭載したTLVを正しく無視しません。サブTLVに応じて、これによりルーティングパスロジーが発生する可能性があります。
An implementation of this specification that never sends Unicast or unscheduled Hellos and doesn't implement any extensions that use mandatory sub-TLVs is safe to deploy in a network in which some nodes implement the protocol described in RFCs 6126 and 7557.
ユニキャストまたは予定外のhelloを送信し、必須のサブTLVを使用する拡張機能を実装していないこの仕様の実装は、いくつかのノードがRFC 6126および7557に記載されているプロトコルを実装するネットワークに展開しても安全です。
Two changes need to be made to an implementation of RFCs 6126 and 7557 so that it can safely interoperate in all cases with implementations of this protocol. First, it needs to be modified either to ignore or to process Unicast and unscheduled Hellos. Second, it needs to be modified to parse sub-TLVs of all the TLVs that it understands and that allow sub-TLVs, and to ignore the TLV if an unknown mandatory sub-TLV is found. It is not necessary to parse unknown TLVs, as these are ignored in any case.
このプロトコルの実装ですべての場合で安全に相互運用できるように、RFCS 6126および7557の実装に2つの変更を加える必要があります。まず、ユニキャストと予定外のhelloを無視または処理するために修正する必要があります。第二に、理解しているすべてのTLVのサブTLVを解析し、それがサブTLVを許可し、未知の必須サブTLVが見つかった場合にTLVを無視するように変更する必要があります。どんな場合でも無視されるので、未知のTLVを解析する必要はありません。
There are other changes, but these are not of a nature to prevent interoperability:
他の変更がありますが、これらは相互運用性を防ぐための性質ではありません。
* the conditions on route acquisition (Section 3.5.3) have been relaxed;
* ルート取得の条件（セクション3.5.3）は緩和されました。
* route selection should no longer use the route's sequence number (Section 3.6);
* ルート選択はルートのシーケンス番号を使用しなくなります（セクション3.6）。
* the format of the packet trailer has been defined (Section 4.2);
* パケットトレーラのフォーマットが定義されています（セクション4.2）。
* router-ids with a value of all-zeros or all-ones have been forbidden (Section 4.1.3);
* すべてのゼロまたはすべてのものの値を持つrouter-idは禁止されています（セクション4.1.3）。
* the compression state is now specific to an address family rather than an address encoding (Section 4.5);
* 圧縮状態は、アドレスエンコーディングではなくアドレスファミリに固有のものです（セクション4.5）。
* packet pacing is now recommended (Section 3.1).
* パケットペーシングが推奨されます（セクション3.1）。
Acknowledgments
謝辞
A number of people have contributed text and ideas to this specification. The authors are particularly indebted to Matthieu Boutier, Gwendoline Chouasne, Margaret Cullen, Donald Eastlake, Toke Høiland-Jørgensen, Benjamin Kaduk, Joao Sobrinho, and Martin Vigoureux. The previous version of this specification [RFC6126] greatly benefited from the input of Joel Halpern. The address compression technique was inspired by [PACKETBB].
この仕様書には、多くの人がテキストやアイデアを貢献しています。著者らは特にマタチューブティエ、Gwendoline Chouasne、Margaret Cullen、Donald Eastlake、TokeHøiland-Jørgensen、Benjamin Kaduk、Joao Sobrinho、Martin Vigoueuxにはお世話になっています。この仕様の以前のバージョン[RFC6126]は、Joel Halpernの入力から大きく恩恵を受けました。アドレス圧縮技術は[PacketBB]に触発されました。
Authors' Addresses
著者の住所
Juliusz Chroboczek IRIF, University of Paris-Diderot Case 7014 75205 Paris CEDEX 13 France
Juliusz Chroboczek IRIF、パリ大学ケース7014 75205 Paris Cedex 13フランス
Email: jch@irif.fr
David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America
David Schinazi Google LLC 1600 Amphitheater Parkway Mountain View、カリフォルニア州94043アメリカ合衆国
Email: dschinazi.ietf@gmail.com