Sunteți pe pagina 1din 4

Spring term 2008

TELCOM 2321 - CS 2520


Wide Area Networks

Lab assignment 1
Report due: Friday Mar 7, 2008, 5pm
Groups of up to 3 students are allowed
One report per group is required
Send report to GSA
GSA: Chih-Kuang Lin
Office hours: Fri 12-2pm, 714 SIS
email: chl21+@pitt.edu

1 Introduction
The purpose of this lab assignment is to familiarize with the ns2 network simulator and run a few
simulations of different scenarios. ns2 is a discrete event simulator used to model network protocols on
different environments, such as wired, wireless and satellite networks. It is an open-source software and is
widely used for both educational and research purposes. One of the main advantages of using a network
simulation environment such as ns2 is the ability to test protocol behaviours in situations where a real-life
experiment is difficult or impossible to carry on.
ns2 simulator is based on two languages: C++ as the programming language for the actual simulation
part and OTcl, a scripting language, for the control part. C++ is used for the actual simulations because
it is powerful, efficient and fast to run. On the other hand, OTcl is used to configure the simulation
environment, set the required parameters and control the simulation. This is because the objects used by
the simulator are well established and when the user needs just to put them together to create a simulation
environment and to modify some parameters, it is faster to write and change an OTcl simulation script
rather than modify and recompile the whole C++ simulator code. When additional functionalities are
needed that are not available with standard ns2 objects, a user is allowed to write custom C++ code to
implement new objects to be integrated in ns2. Lab assignments for this course will use the standard ns2
objects, so you are not required to modify C++ code.
You are required to submit a written report by the due date where you must answer all
the questions asked in the following sections. Add any figure, screenshot, script code that
is required or that you consider relevant.

2 How to use ns2 for this lab


In order to use ns2 simulator for the course purposes, you have two choices: either using the School or
Department computing labs or installing ns2 on your own PC. To use ns2 in SIS computing lab, each
student must have an account to access the Sun workstations at the 8th floor. To get a new account please
contact Mark Steggert (mark@sis.pitt.edu). Once you have an account, you can run the OTcl simulation
scripts on each workstation using the ns command. To use ns2 in CS department, you must access the
department compute server (elements.cs.pitt.edu) and compile the software on your AFS space. ns2 is
not supported by the CS technical staff.

1
In case you wish to run ns2 on your own PC, instructions on how to compile and install the simulator
on different platforms are available at http://www.isi.edu/nsnam/ns/ns-build.html
For assistance, please ask GSA Chih-Kuang Lin. Office hours are Fri 12.00-2:00pm at 714 SIS, e-mail
is chl21+@pitt.edu

3 Where to start from


First thing to do is to become familiar with the ns2 simulation environment by learning how to write
simple simulation scripts. A good source of information is Marc Greis’s tutorial, available at
http://www.isi.edu/nsnam/ns/tutorial
Remember that, in order to run an OTcl script, you need to open a system shell and type the ns
command followed by the script file name:

[user@host ns2]$ ns example.tcl

You are required to read sections I to VI of the tutorial and run the proposed scripts. Although the
tutorial scripts are available for download, you are advised to write them step by step while you read
through the tutorial. This will allow you to learn how to prepare the basic script structure, how to build
a topology and set parameters and how to use other useful features.

Question 1 - Report what you have learned about ns2 and what you are able to do at this point.

Question 2 - Write and run a simulation script that simulates a star topology with four edge nodes
(nodes N1 to N4 ) and a single core node (node N5 ). Each edge node is connected to the core node
with a full duplex link, propagation delay is 10 ms for each link. Three CBR-over-UDP sources are
attached to each edge node, so that each edge node sends packets to every other edge node. Each
source generates 200 pps and packets have different size depending on the the destination node.
Sources also start sending packets at different times, depending on the destination. Packet sizes
and transmission start times for each destination are as follows:

Destination Size (bytes) Start time


1 100 0.2
2 200 0.4
3 300 0.6
4 400 0.8

Bandwidth on each link must be set to the value that guarantees maximum link utilization and no
packet losses. Include the script code in your report and justify your choice of the link bandwidth.

4 Using random sources and plotting results


You are now required to read section VIII of the tutorial and run the proposed script. Pay attention to
how you can define an ON/OFF source with exponential random ON and OFF periods. Pay attention
also to the way an OTcl procedure can be defined and called, how numeric expressions are evaluated
with the expr command and how you can collect data and write them to a text file. The tutorial script
generates output text files with the measured bandwidth as a function of the time in two-column format.
This is a general format that can be used with xgraph but also with gnuplot, excel and other software to
generate charts, so you can use the one you like.

