Network Simulator 2: a Simulation Tool for Linux

screechingagendaNetworking and Communications

Oct 26, 2013 (3 years and 7 months ago)


Network Simulator 2: a Simulation Tool for

Oct 21, 2002


Ibrahim F. Haddad




Using Network Simulator 2 to simulate case scenarios using SCTP and TCP protocols with FTP
and HTTP traffic.

The ARIES (Advanced Research on Internet E
Servers) Project star
ted in 2000 as part of the
Open Systems Lab research activities at the Ericsson Corporate Unit of Research. Initially, the
project aimed to find and prototype the necessary technology to prove the feasibility of an
internet server that had the guaranteed a
vailability, response time and scalability using Linux and
source software. The project was successful, and it continued in 2001 to focus on
enhancing the clustering capabilities of Linux to be the operating system of choice for the
Mobile Internet se
rvers. Many enhancements were added in the areas of load balancing, traffic
distribution and security, in addition to IPv6 support.

One interesting question that came up was what is the impact of supporting IPv6 on other
protocols used by different applica
tions on our Linux clusters? To answer this question, we
started a study investigating the effects of IPv6 support on other protocols, such as SCTP. Part of
the study is to test applications in SCTP over IPv6. However, we did not have the time and
s to set up a lab with multiple nodes and applications that use SCTP over IPv6. Instead,
we chose the next best solution, network simulation.

There is a growing recognition within different internet communities of the importance of
simulation tools that he
lp design and test new internet protocols. New services and protocols
present challenges for testing. For instance, quality of service and multicast delivery require
large and complex environments. Protocol designers recognize the advantages of simulation
when computing resources are not available or are too expensive to duplicate a real lab setup.
With simulation, you can do large
scale tests that are controlled and reproducible. This was
exactly what we needed to build our case scenarios; the search start
ed primarily for an open
source tool because most of our work targets the deployment of open
source software based on

Our target application is a real
time network simulation tool that we can use to define the
different scenarios. A very interesting

source tool we came across was Network Simulator
2 (NS2), which was developed by the Information Sciences Institute at the University of
Southern California.

In this article, we summarize how to install and configure NS2 and look at two different
ulation scenarios. The first scenario involves monitoring SCTP traffic between two nodes,
and the second scenario looks at the behavior of web traffic and web applications over TCP over
a six
node network.

The Tool: Network Simulator 2

NS2 is an open
e simulation tool that runs on Linux. It is a discreet event simulator targeted
at networking research and provides substantial support for simulation of routing, multicast
protocols and IP protocols, such as UDP, TCP, RTP and SRM over wired and wireless (
local and
satellite) networks. It has many advantages that make it a useful tool, such as support for
multiple protocols and the capability of graphically detailing network traffic. Additionally, NS2
supports several algorithms in routing and queuing. LAN
routing and broadcasts are part of
routing algorithms. Queuing algorithms include fair queuing, deficit round
robin and FIFO.

NS2 started as a variant of the REAL network simulator in 1989 (see Resources). REAL is a
network simulator originally intended fo
r studying the dynamic behavior of flow and congestion
control schemes in packet
switched data networks.

Currently NS2 development by VINT group is supported through Defense Advanced Research
Projects Agency (DARPA) with SAMAN and through NSF with CONSER,
both in collaboration
with other researchers including ACIRI (see Resources). NS2 is available on several platforms
such as FreeBSD, Linux, SunOS and Solaris. NS2 also builds and runs under Windows.

Simple scenarios should run on any reasonable machine; ho
wever, very large scenarios benefit
from large amounts of memory. Additionally, NS2 requires the following packages to run: Tcl
release 8.3.2, Tk release 8.3.2, OTcl release 1.0a7 and TclCL release 1.0b11.

Installation and Configuration

The process of inst
alling NS2 is straightforward yet lengthy. At the time of writing, the most
recent version was 2.1b8. We are interested in the "all
one" package because it includes the
source code that we want to patch in SCTP support.

You can download the all
one p
ackage from the NS2 home page (see Resources) into /usr/src
and extract it as follows:

cd /usr/src

tar xzvf ns

cd ns

Because we want to examine a case scenario involving SCTP, we need to apply the SCTP patch
to NS2 from the University of Delaware. The patch is available for the NS2 all
one 2.1b8
version and can be downloaded from the Protocol Engineering Lab home page

(see Resources).
With the Linux

utility, you can update the NS2 source code to include support for SCTP
by applying the patch:

p0 < ns

In the same directory, there is a script named install that will conf
igure, compile and install the
required and optional NS2 components. There is no interaction with the user while installing; the
script is completely automated. You must execute the script as superuser so that installation of
binaries will be completed:


