This is a beginners introduction to ns2 the popular opensoure network simulator
Introduction to NS2
=================
ns is an event-driven network simulator. Ns-2 provides substantial support for simulation of TCP, routing, and multicast protocols over wired and wireless (local and satellite) networks. An extensible simulation engine is implemented in C++ that uses MIT’s Object Tool Command Language, OTcl (an object oriented version of Tcl) as the command and configuration interface. It is popular in academia for its extensibility (due to its open source model) and plentiful online documentation.ns is licensed for use under version 2 of the GNU General Public License.NS was built in C++ and provides a simulation interface through OTcl, an object-oriented dialect of Tcl. The user describes a network topology by writing OTcl scripts, and then the main NS program simulates that topology with specified parameters.
ns began development in 1989 as a variant of the REAL network simulator. By 1995, ns had gained support from DARPA, the VINT (Virtual Inter Network Testbed) project at LBL, Xerox PARC, UCB, and USC/ISI. ns is now developed in collaboration between a number of different researchers and institutions, including SAMAN (supported by DARPA), CONSER (Collaborative Simulation for Education and Research)(through the NSF), and ICIR (formerly ACIRI). It is currently maintained by volunteers. Long-running contributions have also come from Sun Microsystems and the UCB Daedelus and Carnegie Mellon Monarch projects, cited by the ns homepage for wireless code additions.Generation 3 of ns has begun development as of July 1, 2006 and was projected to take four years.Currently ns-3 is in development phase. It is an event based network simulator written in C++ and Python.
How Ns2 Works, Basic Components
===============================
The simulator is invoked via the ns interpreter, an extension of the vanilla otclsh command shell. A simulation is defined by a OTcl script. The scripts use the Simulator Class as the principal interface to the simulation engine. Using the methods defined in this class, a network topology is defined, traffic sources and sinks are configured, the simulation is invoked, and the statistics are collected. By building upon a fully functional language, arbitrary actions can be programmed into the configuration.
Simulation Script Outline
* create the simulator object
* create the nodes
* link the nodes together
* setup the agents
* schedule the start of the simulation
* schedule the end of the simulation
* run
The script is run by the command
$ ns <filename.tcl> .
The ouput file thus generated is given to nam for visualization.
$ nam <output_file generated>
The first step in the simulation is to acquire an instance of the Simulator class. Instances of objects in classes are created and destroyed in ns using the new and delete methods.
Eg: set ns [new Simulator]
A network topology is realized using three primitive building blocks:nodes, links, and agents. The Simulator class has methods to create/configure each of these building blocks.
Nodes are created with the node Simulator method that automatically assigns an unique address to each node.
Links are created between nodes to form a network topology with the simplex-link and duplex-link methods that set up unidirectional and bidirectional links respectively.
Agents are the objects that actively drive the simulation. Agents can be thought of as the processes and/or transport entities that run on nodes that may be end hosts or routers. Traffic sources and sinks, dynamic routing modules and the various protocol modules are all examples of agents. Agents are created by instantiating objects in the subclass of class Agent i.e., Agent/type where type specifies the nature of the agent. For
example, a TCP agent is created using the command:
Eg: set tcp [new Agent/TCP]
Once the agents are created, they are attached to nodes with the attach-agent Simulator method. Each agent is automatically assigned a
port number unique across all agents on a given node (analogous to a tcp or udp port). Some types of agents may have sources attached to them while others may generate their own data. For example, you can attach ‘‘ftp’’ and ‘‘telnet’’ sources to ‘‘tcp’’ agents but ‘‘constant bit-rate’’ agents generate their own data.
The simulation is started via the run method and continues until there are no more events to be processed. At this time, the original invocation of the run command returns and the Tcl script can exit or invoke another simulation run after possible reconfiguration. Alternatively, the simulation can be prematurely halted by invoking the stop command or by exiting the script with Tcl’s standard exit command.
Nam is a Tcl/TK based animation tool for viewing network simulation traces and real world packet traces. It is mainly intended as a companion animator to the ns simulator.
Example program
==============
Save the following file as sample.tcl
###########Topology##########
#
# 1.5mb
# 15ms
# src------------------dest
#
set ns [new Simulator]
set nf [open nam.out w]
$ns namtrace-all $nf
set trace [open trace.out w]
$ns trace-all $trace
proc finish { } { puts "Complete"; exit 1 }
set src [$ns node]
set dest [$ns node]
$ns duplex-link $src $dest 1.5Mb 15ms DropTail
set tcpSender [$ns create-connection TCP/Reno $src TCPSink $dest 1]
set ftp [new Application/FTP]
$ftp attach-agent $tcpSender
$ns at 0.0 "$ftp start"
$ns at 5.0 "finish"
$ns run
Execute it with the command
$ ns sample.tcl
This will generate nam.out and trace.out as specified in sample.tcl. Visualize it with the following command
$ nam nam.out
Interaction between OTCL and C++
==============================
ns uses two languages because simulator has two different kinds of things it needs to do. On one hand, detailed simulations of protocols requires a systems programming language which can efficiently manipulate bytes, packet headers, and implement algorithms that run over large data sets. For these tasks run-time speed is important and turn-around time (run simulation, find bug, fix bug, recompile, re-run) is less important.
On the other hand, a large part of network research involves slightly varying parameters or configurations, or quickly exploring a number of scenarios. In these cases, iteration time (change the model and re-run) is more important. Since configuration runs once (at the beginning of the simulation), run-time of this part of the task is less important. ns meets both of these needs with two languages, C++ and OTcl. C++ is fast to run but slower to change, making it suitable for detailed protocol implementation. OTcl runs much slower but can be changed very quickly (and interactively), making it ideal for simulation configuration. ns (via tclcl) provides glue to make objects and variables appear on both langauges.
The user gives OTCL script, which make use of the object compiled in C++ through an OTCl linkage(Tclcl) that creates a matching of OTCl object for each of the C++.
Statements in OTCL Scripts
========================
Frequesntly used ones are explained here
set ns [new Simulator]
Create a simulator object named ns.
set nf [open nam.out w]
$ns namtrace-all $nf
The first line opens the file 'nam.out'(creates if no there) for writing and gives it the file handle 'nf'. In the second line we tell the simulator object that we created above to write all simulation data that is going to be relevant for nam into this file.
set trace [open trace.tr w]
$ns trace-all $trace
Likewise a trace.tr is created and tells the simulator to write all the trace details to it. (file names are user defined).
$ns at 5.0 "finish"
$ns run
First line tells the simulator to finish after 5.0 seconds. The second line tells to start the simulation.
set s1 [$ns node]
set s2 [$ns node]
set router [$ns node]
set d [$ns node]
A new node object is created with the command '$ns node'. The above code creates four nodes and assigns them to the handles.
$ns duplex-link $s1 $router 1.5Mb 15ms DropTail
This line tells the simulator object to connect the nodes s1 and router with a duplex link with the bandwidth of 1.5Mb, a delay of 15ms and a DropTail queue.
In ns, data is always being sent from one 'agent' to another. So agents are to be created for sending data.
set tcpSender1 [$ns create-connection TCP/Reno $s1 TCPSink $d 0]
set ftp1 [new Application/FTP]
$ftp1 attach-agent $tcpSender1
The above lines creates a TCP connection between s1 and d with flow identifier 0 and assigns it the handle tcpSender1. Then an FTP agent is created and gives the handle ftp1. Then they are attached.This could also be done as:
set tcpsender1 [new Agent/TCP/Reno] #creates a pointer called tcpsender1 to the TCP/Reno agent.
$ns attach-agent $s1 $tcpsender1 #defines the source node of the TCP connection
set tcpsink [new Agent/TCPSink] #creates a pointer called tcpsink to the TCP/Sink agent.
$ns attach-agent $d $tcpsink #defines the source node
$ns connect $tcpsender1 $tcpsink #creates connection
set ftp1 [new Application/FTP] #creates a new FTP application
$ftp1 attach-agent $tcpSender1
$ns at 0.0 "$ftp1 start"
Tells to start simulation at 0.0 seconds.
new Agent/type
Create an Agent of type type which may be:
Null - Traffic Sink
LossMonitor - Traffic Sink that monitors loss parameters
TCP - BSD Tahoe TCP
TCP/FullTcp - Full Reno TCP with two-way connections
TCP/Reno - BSD Reno TCP
TCP/Newreno - a modified version of BSD Reno TCP
TCP/Vegas - Vegas TCP (from U. Arizonia via USC)
TCP/Sack1 - BSD Reno TCP with selective ACKs
TCP/Fack - BSD Reno TCP with forward ACKs
TCPSink - standard TCP sink
TCPSink/DelAck - TCP sink that generates delayed ACKs
TCPSink/Sack1 - TCP sink that generates selective ACKs
TCPSink/Sack1/DelAck - delayed-ack TCP sink with selective ACKs
UDP - UDP Transport
RTP - RTP agent
Session/RTP -
RTCP - RTCP agent
IVS/Source -
IVS/Receiver -
SRM -
The methods, configuration parameters and the relevant state variables associated with these objects are discussed in detail in later sections. Note that some agents e.g. TCP or SRM do not generate their own data. Such agents need sources attached to them to generate data (see attach-
source and attach-traffic methods in AGENT OBJECTS section).
$ns attach-agent node agent
Attach the agent object agent to node. The agent and node objects should have already been created.
Trace File
=========
Trace is organized in 12 fields.
1. Event Type: It is given by four possible symbols r,+,-,d which correspond respectievely to receive(at the output of the link), enqueued, dequeued and dropped.
2. Time: Time at which event occurs.
3. Imput Node: Imput node of the link at which event occurs.
4. Output node: Output node of the link at which event occurs.
5. Packet type: Eg: CBR,TCP....Type correspond to the name we gave to those applications.
6. Packet Size
7. Some flags
8. Flow Identifier: Flow ID if IPv6 that a user can set for each flow at the input OTcl script.
9. Source address: Given in the form node.port
10. Destination address: Given in the same form
11. Sequence number: Network layer protocols packet sequence number. Unlike real networks ns assigns sequence number for UDP packets also.
12. Unique ID od the packet