The user level simulation script requires one command: to specify the unicast routing strategy or protocols for the simulation. A routing strategy is a general mechanism by which will compute routes for the simulation. There are three routing strategies in : Static, Session, and Dynamic. Conversely, a routing protocol is a realisation of a specific algorithm. Currently, Static and Session routing use the Dijkstra's all-pairs SPF algorithm ../ns-2/route.cc RouteLogic::compute_routes; one type of dynamic routing strategy is currently implemented: the Distributed Bellman-Ford algorithm ../ns-2/route-proto.tcl Agent/rtProto/DV::compute_routes. In , we blur the distinction between strategy and protocol for static and session routing, considering them simply as protocols 23.1.
[]rtproto../ns-2/route-proto.tclSimulator::rtproto is the instance procedure in the Simulator../ns-2/ns-lib.tcl that specifies the unicast routing protocol to be used in the simulation. It takes multiple arguments, the first of which is mandatory; this first argument identifies the routing protocol to be used. Subsequent arguments specify the nodes that will run the instance of this protocol. The default is to run the same routing protocol on all the nodes in the topology. As an example, the following commands illustrate the use of the []rtproto command.
$ns rtproto Static # Enable static route strategy for the simulation;
$ns rtproto Session # Enable session routing for this simulation;
$ns rtproto DV $n1 $n2 $n3 # Run DV agents on nodes $n1, $n2, and $n3;
If a simulation script does not specify any []rtproto command,
then will run Static routing on all the nodes in the topology.
Multiple []rtproto lines for the same or different routing protocols can occur in a simulation script. However, a simulation cannot use both centralised routing mechanisms such as static or session routing and detailed dynamic routing protocols such as DV.
In dynamic routing, each node can be running more than one routing protocol. In such situations, more than one routing protocol can have a route to the same destination. Therefore, each protocol affixes a preference value to each of its routes. These values are non-negative integers in the range 0...255. The lower the value, the more preferred the route. When multiple routing protocol agents have a route to the same destination, the most preferred route is chosen and installed in the node's forwarding tables. If more than one agent has the most preferred routes, the ones with the lowest metric is chosen. We call the least cost route from the most preferred protocol the ``candidate'' route. If there are multiple candidate routes from the same or different protocols, then, currently, one of the agent's routes is randomly chosen23.2.