When the installation process is complete, the following message will appear on your shell

Please put


tk$TKVER/unix into your PATH environment; so that

you'll be able to run itm/tclsh/wish/xgraph.


Carefully follow all instructions given in the notices. The above
mentioned variables can be
updated either by editing /etc/profile or changing environment variables directly. In case you
updated /etc/profile, you need to source yo
ur new environment for the changes to take effect
source /etc/profile

The NS2 validation suite will verify that all protocols are functional. This will fail if the install
process was not completed; however, running validation is optional, and it
consumes twice as
much time as the compilation and installation process.

To run the validation suite:

cd ./ns



Using NS2 to Monitor SCTP Traffic

SCTP is a transmission protocol that was
introduced by the IETF workgroup SIGTRAN in
October 2000 (RFC 2960) to allow SS7 traffic over IP. However, since then it has adopted many
more uses because of its versatility as it also supports multihoming, network congestion control,
free sequenced

delivery and many other options.

After applying the SCTP patch to NS2 package, a README file is created: /usr/src/ns
2.1b8/sctp.README. At the end of the sctp.README file, there is an example script
for an SCTP interaction. In the simula
tion generated by this Tcl script, you will observe SCTP's
way handshake as described in RFC 2960, as well as congestion control. This scenario
examines FTP traffic over SCTP between two nodes: node 0 is FTP client and node 1 is FTP

The origin
al script is hard coded for version 2.1b7a. You need to update few lines to reflect your
own setup. Listing 1 has been updated assuming that NS2 version 2.1b8 was installed.

Listing 1. SCTP Simulation Script

The changes that were applied to the original script are basically setting the paths depending on
the specific environment. Once you update the paths of all used tools, you are ready to start NS
for a network simulation of SCTP. To start the simulation, follow these steps:

cd /usr/src/ns

ns ./sctp.tcl

Figure 1. SCTP Data Profile

Figure 2. Simulation Window

On execution, three windows will appear. The first window is
represented by Figure 1 showing a
graph with packet traffic. The second window shows the simulation window as seen in Figure 2.
The third window is the control window of the network animator (NAM).

It is interesting to see the graph generated by NS2
(Figure 1). The yellow x represents a dropped
packet and horizontally to the right is the retransmission. This dropped packet occurred because
of an error loss model that was introduced into the script that simply drops the specified packets
between nodes
given. SCTP manages retransmission similarly to TCP, supporting fast

set err [new ErrorModel/List]

$err droplist {15}

$ns lossmodel $err $n0 $n1

In the simulation window (Figure 2), right click on the link between both nodes and select graph
> graph bandwidth, and then click on Link 0
>1; you will obtain a bar graph representing
bandwidth going from node 0 to node 1. You can repeat this process for reverse traffic
bandwidth to monitor traffic going from node 1 to node 0. Now, you should see t
bandwidth graphs below node display (Figure 3).

Figure 3. Traffic Bandwidth Utility Graphs

Before we start the scenario, we will take a brief look at some important lines in the script and
explain what they do:

[...] // After
initializing trace

// files and simulation windows

set n0 [$ns node] // two nodes are created

set n1 [$ns node] // (n0 and n1)

$ns duplex
link $n0 $n1 .5Mb 300ms DropTail

// then they are

// together

$ns duplex
op $n0 $n1 orient right


set sctp0 [new Agent/SCTP]

$ns attach
agent $n0 $sctp0


set sctp1 [new Agent/SCTP]

$ns attach
agent $n1 $sctp1

Then we define the protocol (SCTP) that will be
used for destination and return traffic. An agent,
defining what protocol to use, is similar to a carrier for packets. Each agent must be attached to a
specific node:

$ns connect $sctp0 $sctp1 // connect both agents

// t
ogether to set up

// a communications

// channel, or a stream


set ftp0 [new Application/FTP] // define the type of

// application that

// will use the

// stream, FTP

$ftp0 attach
agent $sctp0

To start real
time simulation, press the play forward button. The first event to notice is the four
packets that initiate the FTP connection. This corresponds
to the stream initiation behavior
specified in RFC 2960. The other event to observe is congestion control. SCTP will send few
packets at a time and steadily increase until it reaches a maximum throughput but will not flood
the network. Although we do not a
lter our network's bandwidth, the FTP connection between
nodes 0 and 1 shows some basic congestion control. The beginning and end of the FTP
connection are defined on these lines:

$ns at 0.5 "$ftp0 start"

$ns at 4.5 "$ftp0 stop"

