Net2

M. S. RAMAIAH INSTITUTE OF TECHNOLOGY
(AUTONOMOUS INSTITUTE, AFFILIATED TO VTU)
A Presentation Report on
“NETWORK SIMULATOR-2”
Submitted in Partial fulfillment of
5th
Semester B.E
In
Information Science and Engineering
For the subject
Data communication[IS511]
Submitted by
Deekshapoornashri (1MS13IS141)
Greeshma R J (1MS13IS142)
Shakunthala B V (1MS14IS412)
Shanta (1MS14IS413)

M. S. RAMAIAH INSTITUTE OF TECHNOLOGY
DEPARTMENT OF INFORMATION SCIENCE AND
ENGINEERING
BANGALORE – 560 054
C E R T I F I C A T E
This is to certify that the “Presentation on NETWORK SIMULATOR-2”
has been successfully completed by:
Deekshapoornashri 1MS13IS141
Greeshma R J 1MS13IS142
Shakunthala B V 1MS14IS412
Shanta 1MS14IS413
In partial fulfillment of 5th Semester B.E (Information Science
&Engg) for the subject “DATA COMMUNICATION(IS511)”
during the period 2015 - 2016, as prescribed by Department of
Information Science & Engineering, MSRIT.
Signature of Staff Incharge
Mr. Suresh kumar
Asst. Professor,
Dept. of ISE, MSRIT

ACKNOWLEDGEMENTS
Any achievement, be it scholastic or otherwise does not depend solely on the individual efforts but
on the
guidance, encouragement and cooperation of intellectuals, elders and friends. A number of
personalities, in their own capacities have helped us in carrying out this project work. We would like
to take this
opportunity to thank them all.
We deeply express our sincere gratitude to our guide Prof. Mr.Sureshkumar
Assistant Professor, Department of ISE, M.S.R.I.T, Bengaluru, for his able guidance, regular
source of encouragement and assistance throughout this project.
We would like to thank Dr. VIJAYKUMAR B P, Head of Department, Information Science &
Engineering, M.S.R.I.T, Bengaluru, for his valuable suggestions and expert advice.
Most importantly, we would like to thank Dr. N.V.R NAIDU Principal, M.S.R.I.T, Bengaluru, for
his
moral support towards completing our project work.
We thank our Parents, and all the Faculty members of Department of Information Science &
Engineering
For their constant support and encouragement.
Last, but not the least, we would like to thank our peers and friends who provided us with valuable
suggestions to improve our project.

CONTENTS:
 Introduction
 Background of Network Simulation-2
 Instruction procedurefor linux
 Components of NS-2
 Congestion
 Code
 Output screen shot

1. INTRODUCTION
Network Simulator version 2 (Ns2). Ns is a discrete event simulator that is used by
networking research to simulate wired, wireless and satellite networks.
NS started as a variant of the REAL network simulator in 1989 and has since been supported by
the VINT project and others. Ns allows for the simulation of various protocols, applications,
routing, queue types etc. A graphical front end has been developed for use with Ns known as
network animator (nam). Alternatively trace files can be created for analysis, which can be
displayed using Xgraph, Microsoft Excel and many more
ns (from network simulator) is a name for series of discrete event network simulators,
specifically ns-1, ns-2 and ns-3. All of them are discrete-event network simulator, primarily used
in research and teaching. ns-3 is free software, publicly available under the GNU GPLv2 license
for research, development, and use.
The goal of the ns-3 project is to create an open simulation environment for networking research
that will be preferred inside the research community.
 It should be aligned with the simulation needs of modern networking research.
 It should encourage community contribution, peer review, and validation of the software.
ns-1:
The first version of ns, known as ns-1, was developed at Lawrence Berkeley National
Laboratory (LBNL) in the 1995-97 timeframe by Steve McCanne, Sally Floyd, Kevin Fall, and
other contributors. This was known as the LBNL Network Simulator, and derived from an earlier
simulator known as REAL by S. Keshav. The core of the simulator was written in C++,
with Tcl-based scripting of simulation scenarios. Long-running contributions have also come
from Sun Microsystems, the UC Berkeley Daedelus, and Carnegie Mellon Monarch projects.
ns-2:
In 1996-97, ns version 2 (ns-2) was initiated based on a refactoring by Steve McCanne. Use of
Tcl was replaced by MIT's Object Tcl (OTcl), an object-oriented dialect of Tcl. The core of ns-2
is also written in C++, but the C++ simulation objects are linked to shadow objects in OTcl and
variables can be linked between both language realms. Simulation scripts are written in the OTcl
language, an extension of the Tcl scripting language.
Presently, ns-2 consists of over 300,000 lines of source code, and there is probably a comparable
amount of contributed code that is not integrated directly into the main distribution It runs
on GNU/Linux, FreeBSD, Solaris, Mac OS X and Windows versions that support Cygwin. It is
licensed for use under version 2 of the GNU General Public License.
ns-3:
A team led by Tom Henderson (University of Washington), George Riley (Georgia Institute of
Technology), Sally Floyd, and Sumit Roy (University of Washington), applied for and received
funding from the U.S. National Science Foundation (NSF) to build a replacement for ns-2, called

