Network Working Group C. Perkins
Request for Comments: 3561 Nokia Research Center
Category: Experimental E. Belding-Royer
University of California, Santa Barbara
S. Das
University of Cincinnati
July 2003
Network Working Group C. Perkins
Request for Comments: 3561 Nokia Research Center
Category: Experimental E. Belding-Royer
University of California, Santa Barbara
S. Das
University of Cincinnati
July 2003
Ad hoc On-Demand Distance Vector (AODV) Routing
自组织按需距离向量（AODV）路由
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols.
adhoc按需距离向量（AODV）路由协议旨在供adhoc网络中的移动节点使用。它提供了对动态链路条件的快速适应、较低的处理和内存开销、较低的网络利用率，并确定到自组织网络内目的地的单播路由。它使用目的地序列号来确保在任何时候（即使面对路由控制消息的异常传递）都有循环自由，避免了与经典距离向量协议相关的问题（如“计数到无穷大”）。
Table of Contents
目录
1. Introduction ............................................... 2
2. Overview .................................................. 3
3. AODV Terminology ........................................... 4
4. Applicability Statement .................................... 6
5. Message Formats ............................................ 7
5.1. Route Request (RREQ) Message Format ................... 7
5.2. Route Reply (RREP) Message Format ..................... 8
5.3. Route Error (RERR) Message Format ..................... 10
5.4. Route Reply Acknowledgment (RREP-ACK) Message Format .. 11
6. AODV Operation ............................................. 11
6.1. Maintaining Sequence Numbers .......................... 11
6.2. Route Table Entries and Precursor Lists ............... 13
1. Introduction ............................................... 2
2. Overview .................................................. 3
3. AODV Terminology ........................................... 4
4. Applicability Statement .................................... 6
5. Message Formats ............................................ 7
5.1. Route Request (RREQ) Message Format ................... 7
5.2. Route Reply (RREP) Message Format ..................... 8
5.3. Route Error (RERR) Message Format ..................... 10
5.4. Route Reply Acknowledgment (RREP-ACK) Message Format .. 11
6. AODV Operation ............................................. 11
6.1. Maintaining Sequence Numbers .......................... 11
6.2. Route Table Entries and Precursor Lists ............... 13
6.3. Generating Route Requests ............................. 14
6.4. Controlling Dissemination of Route Request Messages ... 15
6.5. Processing and Forwarding Route Requests .............. 16
6.6. Generating Route Replies .............................. 18
6.6.1. Route Reply Generation by the Destination ...... 18
6.6.2. Route Reply Generation by an Intermediate
Node ........................................... 19
6.6.3. Generating Gratuitous RREPs .................... 19
6.7. Receiving and Forwarding Route Replies ................ 20
6.8. Operation over Unidirectional Links ................... 21
6.9. Hello Messages ........................................ 22
6.10 Maintaining Local Connectivity ........................ 23
6.11 Route Error (RERR) Messages, Route Expiry and Route
Deletion .............................................. 24
6.12 Local Repair .......................................... 26
6.13 Actions After Reboot ................................. 27
6.14 Interfaces ............................................ 28
7. AODV and Aggregated Networks ............................... 28
8. Using AODV with Other Networks ............................. 29
9. Extensions ................................................. 30
9.1. Hello Interval Extension Format ....................... 30
10. Configuration Parameters ................................... 31
11. Security Considerations .................................... 33
12. IANA Considerations ........................................ 34
13. IPv6 Considerations ........................................ 34
14. Acknowledgments ............................................ 34
15. Normative References ....................................... 35
16. Informative References ..................................... 35
17. Authors' Addresses ......................................... 36
18. Full Copyright Statement ................................... 37
6.3. Generating Route Requests ............................. 14
6.4. Controlling Dissemination of Route Request Messages ... 15
6.5. Processing and Forwarding Route Requests .............. 16
6.6. Generating Route Replies .............................. 18
6.6.1. Route Reply Generation by the Destination ...... 18
6.6.2. Route Reply Generation by an Intermediate
Node ........................................... 19
6.6.3. Generating Gratuitous RREPs .................... 19
6.7. Receiving and Forwarding Route Replies ................ 20
6.8. Operation over Unidirectional Links ................... 21
6.9. Hello Messages ........................................ 22
6.10 Maintaining Local Connectivity ........................ 23
6.11 Route Error (RERR) Messages, Route Expiry and Route
Deletion .............................................. 24
6.12 Local Repair .......................................... 26
6.13 Actions After Reboot ................................. 27
6.14 Interfaces ............................................ 28
7. AODV and Aggregated Networks ............................... 28
8. Using AODV with Other Networks ............................. 29
9. Extensions ................................................. 30
9.1. Hello Interval Extension Format ....................... 30
10. Configuration Parameters ................................... 31
11. Security Considerations .................................... 33
12. IANA Considerations ........................................ 34
13. IPv6 Considerations ........................................ 34
14. Acknowledgments ............................................ 34
15. Normative References ....................................... 35
16. Informative References ..................................... 35
17. Authors' Addresses ......................................... 36
18. Full Copyright Statement ................................... 37
The Ad hoc On-Demand Distance Vector (AODV) algorithm enables dynamic, self-starting, multihop routing between participating mobile nodes wishing to establish and maintain an ad hoc network. AODV allows mobile nodes to obtain routes quickly for new destinations, and does not require nodes to maintain routes to destinations that are not in active communication. AODV allows mobile nodes to respond to link breakages and changes in network topology in a timely manner. The operation of AODV is loop-free, and by avoiding the Bellman-Ford "counting to infinity" problem offers quick convergence when the ad hoc network topology changes (typically, when a node moves in the network). When links break, AODV causes the affected set of nodes to be notified so that they are able to invalidate the routes using the lost link.
Ad hoc On Demand Distance Vector（AODV）算法能够在希望建立和维护Ad hoc网络的参与移动节点之间实现动态、自启动、多跳路由。AODV允许移动节点快速获取新目的地的路由，并且不需要节点维护到非活动通信目的地的路由。AODV允许移动节点及时响应链路中断和网络拓扑的变化。AODV的操作是无循环的，并且通过避免Bellman-Ford“计数到无穷大”问题，在自组织网络拓扑发生变化时（通常，当节点在网络中移动时）提供快速收敛。当链路中断时，AODV会通知受影响的节点集，以便它们能够使用丢失的链路使路由失效。
One distinguishing feature of AODV is its use of a destination sequence number for each route entry. The destination sequence number is created by the destination to be included along with any route information it sends to requesting nodes. Using destination sequence numbers ensures loop freedom and is simple to program. Given the choice between two routes to a destination, a requesting node is required to select the one with the greatest sequence number.
AODV的一个显著特征是它对每个路由条目使用目的地序列号。目的地序列号由目的地创建，与发送到请求节点的任何路由信息一起包含。使用目标序列号可以确保循环自由度，并且编程简单。在两条到目的地的路由之间进行选择时，请求节点需要选择序列号最大的路由。
Route Requests (RREQs), Route Replies (RREPs), and Route Errors (RERRs) are the message types defined by AODV. These message types are received via UDP, and normal IP header processing applies. So, for instance, the requesting node is expected to use its IP address as the Originator IP address for the messages. For broadcast messages, the IP limited broadcast address (255.255.255.255) is used. This means that such messages are not blindly forwarded. However, AODV operation does require certain messages (e.g., RREQ) to be disseminated widely, perhaps throughout the ad hoc network. The range of dissemination of such RREQs is indicated by the TTL in the IP header. Fragmentation is typically not required.
路由请求（RREQ）、路由回复（RREP）和路由错误（RERR）是AODV定义的消息类型。这些消息类型通过UDP接收，并应用正常的IP报头处理。因此，例如，请求节点将使用其IP地址作为消息的发起方IP地址。对于广播消息，使用IP限制广播地址（255.255.255.255）。这意味着此类消息不会盲目转发。然而，AODV操作确实需要广泛传播某些消息（例如，RREQ），可能是在整个adhoc网络中。此类RREQ的传播范围由IP报头中的TTL指示。通常不需要分段。
As long as the endpoints of a communication connection have valid routes to each other, AODV does not play any role. When a route to a new destination is needed, the node broadcasts a RREQ to find a route to the destination. A route can be determined when the RREQ reaches either the destination itself, or an intermediate node with a 'fresh enough' route to the destination. A 'fresh enough' route is a valid route entry for the destination whose associated sequence number is at least as great as that contained in the RREQ. The route is made available by unicasting a RREP back to the origination of the RREQ. Each node receiving the request caches a route back to the originator of the request, so that the RREP can be unicast from the destination along a path to that originator, or likewise from any intermediate node that is able to satisfy the request.
只要通信连接的端点彼此之间有有效的路由，AODV就不起任何作用。当需要到新目的地的路由时，节点广播RREQ以查找到目的地的路由。当RREQ到达目的地本身或具有到目的地的“足够新鲜”路由的中间节点时，可以确定路由。“足够新鲜”路由是目的地的有效路由条目，其关联序列号至少与RREQ中包含的序列号相同。通过将RREP单播回RREQ的发端，该路由可用。接收请求的每个节点缓存回请求的发起方的路由，以便RREP可以从目的地沿着路径单播到该发起方，或者同样地从能够满足请求的任何中间节点单播。
Nodes monitor the link status of next hops in active routes. When a link break in an active route is detected, a RERR message is used to notify other nodes that the loss of that link has occurred. The RERR message indicates those destinations (possibly subnets) which are no longer reachable by way of the broken link. In order to enable this reporting mechanism, each node keeps a "precursor list", containing the IP address for each its neighbors that are likely to use it as a next hop towards each destination. The information in the precursor lists is most easily acquired during the processing for generation of a RREP message, which by definition has to be sent to a node in a precursor list (see section 6.6). If the RREP has a nonzero prefix
节点监视活动路由中下一跳的链路状态。当检测到活动路由中的链路中断时，将使用RERR消息通知其他节点该链路已丢失。RERR消息表示那些不再可以通过断开的链路到达的目的地（可能是子网）。为了启用此报告机制，每个节点保留一个“前体列表”，其中包含每个节点及其邻居的IP地址，这些邻居可能将其用作每个目的地的下一个跃点。前体列表中的信息最容易在生成RREP消息的过程中获取，根据定义，该消息必须发送到前体列表中的节点（见第6.6节）。如果RREP具有非零前缀
length, then the originator of the RREQ which solicited the RREP information is included among the precursors for the subnet route (not specifically for the particular destination).
长度，则请求RREP信息的RREQ的发起者包括在子网路由的前体中（不是专门针对特定目的地）。
A RREQ may also be received for a multicast IP address. In this document, full processing for such messages is not specified. For example, the originator of such a RREQ for a multicast IP address may have to follow special rules. However, it is important to enable correct multicast operation by intermediate nodes that are not enabled as originating or destination nodes for IP multicast addresses, and likewise are not equipped for any special multicast protocol processing. For such multicast-unaware nodes, processing for a multicast IP address as a destination IP address MUST be carried out in the same way as for any other destination IP address.
还可以接收多播IP地址的RREQ。在本文档中，未指定此类消息的完整处理。例如，多播IP地址的这种RREQ的发起人可能必须遵循特殊规则。然而，重要的是通过中间节点启用正确的多播操作，这些中间节点未启用为IP多播地址的起始或目标节点，并且同样未配备任何特殊多播协议处理。对于这种不知道多播的节点，多播IP地址作为目的地IP地址的处理必须以与任何其他目的地IP地址相同的方式进行。
AODV is a routing protocol, and it deals with route table management. Route table information must be kept even for short-lived routes, such as are created to temporarily store reverse paths towards nodes originating RREQs. AODV uses the following fields with each route table entry:
AODV是一种路由协议，它处理路由表管理。即使对于短命路由，也必须保留路由表信息，例如创建用于临时存储指向发起RREQ的节点的反向路径的路由。AODV对每个路由表条目使用以下字段：
- Destination IP Address - Destination Sequence Number - Valid Destination Sequence Number flag - Other state and routing flags (e.g., valid, invalid, repairable, being repaired) - Network Interface - Hop Count (number of hops needed to reach destination) - Next Hop - List of Precursors (described in Section 6.2) - Lifetime (expiration or deletion time of the route)
- 目的地IP地址-目的地序列号-有效目的地序列号标志-其他状态和路由标志（例如，有效、无效、可修复、正在修复）-网络接口-跳数（到达目的地所需的跳数）-下一跳-前体列表（如第6.2节所述）-生存期（路由的过期或删除时间）
Managing the sequence number is crucial to avoiding routing loops, even when links break and a node is no longer reachable to supply its own information about its sequence number. A destination becomes unreachable when a link breaks or is deactivated. When these conditions occur, the route is invalidated by operations involving the sequence number and marking the route table entry state as invalid. See section 6.1 for details.
管理序列号对于避免路由循环至关重要，即使当链路断开并且节点不再能够提供其自身的序列号信息时也是如此。当链接中断或停用时，目标将无法到达。当出现这些情况时，涉及序列号并将路由表条目状态标记为无效的操作会使路由无效。详见第6.1节。
This protocol specification uses conventional meanings [1] for capitalized words such as MUST, SHOULD, etc., to indicate requirement levels for various protocol features. This section defines other terminology used with AODV that is not already defined in [3].
本协议规范使用大写单词的常规含义[1]，如必须、应该等，以表示各种协议功能的需求水平。本节定义了[3]中尚未定义的与AODV一起使用的其他术语。
active route
活动路线
A route towards a destination that has a routing table entry that is marked as valid. Only active routes can be used to forward data packets.
指向具有标记为有效的路由表项的目标的路由。只有活动路由可用于转发数据包。
broadcast
广播
Broadcasting means transmitting to the IP Limited Broadcast address, 255.255.255.255. A broadcast packet may not be blindly forwarded, but broadcasting is useful to enable dissemination of AODV messages throughout the ad hoc network.
广播是指发送到IP限制广播地址255.255.255.255。广播分组可能不会被盲目转发，但广播有助于在整个自组织网络中传播AODV消息。
destination
目的地
An IP address to which data packets are to be transmitted. Same as "destination node". A node knows it is the destination node for a typical data packet when its address appears in the appropriate field of the IP header. Routes for destination nodes are supplied by action of the AODV protocol, which carries the IP address of the desired destination node in route discovery messages.
数据包要传输到的IP地址。与“目的节点”相同。当一个节点的地址出现在IP报头的相应字段中时，该节点就知道它是典型数据包的目标节点。目标节点的路由由AODV协议的操作提供，该协议在路由发现消息中携带所需目标节点的IP地址。
forwarding node
转发节点
A node that agrees to forward packets destined for another node, by retransmitting them to a next hop that is closer to the unicast destination along a path that has been set up using routing control messages.
通过沿使用路由控制消息设置的路径将数据包重新传输到离单播目的地更近的下一跳，从而同意转发目的地为另一节点的数据包的一种节点。
forward route
前进路线
A route set up to send data packets from a node originating a Route Discovery operation towards its desired destination.
一种路由，用于从发起路由发现操作的节点向其所需目的地发送数据包。
invalid route
无效路由
A route that has expired, denoted by a state of invalid in the routing table entry. An invalid route is used to store previously valid route information for an extended period of time. An invalid route cannot be used to forward data packets, but it can provide information useful for route repairs, and also for future RREQ messages.
已过期的路由，由路由表条目中的无效状态表示。无效路由用于在较长时间内存储以前有效的路由信息。无效路由不能用于转发数据包，但它可以提供对路由修复有用的信息，也可以用于将来的RREQ消息。
originating node
起始节点
A node that initiates an AODV route discovery message to be processed and possibly retransmitted by other nodes in the ad hoc network. For instance, the node initiating a Route Discovery process and broadcasting the RREQ message is called the originating node of the RREQ message.
发起AODV路由发现消息的节点，该消息将由自组织网络中的其他节点处理并可能重新传输。例如，发起路由发现过程并广播RREQ消息的节点称为RREQ消息的发起节点。
reverse route
反向路线
A route set up to forward a reply (RREP) packet back to the originator from the destination or from an intermediate node having a route to the destination.
为将应答（RREP）数据包从目的地或从具有到目的地的路由的中间节点转发回发起方而设置的一种路由。
sequence number
序列号
A monotonically increasing number maintained by each originating node. In AODV routing protocol messages, it is used by other nodes to determine the freshness of the information contained from the originating node.
由每个起始节点维持的单调递增的数。在AODV路由协议消息中，其他节点使用它来确定来自发起节点的信息的新鲜度。
valid route
有效路线
See active route.
请参阅活动路线。
The AODV routing protocol is designed for mobile ad hoc networks with populations of tens to thousands of mobile nodes. AODV can handle low, moderate, and relatively high mobility rates, as well as a variety of data traffic levels. AODV is designed for use in networks where the nodes can all trust each other, either by use of preconfigured keys, or because it is known that there are no malicious intruder nodes. AODV has been designed to reduce the dissemination of control traffic and eliminate overhead on data traffic, in order to improve scalability and performance.
AODV路由协议是为具有数十到数千个移动节点的移动自组织网络设计的。AODV可以处理低、中、相对高的移动速率，以及各种数据流量级别。AODV设计用于所有节点都可以相互信任的网络中，或者通过使用预配置的密钥，或者因为已知不存在恶意入侵者节点。AODV旨在减少控制流量的传播，消除数据流量的开销，以提高可扩展性和性能。
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 |J|R|G|D|U| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |J|R|G|D|U| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Route Request message is illustrated above, and contains the following fields:
路由请求消息的格式如上图所示，包含以下字段：
Type 1
类型1
J Join flag; reserved for multicast.
J加入旗；为多播保留。
R Repair flag; reserved for multicast.
R修复标志；为多播保留。
G Gratuitous RREP flag; indicates whether a gratuitous RREP should be unicast to the node specified in the Destination IP Address field (see sections 6.3, 6.6.3).
G免费RREP标志；指示无偿RREP是否应单播到目标IP地址字段中指定的节点（请参阅第6.3、6.6.3节）。
D Destination only flag; indicates only the destination may respond to this RREQ (see section 6.5).
D仅目的地标志；表示只有目的地可以响应此RREQ（见第6.5节）。
U Unknown sequence number; indicates the destination sequence number is unknown (see section 6.3).
U未知序列号；表示目标序列号未知（见第6.3节）。
Reserved Sent as 0; ignored on reception.
保留发送为0；接待时被忽略。
Hop Count The number of hops from the Originator IP Address to the node handling the request.
跃点计数从发起方IP地址到处理请求的节点的跃点数。
RREQ ID A sequence number uniquely identifying the particular RREQ when taken in conjunction with the originating node's IP address.
RREQ ID当与发起节点的IP地址一起使用时，唯一标识特定RREQ的序列号。
Destination IP Address The IP address of the destination for which a route is desired.
目的地IP地址需要路由的目的地的IP地址。
Destination Sequence Number The latest sequence number received in the past by the originator for any route towards the destination.
目的地序列号发端人过去收到的任何通往目的地的路线的最新序列号。
Originator IP Address The IP address of the node which originated the Route Request.
发起方IP地址发起路由请求的节点的IP地址。
Originator Sequence Number The current sequence number to be used in the route entry pointing towards the originator of the route request.
发起者序列号—指向路由请求发起者的路由条目中要使用的当前序列号。
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 |R|A| Reserved |Prefix Sz| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |R|A| Reserved |Prefix Sz| Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Route Reply message is illustrated above, and contains the following fields:
路由回复消息的格式如上图所示，包含以下字段：
Type 2
类型2
R Repair flag; used for multicast.
R修复标志；用于多播。
A Acknowledgment required; see sections 5.4 and 6.7.
需要确认；见第5.4节和第6.7节。
Reserved Sent as 0; ignored on reception.
保留发送为0；接待时被忽略。
Prefix Size If nonzero, the 5-bit Prefix Size specifies that the indicated next hop may be used for any nodes with the same routing prefix (as defined by the Prefix Size) as the requested destination.
前缀大小如果非零，则5位前缀大小指定所指示的下一跳可用于具有与请求目的地相同的路由前缀（由前缀大小定义）的任何节点。
Hop Count The number of hops from the Originator IP Address to the Destination IP Address. For multicast route requests this indicates the number of hops to the multicast tree member sending the RREP.
跃点计数从发端IP地址到目标IP地址的跃点数。对于多播路由请求，这表示发送RREP的多播树成员的跳数。
Destination IP Address The IP address of the destination for which a route is supplied.
目的地IP地址为其提供路由的目的地的IP地址。
Destination Sequence Number The destination sequence number associated to the route.
目的地序列号与路由关联的目的地序列号。
Originator IP Address The IP address of the node which originated the RREQ for which the route is supplied.
发起方IP地址为其提供路由的RREQ发起节点的IP地址。
Lifetime The time in milliseconds for which nodes receiving the RREP consider the route to be valid.
寿命：接收RRIP的节点认为毫秒的时间考虑路由是有效的。
Note that the Prefix Size allows a subnet router to supply a route for every host in the subnet defined by the routing prefix, which is determined by the IP address of the subnet router and the Prefix Size. In order to make use of this feature, the subnet router has to guarantee reachability to all the hosts sharing the indicated subnet prefix. See section 7 for details. When the prefix size is nonzero, any routing information (and precursor data) MUST be kept with respect to the subnet route, not the individual destination IP address on that subnet.
请注意，前缀大小允许子网路由器为路由前缀定义的子网中的每个主机提供路由，路由前缀由子网路由器的IP地址和前缀大小决定。为了利用此功能，子网路由器必须保证所有共享指定子网前缀的主机的可达性。详见第7节。当前缀大小非零时，必须保留与子网路由有关的任何路由信息（和前体数据），而不是该子网上的单个目标IP地址。
The 'A' bit is used when the link over which the RREP message is sent may be unreliable or unidirectional. When the RREP message contains the 'A' bit set, the receiver of the RREP is expected to return a RREP-ACK message. See section 6.8.
当发送RREP消息的链路可能不可靠或单向时，使用“A”位。当RREP消息包含“A”位集时，RREP的接收器应返回RREP-ACK消息。见第6.8节。
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 |N| Reserved | DestCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Destination IP Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Destination Sequence Number (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Additional Unreachable Destination IP Addresses (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Additional Unreachable Destination Sequence Numbers (if needed)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |N| Reserved | DestCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Destination IP Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreachable Destination Sequence Number (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Additional Unreachable Destination IP Addresses (if needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Additional Unreachable Destination Sequence Numbers (if needed)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Route Error message is illustrated above, and contains the following fields:
路由错误消息的格式如上图所示，包含以下字段：
Type 3
类型3
N No delete flag; set when a node has performed a local repair of a link, and upstream nodes should not delete the route.
N无删除标志；当节点已对链路执行本地修复，且上游节点不应删除路由时设置。
Reserved Sent as 0; ignored on reception.
保留发送为0；接待时被忽略。
DestCount The number of unreachable destinations included in the message; MUST be at least 1.
统计消息中包含的无法到达目的地的数量；必须至少为1。
Unreachable Destination IP Address The IP address of the destination that has become unreachable due to a link break.
无法访问的目标IP地址由于链路中断而无法访问的目标IP地址。
Unreachable Destination Sequence Number The sequence number in the route table entry for the destination listed in the previous Unreachable Destination IP Address field.
无法到达的目的地序列号—路由表条目中的序列号，用于上一个无法到达的目的地IP地址字段中列出的目的地。
The RERR message is sent whenever a link break causes one or more destinations to become unreachable from some of the node's neighbors. See section 6.2 for information about how to maintain the appropriate records for this determination, and section 6.11 for specification about how to create the list of destinations.
每当链路中断导致一个或多个目的地无法从节点的某些邻居访问时，就会发送RERR消息。参见第6.2节了解如何维护本次确定的适当记录，参见第6.11节了解如何创建目的地列表的规范。
The Route Reply Acknowledgment (RREP-ACK) message MUST be sent in response to a RREP message with the 'A' bit set (see section 5.2). This is typically done when there is danger of unidirectional links preventing the completion of a Route Discovery cycle (see section 6.8).
必须发送路由回复确认（RREP-ACK）消息，以响应设置了“a”位的RREP消息（见第5.2节）。这通常是在存在单向链路妨碍完成路由发现周期的危险时进行的（见第6.8节）。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 4
类型4
Reserved Sent as 0; ignored on reception.
保留发送为0；接待时被忽略。
This section describes the scenarios under which nodes generate Route Request (RREQ), Route Reply (RREP) and Route Error (RERR) messages for unicast communication towards a destination, and how the message data are handled. In order to process the messages correctly, certain state information has to be maintained in the route table entries for the destinations of interest.
本节描述了节点生成路由请求（RREQ）、路由回复（RREP）和路由错误（RERR）消息以进行到目的地的单播通信的场景，以及如何处理消息数据。为了正确处理消息，必须在感兴趣的目的地的路由表条目中维护某些状态信息。
All AODV messages are sent to port 654 using UDP.
所有AODV消息都使用UDP发送到端口654。
Every route table entry at every node MUST include the latest information available about the sequence number for the IP address of the destination node for which the route table entry is maintained. This sequence number is called the "destination sequence number". It is updated whenever a node receives new (i.e., not stale) information about the sequence number from RREQ, RREP, or RERR messages that may be received related to that destination. AODV depends on each node in the network to own and maintain its destination sequence number to guarantee the loop-freedom of all routes towards that node. A destination node increments its own sequence number in two circumstances:
每个节点上的每个路由表条目都必须包含有关维护路由表条目的目标节点IP地址序列号的最新可用信息。该序列号称为“目的地序列号”。每当节点从可能接收到的与该目的地相关的RREQ、RREP或RERR消息中接收到关于序列号的新信息（即，未过时）时，它就会更新。AODV依赖于网络中的每个节点拥有并维护其目的地序列号，以保证所有路由到该节点的环路自由。目标节点在两种情况下增加其自身的序列号：
- Immediately before a node originates a route discovery, it MUST increment its own sequence number. This prevents conflicts with previously established reverse routes towards the originator of a RREQ.
- 在节点发起路由发现之前，它必须增加自己的序列号。这可以防止与先前建立的反向路由冲突，这些反向路由指向RREQ的发起方。
- Immediately before a destination node originates a RREP in response to a RREQ, it MUST update its own sequence number to the maximum of its current sequence number and the destination sequence number in the RREQ packet.
- 在目标节点响应RREQ发起RREP之前，它必须将自己的序列号更新为其当前序列号和RREQ数据包中的目标序列号的最大值。
When the destination increments its sequence number, it MUST do so by treating the sequence number value as if it were an unsigned number. To accomplish sequence number rollover, if the sequence number has already been assigned to be the largest possible number representable as a 32-bit unsigned integer (i.e., 4294967295), then when it is incremented it will then have a value of zero (0). On the other hand, if the sequence number currently has the value 2147483647, which is the largest possible positive integer if 2's complement arithmetic is in use with 32-bit integers, the next value will be 2147483648, which is the most negative possible integer in the same numbering system. The representation of negative numbers is not relevant to the increment of AODV sequence numbers. This is in contrast to the manner in which the result of comparing two AODV sequence numbers is to be treated (see below).
当目标增加其序列号时，必须将序列号值视为无符号数。为了实现序列号滚动，如果序列号已被指定为可表示为32位无符号整数（即4294967295）的最大可能数字，则当其递增时，其值将为零（0）。另一方面，如果序列号当前具有值2147483647，这是如果2的补码算法与32位整数一起使用时可能的最大正整数，则下一个值将是2147483648，这是相同编号系统中可能的最大负整数。负数的表示与AODV序列号的增量无关。这与比较两个AODV序列号的结果的处理方式相反（见下文）。
In order to ascertain that information about a destination is not stale, the node compares its current numerical value for the sequence number with that obtained from the incoming AODV message. This comparison MUST be done using signed 32-bit arithmetic, this is necessary to accomplish sequence number rollover. If the result of subtracting the currently stored sequence number from the value of the incoming sequence number is less than zero, then the information related to that destination in the AODV message MUST be discarded, since that information is stale compared to the node's currently stored information.
为了确定关于目的地的信息没有过时，节点将其序列号的当前数值与从传入AODV消息获得的数值进行比较。此比较必须使用有符号32位算术完成，这是完成序列号滚动所必需的。如果从传入序列号的值中减去当前存储的序列号的结果小于零，则必须丢弃AODV消息中与该目的地相关的信息，因为该信息与节点当前存储的信息相比是过时的。
The only other circumstance in which a node may change the destination sequence number in one of its route table entries is in response to a lost or expired link to the next hop towards that destination. The node determines which destinations use a particular next hop by consulting its routing table. In this case, for each destination that uses the next hop, the node increments the sequence number and marks the route as invalid (see also sections 6.11, 6.12). Whenever any fresh enough (i.e., containing a sequence number at least equal to the recorded sequence number) routing information for an affected destination is received by a node that has marked that route table entry as invalid, the node SHOULD update its route table information according to the information contained in the update.
节点可以更改其路由表条目之一中的目的地序列号的唯一其他情况是响应到该目的地的下一跳的丢失或过期链路。节点通过查阅其路由表来确定哪些目的地使用特定的下一跳。在这种情况下，对于使用下一跳的每个目的地，节点增加序列号并将路由标记为无效（另请参见第6.11、6.12节）。当已将路由表条目标记为无效的节点接收到受影响目的地的任何足够新鲜（即，包含至少等于记录的序列号的序列号）的路由信息时，该节点应根据更新中包含的信息更新其路由表信息。
A node may change the sequence number in the routing table entry of a destination only if:
只有在以下情况下，节点才能更改目的地路由表条目中的序列号：
- it is itself the destination node, and offers a new route to itself, or
- 它本身就是目的地节点，并向自身提供新路由，或
- it receives an AODV message with new information about the sequence number for a destination node, or
- 它接收一条AODV消息，其中包含有关目标节点的序列号的新信息，或
- the path towards the destination node expires or breaks.
- 指向目标节点的路径过期或中断。
When a node receives an AODV control packet from a neighbor, or creates or updates a route for a particular destination or subnet, it checks its route table for an entry for the destination. In the event that there is no corresponding entry for that destination, an entry is created. The sequence number is either determined from the information contained in the control packet, or else the valid sequence number field is set to false. The route is only updated if the new sequence number is either
当节点从邻居接收AODV控制数据包，或为特定目的地或子网创建或更新路由时，它会检查其路由表中的目的地条目。如果该目的地没有对应的条目，则会创建一个条目。序列号可以根据控制数据包中包含的信息确定，也可以将有效序列号字段设置为false。仅当新序列号为
(i) higher than the destination sequence number in the route table, or
(i) 高于路由表中的目标序列号，或
(ii) the sequence numbers are equal, but the hop count (of the new information) plus one, is smaller than the existing hop count in the routing table, or
（ii）序列号相等，但（新信息的）跃点计数加上1小于路由表中的现有跃点计数，或
(iii) the sequence number is unknown.
（iii）序列号未知。
The Lifetime field of the routing table entry is either determined from the control packet, or it is initialized to ACTIVE_ROUTE_TIMEOUT. This route may now be used to send any queued data packets and fulfills any outstanding route requests.
路由表条目的生存期字段由控制数据包确定，或者初始化为活动路由超时。该路由现在可用于发送任何排队的数据包，并满足任何未完成的路由请求。
Each time a route is used to forward a data packet, its Active Route Lifetime field of the source, destination and the next hop on the path to the destination is updated to be no less than the current time plus ACTIVE_ROUTE_TIMEOUT. Since the route between each originator and destination pair is expected to be symmetric, the Active Route Lifetime for the previous hop, along the reverse path back to the IP source, is also updated to be no less than the current time plus ACTIVE_ROUTE_TIMEOUT. The lifetime for an Active Route is updated each time the route is used regardless of whether the destination is a single node or a subnet.
每次使用路由转发数据包时，其源、目的地和到目的地的路径上的下一跳的活动路由生存期字段将更新为不小于当前时间加上活动路由超时。由于每个发起者和目的地对之间的路由预期是对称的，因此沿返回IP源的反向路径的上一跳的活动路由生存期也会更新为不小于当前时间加上活动路由超时。无论目的地是单个节点还是子网，每次使用路由时都会更新活动路由的生存期。
For each valid route maintained by a node as a routing table entry, the node also maintains a list of precursors that may be forwarding packets on this route. These precursors will receive notifications from the node in the event of detection of the loss of the next hop link. The list of precursors in a routing table entry contains those neighboring nodes to which a route reply was generated or forwarded.
对于由节点作为路由表条目维护的每个有效路由，该节点还维护可能在该路由上转发分组的前体的列表。如果检测到下一跳链路丢失，这些前体将从节点接收通知。路由表条目中的前体列表包含生成或转发路由应答的相邻节点。
A node disseminates a RREQ when it determines that it needs a route to a destination and does not have one available. This can happen if the destination is previously unknown to the node, or if a previously valid route to the destination expires or is marked as invalid. The Destination Sequence Number field in the RREQ message is the last known destination sequence number for this destination and is copied from the Destination Sequence Number field in the routing table. If no sequence number is known, the unknown sequence number flag MUST be set. The Originator Sequence Number in the RREQ message is the node's own sequence number, which is incremented prior to insertion in a RREQ. The RREQ ID field is incremented by one from the last RREQ ID used by the current node. Each node maintains only one RREQ ID. The Hop Count field is set to zero.
当节点确定它需要到目的地的路由而没有可用路由时，它会传播RREQ。如果节点以前不知道目的地，或者以前有效的到目的地的路由过期或标记为无效，则可能发生这种情况。RREQ消息中的目的地序列号字段是该目的地的最后一个已知目的地序列号，并从路由表中的目的地序列号字段复制。如果序列号未知，则必须设置未知序列号标志。RREQ消息中的发起者序列号是节点自己的序列号，在插入RREQ之前递增。RREQ ID字段从当前节点使用的最后一个RREQ ID递增一。每个节点仅维护一个RREQ ID。跃点计数字段设置为零。
Before broadcasting the RREQ, the originating node buffers the RREQ ID and the Originator IP address (its own address) of the RREQ for PATH_DISCOVERY_TIME. In this way, when the node receives the packet again from its neighbors, it will not reprocess and re-forward the packet.
在广播RREQ之前，发起节点将RREQ ID和RREQ的发起方IP地址（其自己的地址）缓冲到路径发现时间。这样，当节点再次从其邻居接收到数据包时，它将不会重新处理和转发数据包。
An originating node often expects to have bidirectional communications with a destination node. In such cases, it is not sufficient for the originating node to have a route to the destination node; the destination must also have a route back to the originating node. In order for this to happen as efficiently as possible, any generation of a RREP by an intermediate node (as in section 6.6) for delivery to the originating node SHOULD be accompanied by some action that notifies the destination about a route back to the originating node. The originating node selects this mode of operation in the intermediate nodes by setting the 'G' flag. See section 6.6.3 for details about actions taken by the intermediate node in response to a RREQ with the 'G' flag set.
发起节点通常期望与目标节点进行双向通信。在这种情况下，发起节点具有到目的地节点的路由是不够的；目的地还必须有一条回发起节点的路由。为了尽可能有效地实现这一点，中间节点（如第6.6节所述）为交付给发起节点而生成的任何RREP都应伴随一些动作，通知目的地返回发起节点的路由。发起节点通过设置“G”标志在中间节点中选择此操作模式。有关中间节点响应设置了“G”标志的RREQ所采取的措施的详细信息，请参见第6.6.3节。
A node SHOULD NOT originate more than RREQ_RATELIMIT RREQ messages per second. After broadcasting a RREQ, a node waits for a RREP (or other control message with current information regarding a route to the appropriate destination). If a route is not received within NET_TRAVERSAL_TIME milliseconds, the node MAY try again to discover a route by broadcasting another RREQ, up to a maximum of RREQ_RETRIES
节点每秒发起的RREQ_RATELIMIT RREQ消息不应超过。在广播RREQ之后，节点等待RREP（或具有关于到适当目的地的路由的当前信息的其他控制消息）。如果在NET_TRAVERSAL_时间毫秒内未接收到路由，则节点可通过广播另一个RREQ来再次尝试发现路由，最多可重试RREQ_次
times at the maximum TTL value. Each new attempt MUST increment and update the RREQ ID. For each attempt, the TTL field of the IP header is set according to the mechanism specified in section 6.4, in order to enable control over how far the RREQ is disseminated for the each retry.
最大TTL值下的时间。每次新尝试都必须增加并更新RREQ ID。对于每次尝试，IP报头的TTL字段根据第6.4节中指定的机制进行设置，以便能够控制每次重试时RREQ的传播距离。
Data packets waiting for a route (i.e., waiting for a RREP after a RREQ has been sent) SHOULD be buffered. The buffering SHOULD be "first-in, first-out" (FIFO). If a route discovery has been attempted RREQ_RETRIES times at the maximum TTL without receiving any RREP, all data packets destined for the corresponding destination SHOULD be dropped from the buffer and a Destination Unreachable message SHOULD be delivered to the application.
等待路由的数据包（即，在发送RREQ后等待RREP）应进行缓冲。缓冲应为“先进先出”（FIFO）。如果已尝试路由发现，则在未接收任何RREP的情况下，以最大TTL重试RREQ_次，则应从缓冲区中删除所有目的地为相应目的地的数据包，并向应用程序发送目的地不可访问消息。
To reduce congestion in a network, repeated attempts by a source node at route discovery for a single destination MUST utilize a binary exponential backoff. The first time a source node broadcasts a RREQ, it waits NET_TRAVERSAL_TIME milliseconds for the reception of a RREP. If a RREP is not received within that time, the source node sends a new RREQ. When calculating the time to wait for the RREP after sending the second RREQ, the source node MUST use a binary exponential backoff. Hence, the waiting time for the RREP corresponding to the second RREQ is 2 * NET_TRAVERSAL_TIME milliseconds. If a RREP is not received within this time period, another RREQ may be sent, up to RREQ_RETRIES additional attempts after the first RREQ. For each additional attempt, the waiting time for the RREP is multiplied by 2, so that the time conforms to a binary exponential backoff.
为了减少网络中的拥塞，源节点在路由发现时对单个目的地的重复尝试必须利用二进制指数退避。源节点第一次广播RREQ时，它会等待净遍历时间（毫秒）以接收RREP。如果在该时间内未接收到RREP，则源节点发送新的RREQ。在计算发送第二个RREQ后等待RREP的时间时，源节点必须使用二进制指数退避。因此，对应于第二RREQ的RREP的等待时间是2×净遍历时间毫秒。如果在此时间段内未收到RREP，则可能会发送另一个RREQ，直到RREQ_在第一个RREQ之后重试其他尝试。对于每一次额外的尝试，RREP的等待时间乘以2，以便该时间符合二元指数退避。
To prevent unnecessary network-wide dissemination of RREQs, the originating node SHOULD use an expanding ring search technique. In an expanding ring search, the originating node initially uses a TTL = TTL_START in the RREQ packet IP header and sets the timeout for receiving a RREP to RING_TRAVERSAL_TIME milliseconds. RING_TRAVERSAL_TIME is calculated as described in section 10. The TTL_VALUE used in calculating RING_TRAVERSAL_TIME is set equal to the value of the TTL field in the IP header. If the RREQ times out without a corresponding RREP, the originator broadcasts the RREQ again with the TTL incremented by TTL_INCREMENT. This continues until the TTL set in the RREQ reaches TTL_THRESHOLD, beyond which a TTL = NET_DIAMETER is used for each attempt. Each time, the timeout for receiving a RREP is RING_TRAVERSAL_TIME. When it is desired to have all retries traverse the entire ad hoc network, this can be achieved by configuring TTL_START and TTL_INCREMENT both to be the same value as NET_DIAMETER.
为防止RREQ在网络范围内不必要的传播，发起节点应使用扩展环搜索技术。在扩展环搜索中，发起节点最初在RREQ数据包IP报头中使用TTL=TTL_开始，并设置接收RREP到环遍历的超时时间（毫秒）。按照第10节中的说明计算环遍历时间。用于计算环遍历时间的TTL_值设置为等于IP报头中TTL字段的值。如果RREQ在没有相应RREP的情况下超时，则发起者再次广播RREQ，TTL增量为TTL_增量。这将一直持续到RREQ中设置的TTL达到TTL_阈值，超过该阈值，每次尝试都会使用TTL=净直径。每次，接收RREP的超时时间都是环遍历时间。当需要让所有重试遍历整个自组织网络时，可以通过将TTL_开始和TTL_增量配置为与净直径相同的值来实现。
The Hop Count stored in an invalid routing table entry indicates the last known hop count to that destination in the routing table. When a new route to the same destination is required at a later time (e.g., upon route loss), the TTL in the RREQ IP header is initially set to the Hop Count plus TTL_INCREMENT. Thereafter, following each timeout the TTL is incremented by TTL_INCREMENT until TTL = TTL_THRESHOLD is reached. Beyond this TTL = NET_DIAMETER is used. Once TTL = NET_DIAMETER, the timeout for waiting for the RREP is set to NET_TRAVERSAL_TIME, as specified in section 6.3.
存储在无效路由表项中的跃点计数表示路由表中该目标的最后已知跃点计数。当以后需要到同一目的地的新路由时（例如，在路由丢失时），RREQ IP报头中的TTL最初设置为跳数加上TTL_增量。此后，在每次超时之后，TTL将以TTL_增量递增，直到达到TTL=TTL_阈值。除此之外，使用TTL=净直径。一旦TTL=净直径，等待RREP的超时时间设置为净穿越时间，如第6.3节所述。
An expired routing table entry SHOULD NOT be expunged before (current_time + DELETE_PERIOD) (see section 6.11). Otherwise, the soft state corresponding to the route (e.g., last known hop count) will be lost. Furthermore, a longer routing table entry expunge time MAY be configured. Any routing table entry waiting for a RREP SHOULD NOT be expunged before (current_time + 2 * NET_TRAVERSAL_TIME).
过期的路由表条目不应在（当前时间+删除时间）之前删除（见第6.11节）。否则，与路由相对应的软状态（例如，最后已知的跳数）将丢失。此外，可以配置更长的路由表条目删除时间。任何等待RREP的路由表项在（当前\u时间+2*NET\u遍历\u时间）之前都不应被删除。
When a node receives a RREQ, it first creates or updates a route to the previous hop without a valid sequence number (see section 6.2) then checks to determine whether it has received a RREQ with the same Originator IP Address and RREQ ID within at least the last PATH_DISCOVERY_TIME. If such a RREQ has been received, the node silently discards the newly received RREQ. The rest of this subsection describes actions taken for RREQs that are not discarded.
当节点接收到RREQ时，它首先创建或更新到前一跳的路由，但没有有效的序列号（参见第6.2节），然后检查以确定是否在至少最后一次路径发现时间内收到了具有相同发端IP地址和RREQ ID的RREQ。如果已经接收到这样的RREQ，则节点将以静默方式丢弃新接收的RREQ。本小节的其余部分描述了为未放弃的RREQ采取的措施。
First, it first increments the hop count value in the RREQ by one, to account for the new hop through the intermediate node. Then the node searches for a reverse route to the Originator IP Address (see section 6.2), using longest-prefix matching. If need be, the route is created, or updated using the Originator Sequence Number from the RREQ in its routing table. This reverse route will be needed if the node receives a RREP back to the node that originated the RREQ (identified by the Originator IP Address). When the reverse route is created or updated, the following actions on the route are also carried out:
首先，它首先将RREQ中的跃点计数值增加1，以说明通过中间节点的新跃点。然后，节点使用最长前缀匹配搜索到发端IP地址的反向路由（参见第6.2节）。如果需要，将使用路由表中RREQ的发起者序列号创建或更新路由。如果节点接收到返回发起RREQ（由发起者IP地址标识）的节点的RREP，则需要此反向路由。创建或更新倒车路线时，还将对路线执行以下操作：
1. the Originator Sequence Number from the RREQ is compared to the corresponding destination sequence number in the route table entry and copied if greater than the existing value there
1. 将来自RREQ的发起者序列号与路由表条目中的相应目的地序列号进行比较，如果大于其中的现有值，则复制该序列号
2. the valid sequence number field is set to true;
2. 有效序列号字段设置为true；
3. the next hop in the routing table becomes the node from which the RREQ was received (it is obtained from the source IP address in the IP header and is often not equal to the Originator IP Address field in the RREQ message);
3. 路由表中的下一个跃点成为接收RREQ的节点（从IP报头中的源IP地址获得，通常不等于RREQ消息中的发起者IP地址字段）；
4. the hop count is copied from the Hop Count in the RREQ message;
4. 从RREQ消息中的跃点计数复制跃点计数；
Whenever a RREQ message is received, the Lifetime of the reverse route entry for the Originator IP address is set to be the maximum of (ExistingLifetime, MinimalLifetime), where
每当接收到RREQ消息时，发起者IP地址的反向路由条目的生存期设置为最大值（ExistingLifetime，MinimalLifetime），其中
MinimalLifetime = (current time + 2*NET_TRAVERSAL_TIME -
2*HopCount*NODE_TRAVERSAL_TIME).
MinimalLifetime = (current time + 2*NET_TRAVERSAL_TIME -
2*HopCount*NODE_TRAVERSAL_TIME).
The current node can use the reverse route to forward data packets in the same way as for any other route in the routing table.
当前节点可以使用反向路由转发数据包，转发方式与路由表中任何其他路由相同。
If a node does not generate a RREP (following the processing rules in section 6.6), and if the incoming IP header has TTL larger than 1, the node updates and broadcasts the RREQ to address 255.255.255.255 on each of its configured interfaces (see section 6.14). To update the RREQ, the TTL or hop limit field in the outgoing IP header is decreased by one, and the Hop Count field in the RREQ message is incremented by one, to account for the new hop through the intermediate node. Lastly, the Destination Sequence number for the requested destination is set to the maximum of the corresponding value received in the RREQ message, and the destination sequence value currently maintained by the node for the requested destination. However, the forwarding node MUST NOT modify its maintained value for the destination sequence number, even if the value received in the incoming RREQ is larger than the value currently maintained by the forwarding node.
如果节点未生成RREP（遵循第6.6节中的处理规则），并且如果传入IP头的TTL大于1，则节点将更新并广播RREQ，以在其每个配置接口上的地址255.255.255.255（参见第6.14节）。要更新RREQ，传出IP报头中的TTL或跃点限制字段减少1，RREQ消息中的跃点计数字段增加1，以说明通过中间节点的新跃点。最后，所请求目的地的目的地序列号被设置为在RREQ消息中接收到的对应值和节点当前为所请求目的地维护的目的地序列值中的最大值。但是，转发节点不得修改其目的地序列号的维护值，即使传入RREQ中接收的值大于转发节点当前维护的值。
Otherwise, if a node does generate a RREP, then the node discards the RREQ. Notice that, if intermediate nodes reply to every transmission of RREQs for a particular destination, it might turn out that the destination does not receive any of the discovery messages. In this situation, the destination does not learn of a route to the originating node from the RREQ messages. This could cause the destination to initiate a route discovery (for example, if the originator is attempting to establish a TCP session). In order that the destination learn of routes to the originating node, the originating node SHOULD set the "gratuitous RREP" ('G') flag in the RREQ if for any reason the destination is likely to need a route to the originating node. If, in response to a RREQ with the 'G' flag set, an intermediate node returns a RREP, it MUST also unicast a gratuitous RREP to the destination node (see section 6.6.3).
否则，如果节点确实生成RREP，则该节点将丢弃该RREQ。请注意，如果中间节点对特定目的地的每次RREQ传输进行回复，则可能会发现目的地没有接收任何发现消息。在这种情况下，目的地不会从RREQ消息获知到发起节点的路由。这可能会导致目标启动路由发现（例如，如果发端人试图建立TCP会话）。为了使目的地了解到到到发起节点的路由，如果出于任何原因，目的地可能需要到发起节点的路由，则发起节点应在RREQ中设置“免费RREP”（'G'）标志。如果中间节点响应设置了“G”标志的RREQ返回RREP，则它还必须单播免费RREP到目标节点（参见第6.6.3节）。
A node generates a RREP if either:
如果出现以下情况之一，节点将生成RREP：
(i) it is itself the destination, or
(i) 它本身就是目的地，或
(ii) it has an active route to the destination, the destination sequence number in the node's existing route table entry for the destination is valid and greater than or equal to the Destination Sequence Number of the RREQ (comparison using signed 32-bit arithmetic), and the "destination only" ('D') flag is NOT set.
（ii）其具有到目的地的活动路由，目的地节点现有路由表条目中的目的地序列号有效且大于或等于RREQ的目的地序列号（使用有符号32位算术进行比较），且未设置“仅目的地”（'D'）标志。
When generating a RREP message, a node copies the Destination IP Address and the Originator Sequence Number from the RREQ message into the corresponding fields in the RREP message. Processing is slightly different, depending on whether the node is itself the requested destination (see section 6.6.1), or instead if it is an intermediate node with an fresh enough route to the destination (see section 6.6.2).
生成RREP消息时，节点将目标IP地址和发起者序列号从RREQ消息复制到RREP消息中的相应字段中。处理略有不同，这取决于节点本身是否是请求的目的地（参见第6.6.1节），或者它是否是具有足够新鲜的到目的地的路由的中间节点（参见第6.6.2节）。
Once created, the RREP is unicast to the next hop toward the originator of the RREQ, as indicated by the route table entry for that originator. As the RREP is forwarded back towards the node which originated the RREQ message, the Hop Count field is incremented by one at each hop. Thus, when the RREP reaches the originator, the Hop Count represents the distance, in hops, of the destination from the originator.
一旦创建，RREP将单播到指向RREQ发起者的下一跳，如该发起者的路由表条目所示。当RREP被转发回发起RREQ消息的节点时，每个跃点上的跃点计数字段增加一。因此，当RREP到达发端时，跳数表示目的地与发端的距离（以跳数为单位）。
If the generating node is the destination itself, it MUST increment its own sequence number by one if the sequence number in the RREQ packet is equal to that incremented value. Otherwise, the destination does not change its sequence number before generating the RREP message. The destination node places its (perhaps newly incremented) sequence number into the Destination Sequence Number field of the RREP, and enters the value zero in the Hop Count field of the RREP.
如果生成节点是目的地本身，则如果RREQ数据包中的序列号等于增加的值，则必须将其自身的序列号增加1。否则，目的地在生成RREP消息之前不会更改其序列号。目标节点将其（可能是新增加的）序列号放入RREP的目标序列号字段，并在RREP的跃点计数字段中输入值零。
The destination node copies the value MY_ROUTE_TIMEOUT (see section 10) into the Lifetime field of the RREP. Each node MAY reconfigure its value for MY_ROUTE_TIMEOUT, within mild constraints (see section 10).
目标节点将值MY_ROUTE_TIMEOUT（参见第10节）复制到RREP的生存期字段中。每个节点都可以在轻度限制内重新配置其MY_ROUTE_超时值（参见第10节）。
If the node generating the RREP is not the destination node, but instead is an intermediate hop along the path from the originator to the destination, it copies its known sequence number for the destination into the Destination Sequence Number field in the RREP message.
如果生成RREP的节点不是目的地节点，而是从发端到目的地的路径上的中间跳，则它会将其目的地的已知序列号复制到RREP消息中的目的地序列号字段中。
The intermediate node updates the forward route entry by placing the last hop node (from which it received the RREQ, as indicated by the source IP address field in the IP header) into the precursor list for the forward route entry -- i.e., the entry for the Destination IP Address. The intermediate node also updates its route table entry for the node originating the RREQ by placing the next hop towards the destination in the precursor list for the reverse route entry -- i.e., the entry for the Originator IP Address field of the RREQ message data.
中间节点通过将最后一跳节点（从中接收RREQ，如IP报头中的源IP地址字段所示）放入前向路由条目的前体列表（即，目标IP地址的条目）来更新前向路由条目。中间节点还为发起RREQ的节点更新其路由表条目，方法是在反向路由条目（即RREQ消息数据的发起方IP地址字段的条目）的前体列表中向目的地放置下一跳。
The intermediate node places its distance in hops from the destination (indicated by the hop count in the routing table) Count field in the RREP. The Lifetime field of the RREP is calculated by subtracting the current time from the expiration time in its route table entry.
中间节点将其距离目的地（由路由表中的跃点计数指示）的跃点计数字段放置在RREP中。RREP的生存期字段是通过从其路由表条目中的过期时间中减去当前时间来计算的。
After a node receives a RREQ and responds with a RREP, it discards the RREQ. If the RREQ has the 'G' flag set, and the intermediate node returns a RREP to the originating node, it MUST also unicast a gratuitous RREP to the destination node. The gratuitous RREP that is to be sent to the desired destination contains the following values in the RREP message fields:
节点收到RREQ并使用RREP响应后，将丢弃该RREQ。如果RREQ设置了“G”标志，并且中间节点将RREP返回给发起节点，则它还必须单播免费RREP到目的节点。要发送到所需目的地的免费RREP在RREP消息字段中包含以下值：
Hop Count The Hop Count as indicated in the node's route table entry for the originator
跃点计数在节点的路由表条目中为发起者指示的跃点计数
Destination IP Address The IP address of the node that originated the RREQ
目标IP地址发起RREQ的节点的IP地址
Destination Sequence Number The Originator Sequence Number from the RREQ
目的地序列号RREQ中的发起者序列号
Originator IP Address The IP address of the Destination node in the RREQ
发起者IP地址RREQ中目标节点的IP地址
Lifetime The remaining lifetime of the route towards the originator of the RREQ, as known by the intermediate node.
生存期-路由到RREQ发端的剩余生存期，如中间节点所知。
The gratuitous RREP is then sent to the next hop along the path to the destination node, just as if the destination node had already issued a RREQ for the originating node and this RREP was produced in response to that (fictitious) RREQ. The RREP that is sent to the originator of the RREQ is the same whether or not the 'G' bit is set.
然后，免费的RREP沿着到目的地节点的路径发送到下一跳，就像目的地节点已经为发起节点发出了RREQ，并且该RREP是响应该（虚构的）RREQ而生成的一样。无论是否设置了“G”位，发送给RREQ发起者的RREP都是相同的。
When a node receives a RREP message, it searches (using longest-prefix matching) for a route to the previous hop. If needed, a route is created for the previous hop, but without a valid sequence number (see section 6.2). Next, the node then increments the hop count value in the RREP by one, to account for the new hop through the intermediate node. Call this incremented value the "New Hop Count". Then the forward route for this destination is created if it does not already exist. Otherwise, the node compares the Destination Sequence Number in the message with its own stored destination sequence number for the Destination IP Address in the RREP message. Upon comparison, the existing entry is updated only in the following circumstances:
当节点接收到RREP消息时，它会搜索（使用最长前缀匹配）到上一跳的路由。如果需要，为前一跳创建路由，但没有有效的序列号（参见第6.2节）。接下来，节点将RREP中的跃点计数值增加1，以说明通过中间节点的新跃点。将此递增值称为“新跃点计数”。然后，如果该目的地的转发路由不存在，则创建该目的地的转发路由。否则，节点会将消息中的目标序列号与RREP消息中自己存储的目标IP地址的目标序列号进行比较。经比较，现有条目仅在以下情况下更新：
(i) the sequence number in the routing table is marked as invalid in route table entry.
(i) 路由表条目中将路由表中的序列号标记为无效。
(ii) the Destination Sequence Number in the RREP is greater than the node's copy of the destination sequence number and the known value is valid, or
（ii）RREP中的目的地序列号大于节点的目的地序列号副本，且已知值有效，或
(iii) the sequence numbers are the same, but the route is is marked as inactive, or
（iii）序列号相同，但路线标记为非活动，或
(iv) the sequence numbers are the same, and the New Hop Count is smaller than the hop count in route table entry.
（iv）序列号相同，新的跳数小于路由表条目中的跳数。
If the route table entry to the destination is created or updated, then the following actions occur:
如果创建或更新到目的地的路由表条目，则会发生以下操作：
- the route is marked as active,
- 路线标记为活动，
- the destination sequence number is marked as valid,
- 目标序列号标记为有效，
- the next hop in the route entry is assigned to be the node from which the RREP is received, which is indicated by the source IP address field in the IP header,
- 路由条目中的下一跳被指定为接收RREP的节点，该节点由IP报头中的源IP地址字段指示，
- the hop count is set to the value of the New Hop Count,
- 跃点计数设置为新跃点计数的值，
- the expiry time is set to the current time plus the value of the Lifetime in the RREP message,
- 到期时间设置为当前时间加上RREP消息中的生存期值，
- and the destination sequence number is the Destination Sequence Number in the RREP message.
- 目的地序列号是RREP消息中的目的地序列号。
The current node can subsequently use this route to forward data packets to the destination.
当前节点随后可以使用该路由将数据包转发到目的地。
If the current node is not the node indicated by the Originator IP Address in the RREP message AND a forward route has been created or updated as described above, the node consults its route table entry for the originating node to determine the next hop for the RREP packet, and then forwards the RREP towards the originator using the information in that route table entry. If a node forwards a RREP over a link that is likely to have errors or be unidirectional, the node SHOULD set the 'A' flag to require that the recipient of the RREP acknowledge receipt of the RREP by sending a RREP-ACK message back (see section 6.8).
如果当前节点不是由RREP消息中的发起者IP地址指示的节点，并且如上所述已创建或更新转发路由，则该节点参考其发起节点的路由表条目以确定RREP分组的下一跳，然后使用路由表条目中的信息将RREP转发给发起者。如果节点通过可能存在错误或单向的链路转发RREP，则节点应设置“a”标志，要求RREP的接收方通过发送RREP-ACK消息确认收到RREP（见第6.8节）。
When any node transmits a RREP, the precursor list for the corresponding destination node is updated by adding to it the next hop node to which the RREP is forwarded. Also, at each node the (reverse) route used to forward a RREP has its lifetime changed to be the maximum of (existing-lifetime, (current time + ACTIVE_ROUTE_TIMEOUT). Finally, the precursor list for the next hop towards the destination is updated to contain the next hop towards the source.
当任何节点发送RREP时，通过将RREP转发到的下一跳节点添加到对应目的地节点的前体列表中来更新该前体列表。此外，在每个节点上，用于转发RREP的（反向）路由的生存期更改为（现有生存期）（当前时间+活动路由超时）的最大值。最后，更新朝向目的地的下一跳的前体列表，以包含朝向源的下一跳。
It is possible that a RREP transmission may fail, especially if the RREQ transmission triggering the RREP occurs over a unidirectional link. If no other RREP generated from the same route discovery attempt reaches the node which originated the RREQ message, the originator will reattempt route discovery after a timeout (see section 6.3). However, the same scenario might well be repeated without any improvement, and no route would be discovered even after repeated retries. Unless corrective action is taken, this can happen even when bidirectional routes between originator and destination do exist. Link layers using broadcast transmissions for the RREQ will not be able to detect the presence of such unidirectional links. In AODV, any node acts on only the first RREQ with the same RREQ ID and ignores any subsequent RREQs. Suppose, for example, that the first
RREP传输可能会失败，特别是当触发RREP的RREQ传输发生在单向链路上时。如果同一路由发现尝试生成的其他RREP没有到达发起RREQ消息的节点，则发起人将在超时后重新尝试路由发现（参见第6.3节）。然而，相同的场景很可能会重复而没有任何改进，并且即使在重复重试之后也不会发现任何路由。除非采取纠正措施，否则即使发起者和目的地之间确实存在双向路由，也可能发生这种情况。使用用于RREQ的广播传输的链路层将无法检测此类单向链路的存在。在AODV中，任何节点仅作用于具有相同RREQ ID的第一个RREQ，并忽略任何后续RREQ。例如，假设第一个
RREQ arrives along a path that has one or more unidirectional link(s). A subsequent RREQ may arrive via a bidirectional path (assuming such paths exist), but it will be ignored.
RREQ沿着具有一个或多个单向链路的路径到达。后续RREQ可能通过双向路径到达（假设存在此类路径），但将被忽略。
To prevent this problem, when a node detects that its transmission of a RREP message has failed, it remembers the next-hop of the failed RREP in a "blacklist" set. Such failures can be detected via the absence of a link-layer or network-layer acknowledgment (e.g., RREP-ACK). A node ignores all RREQs received from any node in its blacklist set. Nodes are removed from the blacklist set after a BLACKLIST_TIMEOUT period (see section 10). This period should be set to the upper bound of the time it takes to perform the allowed number of route request retry attempts as described in section 6.3.
为了防止此问题，当节点检测到其RREP消息的传输失败时，它会记住“黑名单”集中失败的RREP的下一跳。此类故障可通过缺少链路层或网络层确认（例如，RREP-ACK）来检测。节点忽略从其黑名单集中的任何节点接收的所有RREQ。节点在黑名单超时后从黑名单集中移除（参见第10节）。该时间段应设置为执行第6.3节所述的允许的路由请求重试次数所需的时间上限。
Note that the RREP-ACK packet does not contain any information about which RREP it is acknowledging. The time at which the RREP-ACK is received will likely come just after the time when the RREP was sent with the 'A' bit. This information is expected to be sufficient to provide assurance to the sender of the RREP that the link is currently bidirectional, without any real dependence on the particular RREP message being acknowledged. However, that assurance typically cannot be expected to remain in force permanently.
请注意，RREP-ACK数据包不包含关于其正在确认哪个RREP的任何信息。接收RREP-ACK的时间可能正好在发送带有“A”位的RREP的时间之后。预期该信息足以向RREP的发送者提供链路当前是双向的保证，而不需要对正在确认的特定RREP消息有任何实际依赖性。然而，这种保证通常不能永久有效。
A node MAY offer connectivity information by broadcasting local Hello messages. A node SHOULD only use hello messages if it is part of an active route. Every HELLO_INTERVAL milliseconds, the node checks whether it has sent a broadcast (e.g., a RREQ or an appropriate layer 2 message) within the last HELLO_INTERVAL. If it has not, it MAY broadcast a RREP with TTL = 1, called a Hello message, with the RREP message fields set as follows:
节点可以通过广播本地Hello消息来提供连接信息。只有当节点是活动路由的一部分时，它才应该使用hello消息。每个HELLO_间隔毫秒，节点检查是否在最后一个HELLO_间隔内发送了广播（例如，RREQ或适当的第2层消息）。如果没有，它可以广播TTL=1的RREP，称为Hello消息，RREP消息字段设置如下：
Destination IP Address The node's IP address.
目标IP地址节点的IP地址。
Destination Sequence Number The node's latest sequence number.
目标序列号节点的最新序列号。
Hop Count 0
跃点计数0
Lifetime ALLOWED_HELLO_LOSS * HELLO_INTERVAL
允许使用寿命\u HELLO\u损失*HELLO\u间隔
A node MAY determine connectivity by listening for packets from its set of neighbors. If, within the past DELETE_PERIOD, it has received a Hello message from a neighbor, and then for that neighbor does not receive any packets (Hello messages or otherwise) for more than
节点可以通过侦听来自其邻居集的数据包来确定连接性。如果在过去的DELETE_期间内，它从邻居处接收到Hello消息，并且对于该邻居，在超过个月的时间内没有接收到任何数据包（Hello消息或其他）
ALLOWED_HELLO_LOSS * HELLO_INTERVAL milliseconds, the node SHOULD assume that the link to this neighbor is currently lost. When this happens, the node SHOULD proceed as in Section 6.11.
允许的\u HELLO\u丢失*HELLO\u间隔毫秒，节点应假定到该邻居的链接当前丢失。发生这种情况时，节点应按照第6.11节的要求进行操作。
Whenever a node receives a Hello message from a neighbor, the node SHOULD make sure that it has an active route to the neighbor, and create one if necessary. If a route already exists, then the Lifetime for the route should be increased, if necessary, to be at least ALLOWED_HELLO_LOSS * HELLO_INTERVAL. The route to the neighbor, if it exists, MUST subsequently contain the latest Destination Sequence Number from the Hello message. The current node can now begin using this route to forward data packets. Routes that are created by hello messages and not used by any other active routes will have empty precursor lists and would not trigger a RERR message if the neighbor moves away and a neighbor timeout occurs.
每当节点从邻居接收到Hello消息时，该节点应确保其具有到邻居的活动路由，并在必要时创建一条路由。如果路由已经存在，则应增加路由的生存期（如有必要），以至少允许\u HELLO\u LOSS*HELLO\u INTERVAL。到邻居的路由（如果存在）随后必须包含来自Hello消息的最新目的地序列号。当前节点现在可以开始使用此路由转发数据包。由hello消息创建且未被任何其他活动路由使用的路由将具有空的前体列表，并且如果邻居离开并且发生邻居超时，则不会触发RERR消息。
Each forwarding node SHOULD keep track of its continued connectivity to its active next hops (i.e., which next hops or precursors have forwarded packets to or from the forwarding node during the last ACTIVE_ROUTE_TIMEOUT), as well as neighbors that have transmitted Hello messages during the last (ALLOWED_HELLO_LOSS * HELLO_INTERVAL). A node can maintain accurate information about its continued connectivity to these active next hops, using one or more of the available link or network layer mechanisms, as described below.
每个转发节点应跟踪其到其活动下一个跃点的持续连接（即，哪些下一个跃点或前体在上一个活动路由超时期间向转发节点转发或从转发节点转发数据包），以及在上一个（允许的Hello丢失*Hello间隔）期间发送Hello消息的邻居。节点可以使用一个或多个可用的链路或网络层机制来维护关于其与这些活动下一跳的持续连接的准确信息，如下所述。
- Any suitable link layer notification, such as those provided by IEEE 802.11, can be used to determine connectivity, each time a packet is transmitted to an active next hop. For example, absence of a link layer ACK or failure to get a CTS after sending RTS, even after the maximum number of retransmission attempts, indicates loss of the link to this active next hop.
- 任何合适的链路层通知，如IEEE 802.11提供的通知，可用于在每次将数据包传输到活动下一跳时确定连接性。例如，没有链路层ACK或在发送RTS之后，即使在最大的重传尝试次数之后，也无法获得CTS，这表示到该活动下一跳的链路丢失。
- If layer-2 notification is not available, passive acknowledgment SHOULD be used when the next hop is expected to forward the packet, by listening to the channel for a transmission attempt made by the next hop. If transmission is not detected within NEXT_HOP_WAIT milliseconds or the next hop is the destination (and thus is not supposed to forward the packet) one of the following methods SHOULD be used to determine connectivity:
- 如果第2层通知不可用，则当期望下一跳转发数据包时，应通过侦听下一跳尝试传输的信道来使用被动确认。如果在下一跳等待毫秒内未检测到传输，或者下一跳是目的地（因此不应转发数据包），则应使用以下方法之一确定连接：
* Receiving any packet (including a Hello message) from the next hop.
* 从下一跳接收任何数据包（包括Hello消息）。
* A RREQ unicast to the next hop, asking for a route to the next hop.
* 到下一跳的RREQ单播，请求到下一跳的路由。
* An ICMP Echo Request message unicast to the next hop.
* ICMP回显请求消息单播到下一跳。
If a link to the next hop cannot be detected by any of these methods, the forwarding node SHOULD assume that the link is lost, and take corrective action by following the methods specified in Section 6.11.
如果这些方法中的任何一种都无法检测到到到下一跳的链路，则转发节点应假定该链路丢失，并按照第6.11节中规定的方法采取纠正措施。
Generally, route error and link breakage processing requires the following steps:
通常，路由错误和链路中断处理需要以下步骤：
- Invalidating existing routes
- 使现有路线无效
- Listing affected destinations
- 列出受影响的目的地
- Determining which, if any, neighbors may be affected
- 确定哪些邻居（如有）可能受到影响
- Delivering an appropriate RERR to such neighbors
- 向这些邻居提供适当的RERR
A Route Error (RERR) message MAY be either broadcast (if there are many precursors), unicast (if there is only 1 precursor), or iteratively unicast to all precursors (if broadcast is inappropriate). Even when the RERR message is iteratively unicast to several precursors, it is considered to be a single control message for the purposes of the description in the text that follows. With that understanding, a node SHOULD NOT generate more than RERR_RATELIMIT RERR messages per second.
路由错误（RERR）消息可以是广播（如果有许多前体）、单播（如果只有一个前体），或者迭代地单播到所有前体（如果广播不合适）。即使当RERR消息以迭代方式单播到多个前体时，出于下文中描述的目的，也将其视为单个控制消息。根据这一理解，节点每秒生成的RERR_Rate Limit RERR消息不应超过。
A node initiates processing for a RERR message in three situations:
节点在三种情况下启动对RERR消息的处理：
(i) if it detects a link break for the next hop of an active route in its routing table while transmitting data (and route repair, if attempted, was unsuccessful), or
(i) 如果在传输数据时，它在其路由表中检测到活动路由的下一跳的链路中断（如果尝试，则路由修复失败），或
(ii) if it gets a data packet destined to a node for which it does not have an active route and is not repairing (if using local repair), or
（ii）如果它获得一个目的地为一个节点的数据包，而该节点没有活动路由，并且没有进行修复（如果使用本地修复），或者
(iii) if it receives a RERR from a neighbor for one or more active routes.
（iii）如果它从一个或多个活动路由的邻居处接收到RERR。
For case (i), the node first makes a list of unreachable destinations consisting of the unreachable neighbor and any additional destinations (or subnets, see section 7) in the local routing table that use the unreachable neighbor as the next hop. In this case, if a subnet route is found to be newly unreachable, an IP destination address for the subnet is constructed by appending zeroes to the
对于情况（i），节点首先列出不可到达的目的地，包括不可到达邻居和本地路由表中使用不可到达邻居作为下一跳的任何附加目的地（或子网，参见第7节）。在这种情况下，如果发现新的子网路由不可访问，则子网的IP目标地址将通过在
subnet prefix as shown in the route table entry. This is unambiguous, since the precursor is known to have route table information with a compatible prefix length for that subnet.
如路由表条目所示的子网前缀。这是明确的，因为已知前驱体具有与该子网的前缀长度兼容的路由表信息。
For case (ii), there is only one unreachable destination, which is the destination of the data packet that cannot be delivered. For case (iii), the list should consist of those destinations in the RERR for which there exists a corresponding entry in the local routing table that has the transmitter of the received RERR as the next hop.
对于情况（ii），只有一个不可到达的目的地，即无法传送的数据包的目的地。对于情况（iii），列表应包括RERR中的目的地，对于这些目的地，本地路由表中存在相应的条目，该条目将接收到的RERR的发射机作为下一跳。
Some of the unreachable destinations in the list could be used by neighboring nodes, and it may therefore be necessary to send a (new) RERR. The RERR should contain those destinations that are part of the created list of unreachable destinations and have a non-empty precursor list.
列表中一些无法到达的目的地可能会被相邻节点使用，因此可能需要发送（新）RERR。RERR应包含那些属于已创建的不可访问目的地列表的一部分且具有非空的前体列表的目的地。
The neighboring node(s) that should receive the RERR are all those that belong to a precursor list of at least one of the unreachable destination(s) in the newly created RERR. In case there is only one unique neighbor that needs to receive the RERR, the RERR SHOULD be unicast toward that neighbor. Otherwise the RERR is typically sent to the local broadcast address (Destination IP == 255.255.255.255, TTL == 1) with the unreachable destinations, and their corresponding destination sequence numbers, included in the packet. The DestCount field of the RERR packet indicates the number of unreachable destinations included in the packet.
应该接收RERR的相邻节点是属于新创建的RERR中至少一个不可到达目的地的前体列表的所有节点。如果只有一个唯一的邻居需要接收RERR，则RERR应单播到该邻居。否则，RERR通常被发送到本地广播地址（目的地IP==255.255.255.255，TTL==1），其中不可到达的目的地及其对应的目的地序列号包含在数据包中。RERR数据包的DestCount字段指示数据包中包含的不可到达目的地的数量。
Just before transmitting the RERR, certain updates are made on the routing table that may affect the destination sequence numbers for the unreachable destinations. For each one of these destinations, the corresponding routing table entry is updated as follows:
就在发送RERR之前，对路由表进行了某些更新，这些更新可能会影响不可到达目的地的目的地序列号。对于这些目的地中的每一个，相应的路由表条目更新如下：
1. The destination sequence number of this routing entry, if it exists and is valid, is incremented for cases (i) and (ii) above, and copied from the incoming RERR in case (iii) above.
1. 对于上述（i）和（ii）种情况，此路由条目的目的地序列号（如果存在且有效）将递增，对于上述（iii）种情况，将从传入的RERR复制。
2. The entry is invalidated by marking the route entry as invalid
2. 通过将路线条目标记为无效，条目无效
3. The Lifetime field is updated to current time plus DELETE_PERIOD. Before this time, the entry SHOULD NOT be deleted.
3. 寿命字段将更新为当前时间加上删除周期。在此之前，不应删除该条目。
Note that the Lifetime field in the routing table plays dual role -- for an active route it is the expiry time, and for an invalid route it is the deletion time. If a data packet is received for an invalid route, the Lifetime field is updated to current time plus DELETE_PERIOD. The determination of DELETE_PERIOD is discussed in Section 10.
请注意，路由表中的生存期字段起着双重作用——对于活动路由，它是到期时间，对于无效路由，它是删除时间。如果接收到无效路由的数据包，则生存期字段将更新为当前时间加上删除周期。第10节讨论了删除周期的确定。
When a link break in an active route occurs, the node upstream of that break MAY choose to repair the link locally if the destination was no farther than MAX_REPAIR_TTL hops away. To repair the link break, the node increments the sequence number for the destination and then broadcasts a RREQ for that destination. The TTL of the RREQ should initially be set to the following value:
当活动路由中发生链路中断时，如果目的地不超过MAX_repair_TTL跳数，则该中断上游的节点可以选择本地修复链路。为了修复链路中断，节点增加目的地的序列号，然后广播该目的地的RREQ。RREQ的TTL最初应设置为以下值：
max(MIN_REPAIR_TTL, 0.5 * #hops) + LOCAL_ADD_TTL,
最大值（最小修复TTL，0.5*跳数）+本地添加TTL，
where #hops is the number of hops to the sender (originator) of the currently undeliverable packet. Thus, local repair attempts will often be invisible to the originating node, and will always have TTL >= MIN_REPAIR_TTL + LOCAL_ADD_TTL. The node initiating the repair then waits the discovery period to receive RREPs in response to the RREQ. During local repair data packets SHOULD be buffered. If, at the end of the discovery period, the repairing node has not received a RREP (or other control message creating or updating the route) for that destination, it proceeds as described in Section 6.11 by transmitting a RERR message for that destination.
其中#hops是指向当前无法传递的数据包的发送方（发起方）的跃点数。因此，本地修复尝试通常对原始节点不可见，并且始终具有TTL>=MIN\u repair\u TTL+local\u ADD\u TTL。启动修复的节点然后等待发现周期以接收响应RREQ的RREP。在本地修复期间，应缓冲数据包。如果在发现期结束时，修复节点没有收到该目的地的RREP（或创建或更新路由的其他控制消息），则按照第6.11节所述，继续发送该目的地的RERR消息。
On the other hand, if the node receives one or more RREPs (or other control message creating or updating the route to the desired destination) during the discovery period, it first compares the hop count of the new route with the value in the hop count field of the invalid route table entry for that destination. If the hop count of the newly determined route to the destination is greater than the hop count of the previously known route the node SHOULD issue a RERR message for the destination, with the 'N' bit set. Then it proceeds as described in Section 6.7, updating its route table entry for that destination.
另一方面，如果节点在发现期间接收到一个或多个RREP（或创建或更新到所需目的地的路由的其他控制消息），则它首先将新路由的跃点计数与该目的地的无效路由表条目的跃点计数字段中的值进行比较。如果到目的地的新确定路由的跃点计数大于先前已知路由的跃点计数，则节点应为目的地发出RERR消息，并设置“N”位。然后，它按照第6.7节所述进行，更新该目的地的路由表条目。
A node that receives a RERR message with the 'N' flag set MUST NOT delete the route to that destination. The only action taken should be the retransmission of the message, if the RERR arrived from the next hop along that route, and if there are one or more precursor nodes for that route to the destination. When the originating node receives a RERR message with the 'N' flag set, if this message came from its next hop along its route to the destination then the originating node MAY choose to reinitiate route discovery, as described in Section 6.3.
接收设置了“N”标志的RERR消息的节点不得删除到该目的地的路由。如果RERR从该路由的下一跳到达，并且该路由有一个或多个前导节点到目的地，则所采取的唯一操作应该是消息的重新传输。当发起节点接收到设置了“N”标志的RERR消息时，如果该消息来自沿其路由到目的地的下一跳，则发起节点可选择重新初始化路由发现，如第6.3节所述。
Local repair of link breaks in routes sometimes results in increased path lengths to those destinations. Repairing the link locally is likely to increase the number of data packets that are able to be delivered to the destinations, since data packets will not be dropped as the RERR travels to the originating node. Sending a RERR to the
路由中链路中断的局部修复有时会导致到这些目的地的路径长度增加。本地修复链路很可能会增加能够传送到目的地的数据包的数量，因为数据包不会随着RERR移动到发起节点而丢弃。向服务器发送一个RERR
originating node after locally repairing the link break may allow the originator to find a fresh route to the destination that is better, based on current node positions. However, it does not require the originating node to rebuild the route, as the originator may be done, or nearly done, with the data session.
本地修复链路中断后的发起节点可允许发起方基于当前节点位置找到到目的地的新路由，该路由更好。但是，它不需要原始节点重建路由，因为原始节点可能已经完成或即将完成数据会话。
When a link breaks along an active route, there are often multiple
destinations that become unreachable. The node that is upstream of
the lost link tries an immediate local repair for only the one
destination towards which the data packet was traveling. Other
routes using the same link MUST be marked as invalid, but the node
handling the local repair MAY flag each such newly lost route as
locally repairable; this local repair flag in the route table MUST be
reset when the route times out (e.g., after the route has been not
been active for ACTIVE_ROUTE_TIMEOUT). Before the timeout occurs,
these other routes will be repaired as needed when packets arrive for
the other destinations. Hence, these routes are repaired as needed;
if a data packet does not arrive for the route, then that route will
not be repaired. Alternatively, depending upon local congestion, the
node MAY begin the process of establishing local repairs for the
other routes, without waiting for new packets to arrive. By
proactively repairing the routes that have broken due to the loss of
the link, incoming data packets for those routes will not be subject
to the delay of repairing the route and can be immediately forwarded.
However, repairing the route before a data packet is received for it
runs the risk of repairing routes that are no longer in use.
Therefore, depending upon the local traffic in the network and
whether congestion is being experienced, the node MAY elect to
proactively repair the routes before a data packet is received;
otherwise, it can wait until a data is received, and then commence
the repair of the route.
When a link breaks along an active route, there are often multiple
destinations that become unreachable. The node that is upstream of
the lost link tries an immediate local repair for only the one
destination towards which the data packet was traveling. Other
routes using the same link MUST be marked as invalid, but the node
handling the local repair MAY flag each such newly lost route as
locally repairable; this local repair flag in the route table MUST be
reset when the route times out (e.g., after the route has been not
been active for ACTIVE_ROUTE_TIMEOUT). Before the timeout occurs,
these other routes will be repaired as needed when packets arrive for
the other destinations. Hence, these routes are repaired as needed;
if a data packet does not arrive for the route, then that route will
not be repaired. Alternatively, depending upon local congestion, the
node MAY begin the process of establishing local repairs for the
other routes, without waiting for new packets to arrive. By
proactively repairing the routes that have broken due to the loss of
the link, incoming data packets for those routes will not be subject
to the delay of repairing the route and can be immediately forwarded.
However, repairing the route before a data packet is received for it
runs the risk of repairing routes that are no longer in use.
Therefore, depending upon the local traffic in the network and
whether congestion is being experienced, the node MAY elect to
proactively repair the routes before a data packet is received;
otherwise, it can wait until a data is received, and then commence
the repair of the route.
A node participating in the ad hoc network must take certain actions after reboot as it might lose all sequence number records for all destinations, including its own sequence number. However, there may be neighboring nodes that are using this node as an active next hop. This can potentially create routing loops. To prevent this possibility, each node on reboot waits for DELETE_PERIOD before transmitting any route discovery messages. If the node receives a RREQ, RREP, or RERR control packet, it SHOULD create route entries as appropriate given the sequence number information in the control packets, but MUST not forward any control packets. If the node receives a data packet for some other destination, it SHOULD broadcast a RERR as described in subsection 6.11 and MUST reset the waiting timer to expire after current time plus DELETE_PERIOD.
参与自组织网络的节点在重新启动后必须采取某些操作，因为它可能会丢失所有目的地的所有序列号记录，包括其自身的序列号。但是，可能存在将此节点用作活动下一跳的相邻节点。这可能会创建路由循环。为了防止这种可能性，重新启动时的每个节点都会在传输任何路由发现消息之前等待删除时间段。如果节点接收到RREQ、RREP或RERR控制数据包，则其应根据控制数据包中的序列号信息创建适当的路由条目，但不得转发任何控制数据包。如果节点接收到某个其他目的地的数据包，则应按照第6.11小节中的说明广播RERR，并且必须重置等待计时器，使其在当前时间加上删除周期后过期。
It can be shown [4] that by the time the rebooted node comes out of the waiting phase and becomes an active router again, none of its neighbors will be using it as an active next hop any more. Its own sequence number gets updated once it receives a RREQ from any other node, as the RREQ always carries the maximum destination sequence number seen en route. If no such RREQ arrives, the node MUST initialize its own sequence number to zero.
可以显示[4]当重新引导的节点从等待阶段出来并再次成为活动路由器时，其邻居都不会再将其用作活动的下一跳。一旦从任何其他节点接收到RREQ，它自己的序列号就会更新，因为RREQ总是携带在路由中看到的最大目的地序列号。如果没有这样的RREQ到达，节点必须将自己的序列号初始化为零。
Because AODV should operate smoothly over wired, as well as wireless, networks, and because it is likely that AODV will also be used with multiple wireless devices, the particular interface over which packets arrive must be known to AODV whenever a packet is received. This includes the reception of RREQ, RREP, and RERR messages. Whenever a packet is received from a new neighbor, the interface on which that packet was received is recorded into the route table entry for that neighbor, along with all the other appropriate routing information. Similarly, whenever a route to a new destination is learned, the interface through which the destination can be reached is also recorded into the destination's route table entry.
由于AODV应在有线和无线网络上平稳运行，并且由于AODV很可能也将用于多个无线设备，因此每当接收到数据包时，AODV必须知道数据包到达的特定接口。这包括接收RREQ、RREP和RERR消息。每当从新邻居接收到数据包时，接收该数据包的接口将与所有其他适当的路由信息一起记录到该邻居的路由表条目中。类似地，每当读入到新目的地的路由时，可以到达目的地的接口也被记录到目的地的路由表条目中。
When multiple interfaces are available, a node retransmitting a RREQ message rebroadcasts that message on all interfaces that have been configured for operation in the ad-hoc network, except those on which it is known that all of the nodes neighbors have already received the RREQ For instance, for some broadcast media (e.g., Ethernet) it may be presumed that all nodes on the same link receive a broadcast message at the same time. When a node needs to transmit a RERR, it SHOULD only transmit it on those interfaces that have neighboring precursor nodes for that route.
当多个接口可用时，重新传输RREQ消息的节点在已配置为在自组织网络中操作的所有接口上重新广播该消息，但已知所有节点邻居已经接收到RREQ的接口除外，例如，对于某些广播媒体（例如，以太网）可以假定同一链路上的所有节点同时接收广播消息。当一个节点需要传输RERR时，它应该只在那些具有该路由的相邻前体节点的接口上传输RERR。
AODV has been designed for use by mobile nodes with IP addresses that are not necessarily related to each other, to create an ad hoc network. However, in some cases a collection of mobile nodes MAY operate in a fixed relationship to each other and share a common subnet prefix, moving together within an area where an ad hoc network has formed. Call such a collection of nodes a "subnet". In this case, it is possible for a single node within the subnet to advertise reachability for all other nodes on the subnet, by responding with a RREP message to any RREQ message requesting a route to any node with the subnet routing prefix. Call the single node the "subnet router". In order for a subnet router to operate the AODV protocol for the whole subnet, it has to maintain a destination sequence number for the entire subnet. In any such RREP message sent by the subnet router, the Prefix Size field of the RREP message MUST be set to the
AODV设计用于IP地址不一定相互关联的移动节点，以创建自组织网络。然而，在某些情况下，移动节点的集合可以彼此以固定关系操作，并共享公共子网前缀，在已形成自组织网络的区域内一起移动。将这样的节点集合称为“子网”。在这种情况下，子网内的单个节点可以通过使用RREP消息响应任何RREQ消息，请求到具有子网路由前缀的任何节点的路由，从而通告子网上所有其他节点的可达性。将单个节点称为“子网路由器”。为了使子网路由器对整个子网运行AODV协议，它必须为整个子网维护一个目标序列号。在子网路由器发送的任何此类RREP消息中，RREP消息的前缀大小字段必须设置为
length of the subnet prefix. Other nodes sharing the subnet prefix SHOULD NOT issue RREP messages, and SHOULD forward RREQ messages to the subnet router.
子网前缀的长度。共享子网前缀的其他节点不应发出RREP消息，而应将RREQ消息转发到子网路由器。
The processing for RREPs that give routes to subnets (i.e., have nonzero prefix length) is the same as processing for host-specific RREP messages. Every node that receives the RREP with prefix size information SHOULD create or update the route table entry for the subnet, including the sequence number supplied by the subnet router, and including the appropriate precursor information. Then, in the future the node can use the information to avoid sending future RREQs for other nodes on the same subnet.
为子网提供路由的RREP（即前缀长度非零）的处理与主机特定RREP消息的处理相同。接收带有前缀大小信息的RREP的每个节点都应创建或更新子网的路由表条目，包括子网路由器提供的序列号，并包括适当的前体信息。然后，将来节点可以使用该信息来避免为同一子网上的其他节点发送将来的RREQ。
When a node uses a subnet route it may be that a packet is routed to an IP address on the subnet that is not assigned to any existing node in the ad hoc network. When that happens, the subnet router MUST return ICMP Host Unreachable message to the sending node. Upstream nodes receiving such an ICMP message SHOULD record the information that the particular IP address is unreachable, but MUST NOT invalidate the route entry for any matching subnet prefix.
当节点使用子网路由时，数据包可能被路由到子网上的IP地址，而该IP地址未分配给自组织网络中的任何现有节点。发生这种情况时，子网路由器必须将ICMP主机不可访问消息返回给发送节点。接收此类ICMP消息的上游节点应记录特定IP地址不可访问的信息，但不得使任何匹配子网前缀的路由条目无效。
If several nodes in the subnet advertise reachability to the subnet defined by the subnet prefix, the node with the lowest IP address is elected to be the subnet router, and all other nodes MUST stop advertising reachability.
如果子网中的多个节点向子网前缀定义的子网播发可达性，则选择IP地址最低的节点作为子网路由器，并且所有其他节点必须停止播发可达性。
The behavior of default routes (i.e., routes with routing prefix length 0) is not defined in this specification. Selection of routes sharing prefix bits should be according to longest match first.
本规范中未定义默认路由（即路由前缀长度为0的路由）的行为。共享前缀位的路由选择应首先根据最长匹配进行。
In some configurations, an ad hoc network may be able to provide connectivity between external routing domains that do not use AODV. If the points of contact to the other networks can act as subnet routers (see Section 7) for any relevant networks within the external routing domains, then the ad hoc network can maintain connectivity to the external routing domains. Indeed, the external routing networks can use the ad hoc network defined by AODV as a transit network.
在某些配置中，自组织网络可能能够在不使用AODV的外部路由域之间提供连接。如果与其他网络的接触点可以充当外部路由域内任何相关网络的子网路由器（参见第7节），则自组织网络可以保持与外部路由域的连接。实际上，外部路由网络可以使用AODV定义的自组织网络作为传输网络。
In order to provide this feature, a point of contact to an external network (call it an Infrastructure Router) has to act as the subnet router for every subnet of interest within the external network for which the Infrastructure Router can provide reachability. This includes the need for maintaining a destination sequence number for that external subnet.
为了提供此功能，外部网络的接触点（称之为基础设施路由器）必须充当外部网络中每个感兴趣的子网的子网路由器，基础设施路由器可以为这些子网提供可达性。这包括需要维护该外部子网的目标序列号。
If multiple Infrastructure Routers offer reachability to the same external subnet, those Infrastructure Routers have to cooperate (by means outside the scope of this specification) to provide consistent AODV semantics for ad hoc access to those subnets.
如果多个基础设施路由器提供对同一外部子网的可达性，则这些基础设施路由器必须合作（通过本规范范围之外的方式）为对这些子网的临时访问提供一致的AODV语义。
In this section, the format of extensions to the RREQ and RREP messages is specified. All such extensions appear after the message data, and have the following format:
在本节中，指定了RREQ和RREP消息的扩展格式。所有此类扩展都显示在消息数据之后，并具有以下格式：
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 | type-specific data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | type-specific data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
哪里：
Type 1-255
类型1-255
Length The length of the type-specific data, not including the Type and Length fields of the extension in bytes.
长度特定于类型的数据的长度，不包括扩展的类型和长度字段（以字节为单位）。
Extensions with types between 128 and 255 may NOT be skipped. The rules for extensions will be spelled out more fully, and conform to the rules for handling IPv6 options.
不能跳过类型介于128和255之间的扩展。扩展的规则将更加详细，并符合处理IPv6选项的规则。
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 | Hello Interval ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Hello Interval, continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Hello Interval ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Hello Interval, continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
类型1
Length 4
长度4
Hello Interval The number of milliseconds between successive transmissions of a Hello message.
Hello Interval连续传输Hello消息之间的毫秒数。
The Hello Interval extension MAY be appended to a RREP message with TTL == 1, to be used by a neighboring receiver in determine how long to wait for subsequent such RREP messages (i.e., Hello messages; see section 6.9).
Hello间隔扩展可附加到TTL==1的RREP消息，以供相邻接收器用于确定等待后续此类RREP消息的时间（即，Hello消息；参见第6.9节）。
This section gives default values for some important parameters associated with AODV protocol operations. A particular mobile node may wish to change certain of the parameters, in particular the NET_DIAMETER, MY_ROUTE_TIMEOUT, ALLOWED_HELLO_LOSS, RREQ_RETRIES, and possibly the HELLO_INTERVAL. In the latter case, the node should advertise the HELLO_INTERVAL in its Hello messages, by appending a Hello Interval Extension to the RREP message. Choice of these parameters may affect the performance of the protocol. Changing NODE_TRAVERSAL_TIME also changes the node's estimate of the NET_TRAVERSAL_TIME, and so can only be done with suitable knowledge about the behavior of other nodes in the ad hoc network. The configured value for MY_ROUTE_TIMEOUT MUST be at least 2 * PATH_DISCOVERY_TIME.
本节给出了与AODV协议操作相关的一些重要参数的默认值。特定移动节点可能希望改变某些参数，尤其是净直径、我的路由超时、允许的HELLO丢失、RREQ重试以及可能的HELLO间隔。在后一种情况下，节点应在其HELLO消息中通告HELLO_间隔，方法是在RREP消息中附加HELLO间隔扩展。选择这些参数可能会影响协议的性能。更改节点遍历时间也会更改节点对网络遍历时间的估计，因此只能在适当了解adhoc网络中其他节点行为的情况下进行。MY_ROUTE_TIMEOUT的配置值必须至少为2*PATH_DISCOVERY_TIME。
Parameter Name Value
---------------------- -----
ACTIVE_ROUTE_TIMEOUT 3,000 Milliseconds
ALLOWED_HELLO_LOSS 2
BLACKLIST_TIMEOUT RREQ_RETRIES * NET_TRAVERSAL_TIME
DELETE_PERIOD see note below
HELLO_INTERVAL 1,000 Milliseconds
LOCAL_ADD_TTL 2
MAX_REPAIR_TTL 0.3 * NET_DIAMETER
MIN_REPAIR_TTL see note below
MY_ROUTE_TIMEOUT 2 * ACTIVE_ROUTE_TIMEOUT
NET_DIAMETER 35
NET_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME * NET_DIAMETER
NEXT_HOP_WAIT NODE_TRAVERSAL_TIME + 10
NODE_TRAVERSAL_TIME 40 milliseconds
PATH_DISCOVERY_TIME 2 * NET_TRAVERSAL_TIME
RERR_RATELIMIT 10
RING_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME *
(TTL_VALUE + TIMEOUT_BUFFER)
RREQ_RETRIES 2
RREQ_RATELIMIT 10
TIMEOUT_BUFFER 2
TTL_START 1
TTL_INCREMENT 2
TTL_THRESHOLD 7
TTL_VALUE see note below
Parameter Name Value
---------------------- -----
ACTIVE_ROUTE_TIMEOUT 3,000 Milliseconds
ALLOWED_HELLO_LOSS 2
BLACKLIST_TIMEOUT RREQ_RETRIES * NET_TRAVERSAL_TIME
DELETE_PERIOD see note below
HELLO_INTERVAL 1,000 Milliseconds
LOCAL_ADD_TTL 2
MAX_REPAIR_TTL 0.3 * NET_DIAMETER
MIN_REPAIR_TTL see note below
MY_ROUTE_TIMEOUT 2 * ACTIVE_ROUTE_TIMEOUT
NET_DIAMETER 35
NET_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME * NET_DIAMETER
NEXT_HOP_WAIT NODE_TRAVERSAL_TIME + 10
NODE_TRAVERSAL_TIME 40 milliseconds
PATH_DISCOVERY_TIME 2 * NET_TRAVERSAL_TIME
RERR_RATELIMIT 10
RING_TRAVERSAL_TIME 2 * NODE_TRAVERSAL_TIME *
(TTL_VALUE + TIMEOUT_BUFFER)
RREQ_RETRIES 2
RREQ_RATELIMIT 10
TIMEOUT_BUFFER 2
TTL_START 1
TTL_INCREMENT 2
TTL_THRESHOLD 7
TTL_VALUE see note below
The MIN_REPAIR_TTL should be the last known hop count to the destination. If Hello messages are used, then the ACTIVE_ROUTE_TIMEOUT parameter value MUST be more than the value (ALLOWED_HELLO_LOSS * HELLO_INTERVAL). For a given ACTIVE_ROUTE_TIMEOUT value, this may require some adjustment to the value of the HELLO_INTERVAL, and consequently use of the Hello Interval Extension in the Hello messages.
MIN_REPAIR_TTL应该是到目标的最后一个已知跃点计数。如果使用Hello消息，则活动的\u路由\u超时参数值必须大于该值（允许的\u Hello\u丢失*Hello\u间隔）。对于给定的活动路由超时值，这可能需要对HELLO\u间隔的值进行一些调整，从而在HELLO消息中使用HELLO间隔扩展。
TTL_VALUE is the value of the TTL field in the IP header while the expanding ring search is being performed. This is described further in section 6.4. The TIMEOUT_BUFFER is configurable. Its purpose is to provide a buffer for the timeout so that if the RREP is delayed due to congestion, a timeout is less likely to occur while the RREP is still en route back to the source. To omit this buffer, set TIMEOUT_BUFFER = 0.
TTL_值是执行扩展环搜索时IP标头中TTL字段的值。第6.4节对此作了进一步说明。超时缓冲区是可配置的。其目的是为超时提供缓冲区，以便如果RREP由于拥塞而延迟，则当RREP仍在返回源的途中时，超时发生的可能性较小。要省略此缓冲区，请将TIMEOUT\u buffer设置为0。
DELETE_PERIOD is intended to provide an upper bound on the time for which an upstream node A can have a neighbor B as an active next hop for destination D, while B has invalidated the route to D. Beyond this time B can delete the (already invalidated) route to D. The determination of the upper bound depends somewhat on the characteristics of the underlying link layer. If Hello messages are used to determine the continued availability of links to next hop nodes, DELETE_PERIOD must be at least ALLOWED_HELLO_LOSS * HELLO_INTERVAL. If the link layer feedback is used to detect loss of link, DELETE_PERIOD must be at least ACTIVE_ROUTE_TIMEOUT. If hello messages are received from a neighbor but data packets to that neighbor are lost (e.g., due to temporary link asymmetry), we have to make more concrete assumptions about the underlying link layer. We assume that such asymmetry cannot persist beyond a certain time, say, a multiple K of HELLO_INTERVAL. In other words, a node will invariably receive at least one out of K subsequent Hello messages from a neighbor if the link is working and the neighbor is sending no other traffic. Covering all possibilities,
DELETE_PERIOD旨在提供上游节点A可以将邻居B作为目的地D的活动下一跳的时间上限，而B已经使到D的路由无效。超过此时间B可以删除（已经无效的）路由到D。上界的确定在某种程度上取决于底层链路层的特性。如果Hello消息用于确定到下一跳节点的链接的持续可用性，则DELETE\u PERIOD必须至少允许\u Hello\u LOSS*Hello\u INTERVAL。如果链路层反馈用于检测链路丢失，则删除周期必须至少为活动路由超时。如果从邻居收到hello消息，但发送给该邻居的数据包丢失（例如，由于临时链路不对称），我们必须对底层链路层做出更具体的假设。我们假设这种不对称性不会持续超过一定的时间，比如说，HELLO_间隔的倍数K。换言之，如果链路工作且邻居不发送其他通信量，则节点将始终从邻居接收至少K个后续Hello消息中的一个。涵盖所有可能性，
DELETE_PERIOD = K * max (ACTIVE_ROUTE_TIMEOUT, HELLO_INTERVAL) (K = 5 is recommended).
删除周期=K*max（活动路由超时，HELLO\u间隔）（建议K=5）。
NET_DIAMETER measures the maximum possible number of hops between two nodes in the network. NODE_TRAVERSAL_TIME is a conservative estimate of the average one hop traversal time for packets and should include queuing delays, interrupt processing times and transfer times. ACTIVE_ROUTE_TIMEOUT SHOULD be set to a longer value (at least 10,000 milliseconds) if link-layer indications are used to detect link breakages such as in IEEE 802.11 [5] standard. TTL_START should be set to at least 2 if Hello messages are used for local connectivity information. Performance of the AODV protocol is sensitive to the chosen values of these constants, which often depend on the
NET_DIAMETER测量网络中两个节点之间的最大可能跳数。节点遍历时间是数据包平均一跳遍历时间的保守估计，应包括排队延迟、中断处理时间和传输时间。如果链路层指示用于检测链路中断（如IEEE 802.11[5]标准中的链路中断），则应将ACTIVE_ROUTE_TIMEOUT设置为更长的值（至少10000毫秒）。如果Hello消息用于本地连接信息，则TTL_START应至少设置为2。AODV协议的性能对这些常数的选定值非常敏感，这些值通常取决于
characteristics of the underlying link layer protocol, radio technologies etc. BLACKLIST_TIMEOUT should be suitably increased if an expanding ring search is used. In such cases, it should be {[(TTL_THRESHOLD - TTL_START)/TTL_INCREMENT] + 1 + RREQ_RETRIES} * NET_TRAVERSAL_TIME. This is to account for possible additional route discovery attempts.
底层链路层协议、无线电技术等的特征。如果使用扩展环搜索，则应适当增加黑名单超时。在这种情况下，它应该是{[（TTL_阈值-TTL_开始）/TTL_增量]+1+RREQ_重试次数}*NET_遍历时间。这是为了解释可能的额外路由发现尝试。
Currently, AODV does not specify any special security measures. Route protocols, however, are prime targets for impersonation attacks. In networks where the node membership is not known, it is difficult to determine the occurrence of impersonation attacks, and security prevention techniques are difficult at best. However, when the network membership is known and there is a danger of such attacks, AODV control messages must be protected by use of authentication techniques, such as those involving generation of unforgeable and cryptographically strong message digests or digital signatures. While AODV does not place restrictions on the authentication mechanism used for this purpose, IPsec AH is an appropriate choice for cases where the nodes share an appropriate security association that enables the use of AH.
目前，AODV没有规定任何特殊的安全措施。然而，路由协议是模拟攻击的主要目标。在节点成员身份未知的网络中，很难确定模拟攻击的发生，安全预防技术充其量也很困难。然而，当网络成员身份已知且存在此类攻击的危险时，必须使用身份验证技术来保护AODV控制消息，例如涉及生成不可伪造且加密性强的消息摘要或数字签名的技术。虽然AODV没有对用于此目的的身份验证机制进行限制，但对于节点共享适当的安全关联以启用AH的情况，IPsec AH是一个合适的选择。
In particular, RREP messages SHOULD be authenticated to avoid creation of spurious routes to a desired destination. Otherwise, an attacker could masquerade as the desired destination, and maliciously deny service to the destination and/or maliciously inspect and consume traffic intended for delivery to the destination. RERR messages, while less dangerous, SHOULD be authenticated in order to prevent malicious nodes from disrupting valid routes between nodes that are communication partners.
特别是，应该对RREP消息进行身份验证，以避免创建到所需目的地的虚假路由。否则，攻击者可能伪装成所需的目的地，恶意拒绝向该目的地提供服务和/或恶意检查并使用旨在传送到该目的地的流量。RERR消息虽然不太危险，但应该进行身份验证，以防止恶意节点中断作为通信伙伴的节点之间的有效路由。
AODV does not make any assumption about the method by which addresses are assigned to the mobile nodes, except that they are presumed to have unique IP addresses. Therefore, no special consideration, other than what is natural because of the general protocol specifications, can be made about the applicability of IPsec authentication headers or key exchange mechanisms. However, if the mobile nodes in the ad hoc network have pre-established security associations, it is presumed that the purposes for which the security associations are created include that of authorizing the processing of AODV control messages. Given this understanding, the mobile nodes should be able to use the same authentication mechanisms based on their IP addresses as they would have used otherwise.
除了假定移动节点具有唯一的IP地址外，AODV不对将地址分配给移动节点的方法做出任何假设。因此，对于IPsec身份验证头或密钥交换机制的适用性，除了由于通用协议规范而自然考虑之外，没有其他特殊考虑。然而，如果自组织网络中的移动节点具有预先建立的安全关联，则假定创建安全关联的目的包括授权处理AODV控制消息的目的。基于这种理解，移动节点应该能够基于其IP地址使用与其他情况相同的认证机制。
AODV defines a "Type" field for messages sent to port 654. A new registry has been created for the values for this Type field, and the following values have been assigned:
AODV为发送到端口654的消息定义一个“类型”字段。已为此类型字段的值创建新注册表，并已分配以下值：
Message Type Value
--------------------------- -----
Route Request (RREQ) 1
Route Reply (RREP) 2
Route Error (RERR) 3
Route-Reply Ack (RREP-ACK) 4
Message Type Value
--------------------------- -----
Route Request (RREQ) 1
Route Reply (RREP) 2
Route Error (RERR) 3
Route-Reply Ack (RREP-ACK) 4
AODV control messages can have extensions. Currently, only one extension is defined. A new registry has been created for the Type field of the extensions:
AODV控制消息可以有扩展名。目前，只定义了一个扩展。已为扩展的类型字段创建了一个新注册表：
Extension Type Value
--------------------------- -----
Hello Interval 1
Extension Type Value
--------------------------- -----
Hello Interval 1
Future values of the Message Type or Extension Type can be allocated using standards action [2].
可以使用标准操作[2]分配消息类型或扩展类型的未来值。
See [6] for detailed operation for IPv6. The only changes to the protocol are that the address fields are enlarged.
有关IPv6的详细操作，请参见[6]。协议的唯一变化是地址字段被放大。
Special thanks to Ian Chakeres, UCSB, for his extensive suggestions and contributions to recent revisions.
特别感谢UCSB的Ian Chakeres，感谢他对最新修订的广泛建议和贡献。
We acknowledge with gratitude the work done at University of Pennsylvania within Carl Gunter's group, as well as at Stanford and CMU, to determine some conditions (especially involving reboots and lost RERRs) under which previous versions of AODV could suffer from routing loops. Contributors to those efforts include Karthikeyan Bhargavan, Joshua Broch, Dave Maltz, Madanlal Musuvathi, and Davor Obradovic. The idea of a DELETE_PERIOD, for which expired routes (and, in particular, the sequence numbers) to a particular destination must be maintained, was also suggested by them.
我们感谢Carl Gunter团队内的宾夕法尼亚大学以及斯坦福大学和CMU所做的工作，以确定一些条件（特别是涉及重启和丢失的RRRS），在这些条件下，以前版本的AODV可能遭受路由环路的影响。这些努力的贡献者包括Karthikeyan Bhargavan、Joshua Broch、Dave Maltz、Madanlal Musuvathi和Davor Obradovic。他们还提出了一个删除周期的想法，在这个周期内，必须保留到特定目的地的过期路线（特别是序列号）。
We also acknowledge the comments and improvements suggested by Sung-Ju Lee (especially regarding local repair), Mahesh Marina, Erik Nordstrom (who provided text for section 6.11), Yves Prelot, Marc Mosko, Manel Guerrero Zapata, Philippe Jacquet, and Fred Baker.
我们还感谢Sung Ju Lee（特别是关于本地维修）、Mahesh Marina、Erik Nordstrom（为第6.11节提供文本）、Yves Prelot、Marc Mosko、Manel Guerrero Zapata、Philippe Jacquet和Fred Baker提出的意见和改进。
[1] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[3] Manner, J., et al., "Mobility Related Terminology", Work in Progress, July 2001.
[3] Way，J.等人，“流动相关术语”，正在进行的工作，2001年7月。
[4] Karthikeyan Bhargavan, Carl A. Gunter, and Davor Obradovic. Fault Origin Adjudication. In Proceedings of the Workshop on Formal Methods in Software Practice, Portland, OR, August 2000.
[4] 卡尔蒂克扬·巴格万、卡尔·A·冈特和达沃·奥布拉多维奇。故障源判定。《软件实践中的形式化方法研讨会论文集》，波特兰，2000年8月。
[5] IEEE 802.11 Committee, AlphaGraphics #35, 10201 N.35th Avenue, Phoenix AZ 85051. Wireless LAN Medium Access Control MAC and Physical Layer PHY Specifications, June 1997. IEEE Standard 802.11-97.
[5] IEEE 802.11委员会，AlphaGraphics#35，亚利桑那州凤凰城第35大道10201号，邮编85051。无线LAN介质访问控制MAC和物理层PHY规范，1997年6月。IEEE标准802.11-97。
[6] Perkins, C., Royer, E. and S. Das, "Ad hoc on demand distance vector (AODV) routing for ip version 6", Work in Progress.
[6] Perkins，C.，Royer，E.和S.Das，“ip版本6的特殊按需距离向量（AODV）路由”，正在进行中。
Charles E. Perkins Communications Systems Laboratory Nokia Research Center 313 Fairchild Drive Mountain View, CA 94303 USA
查尔斯·E·珀金斯通信系统实验室诺基亚研究中心313飞兆半导体大道山景城，加利福尼亚州94303
Phone: +1 650 625 2986
Fax: +1 650 691 2170 (fax)
EMail: Charles.Perkins@nokia.com
Phone: +1 650 625 2986
Fax: +1 650 691 2170 (fax)
EMail: Charles.Perkins@nokia.com
Elizabeth M. Belding-Royer Department of Computer Science University of California, Santa Barbara Santa Barbara, CA 93106
伊丽莎白M贝尔丁罗耶加利福尼亚大学计算机科学系，圣塔巴巴拉圣塔巴巴拉，CA 93106
Phone: +1 805 893 3411
Fax: +1 805 893 8553
EMail: ebelding@cs.ucsb.edu
Phone: +1 805 893 3411
Fax: +1 805 893 8553
EMail: ebelding@cs.ucsb.edu
Samir R. Das Department of Electrical and Computer Engineering & Computer Science University of Cincinnati Cincinnati, OH 45221-0030
萨米尔R.DAS辛辛那提大学电气与计算机工程与计算机科学系，辛辛那提，OH4221-10030
Phone: +1 513 556 2594
Fax: +1 513 556 7326
EMail: sdas@ececs.uc.edu
Phone: +1 513 556 2594
Fax: +1 513 556 7326
EMail: sdas@ececs.uc.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。