Notice how the packets are
being sent in an increasing fashion, or visually, in longer formats.
Actually, the packets are always the same length; however, the number of packets received by
the server is increased as can be seen by the number of SACKS received by client (Figure 4).
ACKS are sent to acknowledge each packet received to ensure packet validation and reliability.

Figure 4. SACKS for Every SCTP Packet Sent

The University of Delaware did not implement multihoming in their SCTP patch to NS2. This
means that SCTP behaves s
imilarly to TCP when it comes to streams. Otherwise, packets could
be seen traveling both along the primary path and along another routing path to the server's
second, third or other IP address. A similar behavior is dynamic rerouting, which is a secondary

function of SCTP's primary path monitoring.


Using NS2 to Monitor Web Traffic over TCP

This scenario examines web traffic over a TCP network. To simulate this case, we defined six

node 0 is the client that will request

a web page from the web server.

node 1 is the client's router.

node 2 is the web cache's primary router.

node 3 is the web cache's secondary router.

node 4 is the web cache server.

node 5 is the web server.

The web cache (node 4) is connected to a web ser
ver (node 5) through a router (node 3). The
web client (node 0) is connected to web cache (node 4) with connection routed through the
client's router (node 1). To simulate this case scenario, you need the script shown in Listing 2.

Listing 2. TCP Script

When executing
ns ./tcpweb.tcl
, you will obtain two windows: the network animator and the
simulation window. Figure 5 shows a possible layout of the

nodes in simulation window. To get
an accurate picture of traffic from client, bandwidth graphs for the link between nodes 1 and 2
are displayed.

Figure 5. Dynamic Rerouting of Packets

Link failure occurs between nodes 2 and 4 (Figure 5) as defined by t
he following lines:

$ns rtmodel
at 3 down $lrmon3 $lmcrt1

$ns rtmodel
at 7 up $lrmon3 $lmcrt1

Packets that were on the link are lost and must be retransmitted. After failure, notice the break in
packet traffic in the bandwidth graphs. TCP packets are now
taking another path from web cache
to web client. Yet the connection is not lost because of the failure, since we can see that packets
are still being exchanged between client and cache. If the display of nodes is not to your liking,
you can change it usin
g the Re
layout function button in the simulator window. While playing
the simulation, you can change the step using the slider bar. This will be especially useful during
the link failure between three and seven seconds to see dropped packets.

Another inte
resting aspect of this scenario is the visual server
cache and client
cache interaction.
You can see a model of real
time common interactions on the Internet. Of course, bear in mind
that this is a generalized simulation.

NS2 Graphical Editor

If you prefer

a graphical interface to setup network simulations, NAM supports a drag
user interface. You can place network nodes, link them together and define user agents and their
associated application or traffic generator. SCTP is not included in this int
erface because the
patch was specific to NS2 source code, not NAM. NAM is useful for quickly building a network
topology. However, we experienced multiple segmentation faults during editing (back up your
files often).

The following example explains how to
use basic NAM features. The first step is to start an
instance of NAM by executing
. Selecting New in the file menu, you will see the editor
window appear. For this example, we are trying to build the topology seen in Figure 6.

Figure 6. NAM Editor

On the toolbar, click on the Add node button and place three nodes in editor window by right
clicking at the correct positions. To link nodes, click on Add link. Select one node and drag
to the next node to create link. Next, choose which agents you
want to use on network in agent
down menu. To add an agent, click on the appropriate node. Lastly, you choose what
applications you want to simulate: either FTP or CBR source. To add an application, click on the
chosen agent. At this point, you can ri
ght click on different elements in your topology and edit
their properties such as color or start and end time for applications. If you get a dialog saying that
you must connect your agents, use Add link and connect different agents to simulate your
io. In case of a blunder, there is a delete button on the toolbar. Note that editor and
simulation windows are both part of NAM, but simulation must first be interpreted by NS2 so
that NAM can replay the log of simulation.


We decided to test NS2

because of its support of SCTP (which is a requirement for us), graphical
representations, multiple protocols and many other reasons. However, you need to patch the
source code in case the protocol you want to simulate is not supported and live with low
graphics tool.

NS2 is a tool that helps you better understand certain mechanisms in protocol definitions, such as
congestion control, that are difficult to see in live testing. It provides good documentation and
support for different add
ons. We rec
ommend NS2 as a tool to help understand how protocols
work and interact with different network topologies.

We would like to enforce the need for such tools to be open source and targeted toward
supporting Linux. With the emergence of new protocols, such as

IPv6 and SCTP, NS2 can be
very useful for the Open Source community.