ns-3. This team collaborated with the Planete project of INRIA at Sophia Antipolis, with
Mathieu Lacage as the software lead, and formed a new open source project joined by other
developers worldwide.
In the process of developing ns-3, it was decided to completely abandon backward-compatibility
with ns-2. The new simulator would be written from scratch, using the C++ programming
language. Development of ns-3 began in July 2006. A framework for generating Python bindings
(pybindgen) and use of the Waf build system were contributed by Gustavo Carneiro.
The first release, ns-3.1 was made in June 2008, and afterwards the project continued making
quarterly software releases, and more recently has moved to three releases per year. ns-3 made
its eighteenth release (ns-3.18) in the third quarter of 2013.
Current status of the three versions is:
 ns-1 is no longer developed nor maintained,
 ns-2 build of 2009 is not actively maintainer (and is not being accepted for journal
publications)
 ns-3 is actively developed (but not compatible for work done on ns-2)
Network Simulator 2:
 One of the most popular simulator among networking researchers-Open source, free
 Discrete event, Packet level simulator-Events like ‘received an ack packet’, ‘enqueued a
data packet’ Network protocol stack written in C++
 Tcl (Tool Command Language) used for specifying scenarios and events and takes care
of the below
o Simulation scenario configurations, Periodic or triggered action
o Manipulating existing C++ objects,fast to write and change
o Simulates both wired and wireless networks.
o Ns-the simulator itself, Nam, the network animator-Visualize ns (or other) output
 Nam editor: GUI interface to generate ns scripts
 Pre-processing:
Traffic and topology generators
 Post-processing:
Simple trace analysis, often in Awk, Perl, or Tcl, You can also use grep (under linux),
or C/java

2. Background for ns2
2.1. Node types
Nodes in Ns are the hardware entities (hosts) within a simulation topology. Each
simulation requires an instance of the simulator class. Nodes are defined in a standalone class in
Otcl. Two basic node types exist unicast and multicast, which contain components that are
TclObjects, which give them the correct functionality for routing in a particular simulation.
The node can be configured to customise it for example to create a mobile node in a
wireless topology. Unicast is the default in Ns. Nodes contain a node entry object and classifiers
but to get started the two main classifiers defined for a node that are of concern here are an
address classifier and a port classifier which ensure incoming packets are sent to the correct
agent or outgoing link. This gives us our first two key words “Agent” and “Link” which allows
us to look at a basic node. In the diagram below there are two nodes, which have a link. The link
can be either simplex or duplex.
You will notice that each node has an agent attached; this is the connection/ protocol,
which could be TCP. On top of this agent sits an application, which puts traffic onto our network
such as FTP. An agent is normally software based.
Fig-1. Node Construction
An agent comes in two flavours, a Source agent and a sink agent. The source agent is the
generator of packet data and the sink node is the destination of the packet data. Lets call our
nodes node1 on the left and node2 on the right.
If TCP was added to node1 making it a source agent and we needed to send data to node2
a TCPsink agent would have to be attached to node2. Once the two agents are attached an
explicit declaration is required to connect the two nodes. Alternatively UDP could have been
used on node1 and a null agent sink on node2.
So a node has agents attached and applications attached to the agent only certain
applications should be attached to certain agents for example UDP and CBR we will discuss
CBR in more detail later. A node can have one or more links. A node can be a source or sink
node or even both depending on the topology.

