1 /* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */

     2 /*

     3  * Copyright (c) 2009 IITP RAS

     4  *

     5  * This program is free software; you can redistribute it and/or modify

     6  * it under the terms of the GNU General Public License version 2 as

     7  * published by the Free Software Foundation;

     8  *

     9  * This program is distributed in the hope that it will be useful,

    10  * but WITHOUT ANY WARRANTY; without even the implied warranty of

    11  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

    12  * GNU General Public License for more details.

    13  *

    14  * You should have received a copy of the GNU General Public License

    15  * along with this program; if not, write to the Free Software

    16  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

    17  *

    18  * Based on 

    19  *      NS-2 AODV model developed by the CMU/MONARCH group and optimized and

    20  *      tuned by Samir Das and Mahesh Marina, University of Cincinnati;

    21  * 

    22  *      AODV-UU implementation by Erik Nordström of Uppsala University

    23  *      http://core.it.uu.se/core/index.php/AODV-UU

    24  *

    25  * Authors: Elena Buchatskaia <borovkovaes@iitp.ru>

    26  *          Pavel Boyko <boyko@iitp.ru>

    27  */

    28 

    29 #ifndef AODV_H

    30 #define AODV_H

    31 

    32 /**

    33  * \ingroup routing

    34  * \defgroup aodv AODV

    35  * 

    36  * This model implements the base specification of the Ad hoc on demand distance vector (AODV)

    37  * protocol. Implementation is based on RFC3561.

    38  *

    39  * Class aodv::RoutingProtocol implements all functionality of service packet exchange and inherits Ipv4RoutingProtocol. 

    40  * Base class defines two virtual functions for packet routing and forwarding.  The first one,

    41  * RouteOutput(), is used for locally originated packets, and the second one, RouteInput(), is used for forwarding

    42  * and/or delivering received packets.

    43  *

    44  * Protocol operation depends on the many adjustable parameters. Parameters for this functionality are attributes of

    45  * aodv::RoutingProtocol. We support parameters, with their default values, from RFC and parameters that enable/disable

    46  * protocol features, such as broadcasting HELLO messages, broadcasting data packets and so on.

    47  *

    48  * AODV discovers routes on demand. Therefore, our AODV model  buffer all packets, while a route request packet (RREQ)

    49  * is disseminated. We implement a packet queue in aodv-rqueue.cc. Smart pointer to packet, Ipv4RoutingProtocol::ErrorCallback,

    50  * Ipv4RoutingProtocol::UnicastForwardCallback and IP header are stored in this queue. The packet queue implements garbage collection of old

    51  * packets and a queue size limit.

    52  *

    53  * Routing table implementation support garbage collection of old entries and state machine, defined in standard.

    54  * It implements as a STL map container. The key is a destination IP address.

    55  *

    56  * Some moments of protocol operation aren't described in RFC. This moments generally concern cooperation of different OSI model layers.

    57  * We use following heuristics:

    58  * 

    59  * 1) This AODV implementation can detect the presence of unidirectional links and avoid them if necessary.

    60  *    If the node we received a RREQ for is a neighbor we are probably facing a unidirectional link... 

    61  *    This heuristic is taken from AODV-UU implementation and can be disabled.

    62  *    

    63  * 2) Protocol operation strongly depends on broken link detection mechanism. We implements two such heuristics.

    64  *    First, this implementation support  HELLO messages. However HELLO messages are not a good way to do neighbor sensing

    65  *    in a wireless environment (at least not over 802.11). Therefore, you may experience bad performance when running over wireless.

    66  *    There are several reasons for this:

    67  *      -# HELLO messages are broadcasted. In 802.11, broadcasting is done at a lower bit rate than unicasting,

    68  *         thus HELLO messages travel further than data.

    69  *      -# HELLO messages are small, thus less prone to bit errors than data transmissions.

    70  *      -# Broadcast transmissions are not guaranteed to be bidirectional, unlike unicast transmissions.

    71  *    Second, we use layer 2 feedback when possible. Link considered to be broken, if frame transmission results in a transmission 

    72  *    failure for all retries. This mechanism meant for active links and work much more faster, than first method.

    73  *    Layer 2 feedback implementation relies on TxErrHeader trace source, currently it is supported in AdhocWifiMac only.

    74  *    

    75  * 3) Duplicate packet detection. We use special class DuplicatePacketDetection for this purpose.

    76  *

    77  * Following optional protocol optimizations aren't implemented:

    78  *  - Expanding ring search.

    79  *  - Local link repair.

    80  *  - RREP, RREQ and HELLO message extensions.

    81  * This techniques require direct access to IP header, which contradict assertion from AODV RFC that AODV works over UDP. Our model use UDP

    82  * for simplicity, but this disable us to implement protocol optimizations. We don't use low layer raw socket, because they are not portable.

    83  *

    84  */

    85 

    86 #endif /* AODV_H */