ns (simulator)

This is an old revision of this page, as edited by Mram80 (talk | contribs) at 08:38, 25 October 2006. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


ns (also popularly called ns-2, in reference to its current generation) is a discrete event network simulator. It is popular in academia for its extensibility (due to its open source model) and plentiful online documentation. ns is popularly used in the simulation of routing and multicast protocols, among others, and is heavily used in ad-hoc research. ns supports an array of popular network protocols, offering simulation results for wired and wireless networks alike.

ns is licensed for use under version 2 of the GNU General Public License.

Functionalities of ns

Functionalities for wired, wireless networks, tracing, and visualization are available in ns2.

Support for the wired world include:

  • Routing DV, LS, PIM-SM
  • Transport protocols: TCP and UDP for unicast and SRM for multicast
  • Traffic sources: web, ftp, telnet, cbr (constant bit rate), stochastic, real audio
  • Different types of Queues: drop-tail, RED, FQ, SFQ, DRR
  • Quality of Service: Integrated Services and Differentiated Services
  • Emulation

Support for the wireless world include:

  • Ad hoc routing with different protocols, e.g. AODV, DSR, DSDV, TORA
  • Wired-cum-wireless networks
  • Mobile IP
  • Directed diffusion
  • Satellite
  • Senso-MAC
  • Multiple propagation models (Free space, two-ray ground, shadowing)
  • Energy models
  • Tracing
  • Visualisation

Other Utilities:

  • Network Animator (NAM)
  • TraceGraph

NS2 Structure

File:NS2.jpg Simplified User’s View of NS can see in Fig., ns2 interprets the simulation scripts written in OTcl. A user has to set the different components (e.g. event scheduler objects, network components libraries and setup module libraries) up in the simulation environment. The user writes his simulation as a OTcl script, plumbs the network components together to the complete simulation. If he needs new network components, he is free to implement them and to set them up in his simulation as well. The event scheduler as the other major component besides network components triggers the events of the simulation (e.g. sends packets, starts and stops tracing).

Some parts of ns2 are written in C++ for efficiency reasons. The data path (written in C++) is separated from the control path (written in OTcl). Data path object are compiled and then made available to the OTcl interpreter through an OTcl linkage (tclcl) which maps methods and member variables of the C++ object to methods and variables of the linked OTcl object. The C++ objects are controlled by OTcl objects. It is possible to add methods and member variables to a C++ linked OTcl object. A linked class hierarchy in C++ has its corresponding class hierarchy in OTcl. Results obtained by ns 2 have to be processed by other tools, e.g. the Network Animator (NAM), a perl or a awk script and gnuplot

Design

ns was built in C++ and provides a simulation interface through OTcl, an object-oriented dialect of Tcl.

ns uses two languages because the simulator has two different kinds of things it needs to do. On one hand, detailed simulations of protocols require a systems programming language which can efficiently manipulate bytes and packet headers and can implement algorithms that run over large data sets. For these tasks, run-time speed is important and turn-around time (running the simulation, finding bugs, fixing bugs, recompilation, and re-running the simulation) 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 (changing the model and re-running it) 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 simultaneous usage of C++ and OTcl. C++ is fast to run but slow to change, making it suitable for detailed protocol implementations. OTcl runs much more slowly but can be changed very quickly (and interactively), making it ideal for simulation configuration. Tclcl provides glue to make objects and variables appear in a shared space for both languages.

OTcl is adept in this context for

  • configuration, setup, and "one-time stuff"
  • manipulating existing C++ objects for customization

while C++ may be preferable

  • for anything that requires processing each packet of a flow
  • for changing the behavior of an existing C++ class in ways that have not been anticipated

For example, links are OTcl objects that assemble delay, queuing, and possibly loss modules. While an experiment can be run with these pieces alone, more elaborate setups (such as a special queuing dicipline or model of loss) can be achieved with new C++ objects.

History

ns began development in 1989 as a variant of the REAL network simulator. By 1995, ns had gained support from DARPA, the VINT project at LBL, Xerox PARC, UCB, and USC/ISI [1].

ns is now developed in collaboration between a number of different researchers and institutions, including SAMAN (supported by DARPA), CONSER (through the NSF), and ICIR (formerly ACIRI). 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.

The latest version of ns-2 is 2.30. For documentation on recent changes, see the version 2 change log.

ns-2can be built either from the the various packages (Tcl/Tk, otcl, etc.), or you can download an 'all-in-one' package. It is recommended that you start with the all-in-one package, especially if you're not entirely sure which packages are installed on your system, and where exactly they are installed. The disadvantage of the all-in-one distribution is the size, since it contains some components that you don't need anymore after you compiled ns and nam.

Generation 3 of ns has begun development as of July 1, 2006 and is projected to take four years [2].

References