Basics of NS2

INTRODUCTION TO NS2

INTRODUCTION 

Network Simulator Version 2, widely known as NS2, is an event driven simulation tool that is useful in studying the dynamic nature of communication networks. Simulation of wired as well as wireless network functions and protocols (e.g., routing algorithms, TCP, UDP) can be done using NS2. In general, NS2 provides users with a way of specifying such network protocols and simulating their corresponding behaviors. Due to its flexibility and modular nature, NS2 has gained constant popularity in the networking research community since its birth in 1989. Ever since, several revolutions and revisions have marked the growing maturity of the tool, thanks to substantial contributions from the players in the field. Among these are the University of California and Cornell University who developed the REAL network simulator,1 the foundation which NS is based on. Since 1995 the Defense Advanced Research Projects Agency (DARPA) supported development of NS through the Virtual InterNetwork Testbed (VINT) project.Currently the National Science Foundation (NSF) has joined the ride in development. Last but not the least, the group of researchers and developers in the community are constantly working to keep NS2 strong and versatile.

BASIC ARCHITECTURE OF NS2

Figure given below shows the basic architecture of NS2. NS2 provides users with an executable command ns which takes on input argument, the name of a Tcl simulation scripting file. Users are feeding the name of a Tcl simulation script (which sets up a simulation) as an input argument of an NS2 executable command ns. In most cases, a simulation trace file is created, and is used to plot graph and/or to create animation.

NS2 consists of two key languages: C++ and Object-oriented Tool Command Language (OTcl). While the C++ defines the internal mechanism (i.e.,a back end) of the simulation objects, the OTcl sets up simulation by assembling and configuring the objects as well as scheduling discrete events (i.e.,a front end). The C++ and the OTcl are linked together using TclCL. Mapped to a C++ object, variables in the OTcl domains are sometimes referred to as handles. Conceptually, a handle (e.g., n as a Node handle) is just a string (e.g.,o10) in the OTcl domain, and does not contain any functionality. Instead, the functionality(e.g., receiving a packet) is defined in the mapped C++ object (e.g., of class Connector). In the OTcl domain, a handle acts as a front end which interacts with users and other OTcl objects. It may defines its own procedures and variables to facilitate the interaction. Note that the member procedures and variables in the OTcl domain are called instance procedures(instprocs) and instance variables(instvars), respectively. Before proceeding further, the readers are encouraged to learn C++ and OTcl languages and we include it on our previous posts.

NS2 provides a large number of built in C++ objects. It is advisable to use these C++ objects to set up a simulation using a Tcl simulation script. However, advance users may find these objects insufficient. They need to develop their own C++ objects, and use a OTcl configuration interface to put together these objects. After simulation, NS2 outputs either text-based or animation-based simulation results. To interpret these results graphically and interactively, tools such as NAM (Network AniMator) and XGraph are used. To analyze a particular behavior of the network, users can extract a relevant subset of text-based data and transform it to a more conceivable presentation.

INSTALLATION

NS2 is a free simulation tool. It runs on various platforms including UNIX (or Linux), Windows, and Mac systems. Being developed in the Unix environment, with no surprise, NS2 has the smoothest ride there, and so  does its installation.

NS2 source codes are distributed in two forms: all-in-one suite and the component-wise. With the all-in-one package, users get all the required components along with some optional components. This is basically a recommended choice for the beginners. This package provides an “install” script which configures the NS2 environment and creates NS2 executable file using the “make” utility. The current all-in-one suite consists of the following main components : 

• NS release 2.30,

• Tcl/Tk release 8.4.13,

• OTcl release 1.12, and

• TclCL release 1.18.

and the following are the optional components:

• NAM release 1.12: NAM is an animation tool for viewing network simulation traces and packet traces.

• Zlib version 1.2.3: This is the required library for NAM.

• Xgraph version 12.1: This is a data plotter with interactive buttons for panning, zooming, printing, and selecting display options.

The idea of the component-wise approach is to obtain the above pieces and install them individually. This option save considerable amount of downloading time and memory space. However, it could be troublesome for the beginners, and is therefore recommended only for experienced users.

Click the following links to know more about installation:

• NS2 INSTALLATION ON LINUX PLATFORM

• NS2 INSTALLATION ON WINDOWS PLATFORM

NS2 DIRECTORY AND LANGUAGES

NS2 DIRECTORY

Normally NS2 is installed in the directory nsallinone-2.35 and we can see that in the following figure.

Figure given below shows the directory structure under directory nsallinone-2.35.

Here, directory nsallinone-2.35 is on the Level 1. 

On the Level 2, directory tclcl-1.18 contains classes in TclCL (e.g., Tcl, TclObject, TclClass). All NS2 simulation modules are in directory ns-2.35 on the Level 2. Here after, we will refer to directories ns-2.30 and tclcl-1.18 as  ̃ns/ and  ̃tclcl / respectively.

On Level 3, the modules in the interpreted hierarchy are under the directory tcl. Among the directories,the frequently used ones ( ns-lib.tcl,ns-node.tcl,ns-node.tcl) are stored under the directory lib on Level 4.Simulation modules in compiled hierarchy are classified in the directories on level 3.For example,directory tools contains various helper classes such as  random variable generators. Directory common contains basic modules  related to packet forwarding such as simulator,scheduler,packet and connectors.Directories queue,tcp and trace contain modules for queue, TCP [Transmission Control Protocol and tracing respectively.

Network Simulator is mainly based on two languages. They are;

    1) C++.

    2) OTCL.

NS2 LANGUAGES

The network simulator is a bank of of different network and protocol objects.

Each of these two languages has its own strengths and weaknesses. NS2 beautifully integrates these two languages to draw out their strengths. For most of the time, you would not need to know the integration mechanism. But you need to know the strength and weaknesses of these two languages in order to apply them properly.

OTCL [Object Oriented Tool Command Language]

OTCL is short for MIT Object TCL and it is an extension to the TCL/TK for object oriented programming.An OTcl program can run on the fly without the need for compilation. Upon execution, the interpreter translates OTcl instructions to machine code understandable to the operating system line by line.Therefore, OTcl codes run more slowly than C++ codes do. The upside of OTcl codes is that every change takes effect immediately.

OTcl helps in the following way:

1. With the help of OTcl, we can describe different network topologies.

2. It helps us to specify the protocols and their applications.

3. It allows fast development.

4. Tcl is compatible with many platforms and it is flexible for integration.

5. Tcl is very easy to use and it is available in free.

C++

Most important parts and kernal of NS2 is created by using C++. A C++ program needs to be compiled (i.e., translated) into the executable machine code. Since the executable is in the form of machine code, C++ program is very fast to run. However, the compilation process can be quite annoying. Every tiny little change like adding “int x = 0;” will take few seconds. 

C++ helps in the following way:

1. It helps to increase the efficiency of simulation.

2. Its is used to provide details of the protocols and their operation.

3. It is used to reduce packet and event processing time.

WHY TWO LANGUAGES???

The main requirement of simulator is;

• Detailed simulation of Protocol: Run-time speed.

• Varying parameters or configuration: easy to use.

C++ is fast to run but slower to code and change. Incase of OTCL, it is easy to code but runs slowly.This is the major reason that we are going behind the using of two languages for scripting and for kernal.