HP NETWORK SIMULATOR: A COMWARE OS LEARNING TOOL

Comware v7 is a network operating system that runs on HP high-end network devices. The HP Network Simulator is an ideal Comware v7 learning tool, which allows users to create, configure, and connect simulated networks.

Benefits

Beginners – The HP Network Simulator tool is helpful for users who are new to networking and want to learn how to configure network devices (switches, routers), various topologies, or different routing and switching protocols and features.

Experienced users – The HP Network Simulator learning tool is helpful for users who have experience with non-HP networking devices and want to learn the Comware CLI and features.

Extra devices – Users can create devices using the HP Network Simulator and use them with their physical devices to configure and test topologies that aren’t configurable with just the physical devices they have. For example – A user wants to configure OSPF using 3 or more devices but has only 1 physical router. User can create 2 or more routers using the HP Network Simulator learning tool and connect the simulated devices with the physical device; and configure OSPF.

Certification Test Takers – The HP Network Simulator learning tool is also helpful for candidates who want to take HP Certification exams but don’t have access to physical HP devices to practice on.

For more,Click here

For download, Click here

VISUALIZING TRACE FILE DATA WITH GnuPlot

Gnuplot is a portable command-line driven graphing utility for Linux, OS/2, MS Windows, OSX, VMS, and many other platforms. The source code is copyrighted but freely distributed (i.e., you don't have to pay for it). It was originally created to allow scientists and students to visualize mathematical functions and data interactively, but has grown to support many non-interactive uses such as web scripting. It is also used as a plotting engine by third-party applications like Octave. Gnuplot has been supported and under active development since 1986. 

Gnuplot can be used to visualize the trace file data; several network parameters can be plotted using this Gnu plot..for more details click here

IMPLEMENTING A NEW PROTOCOL

Tutorial to implement protoname in ns2.35

This is an Implementation tutorial of new manet(Mobile Ad-hoc NETworks) unicast protocol name protoname.

List of files to be modified

• ~/ns-allinone-2.35/ns-2.35/common/packet.h
• ~/ns-allinone-2.35/ns-2.35/trace/cmu-trace.h
• ~/ns-allinone-2.35/ns-2.35/trace/cmu-trace.cc
• ~/ns-allinone-2.35/ns-2.35/tcl/lib/ns-packet.tcl
• ~/ns-allinone-2.35/ns-2.35/tcl/lib/ns-default.tcl 
• ~/ns-allinone-2.35/ns-2.35/tcl/lib/ns-lib.tcl
• ~/ns-allinone-2.35/ns-2.35/queue/priqueue.cc

 
** Note: Text in red is the part that is to be added or modified in given file and location and purple colour denotes the terminal commands.

** Note: mod stands for modification.

** Note: Line number is approx and is provided for your convenience. Please check the methods below and above before inserting.

Step 1:

download protoname.rar

http://www.cs.nccu.edu.tw/~g10031/protoname.rar

Extract the files and place them in ~/ns-allinone-2.35/ns-2.35/protoname directory(create the directory if not present)

Step 2:

gedit ~/ns-allinone-2.35/ns-2.35/common/packet.h (mods at 3 places)

• a.  its somewhere near line 200

static const packet_t PT_DCCP = 63;
static const packet_t PT_DCCP_REQ = 64;
static const packet_t PT_DCCP_RESP = 65;
static const packet_t PT_DCCP_ACK = 66;
static const packet_t PT_DCCP_DATA = 67;
static const packet_t PT_DCCP_DATAACK = 68;
static const packet_t PT_DCCP_CLOSE  = 69;
static const packet_t PT_DCCP_CLOSEREQ = 70;
static const packet_t PT_DCCP_RESET = 71;

        // M-DART packets
static const packet_t PT_MDART = 72;

        // insert new packet types here

static const packet_t PT_PROTONAME = 73;

static packet_t       PT_NTYPE = 74; // This MUST be the LAST one

• b. near line 250

static bool data_packet(packet_t type) {
return ( (type) == PT_TCP || \
        (type) == PT_TELNET || \
        (type) == PT_CBR || \
        (type) == PT_AUDIO || \
        (type) == PT_VIDEO || \
        (type) == PT_ACK || \
        (type) == PT_SCTP || \
        (type) == PT_SCTP_APP1 || \
        (type) == PT_HDLC || \  //(remember this mod also)
(type) == PT_PROTONAME \ 
       );

• c.      near line 422

static void initName()

{

                .....

                name_[PT_DCCP_REQ]="DCCP_Request";

name_[PT_DCCP_RESP]="DCCP_Response";

name_[PT_DCCP_ACK]="DCCP_Ack";

name_[PT_DCCP_DATA]="DCCP_Data";

name_[PT_DCCP_DATAACK]="DCCP_DataAck";

name_[PT_DCCP_CLOSE]="DCCP_Close";

name_[PT_DCCP_CLOSEREQ]="DCCP_CloseReq";

name_[PT_DCCP_RESET]="DCCP_Reset";

name_[PT_PROTONAME]="protoname"; 

name_[PT_NTYPE]= "undefined";

}

save and close.

Step 3:

gedit ~/ns-allinone-2.35/ns-2.35/trace/cmu-trace.h (mod at 1 place)

• a. Near line 164.

class CMUTrace: public Trace {
public:
CMUTrace (const char * s, char t);
...
private:
char tracename [MAX_ID_LEN + 1];
int nodeColor [MAX_NODE];
...
void format_tora (Packet * p, int offset);
void format_imep (Packet * p, int offset);
void format_aodv (Packet * p, int offset);
/ / ----------------------------------------------
void format_protoname (Packet *p, int offset);
/ / ----------------------------------------------
void format_aomdv (Packet * p, int offset);
void format_mdart (Packet * p, int offset);

/ / This holds all the tracers added at run-time
static PacketTracer * pktTrc_;

};
# Endif / * __ cmu_trace__ * /

save and close.

Step 4:

gedit ~/ns-allinone-2.35/ns-2.35/trace/cmu-trace.cc (mods at 3 places)

• a. Add this line at start

#include <protoname/protoname_pkt.h>

• b. Near line 1168

void
CMUTrace :: format_mdart (Packet * p, int offset) {
.........
........
........
}

void
CMUTrace::format_protoname(Packet *p, int offset)
{
struct hdr_protoname_pkt* ph = HDR_PROTONAME_PKT(p);
if (pt_->tagged())
{
sprintf(pt_->buffer() + offset, "-protoname:o %d -protoname:s %d -protoname:l %d ", ph->pkt_src(), ph->pkt_seq_num(), ph->pkt_len());
}
else if (newtrace_)
{
sprintf(pt_->buffer() + offset, "-P protoname -Po %d -Ps %d -Pl %d ", ph->pkt_src(), ph->pkt_seq_num(), ph->pkt_len());
}
else
{
sprintf(pt_->buffer() + offset, "[protoname %d %d %d] ", ph->pkt_src(), ph->pkt_seq_num(), ph->pkt_len());
}
}

• c. Near line 1477

void CMUTrace :: format (Packet * p, const char * why)
{...
switch (ch-> ptype ()) {
case PT_MAC:
...
case PT_GAF:
case PT_PING:
break;
/ / --------------------------------------------
case PT_PROTONAME:
format_protoname(p, offset);
break;
/ / --------------------------------------------
default:
...
}

save and close.

Step 5:

gedit ~/ns-allinone-2.35/ns-2.35/tcl/lib/ns-packet.tcl  (mod at 1 place)

• a. Near line 172

# Mobility, Ad-Hoc Networks, Sensor Nets:
    AODV     # routing protocol for ad-hoc networks
    Protoname # new routing protocol for ad-hoc networks
    Diffusion     # diffusion/diffusion.cc
    IMEP     # Internet MANET Encapsulation Protocol, for ad-hoc

Save and close.

Step 6:

gedit ~/ns-allinone-2.35/ns-2.35/tcl/lib/ns-default.tcl  (mod at 1 place)

• a. Add at the last.

# Defaults defined for Protoname
Agent/Protoname set accessible_var_ true

save and close.
Step 7:

gedit ~/ns-allinone-2.35/ns-2.35/tcl/lib/ns-lib.tcl  (mod at 2 places)

• a. Near line 671

switch-exact $ routingAgent_ {
...
ManualRtg {
set ragent [$ self create-manual-rtg-agent $
}
# / ------------------------------------------------ -
Protoname 
{
         set ragent [$self create-protoname-agent $node]
}
# / ------------------------------------------------ -
default {
...
}

---

• b. Near line 2278

Simulator instproc create-omnimcast-agent {node} {
...
}
# / ------------------------------------------------ -----
Simulator instproc create-protoname-agent {node} {
    # Create Protoname routing agent
    set ragent [new Agent/Protoname [$node node-addr]]
    $self at 0.0 "$ragent start"
    $node set ragent_ $ragent
    return $ragent
}
# / ------------------------------------------------ -----
# XXX These are very simulation-specific methods, why should they belon
Simulator instproc put-in-list {agent} {
...
}


Step 8:

gedit ~/ns-allinone-2.35/ns-2.35/queue/priqueue.cc (mod at 1 place)

• a. Near line 95.

void
PriQueue :: recv (Packet * p, Handler * h)
{
struct hdr_cmn * ch = HDR_CMN (p);
if (Prefer_Routing_Protocols) {
switch (ch-> ptype ()) {
...
case PT_MDART:
/ / --------------------------------------------
case PT_PROTONAME:
/ / --------------------------------------------
recvHighPriority (p, h);
break;
default:
Queue :: recv (p, h);
}
}
else {
Queue :: recv (p, h);
}
}

save and close.

Step 9:

gedit ~/ns-allinone-2.35/ns-2.35/Makefile (mod at 1 place)

• a. Near line 336

OBJ_CC = \
tools / random.o tools / rng.o tools / ranvar.o common / misc.o common /
...
wpan/p802_15_4trace.o wpan/p802_15_4transac.o \
apps / pbc.o \
# / / ----------------------------------------------- -
protoname/protoname.o protoname/protoname_rtable.o \
# / / ----------------------------------------------- -
$ (OBJ_STL)

save and close.

Step 10:

build it now, changes done ( run these in terminal in ~/ns-allinone-2.35/ns-2.35 directory )

• a. make clean

• b. touch common/packet.cc

• c. make

• d. sudo make install

(if you are getting some errors check the spaces in the editing you did above)


Step 11:

gedit ~/ns-allinone-2.35/ns-2.35/test.tcl

copy and paste

set ns [new Simulator]
$ns node-config -Routing protoname   
set nf [open out.nam w]     
$ns namtrace-all $nf       
set nd [open out.tr w]       
$ns trace-all $nd             
  proc finish {} {
          global ns nf  nd
          $ns flush-trace 
          close $nf       
          close $nd       
          exec nam out.nam &
          exit 0
   }

for {set i 0} {$i < 7} {incr i} {set n($i) [$ns node] }
for {set i 0} {$i < 7} {incr i} {
$ns duplex-link $n($i) $n([expr ($i+1)%7]) 1Mb 10ms DropTail
}
set udp0 [new Agent/UDP]   
$ns attach-agent $n(0) $udp0
set cbr0 [new Application/Traffic/CBR] 
$cbr0 set packetSize_ 500     
$cbr0 set interval_ 0.005      
$cbr0 attach-agent $udp0
set null0 [new Agent/Null]
$ns attach-agent $n(3) $null0
$ns connect $udp0 $null0 
$ns at 0.5 "$cbr0 start"
$ns rtmodel-at 1.0 down $n(1) $n(2) 
$ns rtmodel-at 2.0 up $n(1) $n(2)   
$ns at 4.5 "$cbr0 stop"
$ns at 5.0 "finish"
$ns run

save and close

ns ~/ns-allinone-2.35/ns-2.35/test.tcl

and boom you are getting the nam (if not sorry troubleshoot once by going through the tutorial again as I am getting the outputs completely and so should you)


The whole credit of this work goes to Francisco J. Ros and Pedro M. Ruiz for their beautiful work and excellent explanation they provide.

APPLICATION LAYER SIMULATIONS ON NS-2

A framework named "ns2-app" is developed and maintained by Xizhi Zhu to simplify the application layer simulations on NS-2.

BE CAREFUL, it's only tested on NS2.33 above, but it should work on some older versions as it doesn't change any existing code.

Why this framework

NS2 supports only unreal applications that just contain the length of packets. There do exist some real applications, but they are difficult to reuse, or even restricted to a specific type of applications.
Therefore, we decide to write this framework trying to reduce the difficulty. Also, a P2P framework is to be provided based on it.

Usage

• The application layer simulation framework
1. Download the latest source code here, uncompress it into the ~/ns-2.33/ directory, and recompile NS. BE CAREFUL, it will overwrite the original Makefile. But you can also modify the Makefile yourself by adding -I./real-app to the INCLUDES section and real-app/adu.o real-app/wrapper.o real-app/real-app.o real-app/test/test.o to the OBJ_CC section.
2. Derive a class from ADU to represent the application layer data, and rewrite the size function. The packets are sent by calling the RealApplication::send() function
3. Derive a class from RealApplication to represent the application, and rewrite the recv function which is called when a packet is arrived.
4. Derive a class from TclClass to combine the application in C++ with OTcl.
5. Write an OTcl script to configure the simulation.

• The P2P application
1. It's still under development.

The source code can be downloaded from the following link:

Download ns2-app-0.02.tar.bz2
After downloading, untar the downloaded folder in  ~/ns-2.33 directory and recompile NS-2.

For more details on installation and the possible errors, please visit the official website of ns2-app here.

OLSR PATCH FOR NS2

UM-OLSR

UM-OLSR is an implementation of the OLSR (Optimized Link State Routing) protocol for the ns-2 Network Simulator. The code is released under the terms of the GNU General Public License (GPL). Due to lack of time this project is not maintained by myself any more, feel free to take over the task of maintenance if you are interested.

UM-OLSR complies with IETF RFC 3626 and supports all core functionalities of OLSR plus the link-layer feedback option. The software has been successfully tested on ns-2, and patches for several versions of the simulator are provided. It is widely employed by the wireless communications research community, as the high number of references in research papers reveal. In addition, it was ported to ns-3 by Gustavo Carneiro (INESC Porto) and to Omnet++ by Alfonso Ariza (Universidad de Málaga). Thus, you can also run OLSR simulations in modern network simulators.
      

Features

Compliant with core OLSR (as described in RFC 3626).
Support for link-layer feedback.
Highly configurable from TCL scripts, i.e., without the need of recompiling the whole simulator. You can:
Activate/deactivate debug mode.
Change the interval at which every message type is sent.
Change nodes’ willingness for forwarding data packets on behalf of other nodes.
Print whatever data structure managed by a node at a certain time.

Download

The source code of UM-OLSR in hosted on SourceForge.net: download.

Contributed patches

Here you can find a sample script for configuring a simulation, as well as some UM-OLSR patches for different versions of ns-2 that were contributed by different people. Thanks a lot to all of them.

olsr_example.tcl
um-olsr-2.33_v0.8.8.patch by Damian Philipp.
um-olsr-2.34_v0.8.8.patch by Damian Philipp.
um-olsr-2.35_v0.8.8.patch by Andrey Lyubimov.

Installation

I assume that you have downloaded and unpackaged the allinone distribution of ns-2 (any of the versions supported by UM-OLSR). Copy um-olsr-0.8.8.tgz (substitute “0.8.8″ for your UM-OLSR version number) into ns-allinone-2.29/ns-2.29/ (substitute “2.29″ for your ns-2 version number), and then do:$ cd ns-allinone-2.29/ns-2.29/ $ tar zxvf um-olsr-0.8.8.tgz $ ln -s ./um-olsr-0.8.8 ./olsr $ patch -p1 < olsr/um-olsr_ns-2.29_v0.8.8.patch

If you had not installed ns-2 yet, then do the following:

$ cd ..
$ ./install

On the other hand, if you are installing UM-OLSR on a running installation of ns-2:

$ ./configure
$ make distclean
$ ./configure
$ make

Note that the code should work on most ns-2 releases, but only patches for some versions are provided. If you need UM-OLSR on a different ns-2 version, just create the appropriate patch and share it if you want.
Using UM-OLSR can be used like any other routing agent in ns-2, so you can use the node-configcommand to attach an OLSR routing agent to the mobile nodes which are to be created.$ns_ node-config -adhocRouting OLSR

After creating your mobile nodes, you can configure each UM-OLSR routing agent individually or all at once. But first we will see the available configuration options and their default value.
debug_ : Print debugging messages on stdout (false).
use_mac_ : Enable link-layer feedback (false).
willingness_ : Set the willingness for forwarding data packets on behalf of other nodes (WILL_DEFAULT = 3).
hello_ival_ : Set the interval of HELLO messages transmission (2 sec).
tc_ival_ : Set the interval of TC messages transmission (5 sec).
mid_ival_ : Set the interval of MID messages transmission (5 sec). This has no actual effect in the simulation, since multiple interfaces are not supported.

In oder to configure all agents, write sentences like these:

Agent/OLSR set debug_ true
Agent/OLSR set hello_ival_ 3

In order to configure a single agent:

set ra [$mobilenode agent 255]
$ra set use_mac_ true
$ra set tc_ival_ 6

By default, every UM-OLSR packet may piggyback up to 4 OLSR messages. You can change this value by redefining the OLSR_MAX_MSGS constant and recompiling the simulator. For the simulation results, the length of IPv4 addresses are assumed by default. If you prefer the length of IPv6 addresses, define OLSR_IPv6 and compile again.

           Once you have performed a simulation, you get a trace file where you can see what happened during the execution. Let us see with some examples the format of the traces generated by UM-OLSR. Following examples use the classic notation of ns-2 trace files. However, “tagged” and “new trace” formats are also supported.

s 21.537326976 _0_ RTR  --- 98 OLSR 56 [0 0 0 0] -------
 [0:255 -1:255 32 0] [1 12 [HELLO 0 0 12]]

The line above indicates that node 0 is sending an OLSR packet (size = 56 bytes) which contains one HELLO message. Specific information about the OLSR packet is by the end of the line (inside the final brackets): number of contained messages, packet sequence number, and the list of OLSR messages. Then we find information about the messages themselves: type, originator address, hop count and message sequence number.

r 13.833447485 _2_ RTR  --- 45 OLSR 84 [0 ffffffff 1 800] -------
 [1:255 -1:255 32 0] [2 10 [HELLO 1 0 10][TC 1 0 11]]

The example above shows the reception of a packet which piggybacks two messages, one HELLO and one TC. Information about each one is also shown. If you need further details about the ns-2 trace formats, please see the ns-2 manual.

courtesy:mohit p thahiliani

VARIABLE BIT RATE [VBR] IMPLEMENTATION IN NS2

We just made a VBR application that randomly change rate or bursts depending on parameters set.

In order to use it in ns you have to follow:

1. Include vbr_traffic.o in Makefile.in 
2. Preferrably set the default values in /home/user/Desktop/ns-allinone-2.35/ns-2.35/tcl/lib 
3. Run ./configure in your ns-allinone-2.35 directory 
4. Run make depend in ns-allinone-2.35
5. Run make

Now your VBR is ready.

Default values in ns-default.tcl:

Application/Traffic/VBR set rate_ 448Kb ;# corresponds to interval of 3.75ms 
Application/Traffic/VBR set rate_dev_ 0.25; 
Application/Traffic/VBR set rate_time_ 2.0; 
Application/Traffic/VBR set burst_time_ 1.0; 
Application/Traffic/VBR set n_o_changes_ 10; 
Application/Traffic/VBR set time_dev_ 0.5; 
Application/Traffic/VBR set constant_ false; 
Application/Traffic/VBR set maxrate_ 648Kb; 
Application/Traffic/VBR set packetSize_ 210; 
Application/Traffic/VBR set maxpkts_ 268435456; # 0x10000000


For vbr .cc file, Click here
For ns-default.tcl, Click here


VBR SYNTAX:

set vbr [new Application/Traffic/VBR]
$vbr set rate_ 448Kb
$vbr set rate_dev_ 0.25
$vbr set rate_time_ 2.0
$vbr set burst_time_ 1.0
$vbr set n_o_changes_ 10
$vbr set time_dev_ 0.5
$vbr set constant_ false
$vbr set maxrate_ 648Kb
$vbr set packetSize_ 210
$vbr set maxpkts_ 268435456
$vbr attach-agent $udp


For more mail to ns2blogger@gmail.com

COMPARATIVE METRICS CALCULATION

Here we are providing some details about comparative metrics that we are using in NS2.

For more details,Click here

INTRODUCTION TO NETWORK SIMULATOR 2

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

INTRODUCTION TO NETWORK SIMULATION

NETWORK

Network is an arrangement of intersecting horizontal and vertical lines. Computer networks allows computers to exchange data.In computer networks, networked computing devices pass data to each other along data connections.The connection between nodes are established using either cabled media or wireless media. The best known computer network is the Internet.

Network computer devices that originate, route and terminate the data are called Network nodes. Nodes can include host such as computers,mobile phones and servers as well as networking hardware. Two such devices are said to be networked together when one device is able to exchange information with the other device, whether or not they have a direct connection to each other. Computer networks support applications such as access to the World Wide Web, shared use of application and storage servers, printers, and fax machines, and use of email and instant messaging applications. Computer networks differ in the physical media used to transmit their signals, the communications protocols to organize network traffic, the network's size, topology and organizational intent.

NETWORK SIMULATION

In network research, network simulation is a technique where a program models the behavior of a network either by calculating the interaction between the different network entities (hosts/packets, etc.) using mathematical formulas, or actually capturing and playing back observations from a production network. The behavior of the network and the various applications and services it supports can then be observed in a test lab; various attributes of the environment can also be modified in a controlled manner to assess how the network would behave under different conditions. When a simulation program is used in conjunction with live applications and services in order to observe end-to-end performance to the user desktop, this technique is also referred to as network emulation.

NETWORK SIMULATOR

A network simulator is software or hardware that predicts the behavior of a computer network without an actual network being present. In simulators, the computer network is typically modeled with devices, traffic etc. and the performance is analysed. Typically, users can then customize the simulator to fulfill their specific analysis needs. Simulators typically come with support for the most popular protocols and networks in use today, such as WLAN, Wi-Max,TCP, WSN, cognitive radio etc.

SIMULATION SCENARIO 

Most of the commercial simulators are GUI driven, while some network simulators are CLI driven. The network model / configuration describes the state of the network (nodes,routers, switches, links) and the events (data transmissions, packet error etc.). An important output of simulations are the trace files. Trace files log every packet, every event that occurred in the simulation and are used for analysis. Network simulators can also provide other tools to facilitate visual analysis of trends and potential trouble spots.

Most network simulators use discrete event simulation, in which a list of pending "events" is stored, and those events are processed in order, with some events triggering future events—such as the event of the arrival of a packet at one node triggering the event of the arrival of that packet at a downstream node.

Some network simulation problems, notably those relying on queuing theory, are well suited to Markov chain simulations, in which no list of future events is maintained and the simulation consists of transiting between different system "states" in a memory less fashion. Markov chain simulation is typically faster but less accurate and flexible than detailed discrete event simulation.

Simulation of networks is a very complex task. For example, if congestion is high, then estimation of the average occupancy is challenging because of high variance. To estimate the likelihood of a buffer overflow in a network, the time required for an accurate answer can be extremely large. Specialized techniques such as "control variates" and "importance sampling" have been developed to speed simulation.

USES OF NETWORK SIMULATOR

Network simulators serve a variety of needs. Compared to the cost and time involved in setting up an entire test bed containing multiple networked computers, routers and data links, network simulators are relatively fast and inexpensive. They allow engineers, researchers to test scenarios that might be particularly difficult or expensive to emulate using real hardware - for instance, simulating a scenario with several nodes or experimenting with a new protocol in the network. Network simulators are particularly useful in allowing researchers to test new networking protocols or changes to existing protocols in a controlled and reproducible environment. A typical network simulator encompasses a wide range of networking technologies and can help the users to build complex networks from basic building blocks such as a variety of nodes and links. With the help of simulators, one can design hierarchical networks using various types of nodes like computers, hubs, bridges, routers, switches, links, mobile units etc.

Various types of Wide Area Network (WAN) technologies like TCP, ATM, IP etc. and Local Area Network (LAN) technologies like Ethernet, token rings etc., can all be simulated with a typical simulator and the user can test, analyze various standard results apart from devising some novel protocol or strategy for routing etc. Network simulators are also widely used to simulate battlefield networks in Network-centric warfare

There are a wide variety of network simulators, ranging from the very simple to the very complex. Minimally, a network simulator must enable a user to represent a network topology, specifying the nodes on the network, the links between those nodes and the traffic between the nodes. More complicated systems may allow the user to specify everything about the protocols used to handle traffic in a network. Graphical applications allow users to easily visualize the workings of their simulated environment. Text-based applications may provide a less intuitive interface, but may permit more advanced forms of customization.

SIMULATION TOOLS

1. Traffic

Developed by: E. Software

Available at: http://members.iinet.net.au/~clark/

Traffic version 2 is a simulation product designed to solve complex call-centre modelling problems, where traditional Erlang equations fail, but it can also be applied to any other queueing problem. It has an easy to use graphical interface and it runs under Windows.

2. PhySim

Developed by: Tetcos

Available at: http://tetcos.com/physim.html

PhySim allows for creation of Baseband, RF, Channel and Receiver chain and comes with inbuilt Oscilloscope, Spectrum Analyzer and Polar Plot. Techniques covered include ASK, FSK, PSK, DPSK, QPSK, PAM, PWM, PPM, TDM - PAM, AM-DSB-SC, SSB - SC , PCM, DM,Transmission Line, IF, RF, Dipole and AWGN. A free download of PhySim demo version is available at www.tetcos.com.

3. NetSim

Developed by: tetcos

Available at: http://www.tetcos.com/software.html

NetSim is developed by Tetcos and it is used for network lab experimentation and research. The protocols covered in simulation are aloha, slotted aloha, Ethernet - CSMA / CD, Fast Ethernet, Gigabit Ethernet, Token Ring, Token Bus, W Lan, X.25 Frame Relay, ATM, TCP, IP -Routing RIP, OSPF, BGP, MPLS, Wi-Max, Wireless Sensor Networks and Zigbee 802.15.4. The standard version features protocol source codes in C which can be modified and linked via the development environment. A free demo version can be downloaded from the website.

4. Shunra Virtual Enterprise

Developed by: Shunra

Available at: http://www.shunra.com/network_simulation_products.aspx

Shunra VE network simulation is a tool for pre-deployment testing and capacity planning and can be used for a wide variety of applications and projects. Shunra VE website claims its use by over 1700 customers within the financial services, retail, manufacturing, energy, technology and telecommunications, healthcare and pharmaceutical, travel, media and hospitality industries as well as government agencies and militaries. Shunra Virtual Enterprise (Shunra VE) is a powerful network simulation solution that creates an exact model of any production environment. This includes the network, remote locations, and the number and distribution of local and remote end-users. With Shunra VE, you can test the functionality, performance, scalability and robustness of any application or network infrastructure under current and future real-world conditions.

5. OPNET

Developed by: O. Technologies

Available at: http://www.opnet.com/

OPNET's suite of products combine predictive modeling and a comprehensive understanding of networking technologies to enable customers to design, deploy, and manage network infrastructure, network equipment, and networked applications. In particular OPNET Modeler is a development environment, allowing you to design and study communication networks,devices, protocols, and applications.

6. GloMoSim

Developed by: UCLA

Available at: http://pcl.cs.ucla.edu/projects/glomosim/

GloMoSim is a scalable simulation environment for wireless and wired network systems. It employs the parallel discrete-event simulation capability provided by Parsec. GloMoSim currently supports protocols for a purely wireless network. In the future, we anticipate adding functionality to simulate a wired as well as a hybrid network with both wired and wireless capabilities. GloMoSim source and binary code can be downloaded only by academic institutions for research purposed. Commercial users must use QualNet, the commercial version of GloMoSim.

7. CNet

Developed by: C. M. U. of Western Australia

Available at: http://www.csse.uwa.edu.au/cnet/

CNET is a simulator of computer networks. This simulator is not really focused on industrial simulation 'per-se', but to an aspect of it. It is a discrete-event network simulator enabling experimentation with various data-link layer, network layer, routingand transport layer networking protocols. It has been specifically developed for, and used in, undergraduate computer networking courses taken by thousands of students worldwide.

8. OptSim

Developed by: R. D. Group

Available at: http://www.rsoftdesign.com/products.php?sub=System+and+Network&itm=OptSim

OptSim 4.7 is the result of the merge between the former OptSim 3.6 sample mode engine, implementing simulation in the time domain sample by sample using a linear convolution algorithm, and the LinkSIM block mode engine, impelenting the Frequency Domain Split Step. It is an intuitive modeling and simulation environment supporting the design and the performance evaluation of the transmission level of optical communication systems.

9. GTNetS

Developed by: GeorgiaTech

Available at: http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/

The Georgia Tech Network Simulator (GTNetS), developed by Dr George Riley, is a full-featured network simulation environment that allows researchers in computer networks to study the behavior of moderate to large scale networks, under a variety of conditions. The design philosophy of GTNetS is to create a simulation environment that is structured much like actual networks are structured. For example, in GTNetS, there is clear and distinct separation of protocol stack layers. It is availabe for download from the website.

10. The Network Simulator - ns2

Developed by: U. of Southern California

Available at: http://www.isi.edu/nsnam/ns/

Ns2 is a discrete event simulator targeted at networking research. Ns provides substantial support for simulation of TCP, routing, and multicast protocols over wired and wireless (local and satellite) networks. Ns is devloped by ISI, the Information Sciences Institute at the USC school of engineering. The full source code of ns 2 can be downloaded and it can be compiled of multiple platform, including most popular Unix flavours and Windows.

11. JiST / SWANS

Developed by: R. B. C. University

Available at: http://jist.ece.cornell.edu/

SWANS is a scalable wireless network simulator built atop the JiST platorm. SWANS is organized as independent software components that can be composed to form complete wireless network or sensor network configurations. Its capabilities are similar to ns2 and GloMoSim, but is able to simulate much larger networks. SWANS leverages the JiST design to acheive high simulation throughput, save memory, and run standard Java network applications over simulated networks. In addition, SWANS implements a data structure, called hierarchical binning, for efficient computation of signal propagation.

12. OMNeT++

Developed by: O. C. Site

Available at: http://www.omnetpp.org/

OMNeT++ is a component-based, modular and open-architecture simulation environment with strong GUI support and an embeddable simulation kernel. The simulator can be used for modelling: communication protocols, computer networks and traffic modelling, multi-processors and distributed systems, etc. OMNeT++ also supports animation and interactive execution. It is freely distributed under an academic public license.

13. QualNet Developer

Developed by: S. N. Technologies

Available at: http://www.scalable-networks.com/

QualNet is a modelling tool for wireless and wired network,. The QualNet suite is composed of 

QualNet Simulator, which claims to be the fastest for real-time traffic modelling. QualNet Animator allows to graphically design the network model (using a wide library of components) and it displays the results of simulation runs. QualNet Designer allos to create Finite State Automata to describe the behaviour of your network, while with QualNet Analyzer and Designer you can interpret and make sense of simulation results. Windows and Linux versions are available. A demo can be downloaded on request.

14. PARSEC

Developed by: U. P. C. Laboratory

Available at: http://pcl.cs.ucla.edu/projects/parsec/

Parsec is a C-based simulation language, developed by the Parallel Computing Laboratory at UCLA, for sequential and parallel execution of discrete-event simulation models. It can also be used as a parallel programming language. It is available in binary form only for academic institutions. Commercial users are directed to its commercial implementation QualNet, marketed by Scalable Networks technologies (http://www.scalable-networks.com/)

15. NCTuns

Developed by: U. of Twente

Available at: http://nsl10.csie.nctu.edu.tw/

The NCTUns is a high-fidelity and extensible network simulator and emulator capable of simulating various protocols used in both wired and wireless IP networks. Its core technology is based on the novel kernel re-entering methodology. NCTUns can be used as an emulator, it directly uses the Linux TCP/IP protocol stack to generate high-fidelity simulation results, and it has many other interesting qualities. It is commercialised by SimReal Inc.

16. Performance PROPHET

Developed by: U. of Vienna

Available at: http://www.dps.uibk.ac.at/projects/prophet/

The Performance Prophet is a tool for modeling and simulation of high performance computing systems based on CSIM (Mesquite Software). Based on a UML model of an application and a simulator for a target architecture, the tool can predict the execution behavior of the application model on cluster and grid architectures. Performance Prophet has been deveoped at the Distributed and Parallel Systems Group of the University of Innsbruck and it has been supported by the Austrian Science Fund.