[要約] RFC 6126は、Babelルーティングプロトコルに関する仕様であり、ネットワーク内のルーティング情報の配布と更新を目的としています。
Independent Submission J. Chroboczek
Request for Comments: 6126 PPS, University of Paris 7
Category: Experimental April 2011
ISSN: 2070-1721
The Babel Routing Protocol
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.
Babelは、ループ回避の距離ベクトルルーティングプロトコルであり、通常の有線ネットワークと無線メッシュネットワークの両方で堅牢で効率的です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6126.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6126で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Features . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specification of Requirements . . . . . . . . . . . . . . 4
2. Conceptual Description of the Protocol . . . . . . . . . . . . 4
2.1. Costs, Metrics, and Neighbourship . . . . . . . . . . . . 5
2.2. The Bellman-Ford Algorithm . . . . . . . . . . . . . . . . 5
2.3. Transient Loops in Bellman-Ford . . . . . . . . . . . . . 6
2.4. Feasibility Conditions . . . . . . . . . . . . . . . . . . 6
2.5. Solving Starvation: Sequencing Routes . . . . . . . . . . 8
2.6. Requests . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Multiple Routers . . . . . . . . . . . . . . . . . . . . . 10
2.8. Overlapping Prefixes . . . . . . . . . . . . . . . . . . . 11
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Message Transmission and Reception . . . . . . . . . . . . 11
3.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 12
3.3. Acknowledged Packets . . . . . . . . . . . . . . . . . . . 15
3.4. Neighbour Acquisition . . . . . . . . . . . . . . . . . . 15
3.5. Routing Table Maintenance . . . . . . . . . . . . . . . . 17
3.6. Route Selection . . . . . . . . . . . . . . . . . . . . . 21
3.7. Sending Updates . . . . . . . . . . . . . . . . . . . . . 22
3.8. Explicit Route Requests . . . . . . . . . . . . . . . . . 24
4. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 27
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 29
4.3. TLV Format . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4. Details of Specific TLVs . . . . . . . . . . . . . . . . . 30
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Normative References . . . . . . . . . . . . . . . . . . . 40
7.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Cost and Metric Computation . . . . . . . . . . . . . 41
A.1. Maintaining Hello History . . . . . . . . . . . . . . . . 41
A.2. Cost Computation . . . . . . . . . . . . . . . . . . . . . 42
A.3. Metric Computation . . . . . . . . . . . . . . . . . . . . 43
Appendix B. Constants . . . . . . . . . . . . . . . . . . . . . . 43
Appendix C. Simplified Implementations . . . . . . . . . . . . . 44
Appendix D. Software Availability . . . . . . . . . . . . . . . . 45
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.
Babelは、ループ回避型の距離ベクトルルーティングプロトコルであり、プレフィックスベースのルーティングを使用するネットワークとフラットルーティングを使用するネットワーク（「メッシュネットワーク」）の両方、および比較的安定した有線ネットワークと高度の両方で堅牢かつ効率的になるように設計されています。動的無線ネットワーク。
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].
Babelを不安定なネットワークに適した主な特性は、単純な距離ベクトルルーティングプロトコル[RIP]とは異なり、再収束中のルーティングループやブラックホールなどのルーティング病理の頻度と持続時間を大幅に制限することです。モビリティイベントが検出された後でも、Babelネットワークは通常ループフリーのままです。その後、Babelはループの自由とネットワークの接続性を維持する構成にすばやく再収束しますが、必ずしも最適とは限りません。多くの場合、この操作ではパケット交換はまったく必要ありません。次に、Babelは、分単位の時間で、最適な構成にゆっくりと収束します。これは、Destination-Sequenced Distance-Vectorルーティング[DSDV]によって開拓された手法である、シーケンスルートを使用することで実現されます。
More precisely, Babel has the following properties:
より正確には、Babelには次のプロパティがあります。
o when every prefix is originated by at most one router, Babel never suffers from routing loops;
o すべてのプレフィックスが最大1つのルーターから発信されている場合、Babelはルーティングループの影響を受けません。
o when a prefix is originated by multiple routers, Babel may occasionally create a transient routing loop for this particular prefix; this loop disappears in a time proportional to its 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;
o プレフィックスが複数のルーターから発信された場合、Babelはこの特定のプレフィックスに対して一時的なルーティングループを作成することがあります。このループは、その直径に比例する時間で消え、関係するルーターが同じプレフィックスのルーティングループに参加することは決してありません（任意のガベージコレクション（GC）時間まで）。
o assuming reasonable 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.
o 妥当なパケット損失率を想定すると、モビリティイベントの後に発生する可能性のあるルーティングブラックホールは、ネットワークの直径に最大比例する時間で修正されます。
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 wireless environment.
Babelノードは、異なるパラメーターで構成されている場合でも、関連付けを正常に確立します。たとえば、バッテリー残量が少ないモバイルノードは、壁の電力にアクセスできるノードよりも大きな時定数（helloや更新間隔など）を使用することを選択できます。逆に、高レベルのモビリティを検出するノードは、より小さい時定数を使用することを選択できます。このような異種ネットワークを構築する機能により、Babelは特にワイヤレス環境に適応します。
Finally, Babel is a hybrid routing protocol, in the sense that it can carry routes for multiple network-layer protocols (IPv4 and IPv6), whichever 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, Babel does impose a hold time when a prefix is retracted (Section 3.5.5). 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. Hence, if a previously deaggregated prefix becomes aggregated, it will be unreachable for a few minutes. This makes Babel unsuitable for use in mobile networks that implement automatic prefix aggregation.
第2に、プレフィックスが取り消されると、Babelは保持時間を課します（セクション3.5.5）。この保持時間は、撤回されている正確なプレフィックスには適用されません。したがって、再び使用可能になった場合の高速再コンバージェンスは妨げられませんが、それをカバーするより短いプレフィックスには適用されます。したがって、以前にデアグリゲートされたプレフィックスがアグリゲートされると、数分間到達できなくなります。このため、Babelは、自動プレフィックス集約を実装するモバイルネットワークでの使用には適していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Babel is a mostly loop-free distance vector protocol: it is based on the Bellman-Ford protocol, 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は、ほとんどループのない距離ベクトルプロトコルです。これは、由緒あるRIP [RIP]と同様に、Bellman-Fordプロトコルに基づいていますが、ループの形成を完全に防止するか、ループが確実に消えるようにする多くの改良が含まれています。タイムリーな方法で、再び形成されません。
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を修正します。読者は、同じアルゴリズムがすべてのソースに対して実行されることを思い出すでしょう。
As many routing algorithms, Babel computes costs of links between any two neighbouring nodes, abstract values attached to the edges between two nodes. We write C(A, B) for the cost of the edge from node A to node B.
多くのルーティングアルゴリズムと同様に、Babelは2つの隣接ノード間のリンクのコスト、2つのノード間のエッジに接続された抽象的な値を計算します。ノードAからノードBへのエッジのコストを表すC（A、B）を記述します。
Given a route between any two nodes, the metric of the route is the sum of the costs of all the edges along the route. The goal of the routing algorithm is to compute, for every source S, the tree of the routes of lowest metric to S.
任意の2つのノード間のルートが与えられた場合、ルートのメトリックは、ルートに沿ったすべてのエッジのコストの合計です。ルーティングアルゴリズムの目的は、すべてのソース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 broadcasts 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（ "I Heard You"）メッセージを送信します。ノードAは、ネイバーBから受信したHelloメッセージとIHUメッセージから得られた情報から、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つのデータを維持します。S（D（A）と書かれた）への推定距離と、NH（A）と書かれたSへの次のホップのルーターです。最初は、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）に設定されます。そうでない場合、Aは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 diagram:
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.
Aはリンクの障害を検出すると、ネクストホップをBに切り替え（メトリック2でSへのルートをまだアドバタイズしています）、メトリック3で新しいルートをアドバタイズし、次にメトリック3で新しいルートをアドバタイズします。このプロセス選択したネイバーを変更し、メトリックを増やすノードの数は、アドバタイズされたメトリックが「無限」に到達するまで続きます。この値は、ルーティングプロトコルが伝送できるすべてのメトリックよりも大きい値です。
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 transitory "micro-loops" during reconvergence).
多くの異なる実現可能性条件が可能です。たとえば、BGPは（かなり抜本的な）実現可能性条件を備えた距離ベクトルプロトコルとしてモデル化できます。ルーティング更新は、受信ノードのAS番号が更新のAS-Path属性に含まれていない場合にのみ受け入れられます（BGPの実現可能性に注意）状態は、再収束中に一時的な「マイクロループ」が存在しないことを保証しません）。
Another simple feasibility condition, used in Destination-Sequenced Distance-Vector (DSDV) routing [DSDV] and in Ad hoc On-Demand Distance Vector (AODV) routing, 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 could decide that a route is feasible only 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 successor, then D(B) < D(A), which implies that the forwarding graph is loop-free.
Destination-Sequenced Distance-Vector（DSDV）ルーティング[DSDV]およびAd hoc On-Demand Distance Vector（AODV）ルーティングで使用される別の単純な実現可能性条件は、次の観察から生じます。ルーティングループは、ルーターが以前に選択したルートよりもメトリックが大きいルートに切り替えました。したがって、ローカルノードでのメトリックが現在選択されているルートのメトリックよりも大きくない場合にのみルートが実行可能であると判断できます。つまり、メトリックD（B）を含むアナウンスがC（A 、B）+ D（B）<= D（A）。すべてのルーターがこの制約に従う場合、すべてのルーターのメトリックは増加せず、次の不変式が常に保持されます。AがBを後続として選択した場合、D（B）<D（A）、つまり転送グラフループフリーです。
Babel uses a slightly more refined feasibility condition, used in 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 [DUAL]で使用される、もう少し洗練された実現可能性条件を使用します。ルーターAが与えられたとき、FD（A）と書かれたAの実現可能距離を、AがSについてこれまでに近隣にアドバタイズした最小のメトリックとして定義します。 AのネイバーBによって送信された更新は、BによってアドバタイズされたメトリックD（B）がAの実現可能距離よりも厳密に小さい場合、つまりD（B）<FD（A）の場合に実現可能です。
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）です。ここで、Aがメトリック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を通るルートを選択し、D（A）= FD（A）= 2です。D（C）= 1 <FD（A）なので、 Cを通る代替ルートはAで実現可能ですが、そのメトリック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, 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）です。このプロパティは、Aが更新を送信するときに保持されるため、常にtrueになり、転送グラフにループが発生しないことが保証されます。
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 a spurious starvation.
AからSへの唯一のルート、つまりBを経由するルートは実行できません。Aは誤った飢餓に苦しんでいます。
At this point, the whole network must be rebooted in order to solve the starvation; this is essentially what EIGRP does when it performs a global synchronisation of all the routers in the network with the source (the "active" phase of EIGRP).
この時点で、飢餓を解決するためにネットワーク全体を再起動する必要があります。これは基本的に、ネットワーク内のすべてのルーターとソース（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.
Babelは、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:
Sがシーケンス番号を増やし、新しいシーケンス番号が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 necessarily used in route selection: a node will normally ignore the sequence number when selecting a route (Section 3.6).
シーケンス番号は実現可能性を決定するために使用されますが、ルート選択では必ずしも使用されないことに注意してください。ノードは通常、ルートを選択するときにシーケンス番号を無視します（セクション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 every 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.
異なるルーター間でシーケンス番号を同期することは問題があるため、Babelは同じプレフィックスのルートが異なるルーターによって発信された場合、それらを別個のエンティティとして扱います。すべてのルートアナウンスは、発信元ルーターのルーターIDを伝達し、プレフィクスごとの実行可能距離は維持されません。ただし、ソースごとに、ソースはrouter-idとプレフィックスのペアです。実際には、Babelはすべてのソースへの転送グラフのループフリーを保証します。複数の非循環グラフの結合は一般に非循環ではないため、プレフィックスが複数のルーターによって発信された場合、Babelは一般にループの自由を保証しませんが、ループは、ループの直径に最も比例して一度に切断されます- -更新がルーティングループを「一巡」するとすぐ。
Consider for example the following diagram, where A has selected the default route through S, and B has selected the one through S':
たとえば、AがSを介してデフォルトルートを選択し、Bが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に切り替わり、Bが同時にAに切り替わるのを妨げるものはありません。ただし、AがBへの新しいルートを正常にアドバタイズするとすぐに、Aを経由するルートはBに対して実行不可能になります。逆に、BがアドバタイズするとすぐにAを通るルート、Bを通るルートは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.
実際には、ルーティングループは、ルーティング情報がループを一周すると、遅くとも消えます。このプロセスはパケットの損失によって遅延する可能性があるため、BabelはルーターIDの変更後に更新が確実に送信されるように一定の努力をしています。
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. Babel avoids this pitfall by maintaining an "unreachable" route for a few minutes after a route is retracted; the time for which such a route must be maintained should be the worst-case propagation time of the retraction of the route to C.
ノードCに障害が発生したとします。 Bがデフォルトのルートに従ってC宛てのパケットを転送する場合、ルーティングループが形成され、AがBがCへの直接ルートを撤回することを知るまで続きます。バベルは、「到達不能」ルートを数分間維持することでこの落とし穴を回避します。ルートが撤回された。このようなルートを維持する必要がある時間は、Cへのルートを撤回する最悪の場合の伝播時間である必要があります。
Every Babel speaker is assigned a router-id, which is an arbitrary string of 8 octets that is assumed unique across the routing domain. We suggest that router-ids should be assigned in modified EUI-64 format [ADDRARCH]. (As a matter of fact, the protocol encoding is slightly more compact when router-ids are assigned in the same manner as the IPv6 layer assigns host IDs.)
すべてのBabelスピーカーにはルーターIDが割り当てられます。これは、ルーティングドメイン全体で一意であると想定される8オクテットの任意の文字列です。 router-idは変更されたEUI-64形式[ADDRARCH]で割り当てることをお勧めします。 （実際のところ、IPv6レイヤーがホストIDを割り当てるのと同じ方法でルーターIDが割り当てられる場合、プロトコルのエンコードは少しコンパクトになります。）
Babel protocol packets are sent in the body of a UDP datagram. Each Babel packet consists of one or more TLVs.
Babelプロトコルパケットは、UDPデータグラムの本文で送信されます。各Babelパケットは、1つ以上のTLVで構成されています。
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 (this is the usual case) 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パケットは、よく知られている（リンクローカル）マルチキャストアドレス（これは通常のケースです）または（リンクローカル）ユニキャストアドレスに送信できます。通常の動作では、Babelスピーカーはマルチキャストパケットとユニキャストパケットの両方を近隣に送信します。
With the exception of Hello TLVs and acknowledgements, all Babel TLVs can be sent to either unicast or multicast addresses, and their semantics does not depend on whether the destination was a unicast or 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.
Hello TLVと確認応答を除いて、すべてのBabel TLVはユニキャストアドレスまたはマルチキャストアドレスのいずれかに送信でき、それらのセマンティクスは、宛先がユニキャストアドレスであるかマルチキャストアドレスであるかに依存しません。したがって、Babelスピーカーは、パケットを解釈するために、受信するパケットの宛先アドレスを判別する必要はありません。
A moderate amount of jitter is applied to packets sent by a Babel speaker: outgoing TLVs are buffered and SHOULD be sent with a small 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スピーカーによって送信されるパケットに適用されます。発信TLVはバッファリングされ、小さなランダム遅延で送信する必要があります（SHOULD）。これは2つの目的で行われます。ネットワーク全体での複数のBabelスピーカーの同期を回避し、複数のTLVを単一のパケットに集約できるようにします。
The exact delay and amount of jitter applied to a packet depends on whether it contains any urgent TLVs. Acknowledgement TLVs MUST be sent before the deadline specified in the corresponding request. The particular class of updates specified in Section 3.7.2 MUST be sent in a timely manner. The particular class of request and update TLVs specified in Section 3.8.2 SHOULD be sent in a timely manner.
パケットに適用される正確な遅延とジッターの量は、緊急のTLVが含まれているかどうかによって異なります。確認応答TLVは、対応する要求で指定された期限の前に送信する必要があります。セクション3.7.2で指定された特定のクラスの更新は、タイムリーに送信する必要があります。セクション3.8.2で指定された特定のクラスの要求および更新TLVは、タイムリーに送信する必要があります（SHOULD）。
Every Babel speaker maintains a number of data structures.
すべてのBabelスピーカーは、いくつかのデータ構造を維持しています。
A node's sequence number is a 16-bit integer that is included in route updates sent for routes originated by this node. A node increments its sequence number (modulo 2^16) whenever it receives a request for a new sequence number (Section 3.8.1.2).
ノードのシーケンス番号は16ビット整数で、このノードが発信したルートに送信されるルート更新に含まれています。ノードは、新しいシーケンス番号（3.8.1.2項）の要求を受信すると、シーケンス番号（2 ^ 16を法とする）をインクリメントします。
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.
選択されたルートが失敗したときに他のノードが実行可能な代替ルートを持つ可能性が低くなるので、ノードはそのシーケンス番号（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 Hello seqno, a 16-bit integer that is sent with each Hello TLV on this interface and is incremented (modulo 2^16) whenever a Hello is sent. (Note that an interface's 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 Hello timer, which governs the sending of periodic Hello and IHU packets, and the update timer, which governs the sending of periodic route updates.
各インターフェイステーブルエントリには2つのタイマーが関連付けられています。Helloタイマーは、定期的なHelloパケットとIHUパケットの送信を制御し、更新タイマーは定期的なルート更新の送信を制御します。
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パケットが最近受信されたすべてのネイバーインターフェイスのリストが含まれています。ネイバーテーブルは、形式（インターフェイス、アドレス）のペアでインデックスが付けられ、すべてのネイバーテーブルエントリには次のデータが含まれます。
o the local node's interface over which this neighbour is reachable;
o このネイバーが到達可能なローカルノードのインターフェース。
o the address of the neighbouring interface;
o 隣接インターフェースのアドレス。
o a history of recently received 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;
o この近隣から最近受信したHelloパケットの履歴。これは、たとえば、このネイバーによって最後に送信されたn個のhelloのうちのどれがローカルノードによって受信されたかを示す、いくつかの小さな値nのnビットのシーケンスである場合があります。
o 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;
o このネイバーから受信した最後のIHUパケットの「送信コスト」値、またはこのネイバーのIHUホールドタイマーが期限切れの場合は16進数のFFFF（無限大）。
o the neighbour's expected Hello sequence number, an integer modulo 2^16.
o 隣人の予想されるHelloシーケンス番号、2 ^ 16を法とする整数。
There are two timers associated with each neighbour entry -- the hello timer, which is initialised from the interval value carried by Hello TLVs, and the IHU timer, which is initialised to a small multiple of the interval carried in IHU TLVs.
各ネイバーエントリには2つのタイマーが関連付けられています。HelloTLVによって伝送される間隔値から初期化されるhelloタイマーと、IHU TLVによって伝送される間隔の小さな倍数に初期化される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 fairly common situation when wireless nodes with multiple radios are involved.
ネイバーテーブルは、ルータIDではなくIPアドレスによってインデックスが作成されることに注意してください。ネイバーシップは、ノード間ではなく、インターフェイス間の関係です。したがって、複数のインターフェースを持つ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: o the prefix (prefix, plen), where plen is the prefix length, that this entry applies to;
ソーステーブルは、実現可能距離を記録するために使用されます。これは（prefix、plen、router-id）という形式のトリプルでインデックスが付けられ、すべてのソーステーブルエントリには次のデータが含まれます。oプレフィックス（prefix、plen）。ここで、plenはこのエントリが適用されるプレフィックス長です。
o the router-id of a router originating this prefix;
o このプレフィックスを発信したルーターのrouter-id。
o a pair (seqno, metric), this source's feasibility distance.
o ペア（シーケンス番号、メトリック）、このソースの実行可能距離。
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:
ルートテーブルには、このノードが認識しているルートが含まれています。これは、形式（プレフィックス、プレン、ネイバー）のトリプルでインデックスが付けられ、すべてのルートテーブルエントリには次のデータが含まれます。
o the source (prefix, plen, router-id) for which this route is advertised;
o このルートがアドバタイズされるソース（prefix、plen、router-id）。
o the neighbour that advertised this route;
o このルートをアドバタイズしたネイバー。
o the metric with which this route was advertised by the neighbour, or FFFF hexadecimal (infinity) for a recently retracted route;
o このルートがネイバーによってアドバタイズされたメトリック、または最近撤回されたルートのFFFF 16進数（無限）。
o the sequence number with which this route was advertised;
o このルートがアドバタイズされたシーケンス番号。
o the next-hop address of this route;
o このルートのネクストホップアドレス。
o a boolean flag indicating whether this route is selected, i.e., whether it is currently being used for forwarding and is being advertised.
o このルートが選択されているかどうか、つまり現在転送に使用され、アドバタイズされているかどうかを示すブールフラグ。
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.4.
各ルートテーブルエントリに関連付けられているタイマーは1つです。ルートの有効期限タイマーです。セクション3.5.4で指定されているように初期化およびリセットされます。
The table of pending 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 prefixes, and every entry in this table contains the following data:
保留中の要求のテーブルには、ローカルノードが送信した（ローカルで発信されたため、または転送されたため）まだ応答が受信されていないseqno要求のリストが含まれています。このテーブルにはプレフィックスでインデックスが付けられ、このテーブルのすべてのエントリには次のデータが含まれています。
o the prefix, router-id, and seqno being requested;
o 要求されているプレフィックス、ルーターID、およびシーケンス番号。
o the neighbour, if any, on behalf of which we are forwarding this request;
o 私たちがこのリクエストを転送している隣人があれば、その隣人。
o a small integer indicating the number of times that this request will be resent if it remains unsatisfied.
o この要求が満たされない場合に再送される回数を示す小さな整数。
There is one timer associated with each pending request; it governs both the resending of requests and their expiry.
保留中の各要求に関連付けられた1つのタイマーがあります。リクエストの再送信と有効期限の両方を管理します。
A Babel speaker may request that any neighbour receiving a given packet reply with an explicit acknowledgement within a given time. While the use of acknowledgement requests is optional, every Babel speaker MUST be able to reply to such a request.
Babelスピーカーは、特定のパケット受信中のネイバーに、特定の時間内に明示的な確認応答を返信するように要求できます。確認要求の使用はオプションですが、すべてのBabelスピーカーはそのような要求に応答できる必要があります。
An acknowledgement MUST be sent to a unicast destination. On the other hand, acknowledgement requests may be sent to either unicast or multicast destinations, in which case they request an acknowledgement from all of the receiving nodes.
確認はユニキャスト宛先に送信されなければなりません。一方、確認応答要求はユニキャスト宛先またはマルチキャスト宛先のいずれかに送信できます。その場合、すべての受信ノードから確認応答を要求します。
When to request acknowledgements is a matter of local policy; the simplest strategy is to never request acknowledgements and to rely on periodic updates to ensure that any reachable routes are eventually propagated throughout the routing domain. For increased efficiency, we suggest that acknowledged packets should be used in order to send urgent updates (Section 3.7.2) 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 acknowledgement requests is not necessary, and not even recommended, as the acknowledgements cause additional traffic and may force additional Address Resolution Protocol (ARP) or Neighbour Discovery exchanges.
承認を要求するタイミングは、ローカルポリシーの問題です。最も単純な戦略は、確認応答を要求せず、定期的な更新に依存して、到達可能なルートがルーティングドメイン全体に確実に伝達されるようにすることです。効率を上げるために、特定のインターフェイスのネイバーの数が少ない場合は、緊急アップデート（セクション3.7.2）を送信するために確認済みパケットを使用することをお勧めします。 Babelは信頼性の低いメディアでのパケット損失を適切に処理するように設計されているため、確認応答が追加のトラフィックを引き起こし、追加のアドレス解決プロトコル（ARP）または近隣探索交換を強制する可能性があるため、確認応答要求ですべてのパケットを送信する必要はなく、推奨もされていません。
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 used in link quality computation.
ネイバー取得は、Babelノードがその各インターフェースで聞いたネイバーのセットを発見し、双方向の到達可能性を確認するプロセスです。信頼性の低いメディアでは、ネイバー取得により、リンク品質の計算に使用できるいくつかの統計が追加で提供されます。
Every Babel node sends periodic Hellos over each of its interfaces. Each Hello TLV carries an increasing (modulo 2^16) sequence number and the interval between successive periodic packets sent on this particular interface.
すべてのBabelノードは、その各インターフェースを介して定期的にHelloを送信します。各Hello TLVは、増加する（モジュロ2 ^ 16）シーケンス番号と、この特定のインターフェイスで送信される連続する定期的なパケット間の間隔を伝送します。
In addition to the periodic Hello packets, a node MAY send unscheduled Hello packets, e.g., to accelerate link cost estimation when a new neighbour is discovered, or when link conditions have suddenly changed.
定期的なHelloパケットに加えて、ノードは、スケジュールされていないHelloパケットを送信して（たとえば、新しいネイバーが発見されたとき、またはリンクの状態が突然変化したときのリンクコストの推定を加速する場合があります）。
A node MAY change its Hello interval. The Hello interval MAY be decreased at any time; it SHOULD NOT be increased, except immediately before sending a Hello packet. (Equivalently, a node SHOULD send an unscheduled Hello immediately after increasing its Hello interval.)
ノードは、Helloインターバルを変更してもよい（MAY）。 Helloインターバルはいつでも短くすることができます。 Helloパケットを送信する直前を除いて、増加しないでください。 （同等に、ノードは、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. A possible algorithm is described in Appendix A.1.
受信したHello TLVの処理方法と維持する統計は、ローカル実装の問題と見なされます。通常、ノードは最近受信したHelloの履歴を保持します。可能なアルゴリズムは、付録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を受信するか、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 SHOULD be sent to a multicast address in order to avoid an ARP or Neighbour Discovery exchange and to aggregate multiple IHUs in a single packet.
双方向の到達可能性を確立するために、各ノードは定期的にIHU（ "I Heard You"）TLVを各隣接ノードに送信します。 IHUは明示的な間隔値を伝送するため、高密度のネットワークでのルーティングトラフィックの量を減らすために、Helloよりも送信頻度が少なくてもかまいません（MAY）。特に、パケット損失の少ないリンクを介して、Helloよりも送信頻度を低くする必要があります。 IHUは概念的にユニキャストですが、ARPまたは近隣探索交換を回避し、複数のIHUを1つのパケットに集約するために、マルチキャストアドレスに送信する必要があります（SHOULD）。
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.
定期的なIHUに加えて、ノードはいつでも、スケジュールされていないIHUパケットを送信できます。また、いつでも、IHU間隔を減らしたり、IHUを送信する直前にIHU間隔を増やしたりしてもよい（MAY）。
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 updates the value of the sending neighbour's txcost (transmission cost), from its perspective, to the value contained in the IHU, and resets this neighbour's IHU timer to a small multiple of the value received in the IHU.
すべてのIHU TLVには2つのデータが含まれています。送信側から見たリンクのrxcost（受信コスト）、ネイバーがリンクコストの計算に使用する（セクション3.4.3）、および定期的なIHUパケット間の間隔です。 IHUを受信するノードは、その観点から、送信側のネイバーのtxcost（送信コスト）の値をIHUに含まれる値に更新し、このネイバーのIHUタイマーをIHUで受信した値の小さな倍数にリセットします。
When a neighbour's IHU timer expires, its txcost is set to infinity.
ネイバーの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 -- namely, the statistics kept in the neighbour table about the reception of Hellos, and the txcost computed from received IHU packets.
ネイバーシップアソシエーションのリンクコストは、ネイバーテーブルに保持されている値、つまり、Helloの受信に関してネイバーテーブルに保持されている統計と、受信した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のネイバーに送信されます。
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の正確性に関する限り、次の条件を満たす必要があります。
o the cost is strictly positive;
o コストは厳密にプラスです。
o if no hellos were received recently, then the cost is infinite;
o helloが最近受信されなかった場合、コストは無限です。
o if the txcost is infinite, then the cost is infinite.
o txcostが無限の場合、コストは無限です。
Note that while this document does not constrain cost computation any further, not all cost computation strategies will give good results. We give a few examples of strategies for computing a link's cost that are known to work well in practice in Appendix A.2.
このドキュメントはコスト計算をこれ以上制約しませんが、すべてのコスト計算戦略が良い結果をもたらすとは限らないことに注意してください。付録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の更新は5要素（prefix、plen、router-id、seqno、metric）であり、（prefix、plen）はルートがアドバタイズされているプレフィックス、router-idはルーターのrouter-idです。この更新を開始したseqnoは、元のルーターseqnoを運ぶ非減少（モジュロ2 ^ 16）整数であり、メトリックはアナウンスされたメトリックです。
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 treated as a retraction, depending on some other conditions (Section 3.5.4). If the feasibility condition is satisfied, then the update cannot possibly cause a routing loop, and the update is accepted.
受け入れられる前に、更新は実行可能性条件（セクション3.5.1）に対してチェックされ、ルートがルーティングループを作成しないことが保証されます。実現可能性の条件が満たされない場合、他のいくつかの条件に応じて、更新は無視されるか、撤回として扱われます（セクション3.5.4）。実現可能性の条件が満たされている場合、更新によってルーティングループが発生する可能性はなく、更新は受け入れられます。
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 with finite metrics large enough to cause a loop are discarded.
実現可能性条件は、受信したすべての更新に適用されます。実現可能性条件は、受信した更新のメトリックを、受信ノードが以前に送信した更新のメトリックと比較します。ループを引き起こすのに十分な大きさの有限メトリックを持つ更新は破棄されます。
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, metric) < (seqno', metric')
when
いつ
seqno > seqno' or (seqno = seqno' and metric < metric')
where sequence numbers are compared modulo 2^16.
ここで、シーケンス番号は2 ^ 16を法として比較されます。
Given a source (p, plen, 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 (p, plen) carrying the router-id id. Feasibility distances are maintained in the source table; the exact procedure is given in Section 3.7.3.
ソース（p、plen、id）が与えられると、このソースのノードの実現可能距離は、上記で定義された順序に従って、この特定のノードがこれまでに送信したすべての有限更新のプレフィックス（p、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:
受信した更新は、それが撤回である場合（メトリックは16進数のFFFFである場合）、または上で定義した意味で、アドバタイズされた距離が対応するソースの実行可能距離よりも厳密である場合に実行可能です。より正確には、次の条件のいずれかが満たされている場合、5つ組（プレフィックス、プレン、ルーターID、シーケンス番号、メトリック）を含むルートアドバタイズメントが実行可能です。
o metric is infinite; or
o メトリックは無限です。または
o no entry exists in the source table indexed by (id, prefix, plen); or
o （id、prefix、plen）でインデックス付けされたソーステーブルにエントリが存在しない。または
o an entry (prefix, plen, router-id, seqno', metric') exists in the source table, and either
o エントリ（prefix、plen、router-id、seqno '、metric'）がソーステーブルに存在し、かつ
* seqno' < seqno or
* seqno '<seqnoまたは
* seqno = seqno' and metric < metric'.
* seqno = seqno 'およびmetric <metric'。
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.
実現可能性条件では、ルートのメトリックではなく、ネイバーによってアドバタイズされたメトリックが考慮されることに注意してください。したがって、近隣のコストの変動は、選択されたルートを実行不可能にすることはできません。
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 and the metric advertised by a neighbour MUST only satisfy the following conditions:
ルートのメトリックは、ネイバーによってアドバタイズされたメトリックとネイバーのリンクコストから計算されます。コスト計算と同様に、メトリック計算はローカルポリシーの問題と見なされます。 Babelに関する限り、ローカルで計算されたリンクコストからメトリックを計算するために使用される関数M（c、m）と、ネイバーによってアドバタイズされたメトリックは、次の条件を満たす必要があります。
o if c is infinite, then M(c, m) is infinite;
o cが無限大の場合、M（c、m）は無限大です。
o M is strictly monotonic: M(c, m) > m.
o Mは厳密に単調です：M（c、m）> m。
Additionally, the metric SHOULD satisfy the following condition:
さらに、メトリックは次の条件を満たす必要があります（SHOULD）。
o M is isotonic: if m <= m', then M(c, m) <= M(c, m').
o Mは等張性です。m<= m 'の場合、M（c、m）<= M（c、m'）になります。
Note that while strict monotonicity is essential to the integrity of the network (persistent routing loops may appear if it is not satisfied), isotonicity is not: if it is not satisfied, Babel will still converge to a locally optimal routing table, but might not reach a global optimum (in fact, such a global optimum may not even exist).
厳密な単調性はネットワークの整合性に不可欠ですが（満たされていない場合は永続的なルーティングループが発生する可能性があります）、等張性は満たされないことに注意してください：満たされていない場合、Babelはローカルに最適なルーティングテーブルに収束しますが、大域的最適値に到達する（実際、そのような大域的最適値は存在しない場合もあります）。
As with cost computation, not all strategies for computing route metrics will give good results. In particular, some metrics are more likely than others to lead to routing instabilities (route flapping). In Appendix A.3, we give a number of examples of strictly monotonic, isotonic routing metrics that are known to work well in practice.
コスト計算と同様に、ルートメトリックを計算するためのすべての戦略が良い結果をもたらすとは限りません。特に、一部のメトリックは、他のメトリックよりもルーティングが不安定になる可能性が高くなります（ルートフラッピング）。付録A.3では、実際にうまく機能することが知られている、厳密に単調で等張なルーティングメトリックの例をいくつか示します。
In a large network, the bulk of Babel traffic consists of route updates; hence, some care has been given to encoding them efficiently. An Update TLV itself only contains the prefix, seqno, and metric, while the next hop is derived either from the network-layer source address of the packet or from an explicit Next Hop TLV in the same packet. The router-id is derived from a separate Router-Id TLV in the same packet, which optimises the case when multiple updates are sent with the same router-id.
大規模なネットワークでは、Babelトラフィックの大部分はルートの更新で構成されます。したがって、それらを効率的にエンコードすることに注意が払われています。更新TLV自体には、プレフィックス、seqno、およびメトリックのみが含まれますが、ネクストホップは、パケットのネットワーク層の送信元アドレスまたは同じパケット内の明示的なネクストホップTLVから派生します。 router-idは、同じパケット内の個別のRouter-Id TLVから派生します。これにより、同じrouter-idで複数の更新が送信される場合が最適化されます。
Additionally, a prefix of the advertised prefix can be omitted in an Update TLV, in which case it is copied from a previous Update TLV in the same packet -- this is known as address compression [PACKETBB].
さらに、アドバタイズされたプレフィックスのプレフィックスは、Update TLVで省略できます。その場合、同じパケットの前のUpdate TLVからコピーされます。これは、アドレス圧縮[PACKETBB]と呼ばれます。
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 can optionally be derived from the low-order bits of the advertised prefix.
最後に、ルーターIDがIPv6アドレスのインターフェースID部分と一致する場合の特別な最適化として、ルーターIDは、アドバタイズされたプレフィックスの下位ビットからオプションで導出できます。
The encoding of updates is described in detail in Section 4.4.
更新のエンコーディングについては、セクション4.4で詳しく説明しています。
When a Babel node receives an update (id, prefix, seqno, metric) from a neighbour neigh with a link cost value equal to cost, it checks whether it already has a routing table entry indexed by (neigh, id, prefix).
Babelノードは、コストに等しいリンクコスト値を持つネイバーネイバーから更新（id、プレフィックス、seqno、メトリック）を受信すると、（neigh、id、プレフィックス）でインデックス付けされたルーティングテーブルエントリがすでにあるかどうかを確認します。
If no such entry exists:
そのようなエントリが存在しない場合：
o if the update is unfeasible, it is ignored;
o 更新が実行不可能な場合、無視されます。
o if the metric is infinite (the update is a retraction), the update is ignored;
o メトリックが無限の場合（更新は撤回です）、更新は無視されます。
o otherwise, a new route table entry is created, indexed by (neigh, id, prefix), with seqno equal to seqno and an advertised metric equal to the metric carried by the update.
o それ以外の場合は、新しいルートテーブルエントリが作成され、（neigh、id、prefix）によってインデックスが付けられます。seqnoはseqnoに等しく、アドバタイズされたメトリックは更新によって伝送されるメトリックに等しくなります。
If such an entry exists:
そのようなエントリが存在する場合：
o if the entry is currently installed and the update is unfeasible, then the behaviour depends on whether the router-ids of the two entries match. If the router-ids are different, the update is treated as though it were a retraction (i.e., as though the metric were FFFF hexadecimal). If the router-ids are equal, the update is ignored;
o エントリが現在インストールされていて、更新が実行不可能な場合、動作は2つのエントリのルーターIDが一致するかどうかによって異なります。 router-idが異なる場合、更新は撤回であるかのように処理されます（つまり、メトリックは16進数のFFFFであるかのように処理されます）。 router-idが等しい場合、更新は無視されます。
o otherwise (i.e., if either the update is feasible or the entry is not currently installed), then the entry's sequence number, advertised metric, metric, and router-id are updated and, unless the advertised metric is infinite, the route's expiry timer is reset to a small multiple of the Interval value included in the update.
o それ以外の場合（つまり、更新が可能であるか、エントリが現在インストールされていない場合）、エントリのシーケンス番号、アドバタイズされたメトリック、メトリック、およびルーターIDが更新され、アドバタイズされたメトリックが無限でない限り、ルートの有効期限タイマーは更新に含まれる間隔値の小さな倍数にリセットします。
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.
ルートの有効期限タイマーがトリガーされたときの動作は、ルートのメトリックが有限であるかどうかによって異なります。メトリックが有限の場合、それは無限大に設定され、有効期限タイマーがリセットされます。メトリックがすでに無限の場合、ルートはルートテーブルからフラッシュされます。
After the routing 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, too old, or have an infinite metric, 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'は、pを宛先とするパケットのルーティングに使用できません。ルーティングループを作成するリスク（セクション2.8）。
To avoid this issue, whenever a prefix is retracted, a routing table entry with infinite metric is maintained as described in Section 3.5.4 above, and packets destined for that prefix MUST NOT be forwarded by following a route for a shorter prefix. The infinite metric entry is maintained until it is superseded by a feasible update; if no such update arrives within the route hold time, the entry is flushed.
この問題を回避するために、プレフィックスが撤回されるときはいつでも、上記のセクション3.5.4で説明されているように、無限メトリックのルーティングテーブルエントリが維持され、そのプレフィックス宛てのパケットは、より短いプレフィックスのルートに従って転送してはなりません。無限のメトリックエントリは、実行可能な更新によって置き換えられるまで維持されます。ルート保持時間内にそのような更新が到着しない場合、エントリはフラッシュされます。
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 protocol's correctness is concerned, the route selection policy MUST only satisfy the following properties:
Babelは、柔軟なルート選択ポリシーを許可するように設計されています。プロトコルの正確性に関する限り、ルート選択ポリシーは次のプロパティのみを満たさなければなりません（MUST）。
o a route with infinite metric (a retracted route) is never selected;
o メトリックが無限のルート（撤回ルート）が選択されることはありません。
o an unfeasible route is never selected.
o 実行不可能なルートが選択されることはありません。
Note, however, that Babel does not naturally guarantee the stability of routing, and configuring conflicting route selection policies on different routers may lead to persistent route oscillation.
ただし、Babelはルーティングの安定性を自然に保証するものではなく、異なるルーターで競合するルート選択ポリシーを構成すると、永続的なルート振動が発生する可能性があることに注意してください。
Defining a good route selection policy for Babel is an open research problem. Route selection can take into account multiple mutually contradictory criteria; in roughly decreasing order of importance, these are:
Babelの適切なルート選択ポリシーを定義することは、未解決の研究課題です。ルートの選択では、相互に矛盾する複数の基準を考慮することができます。重要度の低い順に、これらは次のとおりです。
o routes with a small metric should be preferred over routes with a large metric;
o メトリックが小さいルートは、メトリックが大きいルートよりも優先する必要があります。
o switching router-ids should be avoided;
o router-idの切り替えは避けてください。
o routes through stable neighbours should be preferred over routes through unstable ones;
o 安定したネイバーを経由するルートは、不安定なネイバーを経由するルートよりも優先されます。
o stable routes should be preferred over unstable ones;
o 安定したルートは、不安定なルートよりも優先されます。
o switching next hops should be avoided.
o ネクストホップの切り替えは避けてください。
A simple strategy is to choose the feasible route with the smallest metric, with a small amount of hysteresis applied to avoid switching router-ids.
単純な戦略は、ルーターIDの切り替えを回避するために少量のヒステリシスを適用して、最小のメトリックで実行可能なルートを選択することです。
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 when the number of neighbours is small.
Babelスピーカーは、選択したルートのセットを近隣にアドバタイズします。通常、これは、接続されているすべてのインターフェイスで更新TLVを含む1つ以上のマルチキャストパケットを送信することによって行われます。ただし、マルチキャストがユニキャストよりもはるかに高価なリンクテクノロジーでは、ノードは、ネイバーの数が少ない場合、更新の複数のコピーをユニキャストパケットで送信することを選択できます。
Additionally, in order to ensure that any black-holes are reliably cleared in a timely manner, a Babel node sends retractions (updates with an infinite metric) for any recently retracted prefixes.
さらに、ブラックホールが確実にタイムリーに確実にクリアされるようにするために、Babelノードは、最近撤回された接頭辞に対して撤回（無限メトリックの更新）を送信します。
If an update is for a route injected into the Babel domain by the local node (e.g., the address of a local interface, the prefix of a directly attached network, or redistributed from a different routing protocol), the router-id is set to the local 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 learned from another Babel speaker, the router-id and sequence number are copied from the routing table entry, and the metric is computed as specified in Section 3.5.2.
更新が別のBabelスピーカーから学習したルートに対するものである場合、ルーターIDとシーケンス番号はルーティングテーブルエントリからコピーされ、メトリックはセクション3.5.2で指定されているように計算されます。
Every Babel speaker periodically advertises all of its selected routes on all of its interfaces, including any recently retracted routes. 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.
すべてのBabelスピーカーは、最近撤回されたルートを含め、選択したすべてのルートをすべてのインターフェイスで定期的にアドバタイズします。 Babelはルーティングループの影響を受けず（「無限カウント」はありません）、トリガーされた更新に大きく依存しているため（セクション3.7.2）、このフルダンプはまれにしか発生しません。
In addition to the 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, a node MUST send a triggered update in a timely manner whenever it changes the selected router-id for a given destination. Additionally, it SHOULD make a reasonable attempt at ensuring that all neighbours receive this update.
選択されたルートのルーターIDを所定のプレフィックスに変更すると、ルーティングループが形成されている可能性があります。したがって、ノードは、特定の宛先の選択されたルーターIDを変更するたびに、トリガーされた更新をタイムリーに送信する必要があります。さらに、すべてのネイバーがこの更新を確実に受信するように合理的な試みを行う必要があります。
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 acknowledgement 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 acknowledgements 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, 5 for wireless and 2 for wired links).
それを確実にするための2つの戦略があります。ネイバーの数が少ない場合は、確認応答要求とともに更新を送信するのが妥当です。更新は、すべてのネイバーが数回までパケットを確認するまで再送信されます。ただし、ネイバーの数が多い場合は、ネイバーのすべてから確認応答を要求すると、無視できない量のネットワークトラフィックが発生する可能性があります。その場合は、更新を妥当な回数だけ繰り返すことをお勧めします（たとえば、ワイヤレスの場合は5回、有線のリンクの場合は2回）。
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.
ルートの撤回は多少心配する必要はありません。ルートの撤回がすべての近隣に到達しない場合、ブラックホールが作成される可能性があり、ルーティングループとは異なり、ネットワークの整合性を危険にさらしません。ルートが撤回されると、ノードはトリガーされた更新を送信する必要があり（SHOULD）、すべてのネイバーがこの撤回を確実に受信できるように合理的な試みを行う必要があります（SHOULD）。
Finally, a node MAY send a triggered update when the metric for a given prefix changes in a significant manner, either due to a received update or because a link cost has changed. 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, or to propagate a new sequence number (except to satisfy a request, as specified in Section 3.8).
最後に、受信した更新またはリンクコストの変更により、特定のプレフィックスのメトリックが大幅に変化した場合、ノードはトリガーされた更新を送信できます（MAY）。ノードは、ルートのメトリックにわずかな変動がある場合、選択されたネクストホップが変更される場合、または新しいシーケンス番号を伝搬するために、トリガーされた更新を送信しないでください（セクション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、シーケンス番号、メトリック）を送信する前に、バベルノードはソーステーブルで維持されている実行可能距離を更新します。これは次のように行われます。
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).
（prefix、plen、router-id）でインデックス付けされたエントリがソーステーブルに存在しない場合、値（prefix、plen、router-id、seqno、metric）で作成されます。
If an entry (prefix, plen, router-id, seqno', metric') exists, then it is updated as follows:
エントリ（prefix、plen、router-id、seqno '、metric'）が存在する場合、次のように更新されます。
o if seqno > seqno', then seqno' := seqno, metric' := metric;
o seqno> seqno 'の場合、seqno'：= seqno、metric '：= metric;
o if seqno = seqno' and metric' > metric, then metric' := metric;
o seqno = seqno 'およびmetric'> metricの場合、metric '：= metric;
o otherwise, nothing needs to be done.
o それ以外の場合は、何もする必要はありません。
The garbage-collection timer for the modified entry is then reset. Note that the garbage-collection timer is not reset when a retraction is sent.
次に、変更されたエントリのガベージコレクションタイマーがリセットされます。撤回が送信されても、ガベージコレクションタイマーはリセットされないことに注意してください。
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 is not sent on this particular interface when the advertised route was learnt from a neighbour over the same interface.
ポイントツーポイントリンクやイーサネットなどの有線LANテクノロジーなどの推移的な対称リンクテクノロジーで実行する場合、バベルノードはスプリットホライズンと呼ばれる最適化を使用する必要があります（SHOULD）。特定のインターフェイスでスプリットホライズンが使用されている場合、アドバタイズされたルートが同じインターフェイス上のネイバーから学習された場合、この特定のインターフェイスでルーティングアップデートは送信されません。
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).
インターフェイスが対称的で推移的であることがわかっている場合を除き、スプリットホライズンはインターフェイスに適用しないでください。特に、スプリットホライズンは、分散型ワイヤレスリンクテクノロジー（アドホックモードのIEEE 802.11など）には適用されません。
In normal operation, a node's routing table is populated by the regular and triggered updates sent by its neighbours. Under some circumstances, however, a node sends explicit requests 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 a neighbour.
Babelプロトコルは、2種類の明示的な要求を提供します。特定のプレフィックスの更新を要求するroute要求と、特定のシーケンス番号を持つ特定のプレフィックスの更新を要求する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 update.
次のセクションで説明するように、ノードは要求を受信すると、要求を転送するか、要求に応答して更新を送信します。これにより更新が送信される場合、更新は、要求が受信されたインターフェイスのマルチキャストアドレス、または更新を送信したネイバーのユニキャストアドレスに送信されます。
The exact behaviour is different for route requests and seqno requests.
正確な動作は、ルートリクエストとseqnoリクエストでは異なります。
When a node receives a route request for a prefix (prefix, plen), it checks its route table for a selected route to this exact prefix. If such a route exists, it MUST send an update; if such a route does not, it MUST send a retraction for that prefix.
ノードは、プレフィックス（prefix、plen）のルート要求を受信すると、ルートテーブルをチェックして、この正確なプレフィックスへの選択されたルートを探します。そのようなルートが存在する場合、更新を送信する必要があります。そのようなルートがそうでないなら、それはその接頭辞のための撤回を送らなければなりません。
When a node receives a wildcard route request, it SHOULD send a full routing table dump.
ノードがワイルドカードルート要求を受信すると、完全なルーティングテーブルダンプを送信する必要があります（SHOULD）。
When a node receives a seqno request for a given router-id and sequence number, it checks whether its routing table contains a selected entry for that prefix; if no such entry exists, or the entry has infinite metric, it ignores the request.
ノードは、特定のルーターIDとシーケンス番号のseqno要求を受信すると、そのプレフィックスの選択されたエントリがルーティングテーブルに含まれているかどうかを確認します。そのようなエントリが存在しないか、エントリのメトリックが無限である場合、要求は無視されます。
If a selected route for the given prefix exists, and either the router-ids are different or the router-ids are equal and the entry's sequence number is no smaller than the requested sequence number, it MUST send an update for the given prefix.
指定されたプレフィックスの選択されたルートが存在し、ルーターIDが異なるか、ルーターIDが等しく、エントリのシーケンス番号が要求されたシーケンス番号以上である場合、指定されたプレフィックスの更新を送信する必要があります。
If the router-ids match but the requested seqno is larger 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 and sends an update. A node MUST NOT increase its sequence number by more than 1 in response to a route request.
router-idは一致するが、要求されたseqnoがルートエントリのものより大きい場合、ノードはrouter-idを自身のrouter-idと比較します。 router-idが独自のものである場合は、シーケンス番号を1増やして更新を送信します。ノードは、ルート要求に応じてシーケンス番号を1以上大きくしてはなりません（MUST NOT）。
If the requested router-id is not its own, the received request's hop count is 2 or more, and the node has a route (not necessarily a feasible one) for the requested prefix that does not use the requestor as a next hop, the node SHOULD forward the request. It does so by decreasing the hop count and sending the request in a unicast packet destined to a neighbour that advertises the given prefix (not necessarily the selected neighbour) and that is distinct from the neighbour from which the request was received.
要求されたルーターIDが独自のものではない場合、受信された要求のホップカウントは2以上であり、ノードには、要求者をネクストホップとして使用しない、要求されたプレフィックスへのルート（必ずしも実行可能なルートではない）があります。ノードはリクエストを転送する必要があります。これは、ホップカウントを減らし、指定されたプレフィックス（必ずしも選択されたネイバーではない）をアドバタイズし、リクエストの受信元のネイバーとは異なるネイバー宛てのユニキャストパケットでリクエストを送信することで行われます。
A node SHOULD maintain a list of recently forwarded requests and forward the reply in a timely manner. A node SHOULD compare every incoming request against its list of recently forwarded requests and avoid forwarding it if it is redundant.
ノードは、最近転送されたリクエストのリストを維持し、タイムリーに返信を転送する必要があります。ノードは、すべての着信要求を最近転送された要求のリストと比較し、冗長な場合は転送しないようにする必要があります（SHOULD）。
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 for 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 request MUST NOT be forwarded to a multicast address, and it MUST be forwarded to a single neighbour only.
要求転送メカニズムは必ずしも実現可能性の条件に従うわけではないため、ルーティングループに巻き込まれる可能性があります。したがって、リクエストにはホップカウントが含まれ、ネットワークに留まる時間を制限します。ただし、要求はユニキャストパケットとしてのみ転送されるため、初期ホップカウントを特に低く保つ必要はなく、拡張ホライズン検索を実行する必要はありません。リクエストはマルチキャストアドレスに転送されてはならず（MUST NOT）、単一のネイバーにのみ転送されなければなりません（MUST）。
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.
ルートが撤回または期限切れになると、Babelノードは通常、同じプレフィックスの別の実行可能なルートに切り替えます。ただし、そのようなルートが利用できない場合もあります。
A node that has lost all feasible routes to a given destination MUST 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.
特定の宛先へのすべての実行可能なルートを失ったノードは、seqno要求を送信する必要があります。リクエストのrouter-idは、それが失ったルートのrouter-idに設定され、リクエストされたseqnoはソーステーブルに含まれる値に1を加えたものです。
Such a request SHOULD be multicast over all of the node's attached interfaces. Similar requests will be sent by other nodes that are affected by the route's loss and will be forwarded by neighbouring nodes up to the source. If the network is connected, and there is no packet loss, this will result in a route being advertised with a new sequence number. (Note that, due to duplicate suppression, only a small number of such requests will actually reach the source.)
このようなリクエストは、ノードに接続されているすべてのインターフェース上でマルチキャストする必要があります（SHOULD）。同様のリクエストは、ルートの損失の影響を受ける他のノードによって送信され、送信元までの隣接ノードによって転送されます。ネットワークが接続されていて、パケット損失がない場合、これによりルートが新しいシーケンス番号でアドバタイズされます。 （重複抑制のため、ごく少数のそのようなリクエストのみが実際にソースに到達することに注意してください。）
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. Under heavy packet loss, however, all such requests may be lost; in that case, the second mechanism in the next section will eventually ensure that a new seqno is received.
パケット損失を補償するために、ノードは、ルートが短時間で実行可能にならない場合、そのような要求を少数の回数繰り返す必要があります。ただし、大量のパケット損失があると、そのような要求はすべて失われる可能性があります。その場合、次のセクションの2番目のメカニズムにより、新しい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 retract 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 whenever it receives an unfeasible update for a route that is currently selected. The requested sequence number is computed from the source table as above.
ルートが実行不可能になったために誤って期限切れになるのを防ぐために、ノードは、現在選択されているルートの実行不能な更新を受信するたびに、ユニキャストseqnoリクエストを送信する必要があります（SHOULD）。要求されたシーケンス番号は、上記のようにソーステーブルから計算されます。
Additionally, a node SHOULD send a unicast seqno request whenever it receives an unfeasible update from a currently unselected neighbour that is "good enough", i.e., that would lead to the received route becoming selected were it feasible.
さらに、ノードは、現在選択されていないネイバーから「十分に良好」である実行不可能な更新を受信するたびに、つまり、可能であれば受信ルートが選択されることになる、ユニキャストseqno要求を送信する必要があります。
In normal operation, a route's expiry timer should never trigger: since a route's hold time is computed from an explicit interval included in Update TLVs, a new update should arrive in time to prevent a route from expiring.
通常の操作では、ルートの有効期限タイマーがトリガーされることはありません。ルートの保持時間は更新TLVに含まれる明示的な間隔から計算されるため、ルートが期限切れにならないように新しい更新が間に合うように到着する必要があります。
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 retractions in response to non-wildcard route requests (Section 3.8.1.1), this will usually result in either the route being refreshed or a retraction being received.
ただし、パケット損失が存在する場合、更新が長期間正常に受信されず、ルートが期限切れになる可能性があります。そのような偽の期限切れを回避するために、選択されたルートが期限切れになる直前に、バベルノードはこのルートをアドバタイズしたネイバーにユニキャストルートリクエストを送信する必要があります。ノードは常にワイルドカード以外のルート要求に応答して撤回を送信するため（セクション3.8.1.1）、これにより通常ルートが更新されるか撤回が受信されます。
In order to speed up convergence after a mobility event, a node MAY send a unicast wildcard request after acquiring a new neighbour. Additionally, a node MAY send a small number of multicast wildcard requests shortly after booting.
モビリティイベント後のコンバージェンスを高速化するために、ノードは新しいネイバーを取得した後にユニキャストワイルドカード要求を送信できます（MAY）。さらに、ノードは起動直後に少数のマルチキャストワイルドカード要求を送信する場合があります。
A Babel packet is 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. Babel packets MUST NOT be sent as IPv6 Jumbograms.
IPv4またはIPv6を介して、BabelパケットがUDPデータグラムの本文として送信され、ネットワーク層のホップカウントが1に設定されて、既知のマルチキャストアドレスまたはユニキャストアドレスに送信されます。 IPv6の場合、これらのアドレスはリンクローカルです。送信元と宛先の両方のUDPポートが、既知のポート番号に設定されています。送信元アドレスがリンクローカルIPv6アドレス、またはローカルネットワークに属するIPv4アドレスのいずれかであり、その送信元ポートが既知のBabelポートである場合を除き、Babelパケットは暗黙のうちに無視される必要があります。 BabelパケットはIPv6ジャンボグラムとして送信してはなりません（MUST NOT）。
In order to minimise the number of packets being sent while avoiding lower-layer fragmentation, a Babel node SHOULD attempt to maximise the size of the packets it sends, up to the outgoing interface's MTU adjusted for lower-layer headers (28 octets for UDP/IPv4, 48 octets for UDP/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ノードは、送信するパケットのサイズを最大化し、下位層ヘッダーに合わせて調整された発信インターフェイスのMTU（UDP / IPv4、UDP / IPv6では48オクテット）。接続されたインターフェースのMTU（下位層ヘッダー用に調整）または512オクテットのいずれか大きい方であるが、下位層ヘッダー用に調整された2 ^ 16-1を超えないパケットは送信してはならない（MUST NOT）。すべてのBabelスピーカーは、接続されているインターフェイスのMTU（下位層ヘッダーに合わせて調整）または512オクテットのどちらか大きい方のパケットを受信できる必要があります。
In order to avoid global synchronisation of a Babel network and to aggregate multiple TLVs into large packets, a Babel node MUST buffer every TLV and delay sending a UDP packet by a small, randomly chosen delay [JITTER]. In order to allow accurate computation of packet loss rates, this delay MUST NOT be larger than half the advertised Hello interval.
Babelネットワークのグローバル同期を回避し、複数のTLVを大きなパケットに集約するために、BabelノードはすべてのTLVをバッファリングし、UDPパケットの送信をランダムに選択された小さな遅延[JITTER]だけ遅延させる必要があります。パケット損失率の正確な計算を可能にするために、この遅延は、アドバタイズされたHelloインターバルの半分より大きくてはいけません。
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.
相対時間は、センチ秒（100分の1秒）の数を指定する16ビット値として伝送されます。これにより、10 msの精度で最大約11分の時間が可能になり、Babelのすべての適切なアプリケーションをカバーできます。
A router-id is an arbitrary 8-octet value. Router-ids SHOULD be assigned in modified EUI-64 format [ADDRARCH].
router-idは任意の8オクテット値です。ルーターIDは、変更されたEUI-64形式[ADDRARCH]で割り当てる必要があります（SHOULD）。
Since the bulk of the protocol is taken by addresses, multiple ways of encoding addresses are defined. Additionally, a common subnet prefix may be omitted when multiple addresses are sent in a single packet -- this is known as address compression [PACKETBB].
プロトコルの大部分はアドレスによって取得されるため、アドレスをエンコードする複数の方法が定義されています。さらに、複数のアドレスが単一のパケットで送信される場合、共通のサブネットプレフィックスが省略される場合があります。これは、アドレス圧縮[PACKETBB]と呼ばれます。
Address encodings:
アドレスエンコーディング：
o AE 0: wildcard address. The value is 0 octets long.
o AE 0：ワイルドカードアドレス。値は0オクテットです。
o AE 1: IPv4 address. Compression is allowed. 4 octets or less.
o AE 1：IPv4アドレス。圧縮は許可されます。 4オクテット以下。
o AE 2: IPv6 address. Compression is allowed. 16 octets or less.
o AE 2：IPv6アドレス。圧縮は許可されます。 16オクテット以下。
o AE 3: link-local IPv6 address. The value is 8 octets long, a prefix of fe80::/64 is implied.
o AE 3：リンクローカルIPv6アドレス。値は8オクテット長で、fe80 :: / 64のプレフィックスが含まれます。
The address family of an address is either IPv4 or IPv6; it is undefined for AE 0, IPv4 for AE 1, and IPv6 for AE 2 and 3.
アドレスのアドレスファミリはIPv4またはIPv6です。 AE 0の場合は未定義、AE 1の場合はIPv4、AE 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.
Babelパケットは、4オクテットのヘッダーと、それに続く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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic | Version | Body length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Body ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields :
田畑 ：
Magic The arbitrary but carefully chosen value 42 (decimal); packets with a first octet different from 42 MUST be silently ignored.
Magic任意だが慎重に選択された値42（10進数）。 42と異なる最初のオクテットを持つパケットは、黙って無視されなければなりません（MUST）。
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番目のオクテットを持つパケットは、黙って無視されなければなりません（MUST）。
Body length The length in octets of the body following the packet header.
本文の長さパケットヘッダーに続く本文のオクテット単位の長さ。
Body The packet body; a sequence of TLVs.
本文パケットの本文。 TLVのシーケンス。
Any data following the body MUST be silently ignored.
本文に続くデータは、黙って無視されなければなりません（MUST）。
With the exception of Pad1, all TLVs have the following structure:
Pad1を除いて、すべての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 | Length | Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields :
Type The type of the TLV.
タイプTLVのタイプ。
Length The length of the body, exclusive of the Type and Length fields. If the body is longer than the expected length of a given type of TLV, any extra data MUST be silently ignored.
長さタイプおよび長さフィールドを除く、本体の長さ。ボディが特定のタイプのTLVの予想される長さよりも長い場合、余分なデータは何も通知せずに無視する必要があります。
Body The TLV body, the interpretation of which depends on the type.
本文TLV本体。その解釈はタイプによって異なります。
TLVs with an unknown type value MUST be silently ignored.
タイプ値が不明なTLVは、黙って無視する必要があります。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0 |
+-+-+-+-+-+-+-+-+
Fields :
田畑 ：
Type Set to 0 to indicate a Pad1 TLV.
「0に設定」と入力して、Pad1 TLVを示します。
This TLV is silently ignored on reception.
この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.
Set 1と入力してPadN TLVを示します。
Length The length of the body, exclusive of the Type and Length fields.
長さタイプおよび長さフィールドを除く、本体の長さ。
MBZ Set to 0 on transmission.
MBZ送信時に0に設定されます。
This TLV is silently ignored on reception.
この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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV requests that the receiver send an Acknowledgement TLV within the number of centiseconds specified by the Interval field.
このTLVは、Intervalフィールドで指定されたセンチ秒数以内に受信者が確認TLVを送信することを要求します。
Fields :
田畑 ：
Type Set to 2 to indicate an Acknowledgement Request TLV.
Set to 2と入力して、確認要求TLVを示します。
Length The length of the body, exclusive of the Type and Length fields.
長さタイプおよび長さフィールドを除く、本体の長さ。
Reserved Sent as 0 and MUST be ignored on reception.
予約済み0として送信され、受信時には無視する必要があります。
Nonce An arbitrary value that will be echoed in the receiver's Acknowledgement 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 acknowledgement before this time has elapsed (with a margin allowing for propagation time).
間隔送信者がこのパケットが失われたと見なすまでのセンチ秒単位の時間間隔。これは0であってはなりません。受信者は、この時間が経過する前に確認応答を送信する必要があります（伝播時間を考慮してマージンを確保する必要があります）。
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 | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is sent by a node upon receiving an Acknowledgement Request.
このTLVは、肯定応答要求を受信するとノードによって送信されます。
Fields :
田畑 ：
Type Set to 3 to indicate an Acknowledgement TLV.
Set to 3と入力して、確認応答TLVを示します。
Length The length of the body, exclusive of the Type and Length fields.
長さタイプおよび長さフィールドを除く、本体の長さ。
Nonce Set to the Nonce value of the Acknowledgement Request that prompted this Acknowledgement.
Nonceこの確認を促した確認要求のNonce値に設定します。
Since nonce values are not globally unique, this TLV MUST be sent to a unicast address.
nonce値はグローバルに一意ではないため、この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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seqno | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used for neighbour discovery and for determining a link's reception cost.
このTLVは、ネイバー探索とリンクの受信コストの決定に使用されます。
Fields :
田畑 ：
Type Set to 4 to indicate a Hello TLV.
Hello TLVを示すには、Set to 4と入力します。
Length The length of the body, exclusive of the Type and Length fields.
長さタイプおよび長さフィールドを除く、本体の長さ。
Reserved Sent as 0 and MUST be ignored on reception.
予約済み0として送信され、受信時には無視する必要があります。
Seqno The value of the sending node's Hello seqno for this interface.
Seqnoこのインターフェースの送信ノードのHello seqnoの値。
Interval An upper bound, expressed in centiseconds, on the time after which the sending node will send a new Hello TLV. This MUST NOT be 0.
間隔送信ノードが新しいHello TLVを送信するまでの時間の上限（センチ秒単位）。これは0であってはなりません。
Since there is a single seqno counter for all the Hellos sent by a given node over a given interface, this TLV MUST be sent to a multicast destination. In order to avoid large discontinuities in link quality, multiple Hello TLVs SHOULD NOT be sent in the same packet.
特定のインターフェイスを介して特定のノードによって送信されるすべてのHelloに対して単一のseqnoカウンターがあるため、このTLVはマルチキャストの宛先に送信する必要があります。リンク品質の大きな不連続を回避するために、複数のHello TLVを同じパケットで送信してはなりません（SHOULD NOT）。
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（ "I Heard You"）TLVは、双方向の到達可能性を確認し、リンクの伝送コストを伝送するために使用されます。
Fields :
田畑 ：
Type Set to 5 to indicate an IHU TLV.
Set to 5と入力して、IHU TLVを示します。
Length The length of the body, 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です。最適化として、TLVがユニキャストアドレスに送信される場合、関連付けがポイントツーポイントリンク上にある場合、または双方向の到達可能性がBabelプロトコルの外部の手段によって確認される場合は、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 Addressフィールドでアドレスが指定されているインターフェースの送信ノードに応じたrxcost。値FFFF 16進数（無限）は、このインターフェースに到達できないことを示します。
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 it SHOULD 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 TLVには明示的な宛先アドレスが含まれており、マルチキャストアドレスに送信する必要があります。これにより、異なるネイバー宛てのIHUを単一のパケットに集約でき、ネイバーが存在しない場合にARPまたはネイバー探索交換の必要性を回避できます。データトラフィックに使用されています。
IHU TLVs with an unknown value for the AE field MUST be silently ignored.
AEフィールドの値が不明なIHU 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.
ルーターID TLVは、後続の更新TLVによって暗示されるルーターIDを確立します。
Fields :
田畑 ：
Type Set to 6 to indicate a Router-Id TLV.
6に設定すると、Router-Id TLVを示します。
Length The length of the body, 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
Router-Id後続のアップデートTLVでアドバタイズされるルートのルーターID
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 by subsequent Update TLVs.
ネクストホップTLVは、後続のアップデートTLVによって暗示される特定のアドレスファミリ（IPv4またはIPv6）のネクストホップアドレスを確立します。
Fields :
田畑 ：
Type Set to 7 to indicate a Next Hop TLV.
Set to 7と入力して、ネクストホップTLVを示します。
Length The length of the body, exclusive of the Type and Length fields.
長さタイプおよび長さフィールドを除く、本体の長さ。
AE The encoding of the Address field. This SHOULD be 1 or 3 and MUST NOT be 0.
AEアドレスフィールドのエンコーディング。これは1または3である必要があり、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.
ネクストホップこのアドレスファミリの、後続のアップデートTLVによってアドバタイズされるネクストホップアドレス。
When the address family matches the network-layer protocol that this packet is transported over, a Next Hop TLV is not needed: in that case, the next hop 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フィールドの値が不明なネクストホップ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, this can also have the side effect of establishing a new implied router-id and a new default prefix.
Update TLVはルートをアドバタイズまたは撤回します。最適化として、これには新しい暗黙のルーターIDと新しいデフォルトのプレフィックスを確立するという副作用もあります。
Fields :
田畑 ：
Type Set to 8 to indicate an Update TLV.
「Set to 8」と入力して、アップデートTLVを示します。
Length The length of the body, exclusive of the Type and Length fields.
長さタイプおよび長さフィールドを除く、本体の長さ。
AE The encoding of the Prefix field.
AE接頭辞フィールドのエンコーディング。
Flags The individual bits of this field specify special handling of this TLV (see below). Every node MUST be able to interpret the flags with values 80 and 40 hexadecimal; unknown flags MUST be silently ignored.
フラグこのフィールドの個々のビットは、このTLVの特別な処理を指定します（以下を参照）。すべてのノードは、80と40の16進数の値を持つフラグを解釈できなければなりません。未知のフラグは黙って無視されなければなりません。
Plen The length of the advertised prefix.
Plenアドバタイズされたプレフィックスの長さ。
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 with the flag with value 80 hexadecimal set.
省略アドバタイズされたプレフィックスの先頭で省略され、先行する更新TLVから取得され、値が16進数で80に設定されたオクテットの数。
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 and SHOULD NOT be less than 10. The receiving node will use this value to compute a hold time for this routing 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であってはならず、10未満であってはなりません。受信ノードはこの値を使用して、このルーティングテーブルエントリの保持時間を計算します。値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フィールドは次のように解釈されます。
o if the bit with value 80 hexadecimal is set, then this Update establishes a new default prefix for subsequent Update TLVs with a matching address family within the same packet;
o 16進数の値が80のビットが設定されている場合、この更新は、同じパケット内のアドレスファミリが一致する後続の更新TLVの新しいデフォルトプレフィックスを確立します。
o if the bit with value 40 hexadecimal is set, then the low-order 8 octets of the advertised prefix establish a new default router-id for this TLV and subsequent Update TLVs in the same packet.
o 16進数の値が40のビットが設定されている場合、アドバタイズされたプレフィックスの下位8オクテットは、このパケットの新しいデフォルトルータIDと、同じパケット内の後続の更新TLVを確立します。
The prefix being advertised by an Update TLV is computed as follows:
更新TLVによって通知されるプレフィックスは、次のように計算されます。
o the first Omitted octets of the prefix are taken from the previous Update TLV with flag 80 hexadecimal set and the same address family;
o プレフィックスの最初の省略オクテットは、フラグ80が16進数に設定され、同じアドレスファミリを持つ以前の更新TLVから取得されます。
o the next (Plen/8 - Omitted) (rounded upwards) octets are taken from the Prefix field;
o 次の（Plen / 8-省略）（上に丸められた）オクテットはPrefixフィールドから取得されます。
o the remaining octets are set to 0.
o 残りのオクテットは0に設定されます。
If the Metric field is finite, the router-id of the originating node for this announcement is taken from the low-order 8 octets of the prefix advertised by this Update if the bit with value 40 hexadecimal is set in the Flags field. Otherwise, it is taken either from the preceding Router-Id packet, or the preceding Update packet with flag 40 hexadecimal set, whichever comes last.
[メトリック]フィールドが有限の場合、このアナウンスの発信元ノードのルーターIDは、[フラグ]フィールドで16進数の値が40のビットが設定されている場合、この更新によってアドバタイズされるプレフィックスの下位8オクテットから取得されます。それ以外の場合は、前のRouter-Idパケットか、フラグ40が16進数で設定された前のUpdateパケットのどちらか最後の方から取得されます。
The next-hop address for this update is taken from the last preceding Next Hop TLV with a matching address family in the same packet; if no such TLV exists, it is taken from the network-layer source address of this packet.
この更新のネクストホップアドレスは、同じパケット内のアドレスファミリが一致する直前のネクストホップTLVから取得されます。そのようなTLVが存在しない場合は、このパケットのネットワーク層の送信元アドレスから取得されます。
If the metric field is FFFF hexadecimal, this TLV specifies a retraction. In that case, the current router-id and the Seqno are not used. AE MAY then be 0, in which case this Update retracts all of the routes previously advertised on this interface.
メトリックフィールドが16進数のFFFFの場合、このTLVは撤回を指定します。その場合、現在のrouter-idとSeqnoは使用されません。その後、AEは0になる場合があります。その場合、この更新は、このインターフェースで以前にアドバタイズされたすべてのルートを撤回します。
Update TLVs with an unknown value for the AE field MUST be silently ignored.
AEフィールドの未知の値でTLVを更新することは、黙って無視されなければなりません（MUST）。
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 routing table dump.
Route Request TLVは、指定されたプレフィックスの更新、または完全なルーティングテーブルダンプを送信するようにレシーバーに要求します。
Fields :
田畑 ：
Type Set to 9 to indicate a Route Request TLV.
Set to 9と入力して、ルートリクエストTLVを示します。
Length The length of the body, 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 routing table dump (a wildcard request).
AE接頭辞フィールドのエンコーディング。値0は、これが完全なルーティングテーブルダンプの要求（ワイルドカード要求）であることを指定します。
Plen The length of the requested prefix.
Plen要求されたプレフィックスの長さ。
Prefix The prefix being requested. This field's size is Plen/8 rounded upwards.
接頭辞要求されている接頭辞。このフィールドのサイズは、上向きに丸められたPlen / 8です。
A Request TLV prompts the receiving node to send an update message for the prefix specified by the AE, Plen, and Prefix fields, or a full dump of its routing table if AE is 0 (in which case Plen MUST be 0, and Prefix is of length 0). A Request may be sent to a unicast address if it is destined to a single node, or to a multicast address if the request is destined to all of the neighbours of the sending interface.
要求TLVは、AE、Plen、およびPrefixフィールドで指定されたプレフィックスの更新メッセージ、またはAEが0の場合はそのルーティングテーブルの完全なダンプ（この場合、Plenは0でなければならず、プレフィックスが長さ0の）。リクエストが単一ノード宛ての場合はユニキャストアドレスに、リクエストが送信側インターフェースのすべてのネイバー宛ての場合はマルチキャストアドレスに送信できます。
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 Request TLVは、特定のシーケンス番号を持つ特定のプレフィックスのアップデートを送信するか、ローカルで要求を満たせない場合はリクエストをさらに転送するようにレシーバーに要求します。
Fields :
田畑 ：
Type Set to 10 to indicate a Seqno Request message.
Set to 10と入力して、Seqno Requestメッセージを示します。
Length The length of the body, exclusive of the Type and Length fields.
長さタイプおよび長さフィールドを除く、本体の長さ。
AE The encoding of the Prefix field. This MUST NOT be 0.
AE接頭辞フィールドのエンコーディング。これは0であってはなりません。
Plen The length of the requested prefix.
Plen要求されたプレフィックスの長さ。
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であってはなりません。
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 an 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 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 Request TLVは、AE、Plen、およびPrefixフィールドで指定されたプレフィックスのアップデートを送信するように受信ノードに要求します。ルーターIDは、Router-Idフィールドで指定されたものとは異なるか、Seqno以上Seqnoフィールドで指定されているもの。このリクエストをローカルで満たすことができない場合は、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の場合、リクエストを転送してはなりません（MUST NOT）。
IANA has registered the UDP port number 6697, called "babel", for use by the Babel protocol.
IANAは、Babelプロトコルで使用するために、「babel」と呼ばれるUDPポート番号6697を登録しています。
IANA has registered the IPv6 multicast group ff02:0:0:0:0:0:1:6 and the IPv4 multicast group 224.0.0.111 for use by the Babel protocol.
IANAは、IPv6マルチキャストグループff02：0：0：0：0：0：1：6およびIPv4マルチキャストグループ224.0.0.111をBabelプロトコルで使用するために登録しました。
As defined in this document, Babel is a completely insecure protocol. Any attacker can attract data traffic by advertising routes with a low metric. This particular issue can be solved either by lower-layer security mechanisms (e.g., IPsec or link-layer security), or by appending a cryptographic key to Babel packets; the provision of ignoring any data contained within a Babel packet beyond the body length declared by the header is designed for just such a purpose.
このドキュメントで定義されているように、Babelは完全に安全でないプロトコルです。攻撃者は、低いメトリックでルートをアドバタイズすることにより、データトラフィックを引き付けることができます。この特定の問題は、下位層のセキュリティメカニズム（IPsecやリンク層のセキュリティなど）、またはBabelパケットに暗号化キーを追加することで解決できます。ヘッダーで宣言された本体長を超えるBabelパケットに含まれるデータを無視する規定は、まさにそのような目的のために設計されています。
The information that a Babel node announces to the whole routing domain is often sufficient to determine a mobile node's physical location with reasonable precision. The privacy issues that this causes can be mitigated somewhat by using randomly chosen router-ids and randomly chosen IP addresses, and changing them periodically.
多くの場合、Babelノードがルーティングドメイン全体に通知する情報は、モバイルノードの物理的な位置を適切な精度で特定するのに十分です。これによって引き起こされるプライバシーの問題は、ランダムに選択されたルーターIDとランダムに選択されたIPアドレスを使用し、それらを定期的に変更することである程度軽減できます。
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 provides protection against spoofed Babel packets being sent from the global Internet. No such natural protection exists when Babel packets are carried over IPv4.
IPv6を介して伝送される場合、リンクローカルIPv6アドレスから送信されない限り、Babelパケットは無視されます。ルーターはリンクローカルIPv6パケットを転送しないため、グローバルインターネットから送信されるスプーフィングされたBabelパケットに対する保護を提供します。 IPv4でバベルパケットが伝送される場合、そのような自然な保護は存在しません。
[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[ADDRARCH] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[DSDV] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers", ACM SIGCOMM'94 Conference on Communications Architectures, Protocols and Applications 234-244, 1994.
[DSDV] Perkins、C。およびP. Bhagwat、「モバイルコンピュータ用の高度に動的な宛先順の距離ベクトルルーティング（DSDV）」、ACM SIGCOMM'94 Conference on Communications Architectures、Protocols and Applications 234-244、1994。
[DUAL] Garcia Luna Aceves, J., "Loop-Free Routing Using Diffusing Computations", IEEE/ACM Transactions on Networking 1:1, February 1993.
[DUAL] Garcia Luna Aceves、J。、「拡散計算を使用したループフリールーティング」、ネットワーク上のIEEE / ACMトランザクション1：1、1993年2月。
[EIGRP] Albrightson, B., Garcia Luna Aceves, J., and J. Boyle, "EIGRP -- a Fast Routing Protocol Based on Distance Vectors", Proc. Interop 94, 1994.
[EIGRP] Albrightson、B.、Garcia Luna Aceves、J。、およびJ. Boyle、「EIGRP-距離ベクトルに基づく高速ルーティングプロトコル」、Proc。 Interop 94、1994。
[ETX] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A high-throughput path metric for multi-hop wireless networks", Proc. MobiCom 2003, 2003.
[ETX] De Couto、D.、Aguayo、D.、Bicket、J。、およびR. Morris、「マルチホップワイヤレスネットワークの高スループットパスメトリック」、Proc。 MobiCom 2003、2003。
[IS-IS] "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.
[IS-IS]「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための中間システムから中間システムのドメイン内ルーティング情報交換プロトコル、ISO / IEC 10589：2002。
[JITTER] Floyd, S. and V. Jacobson, "The synchronization of periodic routing messages", IEEE/ACM Transactions on Networking 2, 2, 122-136, April 1994.
[ジッタ]フロイド、S。およびV.ジェイコブソン、「定期的なルーティングメッセージの同期」、IEEE / ACM Transactions on Networking 2、2、122-136、1994年4月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[PACKETBB] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009.
[PACKETBB] Clausen、T.、Dearlove、C.、Dean、J。、およびC. Adjih、「Generalized Mobile Ad Hoc Network（MANET）Packet / Message Format」、RFC 5444、2009年2月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
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 Sections 3.4.3 and 3.5.2. Different nodes MAY use different strategies in a single network and MAY use different strategies on different interface types. This section gives a few examples of such strategies.
リンクコストとルートメトリックを計算するための戦略はローカルな問題です。 Babel自体は、セクション3.4.3および3.5.2に記載されている条件に準拠することのみを要求します。異なるノードは単一のネットワークで異なる戦略を使用してもよく（MAY）、異なるインターフェースタイプでは異なる戦略を使用してもよい（MAY）。このセクションでは、そのような戦略のいくつかの例を示します。
The sample implementation of Babel maintains statistics about the last 16 received Hello TLVs (Appendix A.1), computes costs by using the 2-out-of-3 strategy (Appendix A.2.1) on wired links, and ETX [ETX] on wireless links. It uses an additive algebra for metric computation (Appendix A.3.1).
Babelのサンプル実装は、最後に受信した16個のHello TLV（付録A.1）に関する統計を維持し、有線リンクで2-out-of-3戦略（付録A.2.1）を使用してコストを計算し、ETX [ETX]でワイヤレスリンク。メトリックの計算に加法代数を使用します（付録A.3.1）。
For each neighbour, the sample implementation of Babel maintains a Hello history and an expected sequence number. The Hello history is a vector of 16 bits, where a 1 value represents a received Hello, and a 0 value a missed 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.
各ネイバーに対して、Babelのサンプル実装はHello履歴と予想されるシーケンス番号を維持します。 Hello履歴は16ビットのベクトルであり、1の値は受信したHelloを表し、0の値は失敗したHelloを表します。予想されるシーケンス番号は、neと書かれており、このネイバーから次に受信されたhelloによって運ばれると予想されるシーケンス番号です。
Whenever it receives a Hello packet from a neighbour, a node compares the received sequence number nr with its expected sequence number ne. Depending on the outcome of this comparison, one of the following actions is taken:
隣接ノードからHelloパケットを受信するたびに、ノードは受信したシーケンス番号nrをその予期されるシーケンス番号neと比較します。この比較の結果に応じて、次のいずれかのアクションが実行されます。
o if the two differ by more than 16 (modulo 2^16), then the sending node has probably rebooted and lost its sequence number; the associated neighbour table entry is flushed;
o 2つが16（モジュロ2 ^ 16）以上異なる場合は、送信ノードが再起動してシーケンス番号を失っている可能性があります。関連するネイバーテーブルエントリがフラッシュされます。
o 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");
o それ以外の場合、受信したnrが予想されるシーケンス番号neよりも小さい（2 ^ 16を法とする）場合、送信ノードは通知なしにHello間隔を増やしています。受信ノードは、この近隣のHello履歴から最後の（ne-nr）エントリを削除します（「履歴を元に戻す」）。
o 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").
o それ以外の場合、nrがneよりも大きい（2 ^ 16を法とする）場合、送信ノードはHelloインターバルを減らし、一部のHelloが失われました。受信ノードはHello履歴に（nr-ne）0ビットを追加します（「早送り」）。
The receiving node then appends a 1 bit to the neighbour's Hello history, resets the neighbour's Hello timer, and sets ne to (nr + 1). It then resets the neighbour's Hello timer to 1.5 times the value advertised in the received Hello (the extra margin allows for the delay due to jitter).
次に、受信ノードは、近隣のHello履歴に1ビットを追加し、近隣のHelloタイマーをリセットして、neを（nr + 1）に設定します。次に、近隣のHelloタイマーを、受信したHelloでアドバタイズされた値の1.5倍にリセットします（追加のマージンにより、ジッターによる遅延が許容されます）。
Whenever the Hello timer associated to a neighbour expires, the local node adds a 0 bit to this neighbour's Hello history, and increments the expected Hello number. If the Hello history is empty (it contains 0 bits only), the neighbour entry is flushed; otherwise, it resets the neighbour's Hello timer to the value advertised in the last Hello received from this neighbour (no extra margin is necessary in this case).
ネイバーに関連付けられたHelloタイマーが期限切れになるたびに、ローカルノードはこのネイバーのHello履歴に0ビットを追加し、予想されるHello番号を増分します。 Hello履歴が空（0ビットのみを含む）の場合、ネイバーエントリはフラッシュされます。それ以外の場合は、ネイバーのHelloタイマーを、このネイバーから受信した最後のHelloでアドバタイズされた値にリセットします（この場合、追加のマージンは必要ありません）。
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 K >= 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 K; otherwise, the link is assumed to be down, and the rxcost is set to infinity.
k-out-of-j戦略は、0 <k <= jのような2つの小さな整数kおよびjと、公称リンクコスト、定数K> = 1によってパラメーター化されます。ノードは最後のjの履歴を保持しますこんにちは;それらのk以上が正しく受信された場合、リンクはアップしていると見なされ、rxcostはKに設定されます。そうでない場合、リンクはダウンしていると見なされ、rxcostは無限大に設定されます。
The cost of such a link is defined as
このようなリンクのコストは次のように定義されます
o cost = FFFF hexadecimal if rxcost = FFFF hexadecimal;
o rxcost = 16進数のFFFFの場合、コスト= 16進数のFFFF。
o cost = txcost otherwise.
o それ以外の場合、コスト= txcost。
The Estimated Transmission Cost metric [ETX] estimates the number of times that a unicast frame will be retransmitted by the IEEE 802.11 MAC, assuming infinite persistence.
推定伝送コストメトリック[ETX]は、永続性が無限であると仮定して、ユニキャストフレームがIEEE 802.11 MACによって再送信される回数を推定します。
A node uses a neighbour's Hello history to compute an estimate, written beta, of the probability that a Hello TLV is successfully received. The rxcost is defined as 256/beta.
ノードは、ネイバーのHello履歴を使用して、Hello TLVが正常に受信される確率の推定値（ベータ版）を計算します。 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をMIN（1、256 / txcost）、Hello TLVが正常に送信される確率の推定値とします。コストは次に計算されます
cost = 256/(alpha * beta)
or, equivalently,
または同等に、
cost = (MAX(txcost, 256) * rxcost) / 256.
The simplest approach for obtaining a monotonic, isotonic metric is to define the metric of a route as the sum of the costs of the component links. More formally, if a neighbour advertises a route with metric m over a link with cost c, then the resulting route has metric M(c, m) = c + m.
単調で等張のメトリックを取得するための最も簡単なアプローチは、コンポーネントリンクのコストの合計としてルートのメトリックを定義することです。より正式には、ネイバーがコストcのリンクを介してメトリックmのルートをアドバタイズする場合、結果のルートはメトリックM（c、m）= c + mになります。
A multiplicative metric can be converted to an additive one by taking the logarithm (in some suitable base) of the link costs.
乗算コストは、リンクコストの対数（適切な底数）をとることにより、加算メトリックに変換できます。
A node may want to vary its willingness to forward packets by taking into account information that is external to the Babel protocol, such as the monetary cost of a link, the node's battery status, CPU load, etc. This can be done by adding to every route's metric a value k that depends on the external data. For example, if a battery-powered node receives an update with metric m over a link with cost c, it might compute a metric M(c, m) = k + c + m, where k depends on the battery status.
ノードは、リンクの金銭的コスト、ノードのバッテリーステータス、CPU負荷など、Babelプロトコルの外部にある情報を考慮に入れて、パケットを転送する意欲を変えたい場合があります。これは、すべてのルートのメトリックは、外部データに依存する値kです。たとえば、バッテリー駆動のノードがコストcのリンクを介してメトリックmの更新を受信した場合、ノードはメトリックM（c、m）= k + c + mを計算する可能性があります。
In order to preserve strict monotonicity (Section 3.5.2), the value k must be greater than -c.
厳密な単調性を維持するために（セクション3.5.2）、値kは-cより大きくなければなりません。
The choice of time constants is a trade-off between fast detection of mobility events and protocol overhead. Two implementations of Babel with different time constants will interoperate, although the resulting convergence time will most likely be dictated by the slowest of the two implementations.
時定数の選択は、モビリティイベントの高速検出とプロトコルオーバーヘッドの間のトレードオフです。異なる時定数を持つ2つの実装のBabelは相互運用しますが、結果として生じる収束時間は、2つの実装のうち最も遅いものによって決まる可能性が最も高くなります。
Experience with the sample implementation of Babel indicates that the Hello interval is the most important time constant: a mobility event is detected within 1.5 to 3 Hello intervals. Due to Babel's reliance on triggered updates and explicit requests, the Update interval only has an effect on the time it takes for accurate metrics to be propagated after variations in link costs too small to trigger an unscheduled update.
Babelのサンプル実装の経験は、Helloインターバルが最も重要な時定数であることを示しています。モビリティイベントは1.5〜3のHelloインターバル内で検出されます。トリガーされた更新と明示的な要求にBabelが依存しているため、更新間隔は、リンクコストの変動が小さすぎてスケジュールされていない更新をトリガーできない場合に、正確なメトリックが伝達されるのにかかる時間にのみ影響します。
At the time of writing, the sample implementation of Babel uses the following default values:
執筆時点では、Babelのサンプル実装では次のデフォルト値を使用しています。
Hello Interval: 4 seconds on wireless links, 20 seconds on wired links.
Hello間隔：ワイヤレスリンクで4秒、有線リンクで20秒。
IHU Interval: the advertised IHU interval is always 3 times the Hello interval. IHUs are actually sent with each Hello on lossy links (as determined from the Hello history), but only with every third Hello on lossless links.
IHU間隔：アドバタイズされたIHU間隔は常にHello間隔の3倍です。 IHUは実際には、（Hello履歴から判断される）損失のあるリンクでHelloを送信するたびに送信されますが、損失のないリンクでHelloを送信するのは3回に1回のみです。
Update Interval: 4 times the 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倍。
Source GC time: 3 minutes.
ソースGC時間：3分。
The amount of jitter applied to a packet depends on whether it contains any urgent TLVs or not. Urgent triggered updates and urgent requests are delayed by no more than 200 ms; other TLVs are delayed by no more than one-half the Hello interval.
パケットに適用されるジッターの量は、緊急のTLVが含まれているかどうかによって異なります。緊急トリガーによる更新と緊急リクエストは、200ミリ秒以内に遅延します。他のTLVは、Helloインターバルの半分以下の遅延です。
Babel is a fairly economic protocol. Route updates take between 12 and 40 octets per destination, depending on how successful compression is; in a double-stack mesh network, an average of less than 24 octets 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 20000-entry routing table and the associated source table.
バベルはかなり経済的なプロトコルです。ルートの更新には、圧縮の成功度に応じて、宛先ごとに12〜40オクテットかかります。ダブルスタックメッシュネットワークでは、平均で24オクテット未満が一般的です。ルートテーブルは、IPv6エントリごとに約35オクテットを占めます。これらの値を全体的に見ると、単一のフルサイズイーサネットフレームで約65のルート更新を伝送でき、1メガバイトのメモリに20000エントリのルーティングテーブルと関連するソーステーブルを含めることができます。
Babel is also a reasonably simple protocol. The sample implementation consists of less than 8000 lines of C code, and it compiles to less than 60 kB of text on a 32-bit CISC architecture.
Babelも、かなりシンプルなプロトコルです。サンプル実装は8000行未満のCコードで構成されており、32ビットCISCアーキテクチャで60 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、電子レンジ、そろばんなどの非常に制約された環境では、プロトコルのサブセット実装が望ましい場合があります。
A parasitic implementation is one that uses a Babel network for routing its packets but does not announce any of the routes that it has learnt from its neighbours. (This is slightly more than a passive implementation, which doesn't even announce routes to itself.) It may either maintain a full routing table or simply select a gateway amongst any one of its neighbours that announces a default route. Since a parasitic implementation never forwards packets, it cannot possibly participate in a routing loop; hence, it need not evaluate the feasibility condition and need not maintain a source table.
寄生実装とは、パケットのルーティングにBabelネットワークを使用しますが、近隣から学習したルートをアナウンスしない実装です。 （これは、自分自身へのルートをアナウンスしないパッシブ実装よりもわずかに多くなります。）完全なルーティングテーブルを維持するか、デフォルトルートをアナウンスするネイバーのいずれかからゲートウェイを選択するだけです。寄生実装はパケットを転送しないため、ルーティングループに参加することはできません。したがって、実現可能性の条件を評価したり、ソーステーブルを維持したりする必要はありません。
A parasitic implementation MUST answer acknowledgement requests and MUST participate in the Hello/IHU protocol. Finally, it MUST be able to reply to seqno requests for routes that it announces and SHOULD be able to reply to route requests.
寄生実装は確認応答要求に応答する必要があり、Hello / IHUプロトコルに参加する必要があります。最後に、それがアナウンスするルートのseqnoリクエストに返信できなければならず、ルートリクエストに返信できる必要があります（SHOULD）。
The sample implementation of Babel is available from <http://www.pps.jussieu.fr/~jch/software/babel/>.
Babelのサンプル実装は<http://www.pps.jussieu.fr/~jch/software/babel/>から入手できます。
Author's Address
著者のアドレス
Juliusz Chroboczek PPS, University of Paris 7 Case 7014 75205 Paris Cedex 13, France
Juliusz Chroboczek PPS、パリ大学7 Case 7014 75205 Paris Cedex 13、フランス
EMail: jch@pps.jussieu.fr
メール：jch@pps.jussieu.fr