2.2. Network protocols
IP -- Internet Protocol:
A layer 3 Protocol.Comes in two versions IPV4, IPV6. This is a data-oriented protocol
that communicates data across a network that is used by both source and host.
TCP -- Transmission Control Protocol
IETF RFC 793 defines TCP. TCP is a connection-oriented protocol. A highly reliable
protocol that guarantees delivery. That is normally associated with IP in the TCP/IP model.
UDP -- User Datagram Protocol
IETF RFC 768 defines the UDP transport protocol. UDP does not guarantee delivery of a
message.
HTTP -- Hyper Text Transfer Protocol
Is a request response protocol used on the World Wide Web (WWW). Maintained by the
W3C org. Defined in RFC2068.
POP3 Post Office Protocol version 3
Used to retrieve emails from a server for a local client over TCP/IP. Various RFC’s exist
for POP3
SNMP -- Simple Network Management Protocol
Used to monitor network-attached devices for conditions.
SMTP -- Simple Mail Transfer Protocol
Used for e-mail transmission across the Internet.
SSH -- Secure Shell
Is an application and a protocol. Used for executing commands on a remote computer.
IMAP -- Internet Message Access Protocol
Used for retrieving e-mails from a remote server. It leaves a copy on the server as opposed to
deleting.
DHCP -- Dynamic Host Control Protocol
Dynamically Allocates IP addresses to clients on a LAN.
BGP -- Border Gateway Protocol
Routing Protocol on the Internet. Used by ISP’s

IGRP -- Interior Gateway Routing Protocol
IGRP is a distance vector routing protocol designed by Cisco. Used by routers to
exchange routing data.
RIP -- Routing Information protocol
Allows routers to adapt dynamically to changing network connections
ARP -- Address Resolution Protocol
Is a method of finding a hosts Ethernet MAC address from its IP address
MARS -- Multicast Address Resolution Server
Multicasting is where a source sends a packet simultaneously to multiple destinations.
2.3. Typical applications
Two common applications that are used in Ns, which most will have heard of are FTP
and Telnet. When we use these applications from a home or business Pc / workstation, we are in
fact using the client or traffic source part of the application. All forms of users from various
locations use FTP widely and this client software can be by different vendors. To transfer a file-
using FTP we put traffic on the network, but in order for us to complete this we need to connect
to a FTP server (FTP daemon) or the sink node.
Telnet works with the same type of principle in that it uses TCP as the agent with a client
application and traffic is placed on the on the network for example to gain a remote login to a
server (sink node). Other examples of typical applications are e-mail using SMTP all senders are
using a client (agent) which then transfers your e-mail by putting traffic on the network to
connect via a e-mail server (sink node).
This sink node may if required then become an agent to pass on the data to another sink
node, before the person you sent the e-mail to, client application requests the e-mail you sent
from the sink node. HTTP is another example using a web browser as a client, which puts traffic
on the network to connect to a web server (sink node). The more you think about it the more
applications you could add to the list.
2.4. Constant bit rate (CBR) data transfer
CBR reserves a constant amount of bandwidth during the connection set up even when
idle. The CBR service was conceived to support applications such as voice and video, which
require jitter (small time variations).
The source may send at a negotiated or lower rate at any time and for any duration. The
connection in Ns would normally be set up with a UDP agent and the traffic source would be
CBR. In the diagram below node0 and 1 are both using UDP and CBR, which are sending data
via node2 to the null agent sink node3.There is bandwidth congestion at node2 which means

packets of data are being dropped for example using a drop tail queue. This results in
node3 not receiving all the data.
Nam snap shot
Fig-2 Drop tail queue
In CBR when packets are lost they are not re transmitted as receiving packets late in a
voice or video stream is of no use. The human eye and mind will normally fill in any small gaps.
This is one reason why CBR may run over UDP as there is no need to receive an
acknowledgement. For streams of data that require some form of order, TCP should be used.
2.5. Traffic generator function
So far we have covered node types, agents, applications and that we attach or link the
objects in a simulation. An overview was given of CBR, which is a traffic source and that
packets of data were sent across the network. Let us now look at how the traffic is put on the
network with a typical traffic generator function. First off we create our simulation and set up the
topology this will be discussed later. In order to put traffic on a network we need to attach an
agent to a node and attach the application to the agent and link the source and sink nodes.
 Set up a UDP connection with a variable name of udp and attach the UDP agent (variable
name $udp) to node1 (variable name $n1).
setudp [new Agent/UDP]
$ns attach-agent $n1 $udp
 Set up a null agent sink node with a variable name of null. Attach the null agent (variable
name $null) to node3 (variable name $n3). Then connect the traffic source node (node1)
to our sink node (node3).
set null [new Agent/Null]
$ns attach-agent $n3 $null
$ns connect $udp $null

