DSR in ns-2

[ Back to Network Simulator 2 for Wireless Home Page ]
Source code :

    Not all flies in ./dsr/ directory are used by the ns-2. the routing agent is implemented as Agent/DSRAgent.
    Thus, the source codes include:
Data Structure for Route

It is found that srh->addr and p.route are two different structures. srh() is always along with the packet. however, when DSR agent received a packet, it will
       SRPacket p(packet, srh);

 This generate a "p" which is frequently used by all other functions. remember p does not go along with the packet leaving dsr agent. Before the packet was sent out of the agent, another statement will be used to update "SRH" in sendOutPacketwithRoute

Also, the tap() entry is also generate a p for its use. however, another entry point of agent "xmitFailed" use srh() directly.

Special tcl interface.

Unless other routing protocol, the ns-2.1b9a,has a special node type named as "SRNodeNew". From those routines in the ns-lib.tcl. We can see that speical. Also, there is a tcl file in mobiloty/dsr.tcl is also related.
Simulator instproc create-node-instance args {
$self instvar routingAgent_
# DSR is a special case
if {$routingAgent_ == "DSR"} {
set nodeclass [$self set-dsr-nodetype]
} else {
set nodeclass Node/MobileNode
return [eval new $nodeclass $args]

Simulator instproc set-dsr-nodetype {} {
$self instvar wiredRouting_
set nodetype SRNodeNew
# MIP mobilenode
if [Simulator set mobile_ip_] {
set nodetype SRNodeNew/MIPMH
# basestation dsr node
if { [info exists wiredRouting_] && $wiredRouting_ == "ON"} {
set nodetype Node/MobileNode/BaseStationNode
return $nodetype

DSR Signaling Packets in Brief:

Entry Points for DSR agent:
  1. first, as normal, the recv() function which means a packet with a address destine to this node or from upper-target.
  2. xmitFailed(). This is the callback function when a MAC transmission failes. Based on this chance, route-error message generated
  3. tap(). This is a hidden entry when you turn promiscuous on. snooping the route and shorten the path.

Basic functions:

The longest route we can handle is defined in : define MAX_SR_LEN 16           // longest source route we can handle

Possible Reason for xmit_failure below IP layer:
DSR scheme options:
In the beginning of dsragent.cc, it define many bool selectors of some options like:

/*************** selectors ******************/
bool dsragent_snoop_forwarded_errors = true;
// give errors we forward to our cache?
bool dsragent_snoop_source_routes = true;
// should we snoop on any source routes we see?
bool dsragent_reply_only_to_first_rtreq = false;
// should we only respond to the first route request we receive from a host?
bool dsragent_propagate_last_error = true;
// should we take the data from the last route error msg sent to us
// and propagate it around on the next propagating route request we do?
// this is aka grat route error propagation
bool dsragent_send_grat_replies = true;
// should we send gratuitous replies to effect route shortening?
bool dsragent_salvage_with_cache = true;
// should we consult our cache for a route if we get a xmitfailure
// and salvage the packet using the route if possible
bool dsragent_use_tap = true;
// should we listen to a promiscuous tap?
bool dsragent_reply_from_cache_on_propagating = true;
// should we consult the route cache before propagating rt req's and
// answer if possible?
bool dsragent_ring_zero_search = true;
// should we send a non-propagating route request as the first action
// in each route discovery action?

// NOTE: to completely turn off replying from cache, you should
// set both dsragent_ring_zero_search and
// dsragent_reply_from_cache_on_propagating to false

bool dsragent_dont_salvage_bad_replies = true;
// if we have an xmit failure on a packet, and the packet contains a
// route reply, should we scan the reply to see if contains the dead link?
// if it does, we won't salvage the packet unless there's something aside
// from a reply in it (in which case we salvage, but cut out the rt reply)
bool dsragent_require_bi_routes = true;
// do we need to have bidirectional source routes?
// [XXX this flag doesn't control all the behaviors and code that assume
// bidirectional links -dam 5/14/98]

#if 0
bool lsnode_holdoff_rt_reply = true;
// if we have a cached route to reply to route_request with, should we
// hold off and not send it for a while?
bool lsnode_require_use = true;
// do we require ourselves to hear a route requestor use a route
// before we withold our route, or is merely hearing another (better)
// route reply enough?

About Flow State:

It is also desirable to disable the flow state stuff. it make the dsr code messy. flow state is not an orginal idea.
static const bool dsragent_enable_flowstate = false;
static const bool dsragent_prefer_default_flow = false;

About Packet Salvage

it's unknown how to complete disable the packet retransmission in layer 3. Even you change three expressions in dsragent.cc.

  1. salvage_with_cache = false (from true)
  2. salvage_max_request =0 (from 1)
  3. salvage_times = 0 (from 15)

The trace file still show that the routing agent send a undeliverable packet again. See xmitFail() function. I guess, it is necessary to disable "GOD" also.


Bryan's NS-2 DSR FAQ