Independent Submission J. Chroboczek
Request for Comments: 6126 PPS, University of Paris 7
Category: Experimental April 2011
ISSN: 2070-1721
Independent Submission J. Chroboczek
Request for Comments: 6126 PPS, University of Paris 7
Category: Experimental April 2011
ISSN: 2070-1721
The Babel Routing Protocol
巴贝尔路由协议
Abstract
摘要
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.
Babel是一种避免环路的距离向量路由协议，在普通有线网络和无线网状网络中都是健壮和高效的。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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
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]不同，它强烈限制了路由病态的频率和持续时间，如重新聚合期间的路由循环和黑洞。即使在检测到移动事件之后，巴贝尔网络通常保持无环路。然后，巴贝尔迅速重新聚合到一种配置，该配置保留了网络的循环自由度和连通性，但不一定是最优的；在许多情况下，此操作根本不需要数据包交换。然后，巴贝尔在几分钟的时间内慢慢收敛到最佳配置。这是通过使用顺序路由（Destination sequenced Distance Vector routing[DSDV]首创的一种技术）实现的。
More precisely, Babel has the following properties:
更准确地说，巴别塔具有以下特性：
o when every prefix is originated by at most one router, Babel never suffers from routing loops;
o 当每个前缀最多由一个路由器产生时，巴贝尔从不遭受路由循环；
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
Babel节点将成功建立关联，即使它们配置了不同的参数。例如，电池电量不足的移动节点可能会选择使用比能够访问墙壁的节点更大的时间常数（hello和update Interval等）
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.
权力相反，检测到高移动性水平的节点可以选择使用较小的时间常数。构建这种异构网络的能力使巴贝尔特别适合无线环境。
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是一种混合路由协议，因为它可以承载多个网络层协议（IPv4和IPv6）的路由，无论Babel数据包本身承载哪个协议。
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有两个限制，不适合在某些环境中使用。首先，巴贝尔依赖于定期的路由表更新，而不是使用可靠的传输；因此，在大型、稳定的网络中，它比仅在网络拓扑发生变化时发送更新的协议产生更多的流量。在这种网络中，诸如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.
第二，当前缀被收回时，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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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是一个基本上没有环路的距离向量协议：它基于Bellman-Ford协议，就像古老的RIP[RIP]，但包括许多改进，要么完全防止环路形成，要么确保环路及时消失，不再形成。
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计算任意两个相邻节点之间链路的成本，即附加到两个节点之间边缘的抽象值。我们用C（A，B）表示从节点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.
给定任意两个节点之间的路由，路由的度量是沿路由的所有边的成本之和。路由算法的目标是为每个源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).
成本和指标不需要是整数。通常，它们可以是任何代数中满足两个相当一般条件的值（第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消息；它还定期向最近听到问候的每个邻居发送IHU（“我听到你了”）消息。根据从其邻居B接收的Hello和IHU消息导出的信息，节点a计算从a到B的链路的成本C（a，B）。
Every node A maintains two pieces of data: its estimated distance to S, written D(A), and its next-hop router to S, written NH(A). Initially, D(S) = 0, D(A) is infinite, and NH(A) is undefined.
每个节点A维护两段数据：其到S的估计距离，写入D（A），以及其到S的下一跳路由器，写入NH（A）。最初，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.
对该算法的许多改进是可能的，巴别塔也使用了这些改进。特别地，除了常规的预定更新之外，只要检测到拓扑中的重大变化，就可以通过发送非预定的“触发更新”来提高收敛速度。此外，节点可以维护多个备用路由，这些备用路由由其所选邻居以外的邻居播发，并且如果所选路由失败，可以立即使用这些备用路由。
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
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
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（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是一个非常健壮的算法：当路由器延迟路由获取或丢弃一些更新时，它的收敛特性保持不变。巴贝尔路由器丢弃接收到的路由通知，除非它们能够证明接受它们不可能导致路由循环。
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.
在目的地顺序距离向量（DSDV）路由[DSDV]和自组织按需距离向量（AODV）路由中使用的另一个简单的可行性条件来自以下观察：路由循环只能在路由器切换到比其先前选择的路由具有更大度量的路由后出现。因此，只有当路由在本地节点的度量不大于当前所选路由的度量时，才可以确定路由是可行的，即，当C（a，B）+D（B）<=D（a）时，承载度量D（B）的公告被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向其任何邻居宣传S的最小度量。当B公布的度量D（B）严格小于a的可行性距离时，即当D（B）<FD（a）时，a的邻居B发送的更新是可行的。
It is easy to see that this latter condition is no more restrictive than DSDV-feasibility. Suppose that node A obeys DSDV-feasibility; then D(A) is nonincreasing, hence at all times D(A) <= FD(A). Suppose now that A receives a DSDV-feasible update that advertises a metric D(B). Since the update is DSDV-feasible, C(A, B) + D(B) <= D(A), hence D(B) < D(A), and since D(A) <= FD(A), D(B) < FD(A).
不难看出，后一种情况并不比DSDV的可行性更具限制性。假设节点A服从DSDV；那么D（A）是非递增的，因此在任何时候D（A）<=FD（A）。现在假设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
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）。由于此属性在发送更新时保留，因此始终保持为真，这确保转发图没有循环。
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
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
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的“活动”阶段）时，这基本上就是EIGRP所做的。
Babel reacts to starvation in a less drastic manner, by using sequenced routes, a technique introduced by DSDV and adopted by AODV. In addition to a metric, every route carries a sequence number, a nondecreasing integer that is propagated unchanged through the network and is only ever incremented by the source; a pair (s, m), where s is a sequence number and m a metric, is called a distance.
巴别塔对饥饿的反应不那么激烈，它使用的是由DSDV引入并被AODV采用的一种技术——序列路由。除了一个度量之外，每条路由都携带一个序列号，这是一个非减量整数，在网络中传播时保持不变，并且仅由源递增；一对（s，m），其中s是序列号，m是度量，称为距离。
A received update is feasible when either it is more recent than the feasibility distance maintained by the receiving node, or it is
当接收到的更新比接收节点保持的可行性距离最近，或者是
equally recent and the metric is strictly smaller. More formally, if
FD(A) = (s, m), then an update carrying the distance (s', m') is
feasible when either s' > s, or s = s' and m' < m.
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
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
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.
巴贝尔采取了不同的方法。当一个节点检测到它正遭受潜在的虚假饥饿时，它会向源发送一个明确的请求，请求一个新的序列号。该请求被逐跳转发到源，与可行性条件无关。在接收到请求后，源增加其序列号并广播更新，该更新被转发到请求节点。
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.)
请注意，在网络拓扑发生更改后，通常并非所有此类请求都会到达源，因为有些请求将通过现在断开的链接发送。然而，如果网络仍然连接，则遭受虚假饥饿的节点中的至少一个具有到源的（不可行的）路由；因此，在没有分组丢失的情况下，至少一个这样的请求将到达源。（少量重新发送请求可补偿数据包丢失。）
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，并且可行性距离不是按前缀维护的，而是按源维护的，其中，源是路由器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
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).
此外，在路由器公布两条路由后，两个源都将在其源表中，这将防止它们再次参与涉及来自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
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.)
每个巴别塔扬声器都分配了一个路由器id，这是一个由8个八位字节组成的任意字符串，假定在整个路由域中是唯一的。我们建议路由器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数据包由一个或多个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包可以发送到众所周知的（链路本地）多播地址（这是通常的情况）或（链路本地）单播地址。在正常操作中，巴别塔扬声器向其邻居发送多播和单播数据包。
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都可以发送到单播或多播地址，它们的语义不取决于目的地是单播还是多播地址。因此，巴别塔说话者不需要确定它接收的数据包的目的地址来解释它。
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.
巴别塔扬声器发送的数据包会有适度的抖动：传出的TLV会被缓冲，并且应该以较小的随机延迟发送。这样做有两个目的：它避免了网络上多个巴别塔扬声器的同步[JITTER]，并允许将多个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。
Every Babel speaker maintains a number of data structures.
每个巴别塔扬声器都维护许多数据结构。
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），因为增加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
interface表包含节点使用Babel协议的接口列表。每个接口表条目都包含接口的Hello seqno，这是一个16位整数，随每个接口表条目一起发送
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.)
此接口上的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.
有两个计时器与每个接口表条目相关联——Hello计时器，用于控制定期Hello和IHU数据包的发送；update计时器，用于控制定期路由更新的发送。
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，这可以是n比特的序列，指示该邻居最近发送的n个hello中的哪一个已被本地节点接收；
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保持计时器已过期，则为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.
有两个定时器与每个相邻条目关联——hello定时器，根据hello TLV携带的间隔值初始化；IHU定时器，初始化为IHU TLV携带的间隔的小倍数。
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.
注意，邻居表是由IP地址而不是路由器ID索引的：邻居关系是接口之间的关系，而不是节点之间的关系。因此，具有多个接口的两个节点可以参与多个邻居关系，这在涉及具有多个无线电的无线节点时是相当常见的情况。
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:
源表用于记录可行性距离。它由格式的三元组（前缀、plen、路由器id）索引，每个源表条目包含以下数据：
o the prefix (prefix, plen), where plen is the prefix length, that this entry applies to;
o 前缀（prefix，plen），其中，plen是该条目适用的前缀长度；
o the router-id of a router originating this prefix;
o 发起此前缀的路由器的路由器id；
o a pair (seqno, metric), this source's feasibility distance.
o 一对（seqno，metric），该源的可行性距离。
There is one timer associated with each entry in the source table -- the source garbage-collection timer. It is initialised to a time on the order of minutes and reset as specified in Section 3.7.3.
源表中的每个条目都有一个计时器——源垃圾收集计时器。按照第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:
路由表包含此节点已知的路由。它由形式的三元组（前缀、plen、邻居）索引，每个路由表条目包含以下数据：
o the source (prefix, plen, router-id) for which this route is advertised;
o 为其播发此路由的源（前缀、plen、路由器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十六进制（无穷大）；
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.
每个路由表条目都有一个计时器——路由到期计时器。按照第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和seqno；
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.
有一个计时器与每个挂起的请求相关联；它管理请求的重新发送及其到期。
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.
巴别塔说话者可以请求任何接收到给定分组的邻居在给定时间内回复明确的确认。虽然使用确认请求是可选的，但每个巴别塔发言人都必须能够答复此类请求。
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.
邻居捕获是巴别塔节点发现通过其每个接口听到的邻居集并确定双向可达性的过程。在不可靠的媒体上，邻居捕获还提供了一些可用于链路质量计算的统计信息。
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间隔。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（“我听到了”）TLV。由于ihu带有一个显式的间隔值，因此它们可能比hello发送的频率低，以减少密集网络中的路由流量；特别是，它们应该在几乎没有数据包丢失的情况下通过链路发送，而不是像Hellos那样频繁。虽然IHU在概念上是单播的，但它们应该发送到多播地址，以避免ARP或邻居发现交换，并在单个数据包中聚合多个IHU。
In addition to the periodic IHUs, a node MAY, at any time, send an unscheduled IHU packet. It MAY also, at any time, decrease its IHU interval, and it MAY increase its IHU interval immediately before sending an IHU.
除了周期性IHU之外，节点可以在任何时候发送未经调度的IHU分组。它也可以在任何时候减少其IHU间隔，并且可以在发送IHU之前立即增加其IHU间隔。
Every IHU TLV contains two pieces of data: the link's rxcost (reception cost) from the sender's perspective, used by the neighbour for computing link costs (Section 3.4.3), and the interval between periodic IHU packets. A node receiving an IHU 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包含两条数据：从发送方的角度来看，链路的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如何组合以计算链路成本是当地政策的问题；就巴别塔的正确性而言，只需满足以下条件：
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更新是一个五元组（prefix，plen，router id，seqno，metric），其中（prefix，plen）是为其通告路由的前缀，router id是发起此更新的路由器的路由器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，metric），其中seqno是模2^16的整数，metric是正整数。可行性距离是按字典顺序进行比较的，第一部分是颠倒的：我们说一个距离（seqno，metric）严格地比一个距离（seqno，metric'）要好
(seqno, metric) < (seqno', metric')
（序号，公制）<（序号，公制）
when
什么时候
seqno > seqno' or (seqno = seqno' and metric < metric')
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），根据上面定义的顺序，该源的节点的可行性距离是该特定节点发送的所有有限更新的距离的最小值，这些更新用于承载路由器id的前缀（p，plen）。可行性距离保留在源表中；第3.7.3节给出了准确的程序。
A received update is feasible when either it is a retraction (its metric is FFFF hexadecimal), or the advertised distance is strictly better, in the sense defined above, than the feasibility distance for the corresponding source. More precisely, a route advertisement carrying the quintuple (prefix, plen, router-id, seqno, metric) is feasible if one of the following conditions holds:
当接收到的更新是收回（其度量为FFFF十六进制）或播发距离严格优于相应源的可行性距离（在上文定义的意义上）时，接收到的更新是可行的。更准确地说，如果满足以下条件之一，则携带五元组（前缀、plen、路由器id、序号、度量）的路由公告是可行的：
o metric is infinite; or
o 度量是无限的；或
o no entry exists in the source table indexed by (id, prefix, plen); or
o 源表中不存在由（id、前缀、plen）索引的项；或
o an entry (prefix, plen, router-id, seqno', metric') exists in the source table, and either
o 源表中存在一个条目（前缀、plen、路由器id、序号、度量），并且
* seqno' < seqno or
* seqno'<seqno或
* seqno = seqno' and metric < metric'.
* seqno=seqno'和公制<公制'。
Note that the feasibility condition considers the metric advertised by the neighbour, not the route's metric; hence, a fluctuation in a neighbour's cost cannot render a selected route unfeasible.
注意，可行性条件考虑的是邻居公布的指标，而不是路线的指标；因此，邻居成本的波动不会导致所选路线不可行。
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:
此外，度量应满足以下条件：
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.
在大型网络中，巴别塔的大部分流量由路由更新组成；因此，在有效地编码它们方面给予了一些注意。更新TLV本身仅包含前缀、seqno和度量，而下一跳是从数据包的网络层源地址或同一数据包中的显式下一跳TLV派生的。路由器id来自同一数据包中的单独路由器id TLV，这优化了使用相同路由器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].
此外，在更新TLV中可以省略播发前缀的前缀，在这种情况下，它是从同一数据包中的先前更新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节点从邻居neigh接收到链路成本值等于成本的更新（id、前缀、序号、度量）时，它会检查是否已经有一个路由表项，该路由表项的索引为（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 如果条目当前已安装且更新不可行，则行为取决于两个条目的路由器ID是否匹配。如果路由器ID不同，则将更新视为收回（即，度量为FFFF十六进制）。如果路由器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旨在允许灵活的路线选择策略。就协议的正确性而言，路由选择策略必须仅满足以下属性：
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:
为巴别塔定义一个好的路线选择策略是一个开放的研究问题。路线选择可以考虑多个相互矛盾的标准；按照重要性的大致递减顺序，这些是：
o routes with a small metric should be preferred over routes with a large metric;
o 小指标路线应优先于大指标路线；
o switching router-ids should be avoided;
o 应避免交换路由器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.
一位巴别塔演讲者向其邻居宣传其选定的路线。通常，这是通过在其所有连接的接口上发送一个或多个包含更新TLV的多播数据包来实现的；然而，在多播比单播昂贵得多的链路技术上，当邻居数较少时，节点可以选择在单播分组中发送更新的多个副本。
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.
如果更新是针对本地节点注入巴别塔域的路由（例如，本地接口的地址、直连网络的前缀或从不同路由协议重新分发），则路由器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.
如果更新是针对从另一个巴别塔扬声器学习到的路由，则从路由表条目复制路由器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不受路由循环的影响（不存在“无限计数”），并且严重依赖于触发的更新（第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.
除了定期的路由更新外，巴别塔扬声器还发送计划外的或触发的更新，以便通知其邻居网络拓扑的重大变化。
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).
有两种策略可以确保这一点。如果邻居的数量很小，那么将更新与确认请求一起发送是合理的；直到所有邻居都确认了数据包，更新才会重新发送，最多可发送若干次。但是，如果邻居的数量很大，请求所有邻居的确认可能会导致不可忽略的网络流量；在这种情况下，最好简单地重复更新一些合理的次数（例如，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.
路由收回稍微不那么令人担忧：如果路由收回没有到达所有邻居，可能会产生一个黑洞，与路由循环不同，它不会危及网络的完整性。当一条路由被收回时，一个节点应该发送一个触发的更新，并且应该做出合理的尝试来确保所有邻居都收到这个收回。
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).
最后，当给定前缀的度量由于接收到的更新或由于链路成本已经改变而显著改变时，节点可以发送触发的更新。节点不应出于其他原因发送触发的更新，例如当路由的度量发生微小波动时，当选定的下一跳发生变化时，或传播新的序列号（除非满足第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.
在发送具有有限度量（即，不是路由收回）的更新（前缀、plen、路由器id、序号、度量）之前，Babel节点更新源表中维护的可行性距离。这是这样做的。
If no entry indexed by (prefix, plen, router-id) exists in the source table, then one is created with value (prefix, plen, router-id, seqno, metric).
如果源表中不存在以（前缀、plen、路由器id）为索引的条目，则将使用值（前缀、plen、路由器id、序号、度量）创建一个条目。
If an entry (prefix, plen, router-id, seqno', metric') exists, then it is updated as follows:
如果存在条目（前缀、plen、路由器id、序号、度量），则会按如下方式进行更新：
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技术（如以太网）上运行时，Babel节点应使用称为拆分地平线的优化。当在给定接口上使用拆分视界时，当通过同一接口从邻居处学习播发的路由时，不会在此特定接口上发送路由更新。
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协议提供两种显式请求：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.
当节点收到通配符路由请求时，它应该发送一个完整的路由表转储。
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不同或相等，且条目的序列号不小于请求的序列号，则必须发送给定前缀的更新。
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.
如果路由器id匹配，但请求的序号大于路由条目的序号，则节点将路由器id与其自己的路由器id进行比较。如果路由器id是自己的，则将其序号增加1并发送更新。节点响应路由请求时，其序号不得增加1以上。
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.
节点应维护最近转发的请求列表，并及时转发回复。节点应将每个传入请求与其最近转发的请求列表进行比较，并避免转发冗余请求。
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.
低，无需执行扩展范围搜索。请求不能转发到多播地址，只能转发到单个邻居。
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请求；只有一种情况需要发起请求（第3.8.2.1节）。
When a route is retracted or expires, a Babel node usually switches to another feasible route for the same prefix. It may be the case, however, that no such routes are available.
当一条路由被收回或过期时，巴别塔节点通常会为相同的前缀切换到另一条可行的路由。然而，可能没有这样的路线。
A node that has lost all feasible routes to a given destination 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请求。请求的路由器id设置为刚刚丢失的路由的路由器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.)
这样的请求应该在节点的所有连接接口上进行多播。类似的请求将由受路由丢失影响的其他节点发送，并由相邻节点转发到源节点。如果网络已连接，并且没有数据包丢失，这将导致使用新序列号通告路由。（请注意，由于重复抑制，只有少量此类请求实际到达源。）
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.
为了补偿数据包丢失，如果在短时间内没有可行的路由，则节点应重复此类请求少量次。然而，在严重的数据包丢失情况下，所有这些请求都可能丢失；在这种情况下，下一节中的第二个机制将最终确保接收到新的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请求。如上所述，从源表计算请求的序列号。
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.
然而，在存在分组丢失的情况下，可能在延长的时间段内没有成功接收到更新，从而导致路由过期。为了避免这种虚假失效，在所选路由失效之前不久，Babel节点应向播发该路由的邻居发送单播路由请求；由于节点总是响应非通配符路由请求发送收回（第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.
为了在移动事件之后加速收敛，节点可以在获取新邻居之后发送单播通配符请求。此外，节点可在引导后不久发送少量多播通配符请求。
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.
Babel数据包作为UDP数据报的主体发送，网络层跳数设置为1，通过IPv4或IPv6发送到众所周知的多播地址或单播地址；在IPv6的情况下，这些地址是本地链路。源和目标UDP端口都设置为已知的端口号。除非Babel数据包的源地址是链路本地IPv6地址或属于本地网络的IPv4地址，并且其源端口是众所周知的Babel端口，否则必须以静默方式忽略该数据包。Babel数据包不得作为IPv6巨型程序发送。
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-
为了尽量减少发送的数据包数量，同时避免低层碎片，Babel节点应尝试最大化其发送的数据包的大小，直到输出接口的MTU针对低层头进行了调整（UDP/IPv4为28个八位字节，UDP/IPv6为48个八位字节）。它发送的数据包不得大于连接接口的MTU（针对较低层头进行调整）或512个八位字节（以较大者为准），但不得超过针对较低层头进行调整的2^16-1-
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.
层标题。每个巴别塔扬声器必须能够接收与任何连接接口的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，并通过一个小的随机选择的延迟[JITTER]延迟发送UDP数据包。为了准确计算数据包丢失率，此延迟不得大于播发的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.
相对时间作为16位值携带，指定厘米秒数（百分之一秒）。这使时间达到约11分钟，粒度为10毫秒，应涵盖巴贝尔的所有合理应用。
A router-id is an arbitrary 8-octet value. Router-ids SHOULD be assigned in modified EUI-64 format [ADDRARCH].
路由器id是一个任意的8位字节值。路由器ID应以修改的EUI-64格式[ADDRARCH]分配。
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和AE 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-octet报头组成，后跟一系列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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
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.
魔术任意但仔细选择的值42（十进制）；第一个八位组不同于42的数据包必须被静默忽略。
Version This document specifies version 2 of the Babel protocol. Packets with a second octet different from 2 MUST be silently ignored.
版本本文件规定了巴别塔协议的版本2。第二个八位组不同于2的数据包必须被静默忽略。
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.
正文后面的任何数据都必须以静默方式忽略。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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 |
+-+-+-+-+-+-+-+-+
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
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.
输入设置为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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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请求接收器在间隔字段指定的厘米数内发送确认TLV。
Fields :
领域：
Type Set to 2 to indicate an Acknowledgement Request TLV.
输入设置为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.
Nonce将在接收器的确认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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
输入设置为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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
输入Set为4以指示Hello 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发送，在接收时必须忽略。
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。
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...
+-+-+-+-+-+-+-+-+-+-+-+-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length | AE | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rxcost | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address...
+-+-+-+-+-+-+-+-+-+-+-+-
An IHU ("I Heard You") TLV is used for confirming bidirectional reachability and carrying a link's transmission cost.
IHU（“我听说你”）TLV用于确认双向可达性和承载链路的传输成本。
Fields :
领域：
Type Set to 5 to indicate an IHU TLV.
输入设置为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根据在地址字段中指定地址的接口发送节点的Rxcost。FFFF十六进制值（无穷大）表示无法访问此接口。
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
从概念上讲，IHU的目的地是一个邻居。但是，IHU TLV包含一个明确的目标地址，应该将其发送到多播地址，因为这允许聚集目标IHU
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.
将不同的邻居放入单个数据包中，避免在邻居未用于数据通信时需要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 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
输入Set为6以指示路由器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
路由器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...
+-+-+-+-+-+-+-+-+-+-+-+-
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为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...
+-+-+-+-+-+-+-+-+-+-+-+-
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.
更新TLV播发或收回路线。作为一种优化，这还可能产生建立新的隐含路由器id和新的默认前缀的副作用。
Fields :
领域：
Type Set to 8 to indicate an Update TLV.
键入Set为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的标志；未知标志必须以静默方式忽略。
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，标志值为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十六进制值（无穷大）表示，除非收到请求，否则不会重复本公告（第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.
Metric此路由的发件人度量。FFFF十六进制值（无穷大）表示这是一个路线收回。
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 如果设置了值为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 如果设置了值为40十六进制的位，则播发前缀的低位8个八位字节为该TLV和同一数据包中的后续更新TLV建立新的默认路由器id。
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 前缀的第一个省略的八位字节取自上一次更新TLV，设置了标志80十六进制和相同的地址族；
o the next (Plen/8 - Omitted) (rounded upwards) octets are taken from the Prefix field;
o 下一个（Plen/8-省略）（向上舍入）八位字节取自前缀字段；
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.
如果度量字段是有限的，则如果在标志字段中设置了值为40十六进制的位，则此通告的发起节点的路由器id将取自此更新播发的前缀的低位8个八位字节。否则，它将取自前面的路由器Id数据包或设置了标志40十六进制的前面更新数据包，以最后一个为准。
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.
如果公制字段为FFFF十六进制，则此TLV指定收回。在这种情况下，不使用当前路由器id和Seqno。AE随后可能为0，在这种情况下，此更新将收回先前在此接口上公布的所有路由。
Update 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 = 9 | Length | AE | Plen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-
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.
路由请求TLV提示接收方发送给定前缀的更新或完整路由表转储。
Fields :
领域：
Type Set to 9 to indicate a Route Request TLV.
输入设置为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...
+-+-+-+-+-+-+-+-+-+-+
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.
输入设置为10以指示Seqno请求消息。
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请求TLV提示接收节点发送由AE、Plen和prefix字段指定的前缀的更新，路由器id不同于路由器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，则不得转发该请求。
IANA has registered the UDP port number 6697, called "babel", for use by the Babel protocol.
IANA已注册UDP端口号6697，称为“babel”，供babel协议使用。
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传输时，Babel数据包被忽略，除非它们是从链路本地IPv6地址发送的；由于路由器不转发本地IPv6数据包，因此可以防止来自全球互联网的伪造Babel数据包。当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 42912006年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通信体系结构、协议和应用会议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:11993年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 941994年。
[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.
[JITTER]Floyd，S.和V.Jacobson，“定期路由消息的同步”，IEEE/ACM网络事务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 23281998年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，“通用移动自组网（MANET）分组/消息格式”，RFC 54442009年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.
计算链路成本和路由度量的策略是本地事务；巴别塔本身仅要求其符合第3.4.3节和第3.5.2节中给出的条件。不同的节点可以在单个网络中使用不同的策略，并且可以在不同的接口类型上使用不同的策略。本节给出了一些此类策略的示例。
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），在有线链路上使用三取二策略（附录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 history是一个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 如果两者相差超过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小于（模2^16）预期的序列号ne，则发送节点在我们没有注意到的情况下增加了其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策略由两个小整数k和j参数化，使得0<k<=j，并且标称链路成本为常数k>=1。节点保存最后一个j hello的历史记录；如果正确地接收到k个或多个，则假定链路已接通，并且rxcost设置为k；否则，假定链路断开，并且rxcost设置为无穷大。
The cost of such a link is defined as
此类链接的成本定义为：
o cost = FFFF hexadecimal if rxcost = FFFF hexadecimal;
o 如果rxcost=FFFF十六进制，则成本=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的概率的估计值（写beta）。RX成本定义为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（1256/txcost），表示成功发送Hello TLV的概率估计值。然后通过以下公式计算成本：
cost = 256/(alpha * beta)
cost = 256/(alpha * beta)
or, equivalently,
或者，相当于，
cost = (MAX(txcost, 256) * rxcost) / 256.
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.
节点可能希望通过考虑Babel协议外部的信息来改变其转发数据包的意愿，例如链路的货币成本、节点的电池状态、CPU负载等。这可以通过向每个路由的度量中添加一个取决于外部数据的值k来实现。例如，如果电池供电的节点通过成本为c的链路接收到具有度量m的更新，则它可能计算度量m（c，m）=k+c+m，其中k取决于电池状态。
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.
时间常数的选择是移动事件快速检测和协议开销之间的权衡。具有不同时间常数的两个Babel实现将互操作，尽管最终的收敛时间很可能由两个实现中最慢的一个决定。
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.
你好间隔：无线连接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。
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个路由更新，一兆字节的内存可以包含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体系结构上编译到不到60KB的文本。
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.
在其任何一个邻居中选择一个宣布默认路由的网关。由于寄生实现从不转发数据包，因此它不可能参与路由循环；因此，它不需要评估可行性条件，也不需要维护源表。
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路由请求，并且应该能够回复路由请求。
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，巴黎第七大学案例7014，75205巴黎CEDEX 13，法国
EMail: jch@pps.jussieu.fr
EMail: jch@pps.jussieu.fr