3: Installation Procedure for Network Simulator 2(NS2) for Linux
Environment.
Step : 1 Download NS-23.5 from http://www.isi.edu/nsnam/ns/
Step : 2 Go to terminal and install the necessary updates using the command “
sudo apt-get update
Step : 3 Then install the ns2 required libraries using the command
sudo apt-get install build-essential autoconfautomakelibxmu-dev
Step : 4 Untar the downloaded ns-allinone-xxx.tar.gz file using the command
tarzxvf ns-allinone-2.35.tar.gz
Step : 5 Execute the commands one by one as given below
Step : 6 <Path of the ns file to be copied>cd ns-allinone-2.35
Step : 7 < Path of the ns file to be copied/ns-allinone-2.35>./install
Step : 8
Now that NS2 is installed, there are some environment variables that need
to be added to your profile. This can be done by editing the .bashrc file. Be sure to
change “/path/to” to the path of where you have extracted NS2.
Open the file using: gedit ~/.bashrc and the following at the end of the file:
# LD_LIBRARY_PATH
OTCLLIB=/path/to/ns-allinone-2.35/otcl-1.14
NS2=/path/to/ns-allinone-2.35/lib
USR_LocalLIB=/usr/local/lib
export
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCLLIB:$NS2:$USR_Local
LIB
# TCL_LIBRARY
TCLIB=/path/to/ns-allinone-2.35/tcl8.5.10/library
USRLIB=/usr/lib
export TCL_LIBRARY=$TCLIB:$USRLIB
# PATH
XGRAPH=/path/to/ns-allinone-2.35/xgraph-12.2/:/path/to/ns-allinone-
2.35/bin:/path/to/ns-allinone-2.35/tcl8.5.10/unix:/path/to/ns-allinone-
2.35/tk8.5.10/unix
NS=/path/to/ns-allinone-2.35/ns-2.35/
NAM=/path/to/ns-allinone-2.35/nam-1.15/
export PATH=$PATH:$XGRAPH:$NS:$NAM

Step : 9
You need to validate NS2 to check if everything is ok but beware that it will take
lots of time:
< Path of the ns file to be copied/ns-allinone-2.35/>cd ns-2.35
< Path of the ns file to be copied/ns-allinone-2.35/ns-2.35>./validate
This will take some time to validate the ns2 installation.
Step : 10
Now if you want to start NS2 directly without going into the directory every time,
it is useful to create a symbolic link from a terminal:
ln -s /path/to/ns-allinpne-2.35/ns-2.35/ns /usr/bin/ns
you can now run ns from a terminal window by executing :ns if you received the “%”
sign, it means that NS is running.

4. components of ns2
4.1. The structure of ns, including how to add a C++ patch (briefly)
Ns uses two languages C++ to implement protocols and Object Oriented Tcl (OTcl) to
write simulation scripts. Ns is an OTcl script interpreter that has a simulation event scheduler and
network libraries. So we write an Otcl script, which initiates an event scheduler. In the script we
define the topology of the network using objects and functions from the libraries.
Traffic is added to the network and told when to commence and when to end. This is
handled by the event scheduler, as is the termination of the simulation. The results from the
interpreter can then be analysed or graphically displayed using nam. Without getting to
complicated data path implementations are written and compiled by C++ in order to save
processing time.Once compiled these objects become available to the OTcl interpreter via an
OTcl linkage. The linkage creates a matching OTcl object and makes available to it functions
and variables that are also available to the linked C++ object. A class hierarchy in C++ (also
called the compiled hierarchy), and a similar class hierarchy within the OTcl interpreter (also
called the interpreted hierarchy) are also maintained between the linkage.
Fig-5 Linkage [NIL01]
Fig-6 Architecture [NIL01]

