F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[aodv] Cosmetics

Browse Source
This commit is contained in:
Pavel Boyko
2009-10-30 13:00:24 +03:00
parent 0ba754ce77
commit dae3b91ebc
2 changed files with 23 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
src/routing/manet/aodv/aodv-routing-protocol.cc
View File

@@ -465,7 +465,7 @@ RoutingProtocol::NotifyInterfaceUp (uint32_t i)
Ptr<WifiNetDevice> wifi = dev->GetObject<WifiNetDevice> ();
if (wifi == 0)
return;
Ptr<WifiMac> mac = wifi->GetMac ()->GetObject<AdhocWifiMac> ();
Ptr<WifiMac> mac = wifi->GetMac ();
if (mac == 0)
return;

39
src/routing/manet/aodv/aodv.h
View File

@@ -36,9 +36,9 @@
* This model implements the base specification of the Ad hoc on demand distance vector (AODV)
* protocol. Implementation is based on RFC3561.
*
* Class aodv::RoutingProtocol implements all functionality of service packet exchange and inherit from
* Ipv4RoutingProtocol. Base class defines two virtual functions for packet routing and forwarding. The first,
* RouteOutput(), is used for locally originated packets, and the second, RouteInput(), is used for forwarding
* Class aodv::RoutingProtocol implements all functionality of service packet exchange and inherits Ipv4RoutingProtocol.
* Base class defines two virtual functions for packet routing and forwarding. The first one,
* RouteOutput(), is used for locally originated packets, and the second one, RouteInput(), is used for forwarding
* and/or delivering received packets.
*
* Protocol operation depends on the many adjustable parameters. Parameters for this functionality are attributes of
@@ -46,34 +46,39 @@
* protocol features, such as broadcasting HELLO messages, broadcasting data packets and so on.
*
* AODV discovers routes on demand. Therefore, our AODV model buffer all packets, while a route request packet (RREQ)
* is disseminated. We implement a packet queue in aodv-rqueue.cc. In reality, smart pointer to packet, Ipv4RoutingProtocol::ErrorCallback,
* is disseminated. We implement a packet queue in aodv-rqueue.cc. Smart pointer to packet, Ipv4RoutingProtocol::ErrorCallback,
* Ipv4RoutingProtocol::UnicastForwardCallback and IP header are stored in this queue. The packet queue implements garbage collection of old
* packets and a queue limit.
* packets and a queue size limit.
*
* Routing table implementation support garbage collection of old entries and state machine, defined in standard.
* It implements as a STL map container. The key is a destination IP address.
*
* Some moments of protocol operation aren't described in RFC. This moments generally concern cooperation of different OSI model layers.
* We use following heuristics:
* 1) This AODV implementation can detect the presence of unidirectional links,and avoid them if necessary.
* If the node we received a RREQ for is a neighbor we are probably facing a unidirectional link... This is feature can be disable.
*
* 1) This AODV implementation can detect the presence of unidirectional links and avoid them if necessary.
* If the node we received a RREQ for is a neighbor we are probably facing a unidirectional link...
* This heuristic is taken from AODV-UU implementation and can be disabled.
*
* 2) Protocol operation strongly depends on broken link detection mechanism. We implements two such heuristics.
* Firstly, this implementation support HELLO messages. However HELLO messages are not a good way to do neighbor sensing
* First, this implementation support HELLO messages. However HELLO messages are not a good way to do neighbor sensing
* in a wireless environment (at least not over 802.11). Therefore, you may experience bad performance when running over wireless.
* There are several reasons for this:
* a) HELLO messages are broadcasted. In 802.11, broadcasting is done at a lower bit rate than unicasting,
* -# HELLO messages are broadcasted. In 802.11, broadcasting is done at a lower bit rate than unicasting,
* thus HELLO messages travel further than data.
* b) HELLO messages are small, thus less prone to bit errors than data transmissions.
* c) Broadcast transmissions are not guaranteed to be bidirectional, unlike unicast transmissions.
* Secondly, we use layer 2 feedback. Link considered to be broken, if frame transmission results in a transmission failure for all retries.
* This mechanism meant for active links and work much more faster, than first method.
* -# HELLO messages are small, thus less prone to bit errors than data transmissions.
* -# Broadcast transmissions are not guaranteed to be bidirectional, unlike unicast transmissions.
* Second, we use layer 2 feedback when possible. Link considered to be broken, if frame transmission results in a transmission
* failure for all retries. This mechanism meant for active links and work much more faster, than first method.
* Layer 2 feedback implementation relies on TxErrHeader trace source, currently it is supported in AdhocWifiMac only.
*
* 3) Duplicate packet detection. We use special class dpd::DuplicatePacketDetection for this purpose.
*
* Following optional protocol optimizations aren't implemented:
* 1) Expanding ring search.
* 2) Local link repair.
* 3) RREP, RREQ and HELLO message extensions.
* This technique require direct access to IP header, which contradict assertion from AODV RFC that AODV works over UDP. Our model use UDP
* - Expanding ring search.
* - Local link repair.
* - RREP, RREQ and HELLO message extensions.
* This techniques require direct access to IP header, which contradict assertion from AODV RFC that AODV works over UDP. Our model use UDP
* for simplicity, but this disable us to implement protocol optimizations. We don't use low layer raw socket, because they are not portable.
*
*/