--- a/doc/models/Makefile Tue May 24 17:01:37 2011 -0700
+++ b/doc/models/Makefile Tue May 24 18:47:02 2011 -0700
@@ -24,6 +24,7 @@
$(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 \
--- a/doc/models/source/index.rst Tue May 24 17:01:37 2011 -0700
+++ b/doc/models/source/index.rst Tue May 24 18:47:02 2011 -0700
@@ -24,6 +24,7 @@
bridge
click
csma
+ dsdv
emulation-overview
energy
flow-monitor
--- a/src/dsdv/doc/dsdv.h Tue May 24 17:01:37 2011 -0700
+++ b/src/dsdv/doc/dsdv.h Tue May 24 18:47:02 2011 -0700
@@ -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_ */
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/src/dsdv/doc/dsdv.rst Tue May 24 18:47:02 2011 -0700
@@ -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