Move dsdv module description out of doxygen
This commit is contained in:
@@ -24,6 +24,7 @@ SOURCES = \
|
||||
$(SRC)/bridge/doc/bridge.rst \
|
||||
$(SRC)/click/doc/click.rst \
|
||||
$(SRC)/csma/doc/csma.rst \
|
||||
$(SRC)/dsdv/doc/dsdv.rst \
|
||||
$(SRC)/mpi/doc/distributed.rst \
|
||||
$(SRC)/energy/doc/energy.rst \
|
||||
$(SRC)/emu/doc/emu.rst \
|
||||
|
||||
@@ -24,6 +24,7 @@ This document is written in `reStructuredText <http://docutils.sourceforge.net/r
|
||||
bridge
|
||||
click
|
||||
csma
|
||||
dsdv
|
||||
emulation-overview
|
||||
energy
|
||||
flow-monitor
|
||||
|
||||
@@ -35,43 +35,9 @@
|
||||
/**
|
||||
* \defgroup dsdv DSDV Routing
|
||||
*
|
||||
* \brief Destination-Sequenced Distance Vector (DSDV) routing protocol is a pro-active, table-driven routing protocol
|
||||
* for MANETs developed by Charles E. Perkins and Pravin Bhagwat in 1994. It uses the hop count as metric in route
|
||||
* selection.
|
||||
*
|
||||
* DSDV Routing Table: Every node will maintain a table listing all the other nodes it has known either directly
|
||||
* or through some neighbors. Every node has a single entry in the routing table. The entry will have information
|
||||
* about the node's IP address, last known sequence number and the hop count to reach that node. Along with these
|
||||
* details the table also keeps track of the nexthop neighbor to reach the destination node, the timestamp of the last
|
||||
* update received for that node.
|
||||
*
|
||||
* The DSDV update message consists of three fields, Destination Address, Sequence Number and Hop Count.
|
||||
*
|
||||
* Each node uses 2 mechanisms to send out the DSDV updates. They are,
|
||||
* 1. Periodic Updates
|
||||
* Periodic updates are sent out after every m_periodicUpdateInterval(default:15s). In this update the node broadcasts
|
||||
* out its entire routing table.
|
||||
* 2. Trigger Updates
|
||||
* Trigger Updates are small updates in-between the periodic updates. These updates are sent out whenever a node
|
||||
* receives a DSDV packet that caused a change in its routing table. The original paper did not clearly mention
|
||||
* when for what change in the table should a DSDV update be sent out. The current implemntation sends out an update
|
||||
* irrespective of the change in the routing table.
|
||||
*
|
||||
* The updates are accepted based on the metric for a particular node. The first factor determinig the acceptance of
|
||||
* an update is the sequence number. It has to accept the update if the sequence number of the update message is higher
|
||||
* irrespective of the metric. If the update with same sequence number is received, then the update with least metric
|
||||
* (hopCount) is given precedence.
|
||||
*
|
||||
* In highly mobile scenarios, there is a high chance of route fluctuations, thus we have the concept of weighted
|
||||
* settling time where an update with change in metric will not be advertised to neighbors. The node waits for
|
||||
* the settling time to make sure that it did not receive the update from its old neighbor before sending out
|
||||
* that update.
|
||||
*
|
||||
* The current implementation covers all the above features of DSDV. The current implementation also has a request queue
|
||||
* to buffer packets that have no routes to destination. The default is set to buffer up to 5 packets per destination.
|
||||
*
|
||||
* Link to the Paper: http://portal.acm.org/citation.cfm?doid=190314.190336
|
||||
*
|
||||
* This section documents the API of the ns-3 DSDV module. For a
|
||||
* generic functional description, please refer to the ns-3 model
|
||||
* library document.
|
||||
*/
|
||||
|
||||
#endif /* DSDV_H_ */
|
||||
|
||||
49
src/dsdv/doc/dsdv.rst
Normal file
49
src/dsdv/doc/dsdv.rst
Normal file
@@ -0,0 +1,49 @@
|
||||
.. include:: replace.txt
|
||||
|
||||
DSDV Routing
|
||||
------------
|
||||
|
||||
Destination-Sequenced Distance Vector (DSDV) routing protocol is a pro-active, table-driven routing protocol
|
||||
for MANETs developed by Charles E. Perkins and Pravin Bhagwat in 1994. It uses the hop count as metric in route
|
||||
selection.
|
||||
|
||||
|
||||
DSDV Routing Overview
|
||||
*********************
|
||||
|
||||
DSDV Routing Table: Every node will maintain a table listing all the other nodes it has known either directly
|
||||
or through some neighbors. Every node has a single entry in the routing table. The entry will have information
|
||||
about the node's IP address, last known sequence number and the hop count to reach that node. Along with these
|
||||
details the table also keeps track of the nexthop neighbor to reach the destination node, the timestamp of the last
|
||||
update received for that node.
|
||||
|
||||
The DSDV update message consists of three fields, Destination Address, Sequence Number and Hop Count.
|
||||
|
||||
Each node uses 2 mechanisms to send out the DSDV updates. They are,
|
||||
|
||||
1. Periodic Updates
|
||||
Periodic updates are sent out after every m_periodicUpdateInterval(default:15s). In this update the node broadcasts
|
||||
out its entire routing table.
|
||||
2. Trigger Updates
|
||||
Trigger Updates are small updates in-between the periodic updates. These updates are sent out whenever a node
|
||||
receives a DSDV packet that caused a change in its routing table. The original paper did not clearly mention
|
||||
when for what change in the table should a DSDV update be sent out. The current implemntation sends out an update
|
||||
irrespective of the change in the routing table.
|
||||
|
||||
The updates are accepted based on the metric for a particular node. The first factor determinig the acceptance of
|
||||
an update is the sequence number. It has to accept the update if the sequence number of the update message is higher
|
||||
irrespective of the metric. If the update with same sequence number is received, then the update with least metric
|
||||
(hopCount) is given precedence.
|
||||
|
||||
In highly mobile scenarios, there is a high chance of route fluctuations, thus we have the concept of weighted
|
||||
settling time where an update with change in metric will not be advertised to neighbors. The node waits for
|
||||
the settling time to make sure that it did not receive the update from its old neighbor before sending out
|
||||
that update.
|
||||
|
||||
The current implementation covers all the above features of DSDV. The current implementation also has a request queue
|
||||
to buffer packets that have no routes to destination. The default is set to buffer up to 5 packets per destination.
|
||||
|
||||
References
|
||||
**********
|
||||
|
||||
Link to the Paper: http://portal.acm.org/citation.cfm?doid=190314.190336
|
||||
Reference in New Issue
Block a user