In order to use the testbed specific commands you must include the following line near the top of your NS file (before any testbed commands are used):
source tb_compat.tcl
If you wish to use your file under NS you can use download this tb_compat.tcl. Place it in the same directory as your NS file. When run in this way under NS the testbed commands will have no effect, but NS will be able to parse your file.
set node1 [$ns node]What is really going on is that the simulator, represented by
$ns is creating a new node, involving a bunch of internal
data changes, and returning a reference to it which is stored in the
variable node1. In almost all cases, when you need to
refer to a node you will do it as $node1, the
$ indicating that you want the value the variable
node1, i.e. the reference to the node. Thus you will be
issuing commands like:
$ns duplex-link $node1 $node2 100Mb 150ms DropTail tb-set-ip $node1 192.0.0.2
(Note the $'s)
You will notice that when your experiment is setup the node names
and such will be node1. This happens because the parser
detects what variable you are using to store the node reference and
uses that as the node name. In the case that you do something like:
set node1 [$ns node2] set A $node1
The node will still be called node1 as that was the first
variable to contain the reference.
If you are dealing with many nodes you may store them in array, perhaps like this:
for {set i 0} {$i < 4} {incr i} {
set nodes($i) [$ns node]
}
In this case the names of the node will be nodes-0,
nodes-1, nodes-2, nodes-3. (In
other words, the ( character is replaced with
-, and ) is removed.) This slightly
different syntax comes is to avoid any problems that ()
may cause later in the process. For example, the ()
characters cannot appear in DNS entries.
As a final note, everything said above for nodes applies equally to lans. I.e.:
set lan0 [$ns make-lan "$node0 $node1" 100Mb .1ms] tb-set-lan-loss $lan0 .02
(Again, note the $'s)
Links can also be named just like nodes and lans. The names can then be used to set loss rates or IP addresses. This technique is the only way to set such attributes when their are multiple links between two nodes.
set link1 [$ns duplex-link $node0 $node1 100Mb .1ms DropTail] tb-set-link-loss $link1 0.05 tb-set-ip-link $node0 $link1 192.0.0.128
tb- commands have the same status as all other Tcl and NS commands. Thus the order matters not only relative to each other but also relative other commands. One common example of this is that IP commands must be issued after the links or lans are created.
tb-set-hardware node type [args]. tb-set-hardware $node3 pc tb-set-hardware $node4 shark
Notes:
pc, pc600,
pc850, and shark are
supported types. pc is the default type.
Each node will be assigned an IP address for each interface that is in use. The following commands will allow you to explicitly set those IP addresses. IP addresses will be automatically generated for all nodes that you do not explicitly set IP addresses.
In the common case the IP addresses on either side of a link must be in the same subnet. Likewise, all IP addresses on a LAN should be in the same subnet. Generally the same subnet should not be used for more than one link or LAN in a given experiment, nor should one node have multiple interfaces in the same subnet. Automatically generated IP addresses will conform to these requirements. If part of a link or lan is explicitly specified with the commands below then the remainder will be automatically generated under the same subnet.
IP address assignment is deterministic and tries to fill lower IP's
first, starting at 2. Except in the partial specification case (see
above), all automatic IP addresses are in the network
192.168.
tb-set-ip node ip tb-set-ip $node1 142.3.4.5
Notes:
tb-set-ip and any other IP command on
the same node will result in an error.
tb-set-ip-link node link ip tb-set-ip-link $node0 $link0 142.3.4.6
Notes:
tb-set-ip on the
same node.
tb-set-ip-lan node lan ip tb-set-ip-lan $node1 $lan0 142.3.4.6
Notes:
tb-set-ip on the
same node.
tb-set-ip-interface node dst ip tb-set-ip-interface $node2 $node1 142.3.4.6
Notes:
tb-set-ip. (See above)
tb-set-ip-routing protocol. tb-set-ip-routing none tb-set-ip-routing ospf
Notes:
none is the default protocol;
i.e., no default routing is setup.
ospf is implemented by running gated
on all nodes in the experiment.
tb-set-node-os node os tb-set-node-os $node1 FBSD-STD tb-set-node-os $node1 MY_OS
Notes:
tb-set-node-rpms node rpms... tb-set-node-rpms $node0 rpm1 rpm2 rpm3
Notes:
tb-set-node-startup node startupcmd
tb-set-node-startup $node0 {mystart.sh -a}
Notes:
tb-set-node-cmdline node cmdline
tb-set-node-cmdline $node0 {???}
Notes:
tb-set-node-tarfiles node dir tarfile tb-set-node-tarfiles $node0 /bin mybinmods.tar /sbin mysbinmods.tar
Notes:
This is the NS syntax for creating a link:
$ns duplex-link $node1 $node2 100Mb 150ms DropTail
Note that it does not allow for specifying link loss rates. Emulab does, however, support link loss. The following commands can be used to specify link loss rates.
tb-set-link-loss src dst loss tb-set-link-loss link loss tb-set-link-loss $node1 $node2 0.05 tb-set-link-loss $link1 0.02
Notes:
tb-set-lan-loss lan loss tb-set-lan-loss $lan1 0.3
Notes:
tb-set-node-lan-delay node lan delay tb-set-node-lan-delay $lan0 $node0 40ms
Notes:
make-lan. Thus in a LAN where
no tb-set-node-delay calls are made the node to
node latency will be the latency passed to
make-lan.
tb-set-node-lan-bandwidth node lan bandwidth tb-set-node-lan-bandwidth $lan0 $node0 20Mb
Notes:
make-lan.
tb-set-node-lan-loss node lan loss tb-set-node-lan-loss $lan0 $node0 0.05
Notes:
(1-(1-A)(1-B)).
make-lan command. If a loss rate of
L is passed to make-lan then the node to
switch loss rate for each node is set to
(1-sqrt(1-L)). Thus as each packet will
have two such chances to be lost the node to loss rate comes out
as the desired L.
tb-set-node-lan-params node lan delay bandwidth loss tb-set-node-lan-params $node0 $lan0 40ms 20Mb 0.05
Notes:
tb-set-link-simplex-params link src delay bw loss tb-set-link-simplex-params $link1 $srcnode 100ms 50Mb 0.2
Notes:
tb-set-lan-simplex-params below for LANs.
tb-set-lan-simplex-params lan node todelay tobw toloss fromdelay frombw fromloss tb-set-lan-simplex-params $lan1 $node1 100ms 10Mb 0.1 5ms 100Mb 0
Notes:
tb-set-node-lan-params
except that it allows the characteristics in each direction to be
chosen separately. See all the notes for
tb-set-node-lan-params.
Virtual Types are a method of defining fuzzy types. I.e. types that can be fulfilled by multiple different physical types. The advantage of virtual types (vtypes) is that all nodes of the same vtype will usually be the same physical type of node. In this way, vtypes allows logical grouping of nodes.
As an example, imagine we have network with internal routers connecting leaf nodes. We want the routers to all have the same hardware, and the leaf nods to all have the same hardware, but the specifics of this hardware do not matter. We have the following fragment in our NS file:
...
tb-make-soft-vtype router {pc600 pc850}
tb-make-soft-vtype leaf {pc600 pc850}
tb-set-hardware $router1 router
tb-set-hardware $router2 router
tb-set-hardware $leaf1 leaf
tb-set-hardware $leaf2 leaf
Here we have set up two soft (see below) vtypes, router and leaf. Our router nodes are then specified to be of type router, and the leaf nods of type leaf. When the experiment is swapped in the testbed will attempt to make router1 and router2 be of the same type, and similarly, leaf1 and leaf2 of the same type. However, the routers/leafs may be pc600s or they may be pc850s, whichever is easier to fit in to the available resources.
As a basic use, vtypes can be used to request nodes that are all the same type, but can be of any available type:
...
tb-make-soft-vtype N {pc600 pc850}
tb-set-hardware $node1 N
tb-set-hardware $node2 N
...
Vtypes come in two varieties, hard and soft. With soft vtypes, the testbed will try to make all nodes of that vtype the same physical type, but may do otherwise if resources are tight. Hard vtypes behave just like soft vtypes except that the testbed will give higher priority to vtype consistency and swapping in will fail if the vtypes can not be satisfied. So, if you use soft vtypes you are more likely to swap in but there is a chance your node of a specific vtype will not all be the same. If you use hard vtypes all nods of a given vtype will be the same, but swapping in may fail.
Finally, you can have weighted soft vtypes. Here you assign a weight from 0 to 1 exclusive to your vtype. The testbed will give higher priority to consistency in the higher weighted vtypes. The primary use of this in to rank multiple vtypes by importance of consistency. Soft vtypes have a weight of 0.5 by default.
As a final note, when specifying the types of a vtype, use the most specific type possible. For example: tb-make-soft-vtype router {pc pc600}, is not very useful, as pc600 is a sub type of pc. You may very well end up with two routers as type pc with different hardware, as pc covers multiple types of hardware.
tb-make-soft-vtype vtype {types}
tb-make-hard-vtype vtype {types}
tb-make-weighted-vtype vtype weight {types}
tb-make-soft-vtype router {pc600 pc850}
tb-make-hard-vtype leaf {pc600 pc850}
tb-make-weighted-vtype A 0.1 {pc600 pc850}
Notes:
tb-make-soft-vtype creates vtypes with weight 0.5.
tb-set-hardware
commands that use them.
tb-fix-node with nodes that have a vtype.
tb-fix-node vnode pnode tb-fix-node $node0 pc42
Notes: