Network simulator 2 a simulation tool for linux

네이버 :: 마음까지 함께하는 네이버 카페 페이지 1 / 8
카페iN 출력하기 | 창 닫기
Network Simulator 2: a Simulation Tool for Linux | .. Network Simulator 2 2005.09.11 19:37
홍길동(whitekamvo) http://cafe.naver.com/prognara/1
Network Simulator 2: a Simulation Tool for Linux
By Ibrahim Haddad and David Gordon on Mon, 2002-10-21 01:00. Software
Using Network Simulator 2 to simulate case scenarios using SCTP and TCP protocols with FTP and HTTP traffi
c.
The ARIES (Advanced Research on Internet E-Servers) Project started in 2000 as part of the Open Systems La
b research activities at the Ericsson Corporate Unit of Research. Initially, the project aimed to find and prototyp
e the necessary technology to prove the feasibility of an internet server that had the guaranteed availability, res
ponse time and scalability using Linux and open-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 servers. 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 dif
ferent applications on our Linux clusters? To answer this question, we started a study investigating the effects o
f IPv6 support on other protocols, such as SCTP. Part of the study is to test applications in SCTP over IPv6. Ho
wever, we did not have the time and resources to set up a lab with multiple nodes and applications that use SC
TP 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 h
elp design and test new internet protocols. New services and protocols present challenges for testing. For insta
nce, quality of service and multicast delivery require large and complex environments. Protocol designers recog
nize the advantages of simulation when computing resources are not available or are too expensive to duplicat
e 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 started primarily for an open-source tool becau
se most of our work targets the deployment of open-source software based on Linux.
Our target application is a real-time network simulation tool that we can use to define the different scenarios. A
very interesting open-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 simulation scenarios. T
he first scenario involves monitoring SCTP traffic between two nodes, and the second scenario looks at the beh
avior of web traffic and web applications over TCP over a six-node network.
The Tool: Network Simulator 2
NS2 is an open-source 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 tha
t 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 p
art 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 o
riginally intended for studying the dynamic behavior of flow and congestion control schemes in packet-switche
d 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 AC
IRI (see Resources). NS2 is available on several platforms such as FreeBSD, Linux, SunOS and Solaris. NS2 al
so builds and runs under Windows.
Simple scenarios should run on any reasonable machine; however, very large scenarios benefit from large amo
unts 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 installing NS2 is straightforward yet lengthy. At the time of writing, the most recent version was
2.1b8. We are interested in the "all-in-one" package because it includes the source code that we want to patc
h in SCTP support.
http://cafe.naver.com/ArticlePrint.nhn?clubid=11416022&articleid=1 2006-11-15

You can download the all-in-one package from the NS2 home page (see Resources) into /usr/src and extract i
t as follows:
cd /usr/src
tar xzvf ns-allinone-2.1b8.tar.gz
cd ns-allinone-2.1b8
Because we want to examine a case scenario involving SCTP, we need to apply the SCTP patch to NS2 from t
he University of Delaware. The patch is available for the NS2 all-in-one 2.1b8 version and can be downloaded
from the Protocol Engineering Lab home page (see Resources). With the Linux patch utility, you can update the
NS2 source code to include support for SCTP by applying the patch:
patch -p0 < ns-allinone-2.1b8.sctp-rel2.2_patch_orig
In the same directory, there is a script named install that will configure, compile and install the required and opt
ional 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:
./install
When the installation process is complete, the following message will appear on your shell
Please put
$CUR_PATH/bin:$CUR_PATH/tcl$TCLVER/unix:$CUR_PATH/
tk$TKVER/unix into your PATH environment; so that
you'll be able to run itm/tclsh/wish/xgraph.
IMPORTANT NOTICES: [...]
Carefully follow all instructions given in the notices. The above-mentioned variables can be updated either by e
diting /etc/profile or changing environment variables directly. In case you updated /etc/profile, you need to sou
rce your new environment for the changes to take effect (i.e., source /etc/profile).
The NS2 validation suite will verify that all protocols are functional. This will fail if the install process was not co
mpleted; however, running validation is optional, and it consumes twice as much time as the compilation and i
nstallation process.
To run the validation suite:
cd ./ns-2.1b8
./validate
Using NS2 to Monitor SCTP Traffic
SCTP is a transmission protocol that was introduced by the IETF workgroup SIGTRAN in October 2000 (RFC 29
60) to allow SS7 traffic over IP. However, since then it has adopted many more uses because of its versatility a
s it also supports multihoming, network congestion control, error-free sequenced delivery and many other optio
ns.
After applying the SCTP patch to NS2 package, a README file is created: /usr/src/ns-allinone-2.1b8/ns-2.1b
8/sctp.README. At the end of the sctp.README file, there is an example script for an SCTP interaction. In the
simulation generated by this Tcl script, you will observe SCTP's four-way handshake as described in RFC 296
0, 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 server.
The original script is hard coded for version 2.1b7a. You need to update few lines to reflect your own setup. Lis
ting 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 en
vironment. Once you update the paths of all used tools, you are ready to start NS2 for a network simulation of
SCTP. To start the simulation, follow these steps:
cd /usr/src/ns-allinone-2.1b8
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 pac
ket traffic. The second window shows the simulation window as seen in Figure 2. The third window is the contr
ol 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 ho
rizontally 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 ret
ransmission similarly to TCP, supporting fast retransmit.
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 ban
dwidth, 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 traffic 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 the
y 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 linked
// together
$ns duplex-link-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
// together 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 init
iate the FTP connection. This corresponds to the stream initiation behavior specified in RFC 2960. The other ev
ent 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 alter our network's bandwidth, the FT
P 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 pac
kets 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). SACKS are sent to acknowledge each packet recei
ved 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 b
ehaves similarly to TCP when it comes to streams. Otherwise, packets could be seen traveling both along the p
rimary 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 nodes:
z node 0 is the client that will request a web page from the web server.
z node 1 is the client's router.
z node 2 is the web cache's primary router.
z node 3 is the web cache's secondary router.
z node 4 is the web cache server.
z node 5 is the web server.
The web cache (node 4) is connected to a web server (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 the 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 conn
ection 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 using the Re-layout function button i
n 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 interesting 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 si
mulation.
NS2 Graphical Editor
If you prefer a graphical interface to setup network simulations, NAM supports a drag-and-drop user interface.
You can place network nodes, link them together and define user agents and their associated application or tra
ffic generator. SCTP is not included in this interface because the patch was specific to NS2 source code, not N
AM. NAM is useful for quickly building a network topology. However, we experienced multiple segmentation faul
ts 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 ./nam. Selecting New in the file menu, you will see the editor window appear. For this example, we a
re 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 cor
rect positions. To link nodes, click on Add link. Select one node and drag-click to the next node to create link.
Next, choose which agents you want to use on network in agent drop-down menu. To add an agent, click on t
he 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 right click on different elements in your to
pology and edit their properties such as color or start and end time for applications. If you get a dialog saying t
hat you must connect your agents, use Add link and connect different agents to simulate your scenario. In cas
e 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.
Conclusion
We decided to test NS2 because of its support of SCTP (which is a requirement for us), graphical representatio
ns, multiple protocols and many other reasons. However, you need to patch the source code in case the proto
col you want to simulate is not supported and live with low-quality 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-on
s. We recommend NS2 as a tool to help understand how protocols work and interact with different network top
ologies.
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 commu
nity.
Acknowledgements
The Open Systems Lab at Ericsson Research for supporting our work with Linux and open-source software.
Resources
Application and Protocol Testing through Network Emulation
(DARPA) VINT Project
Macroscopic Internet Data Measurement and Analysis
NS2 Home Page
NS2 Tutorial
REAL Network Simulator
Scalable Simulation Framework

SCTP Patch for NS2
Stream Control Transmission Protocol
University of Essen and Siemens, SCTP Implementation
David Gordon (davidgordonca@hotmail.com) is finishing his Bachelor's degree in Computer Science at Sherbro
oke University in Quebec, Canada. He is currently an intern in the Open Systems Lab at Ericsson Research and
a member of the IPv6 research group. His interests include internet protocols, networking, cryptography and ne
twork security.
Ibrahim F. Haddad (Ibrahim.Haddad@Ericsson.com) is a researcher at the Ericsson Corporate Unit of Research
in Montreal, Canada, where he is involved in researching carrier-class server nodes for real-time all-IP network
s. He is mainly responsible of the security and IPv6 research activities at the Open Systems Lab.

Network simulator 2 a simulation tool for linux

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Network simulator 2 a simulation tool for linux

Similar to Network simulator 2 a simulation tool for linux (20)

More from Pratik Joshi

More from Pratik Joshi (6)

Recently uploaded

Recently uploaded (20)

Network simulator 2 a simulation tool for linux