NS3官方文档翻译之NS3.19中的AODV

文档来源https://www.nsnam.org/docs/release/3.19/models/html/aodv.html
我自己进行翻译的，当然在百度翻译的帮助下，中英对照，以防翻译看不懂。

Ad Hoc On-Demand Distance Vector (AODV)
无线自组织按需距离矢量协议

This model implements the base specification of the Ad Hoc On-Demand Distance Vector (AODV) protocol.
该模型实现了无线自组织按需距离矢量（AODV）协议的基本规范。
The implementation is based on RFC 3561.
该实现基于RFC 3561。
The model was written by Elena Buchatskaia and Pavel Boyko of ITTP RAS, and is based on the ns-2 AODV model developed by the CMU/MONARCH group and optimized and tuned by Samir Das and Mahesh Marina, University of Cincinnati, and also on the AODV-UU implementation by Erik Nordström of Uppsala University.

Model Description
模块描述
The source code for the AODV model lives in the directory src/aodv.
AODV模型的源代码位于目录src/aodv中。

Design设计

Class ns3::aodv::RoutingProtocol implements all functionality of service packet exchange and inherits from ns3::Ipv4RoutingProtocol.
类ns3::aodv::RoutingProtocol实现了所有服务数据包交换的功能和继承ns3::Ipv4RoutingProtocol。
The base class defines two virtual functions for packet routing and forwarding.
基类定义了两个用于分组路由和转发的虚函数。
The first one, ns3::aodv::RouteOutput, is used for locally originated packets, and the second one, ns3::aodv::RouteInput, is used for forwarding and/or delivering received packets.
第一个，ns3::aodv::RouteOutput()，用于主动发包时调用的；第二个，ns3::aodv::RouteInput()，用于转发和/或分发收到的数据包。

Protocol operation depends on many adjustable parameters.
该协议调用取决于许多可改变的参数。
Parameters for this functionality are attributes of ns3::aodv::RoutingProtocol.
此功能的参数是ns3::aodv::RoutingProtocol的属性。
Parameter default values are drawn from the RFC and allow the enabling/disabling protocol features, such as broadcasting HELLO messages, broadcasting data packets and so on.
参数的缺省值是从RFC中来的，并允许启用/禁用协议特性，如广播hello消息、广播数据包等。

AODV discovers routes on demand.
AODV按需发现路由。
Therefore, the AODV model buffers all packets while a route request packet (RREQ) is disseminated.
因此，当路由请求包（RREQ）被发送出去后，AODV模型缓存所有的数据包。
A packet queue is implemented in aodv-rqueue.cc.
aodv-rqueue.cc中实现了数据包队列。
A smart pointer to the packet, ns3::Ipv4RoutingProtocol::ErrorCallback, ns3::Ipv4RoutingProtocol::UnicastForwardCallback, and the IP header are stored in this queue.
一个巧妙的数据包类型的指针，ns3::Ipv4RoutingProtocol::ErrorCallback()、ns3::Ipv4RoutingProtocol::UnicastForwardCallback()和IP报头，都存储在这个队列。
The packet queue implements garbage collection of old packets and a queue size limit.
数据包队列实现了旧数据包的垃圾收集和队列大小限制。

The routing table implementation supports garbage collection of old entries and state machine, defined in the standard.
在标准中定义的路由表的实现支持旧条目的垃圾回收和状态机。
It is implemented as a STL map container. The key is a destination IP address.
它是作为一个STL映射容器实现的。关键是目标IP地址。

Some elements of protocol operation aren’t described in the RFC.
一些协议的基本操作没有在RFC中说明。
These elements generally concern cooperation of different OSI model layers.
这些原理通常涉及不同OSI模型层的合作。
The model uses the following heuristics:
该模型使用以下启发式：
This AODV implementation can detect the presence of unidirectional links and avoid them if necessary.
此AODV实现可以检测单向链路的存在，并在必要时避免它们。
If the node the model receives an RREQ for is a neighbor, the cause may be a unidirectional link.
如果一个节点收到来自邻居的一个RREQ，这可能是单向链路造成的。
This heuristic is taken from AODV-UU implementation and can be disabled.
这种探索是从AODV-UU实现和可以被禁用。

Protocol operation strongly depends on broken link detection mechanism.
协议操作非常依赖于断链路检测机制。
The model implements two such heuristics.
该模型实现了两个这样的启发式算法。
First, this implementation support HELLO messages.
首先，这个实现支持hello消息。
However HELLO messages are not a good way to perform neighbor sensing in a wireless environment (at least not over 802.11).
然而，hello消息不是在无线环境中执行邻居感知（至少不超过802.11）的好方法。
Therefore, one may experience bad performance when running over wireless.
因此，在无线运行时可能会遇到糟糕的性能。
There are several reasons for this:
有以下几个原因：
1) HELLO messages are broadcasted. In 802.11, broadcasting is often done at a lower bit rate than unicasting, thus HELLO messages can travel further than unicast data.
HELLO消息是广播。在802.11中，广播通常比单播已更低的比特率进行，因此HELLO消息可以比单播数据能够传播得更远。
2) HELLO messages are small, thus less prone to bit errors than data transmissions, and 3) Broadcast transmissions are not guaranteed to be bidirectional, unlike unicast transmissions.
Hello消息很小，因此比数据传输更容易发生比特错误，3）广播传输不能保证是双向的，不像单播传输那样。
Second, we use layer 2 feedback when possible.
第二，如果可能的话，我们使用第2层反馈。
Link are considered to be broken if frame transmission results in a transmission failure for all retries.
如果在帧传输时所有重试发送失败,链接被认为是断开的。
This mechanism is meant for active links and works faster than the first method.
这种机制用于主动链接，比第一种方法工作得更快。

The layer 2 feedback implementation relies on the TxErrHeader trace source, currently supported in AdhocWifiMac only.
2层反馈的实现依赖于txerrheader跟踪源，目前只支持adhocwifimac。

Scope and Limitations
适用范围和局限性

The model is for IPv4 only.
该模块只能用于IPv4。
The following optional protocol optimizations are not implemented:
下面的可选协议优化没有实现：
1.Expanding ring search.
1、扩展环搜索。
2.Local link repair.
2、本地链路修复。
3.RREP, RREQ and HELLO message extensions.
3、RREP、RREQ和HELLO消息扩展。
These techniques require direct access to IP header, which contradicts the assertion from the AODV RFC that AODV works over UDP.
这些技术要求直接访问IP报头，这违背了AODV在UDP上工作的AODV的说明。
This model uses UDP for simplicity, hindering the ability to implement certain protocol optimizations.
此模型为了简单使用UDP，阻碍了实现某些协议优化的能力。
The model doesn’t use low layer raw sockets because they are not portable.
该模型不使用低层原始套接字，因为它们不可移植。