文檔來源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.
該模型不使用低層原始套接字，因爲它們不可移植。