If we look at the structure of Ns we develop and execute in Tcl using object libraries
contained in OTcl. The event scheduler and most network components are developed in C++ to
give us the Ns simulation. The Tclcl is the Tcl/C++ interface between OTcl and C++.
In order to enhance the functionality of Ns extensions are added. These extensions are
modifications to the C++ or OTcl source code. Alternatively these may be completely new
agents or traffic sources etc. As an example the event scheduler and network component object
classes are located in the Ns-2 directory. In the Ns-2 directory are UDP.h and UDP.cc, which are
the C++ files used to implement the UDP agent (this location may vary with different versions of
Ns).
Similarly the tcl/lib directory contains the OTcl source code for node, links etc. To patch
Ns to work with a new or modified agent means the creation of C++ code, which will involve the
creation of a class and possibly a header file. A linkage has to be set up within the C++ class to
ensure the OTcl can use instances of the C++ class. Dependent on what is being written, a header
file may have to be registered in the packet.h and ns-packet.tcl.Methods may have to be added to
existing classes. Once these modifications are made the makefile will have to be modified to add
yourclass.o to the object file list. Then run make clean and make depend before recompiling
using make. This will patch the system to use your new or modified class.Sometimes a patch
may be released to modify or update the software this normally comes with the extension. patch.
To add this simply ensure you are in the correct working directory and type:
patch p0 <patchname.patch
4.2. The role of the Tk/Tcl and OTcl command language
Tcl is a command line tool Tk is a graphical interface for Tcl. Tcl is used because of the
fast iteration time it takes to modify a simulation model and re run the script file. Tcl/Tk uses a
simple interface so users do not have to learn any complex languages such as C++.
OTclas already discussed is built upon or encapsulates features of Tcl and as OTcl is
object oriented it is interfaced with C++ through the use of Tclcl. OTcl is the front-end to the
simulator as it is interpreted rather than compiled, the benefits for Ns is development speed
rather than it’s slower execution speed. So we could say OTcl is used for control as it allows us
to design our simulations by sharing member functions. OTcl is used for triggered actions. It also
manipulates the existing objects in C++.

Simulate the network topology with the congestion between the nodes.
#Create Simualator
set ns [new Simulator]
#Use colors to differentiate the traffics
$ns color 1 Blue
$ns color 2 Red
#Open trace and NAM trace file
setntrace [open prog6.tr w]
$ns trace-all $ntrace
setnamfile [open prog6.nam w]
$ns namtrace-all $namfile
#Finish Procedure
proc Finish {} {
global ns ntracenamfile
#Dump all trace data and close the files
$ns flush-trace
close $ntrace
close $namfile
#Execute the NAM animation file
execnam prog6.nam &
#Calculate the number of packets dropped due to collision
puts "The number of packet drops due to collision is"
execgrep "^d" prog6.tr | cut -d " " -f 4 | grep -c "3" &
exit 0
}
#Create 6 nodes
for {set i 0} {$i < 6} {incr i} {
set n($i) [$ns node]
}
#Create duplex links between the nodes
$ns duplex-link $n(0) $n(2) 2Mb 10ms DropTail
$ns duplex-link $n(1) $n(2) 2Mb 10ms DropTail
$ns duplex-link $n(2) $n(3) 0.2Mb 100ms DropTail
#Nodes n(3), n(4) and n(5) are considered in a LAN
set lan0 [$ns newLan "$n(3) $n(4) $n(5)" 0.5Mb 40ms LL Queue/DropTail MAC/802_3
Channel]

#Orientation to the nodes
$ns duplex-link-op $n(0) $n(2) orient right-down
$ns duplex-link-op $n(1) $n(2) orient right-up
$ns duplex-link-op $n(2) $n(3) orient right
#Set up queue between n(2) and n(3) and monitor the queue
$ns queue-limit $n(2) $n(3) 20
$ns simplex-link-op $n(2) $n(3) queuePos 0.5
#Setup TCP connection between n(0) and n(4)
set tcp0 [new Agent/TCP/Newreno]
$ns attach-agent $n(0) $tcp0
set sink0 [new Agent/TCPSink/DelAck]
$ns attach-agent $n(4) $sink0
$ns connect $tcp0 $sink0
$tcp0 set fid_ 1
$tcp0 set window_ 8000
$tcp0 set packetSize_ 552
#Apply FTP application over TCP
set ftp0 [new Application/FTP]
$ftp0 attach-agent $tcp0
$ftp0 set type_ FTP
#Setup another TCP connection between n(5) and n(1)
set tcp1 [new Agent/TCP/Newreno]
$ns attach-agent $n(5) $tcp1
set sink1 [new Agent/TCPSink/DelAck]
$ns attach-agent $n(1) $sink1
$ns connect $tcp1 $sink1
$tcp1 set fid_ 2
$tcp1 set window_ 8000
$tcp1 set packetSize_ 552
#Apply FTP application over TCP
set ftp1 [new Application/FTP]
$ftp1 attach-agent $tcp1
$ftp1 set type_ FTP
#Schedule the events
$ns at 0.1 "$ftp0 start"
$ns at 0.2 "$ftp1 start"
$ns at 24.8 "$ftp0 stop"
$ns at 24.9 "$ftp1 stop"
$ns at 25.0 "Finish"

#Run the simulation
$ns run
Output:
Network topology as below:
The throughput of FTP is
73196.227642276426 bytes per second
The throughput of CBR is
37347.26688102894 bytes per second

Net2

More Related Content

What's hot

Viewers also liked

Similar to Net2

Recently uploaded

Net2