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.EIn

Information Science and EngineeringFor the subject

Data communication[IS511]

Submitted by

Deekshapoornashri (1MS13IS141)

Greeshma R J (1MS13IS142)

Shakunthala B V (1MS14IS412)

Shanta (1MS14IS413)

M. S. RAMAIAH INSTITUTE OF TECHNOLOGYDEPARTMENT OF INFORMATION SCIENCE AND

ENGINEERINGBANGALORE – 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.SureshkumarAssistant 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 procedure for linux Components of NS-2 Congestion Code Output screen shot

1. INTRODUCTIONNetwork 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 morens (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 belowo Simulation scenario configurations, Periodic or triggered actiono Manipulating existing C++ objects,fast to write and changeo 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 typesNodes 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 ProtocolIETF 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 ProtocolIs a request response protocol used on the World Wide Web (WWW). Maintained by the

W3C org. Defined in RFC2068.

POP3 Post Office Protocol version 3Used to retrieve emails from a server for a local client over TCP/IP. Various RFC’s exist

for POP3

SNMP -- Simple Network Management ProtocolUsed to monitor network-attached devices for conditions.

SMTP -- Simple Mail Transfer ProtocolUsed for e-mail transmission across the Internet.

SSH -- Secure ShellIs an application and a protocol. Used for executing commands on a remote computer.

IMAP -- Internet Message Access ProtocolUsed for retrieving e-mails from a remote server. It leaves a copy on the server as opposed to deleting.

DHCP -- Dynamic Host Control ProtocolDynamically Allocates IP addresses to clients on a LAN.

BGP -- Border Gateway ProtocolRouting Protocol on the Internet. Used by ISP’s

IGRP -- Interior Gateway Routing ProtocolIGRP is a distance vector routing protocol designed by Cisco. Used by routers to

exchange routing data.

RIP -- Routing Information protocolAllows routers to adapt dynamically to changing network connections

ARP -- Address Resolution ProtocolIs a method of finding a hosts Ethernet MAC address from its IP address

MARS -- Multicast Address Resolution ServerMulticasting 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 transferCBR 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 functionSo 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 LinuxEnvironment.

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 updateStep : 3 Then install the ns2 required libraries using the command

sudo apt-get install build-essential autoconfautomakelibxmu-devStep : 4 Untar the downloaded ns-allinone-xxx.tar.gz file using the command

tarzxvf ns-allinone-2.35.tar.gzStep : 5 Execute the commands one by one as given belowStep : 6 <Path of the ns file to be copied>cd ns-allinone-2.35Step : 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_PATHOTCLLIB=/path/to/ns-allinone-2.35/otcl-1.14NS2=/path/to/ns-allinone-2.35/libUSR_LocalLIB=/usr/local/libexport LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OTCLLIB:$NS2:$USR_LocalLIB# TCL_LIBRARYTCLIB=/path/to/ns-allinone-2.35/tcl8.5.10/libraryUSRLIB=/usr/libexport TCL_LIBRARY=$TCLIB:$USRLIB# PATHXGRAPH=/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/unixNS=/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 : 10Now 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.patch4.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 Simualatorset ns [new Simulator]

#Use colors to differentiate the traffics$ns color 1 Blue$ns color 2 Red

#Open trace and NAM trace filesetntrace [open prog6.tr w]$ns trace-all $ntracesetnamfile [open prog6.nam w]$ns namtrace-all $namfile

#Finish Procedureproc Finish {} {global ns ntracenamfile#Dump all trace data and close the files$ns flush-traceclose $ntraceclose $namfile

#Execute the NAM animation fileexecnam prog6.nam &

#Calculate the number of packets dropped due to collisionputs "The number of packet drops due to collision is"execgrep "^d" prog6.tr | cut -d " " -f 4 | grep -c "3" &exit 0}

#Create 6 nodesfor {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 LANset 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) $tcp0set 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 TCPset 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) $tcp1set 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 TCPset 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 runOutput:

Network topology as below:

The throughput of FTP is73196.227642276426 bytes per secondThe throughput of CBR is37347.26688102894 bytes per second