2
Question 3 - Report about the simulation you ran and show and comment the graph obtained. Change
the frequency at which the script updates the output files by setting the time parameter in the
record procedure to 2, 1, 0.5 and 0.1. Show the corresponding graphs obtained and add your
comments.
You may have noticed that running the simulation script multiple times always gives the same result.
This is because ns2 generates random variables with a predetermined seed, causing the same series
of events to happen. This behavior can be changed by seeding the random number generator in a
different way. Add the following line at the beginning of the simulation script, immediately after
the new simulator object declaration:

global defaultRNG
$defaultRNG seed NEW_SEED

where NEW SEED is an integer. If NEW SEED is set to zero, the actual seed is not fixed and is set to a
value that depends on the current system time. Run at least 5 different simulations with different
seeds and show the graphs obtained. Add your comments. For further details on the random
number generator used in ns2, refer to section 25.1 of the ns2 manual at
http://www.isi.edu/nsnam/ns/doc/node266.html

5 Dealing with the bandwidth-delay tradeoff


Refer to section 6 of the ns2 manual (http://www.isi.edu/nsnam/ns/doc) for a description of the link
characteristics and to section 38.3 for traffic source characteristics. Now simulate a simplex link be-
tween two nodes, source and destination. The distance between the nodes is 3,000 miles and the signal
propagates at the speed of light.
The source is a CBR over UDP source, sending a single packet of size 62,500 bytes (you need to
set the maxpkts source parameter to limit the number of packets generated). Since the default UDP
maximum segment size is 1000 bytes, you need also to set the packetSize parameter of the UDP agent
to something greater than 62,500 bytes, e.g. 64 kbytes. Refer to section 33 of the ns2 manual for details
about UDP agents.
The destination is a LossMonitor sink that allows to measure also the time the last packet was
received through the lastPktTime state variable. Refer to section 10.8 of the ns2 manual for details
about LossMonitor agents.
The simulation script must write, either to a file or to the standard output, the link bandwidth, the
propagation delay, the packet transmission time, the time the packet was receiced by the LossMonitor
sink, the resulting a parameter. Run simulations for different values of the link bandwidth in the range
where the a parameter (a = 5LC/D) goes from 0.03 to 1.5.

Question 4 - Compute the critical bandwidth of the link and plot the propagation delay, the packet
transmission time and the time the packet was receiced by the LossMonitor sink as a function of
the link bandwidth, using the results from the simulation script. Add your comments and include
the script code in your report.

6 Sharing bandwidth and monitoring queues


In ns2 a generic link from node Ni to node Nj is equipped with a limited queue, whose maximum size
defaults to 50 packets. It is possible to modify the queue maximum size within a script with the following
command

3
$ns queue-limit $ni $nj QUEUE_SIZE

ns2 also provides queue monitor objects that allow the user to monitor what is going on in a queue
between two nodes. Arrivals, departures, drops and queue size in terms of packets and bytes can be
monitored with this object. A queue monitor object named queue mon may be defined as

set queue_mon [$ns monitor-queue $ni $nj [open queue.tr w]]

A queue monitor integrator is an object that computes the integral of the monitored queue size, either
in bytes or packets, and it is useful to monitor the queue status. Such an object for the queue monitor
defined above may be defined as

set queue_pint [$queue_mon get-pkts-integrator]


set queue_bint [$queue_mon get-bytes-integrator]

Further information on queues, queue monitors and related parameters is available on section 7.3 of the
ns2 manual.
You are now required to download and check the OTcl script named queue.tcl from the course web
page and answer the following questions.

Question 5 - Before running the simulation script, draw the topology defined, including sources and
sinks. Then describe what the simulation script actually does.

Question 6 - Run five different simulations where the additional source attached to node 6 is a CBR
source generating 500-byte packets at 100, 125, 200, 300 and 500 kbps. Queue limit on link 2 → 3
must be set to 30 packets. Using the output file produced by the simulation, plot the bandwidth
actually used by the three sources, the packet drop rate and the queue size at the monitored queue
as a function of the simulation time. Use the ”instantaneous” values provided by the simulation
script, computed as short-term averages over each record interval. Include the five graphs in your
report and add you comments.

Question 7 - Now run a number of different simulations, setting the additional CBR source rate to 125
kbps and increasing the queue limit on link 2 → 3 by steps of 50 packets starting from 50. Explain
when and why you can stop increasing the queue limit. Show the graphs and add your comments.

Question 8 - Run more simulations choosing as the additional source an exponential ON/OFF source
first, and then an aggregate of 10 Pareto ON/OFF sources. Set the peak rate to 125 kbps, the
packet size to 500 bytes, the ON and OFF average periods to 0.4s and 0.1s respectively, the shape
parameter of the Pareto sources to 1.2 and the queue limit on link 2 → 3 to 200 packets. Set the
source starting and ending transmission times to 0 and 100 respectively. Run several simulations
and compare the average queue size obtained.

S-ar putea să vă placă și