Analysis of a Network
Simulation Tool for Advanced
Courses in Computer
Communication
Master Thesis
January 2001
Tomas Björnerbäck
Supervisor: Dr. Jerry Eriksson
Author:
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
2
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Abstract
This Master Thesis presents the commercial network simulator OPNET
Modeler1 and examines its suitability for advanced courses in computer
communication at the University of Umeå, Sweden, by modelling and
simulating four different scenarios:




TCP's slow start characteristics and an example of how performance
changes when parameters are changed.
Simulate routing protocols under different circumstances such as link
breakdown and link restart.
Examine how Quality of Service (QoS) affects transfers in packet
coupled (IP) and virtual circuit coupled (ATM) networks.
How background traffic can be modeled in OPNET and what impact it
has on the results.
The examples are rather detailed in order to be helpful for tutors and students
using OPNET in class.
The author of this report found OPNET very suitable for the above mentioned
use, but it is not totally flawless, especially the graphical user interface has
annoying glitches and the price of the program is a bit high for the intended
usage.
A list of exercises suitable for students at the mentioned course is included.
1
OPNET Modeler is a copyrighted trademark by OPNET Technologies, Inc., Washington D.C.,
USA. OPNET is an abbreviation of "The Optimized Network Engineering Tool" and from this
point on referred to as "OPNET".
3
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Table of contents
1
2
3
4
Introduction
Terminology
Requirements on the software
Modeling in OPNET
4.1.1
Modeling TCP's Slow-start
4.1.2
Characteristics of slow-start
4.1.3
Description of the constructed model
4.1.4
Implementation
4.1.5
Results
4.2
Modeling a routing protocol
4.2.1
Selection of routing protocol
4.2.2
Description of OSPF-model
4.2.3
Implementation
4.2.4
Results of OSPF-simulation
4.2.5
Description of IGRP-model
4.2.6
Results of IGRP-simulation
4.2.7
EIGRP
4.3
Modeling Quality of Service (QoS)
4.3.1
Description of the Ethernet-example
4.3.2
Slow link between the routers
4.3.3
Results with a slow link
4.3.4
Fast link between the routers
4.3.5
Results with a fast link
4.3.6
Description of the ATM-example
4.3.7
Results ATM-scenario
4.3.8
Conclusions
4.4
Modeling background traffic
4.4.1
Effects of background traffic
4.4.2
Description of the constructed model
4.4.3
Results
5
Is OPNET suitable at Umeå University?
5.1
OPNET from ground up
5.2
Suitability to examined models
5.3
Overall handling
5.3.1
Pros
5.3.2
Cons
5.4
Final verdict
6
Suitable project in class
6.1
Background
6.2
Examples of easy projects
6.3
Examples of intermediate projects
7
Acknowledgements
8
References
9
Authors' Address
10
Full Copyright Statement
5
6
8
10
11
11
11
12
12
14
17
17
18
19
21
23
23
24
26
27
27
28
30
31
34
35
38
39
39
39
40
43
43
44
45
45
45
47
49
49
49
49
51
52
54
54
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
1 Introduction
Over the last ten years, computers have evolved rapidly and are now used in
almost every office and in lots of homes in the industrial world. A stand alone
computer is very useful for accounting, word processing, game play and so on,
but when you connect computers to each other, huge synergy effects come into
play. You can easily share hardware such as printers, send messages to friends,
search distant databases for information, save money by trading goods and
knowledge over the network, remotely control other computers, play networked
games and so on.
The increased utilization of networks by the increasing number of users
generating ever more traffic have placed increased demands on the underlying
systems, both in capacity and in terms of increased demands for flexibility and
low latency, that has led to an increased complexity of both the networking
hardware and the protocols that carry the information between the nodes.
The complexity and the number of variables are so vast that regular
mathematical analysis is in practice impossible to perform with the needed
degree of accuracy2. The solution has been known in this and in many other
disciplines for several years and it is simulation. Simulation is almost like game
play: divide the big problem into tiny tasks and define rules for the different
tasks, e.g. how they can interact with each other and what and how they can
manipulate different variables. If the rules and tasks are cleverly chosen they
can be put together to construct a complicated system, for instance a network
protocol.
By concatenating bigger pieces, soon you have an entire network and by
assigning start values and for how long the process is allowed to work, a
computer can be made to systematically follow the rules, in OPNET designed as
state transition diagrams, and perform the many tiny tasks that together behave
like the real process. During the simulation, it is wise to follow interesting
variables and save their values in a log for later analysis. This is what OPNET is
all about - simulate a networks' behavior under different circumstances and
analyze the results for easier and faster research and development (R&D) of
new and improved network topologies, protocols etc. to meet the above
mentioned demands on the networks.
This master thesis in computer science will analyze the commercial network
simulation package OPNET and try to find out if it can be used in the higher
level-courses in computer communication at Umeå University, Sweden. No
similar program have been used previously so it is a great honour for the author
to lead the way for coming generations of students.
2
See [Opnet, 634-636] for an in-depth investigation about analytical vs. hybrid simulations.
6
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Using a product like this as a problem-solving tool for exercises in class places
high demands on software, students and tutors. One part of the report will be
dedicated to sorting out what the demands are and how OPNET fulfills them.
The examined scenarios have been carefully selected by the author and the
supervisor to show as many parts as possible of the software while still
maintaining a moderate level of difficulty. They range from modifying the
underlying C-code in the protocols to quality of service (QoS) on different
topologies, routing protocols and finally modeled background traffic.
The supervisor is Dr. Jerry Eriksson who supported and gave guidance during
the writing of this Master Thesis.
The department of computer science at Umeå University sponsored the project
with salary to the author and they bought all necessary software.
7
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
2 Terminology
[Ref, #,#,...]: Describes in what reference (Ref) and on what page(s) (#) the
information is found.
ABR:
Available Bitrate. One of ATMs lowest QoS-levels.
ACK:
A message (acknowledgement) from the receiver to the sender
with information about the successful reception of a certain
packet.
Aggregate:
A collection of items are added together and represented by a
single entity, with the same behavior as the collection.
ATM:
Asynchronous Transfer Mode. A network-type originally intended
for carrying telephone-traffic. Supports a wide range of QoSmethods. Has very small packets and fast switching to decrease
delays.
CBR:
Constant Bitrate. One of ATMs highest QoS-levels.
Flow:
An individual, uni-directional datastream between two hosts or
applications, uniquely identified by a five-tuple: (Transport
protocol, Source address, Source port number, Destination
address, Destination port number).
FIFO:
First-In First-out. A queue-methodology used in many places,
even in the checkout counter at grocery stores.
FTP:
File Transfer Protocol. A protocol dedicated to transferring files
between a server and a client.
ICMP:
Internet Control Message Protocol. A protocol in the IP-family
designed to transfer information between nodes, such as "Host
unreachable" and ping-messages.
IP:
Internet Protocol. A protocol in the transport layer that manages
addressing and encapsulation of data from higher sublayers.
Link:
A physical medium between two points with equipment to send
data between the points at a certain datarate.
Packet:
A piece of data transmitted across a network. It may contain an
entire message or parts thereof and is assembled at the receiver.
Ping:
One of the messages in ICMP. Will measure the time to travel
between two nodes.
8
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Protocol:
An agreed upon form of communication. Syntax, semantic and
physical characteristics of the messages.
Protocolstack:
A hierachy of protocols that simplifies transmission of data by a
modular design which allows access on the different levels. Each
underlying layer encapsulates everything from the higher layers in
a packet with a header and sometimes a trailer.
QoS:
The idea behind QoS (Quality of Service) is to allow different
levels of service to be provided for traffic streams on a common
network infrastructure.
Reliable:
The receiver is guaranteed to get exactly what the sender sent by
calculating checksums and retransmissions. In case of
undeliverable messages, the sender is aware of the failed
transmission by the missing ACK.
Routing:
The selection of path at intersections in a network to get from
point A to point B.
RSVP:
Reservation Protocol. A QoS-protocol that incorporates the routers
along the path in the process of reserving a certain QoS.
TCP:
Transmission Control Protocol. A reliable protocol in the IP-suite
that is very common on the Internet, e.g. all webpages are
transferred over TCP.
ToS:
Type of Service. A field in the IPv4-header with a request of
prioritized handling at different levels. Used in a few QoSprotocols to sort the packet to correct queue etc.
Server-QoS: A service-level a client requests from a server to prioritize the
service from the server. Higher service-level gives faster handling.
Arranged by some kind of queue-system in the server, such as
WFQ.
WFQ:
Weighted Fair Queuing. A queuing-system with several queues
with different priorities. If for instance one has three queues, the
queue with highest priority may be emptied ten times (weight)
before the queue with lowest priority will be emtied once and so
on. It guarantees every queue to get service (fair).
9
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
3 Requirements on the software
Introducing a tool in advanced courses in computer communication is not a very
simple task. The first step is to evaluate different software and select a few
suitable candidates. Before the writing of this master thesis, that selection was
made by the supervisor Jerry Eriksson. Opnet Modeler and Ns/Nam were
selected and the latter evaluated by another student, but with more emphasis on
multicasting in the industry.
The tutors and students using OPNET will need to have a solid base of
knowledge in the area of networking to be able to use and understand any
networking simulator, not to mention to draw any conclusions from the results,
so we concentrate on the software's usability and features:






The tool need to be fully configurable and have support for as many
kinds of different network topologies (IP, ATM, Token Ring, ...) and
networking products (switches, routers, links, ...) as possible, while still
being as easy as possible to learn.
It needs to be able to run on several different platforms, because of the
different computer systems at the university (WinNT, Solaris, HP-UX,
...).
The documentation need to be very detailed and cover all areas of usage
and the support need to be quick at answering and their answers need to
be accurate and precise.
There should be many examples for the students to study and modify.
A large user-base and mailing lists where one can help each other is a
great advantage.
It's very good if the tool is in use in the industry, because many of the
students will end up there and will have an competitive advantage if they
have experience in using the tools.
Let's examine a few examples and evaluate how OPNET suits our needs. The
conclusions will be collected in the chapter 5.2.
10
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4 Modeling in OPNET
In this section, different aspects of OPNET will be examined by showing how it
can be used to solve different problems and what features it has that can
simplify for the user and speed up the runtime of the simulations.
The four examined scenarios have been carefully selected to show as many
different aspects of OPNET as possible and be at a level of difficulty suitable
for the students and tutors at computer communications courses.
4.1.1 Modeling TCP's Slow-start
By using the well-known protocol TCP and examine its behavior during the
initial phase in OPNET, we can learn more about OPNET and perhaps get a
better insight into the complex TCP-protocol.
4.1.2 Characteristics of slow-start
TCP, transmission control protocol, is a reliable protocol. That means that even
if the underlying transport layer, such as IP, is connectionless and lacks error
control, TCP takes responsibility for the data and keeps resending and error
checking the packets until they are securely transmitted, or in case of a broken
link, the transfer is securely aborted and the higher layers are informed of the
abortion [Halsall, 643].
In naive implementations of TCP, the sender receives the maximum sliding
window size from the receiver during connection establishment. In the first
burst, the sender sends that number of datagrams. If an intermediate router is
congested, it will drop packets, hence reduce throughput drastically.
Slow start injects packets into the network at the rate at which the
acknowledgements are returned by the other end by using a congestion window,
cwnd. The cwnd starts at the size of one segment as announced by the receiver.
Ethernet usually uses 1460 bytes as segment size. For each ACK received by
the sender, the cwnd is increased by one segment. This means cwnd doubles
each successful round, which gives an exponential growth. The sender sends
'min(cwnd, sliding window)' number of packets before awaiting more ACKs.
[RFC2001, 1]
11
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4.1.3 Description of the constructed model
Figure 1 is a picture of the setup used in this example. It contains advanced
PPP-links with adjustable speed (10 000 bps and 100 000 000 bps are used) and
in some cases, one of them is loaded to 95% from other traffic in both
directions. The internet-cloud is simply delaying the packets with 0.07 seconds
to simulate a long distance between the endpoints. The client downloads 10 files
à 280 kB per hour from the server via FTP.
Figure 1 Entire scenario for TCP-modification.
4.1.4 Implementation
The idea behind this example is not to redefine the entire complex TCPprotocol, but merely to see how it behaves during the initial phase of a transfer.
We'll examine the bundled Proto-C3 version of TCP and make it give away its
secrets. Open the process model "tcp_conn_v3", press the "HB"-button and add
"static TcpT_Size cwnd_bkup;" in the bottom of the file and save it. Doubleclick the top half of the Init-state and change to the following in the middle of
the file:
/* Initialize the congestion window and slow start threshold values. */
/* (refer page 310 in TCP/IP Illustrated Vol. I by W. Richard Stevens).
/* cwnd = snd_mss; */ /* Don't use this during modified testing */
*/
if (cwnd_bkup < 1)
cwnd_bkup = snd_mss;
cwnd = cwnd_bkup;
printf("** Init: Setting cwnd = %d\n", cwnd);
Double-click on the top half of the Closing-state and Close-wait-state and add
the following in the top of the files:
if (cwnd >= (0.2*cwnd_bkup))
cwnd_bkup = (cwnd/snd_mss)*snd_mss;
The check is there to keep the uplink that only contains control-information
from destroying the settings for the downlink with the large file transfer (or vice
versa). The window is saved in multiples of the Maximum Segment Size by the
integer division.
3
Proto-C is a registered trademark of OPNET Technologies, Inc.
12
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
During the first run we'll now initialize the window as in normal cases and in
the following runs it will be initialized to the value which is more adapted to the
speed and traffic on the link. It will avoid the slow-start growth of the windows
and probably decrease the number of round trips added to the total time, thereby
decreasing the TCP-delay.
We also have to adjust in three other places of the code. Press the "FB"-button
and modify to the following:
In static
void tcp_timeout_retrans (void):
/* Set the slow-start threshold to half the current window */
ssthresh = (MIN (snd_wnd, cwnd)) / 2;
if (ssthresh <= 2.0*snd_mss)
ssthresh = 2.0*snd_mss;
/* cwnd = snd_mss; */ /* Disable this line*/
In static
void tcp_una_buf_process (void):
/* If no data is in transit and nothing's been sent */
/* for a long time, slow-start to avoid congestion. */
if (snd_nxt == snd_una && (op_sim_time () - last_snd_time >
current_rto)){
/* Reset the congestion window to one segment. */
/* Note that no segment has been dropped, so */
/* the current cwnd may be a reasonable slow- */
/* start threshold value.
*/
ssthresh = MAX (cwnd, ssthresh);
/* cwnd = snd_mss;
*/ /* Disable this line */
In static
void tcp_snd_buf_process (void):
/* If no data is in transit and nothing's been sent */
/* for a long time, slow-start to avoid congestion. */
if (snd_nxt == snd_una && (op_sim_time () - last_snd_time >
current_rto)){
/* Reset the congestion window to one segment. */
/* Note that no segment has been dropped, so */
/* the current cwnd may be a reasonable slow- */
/* start threshold value.
*/
ssthresh = MAX (cwnd, ssthresh);
/* cwnd = snd_mss; */ /* Disable this line */
When all changes are saved, it is just to compile the process model by pressing
the Compile-button (on the Windows-platform, Visual C++ 6.0 is needed).
Printf() and similar works after editing the Preferences and setting "Console =
True" and restarting Opnet Modeler.
13
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4.1.5 Results
In Figure 2 and Figure 3 it really shows that the four scenarios with modified
TCP have larger congestion windows. Figure 4 and Figure 5 shows how the
server keeps track of the receive window of the client. 65535 is the largest size
supported and the only big drop from that size is for the 100 Mbps-link with
background-traffic.
The expected decrease in TCP-delay is only apparent in Figure 7. Probably the
slow link in Figure 6 is preventing the packets from getting any lower delays
than they already have.
The most interesting results are in Figure 8 and Figure 9 where the actual
amount of data transferred is plotted. First, there are two groups, one from the
slower link and one from the faster. It is difficult to extract any concrete
conclusions from that graph. The modified protocol is best on the unloaded 100
Mbps-link and worst when it was loaded and it was even more of a tie on the 10
kbps link. The author chose not to copy the legends into the graphs, because it
will clutter the graph even more. Study the graphs in color.
The conclusion is that we lowered the TCP-delay, but did no measurable
difference in transfer speed.
Figure 2 Size of Congestion Window in bytes,
10kbps link.
14
Figure 3 Size of Congestion Window in bytes,
100Mbps link.
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 4 Size of Remote Receive Window in
bytes, 10kbps link.
Figure 5 Size of Remote Receive Window in
bytes, 100Mbps link.
Figure 6 TCP-delay, 10kbps link.
Figure 7 TCP-delay, 100Mbps link.
15
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 8 FTP-traffic received, all scenarios.
16
Figure 9 FTP-traffic received, integrated
amount of transferred data.
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4.2
Modeling a routing protocol
The Internet Protocol (IP) cannot find by itself the path through a network with
routers. There are several different protocols in Table 1 helping IP determine
suitable routes for the packets. Each routing protocol has its own area in the
network and route redistribution takes place on the borders in order to exchange
information between the protocols and areas [Opnet, 604-605]. The traffic
generated by the routing protocols is called routing overhead and must be kept
at a minimum, since it uses valuable capacity on the links.
OSPF
IGRP
BGP4
X
X
X
X
X
X
(X)
IBGP4
X
X
X
X
X
X
X
?
?
X
X
X
Cost based
on
Dynamic
Cost
X
Static Cost
Border
Gateway
Multiple
paths to
destination
.Load
Balancing
X
Interior
Gateway
Distancevector
RIP
Link State
Protocol
We will use ideal links, without packet loss, to keep complexity of the exercise
within reasonable bounds.
Hopcount
Statically
assigned
Linkattribute
Statically
assigned
Table 1 Routing protocols and their capabilities [Opnet, 604-605].
4.2.1 Selection of routing protocol
We will examine two routing protocols from Table 1. The ICMP's "ping" with
the "record route" option will show the changes in routes during the simulation.
The scenario is depicted in Figure 10 and we want to see how the chosen
protocols handle a link failure and a link restart. We also will try to find out
what the practical differences are between a distance-vector protocol and a link
state protocol. In theory, a distance-vector protocol periodically (every 30
seconds) exchanges distance-vectors with all its neighbors, containing estimated
path costs to all networks. If a link fails, it often takes a long time for the
updates to propagate through the network. Link-state routers determine the link
cost for all interfaces and advertise them to all other routers. If a link cost is
changed, for example by a failure or addition of a link, the router immediately
advertises the new set of link costs to all routers. Because all routers receive all
information, they can reconstruct the entire topology and calculate the shortest
paths to all destinations. This gives faster updates and more efficient routing,
but the flooding from the routers may generate a lot of traffic [Stallings, 408416].
17
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
RIP does not scale well and is normally only used in small networks, which may
be a part of a larger network. It is simple to configure and is the default protocol
on most routers in OPNET, but the lack of multiple paths to a destination and
inability to work as a border gateway makes it uninteresting for this exercise.
IGRP is similar to RIP but it has support for both multiple paths and load
balancing, hence IGRP is our choice of distance vector protocol.
BGP4 is, in this exercises aspects, quite similar to OSPF but is mostly used on
border gateways so the comparison may be too difficult with IGRP, hence we
select OSPF as link state protocol.
4.2.2 Description of OSPF-model
The bundled example "Routing" is an excellent starting point for this exercise.
Open it. From the Scenarios-menu, we'll use the OSPF- and IGRP-scenarios
with some modifications to create the link failure and the link recovery. Ping
with record route is used to track the events in the network throughout the
simulation.
Initially the OSPF-scenario looks like Figure 10.
Figure 10 OSPF initially. Traffic will flow from Northberg to Eastber. The link between
Backbone router 2 and 4 will fail after 500 seconds and recover after 1000 seconds.
The ping-traffic will originate in the Northberg-subnet and have the Eastbersubnet as target and the link failing and recovering is the one between Backbone
Router 2 and Backbone Router 4, because initially the traffic between Northberg
and Eastber travels that link, as will be shown.
We'll also keep track of the dropped packets. One probe in Northbergs router
and one in Backbone router 4 will collect information about that.
18
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4.2.3 Implementation
First of all, save the entire project as <name>_Routing so the bundled version
won't get destroyed and all your output will end up in your mod_dirs (editable
in
Edit->Preferences. The first entry in that list is where your files will end up).
Click the Object palette-icon and select Utilities from the drop-box. Drag one
Failure Recovery-icon and one IP Attribute configuration icon to the subnet
looking like Figure 10. The former controls the link failure and the latter enables
us to activate Record Route for the Ping-command:







Select Edit Attributes on the IP Attribute configuration and select Edit on
IP Ping Parameters. Edit the Details and select Enable on Record Route.
Select the link between Router 2 and Router 4, right-click and select Edit
Attributes. Select the Name and copy (Ctrl-c) the link's name.
Select Edit Attributes on the Failure Recovery-icon and select Link
Failure/Recovery. On Rows, select two. Paste the Name (BACKBONE
ROUTER 4 <-> BACKBONE ROUTER 2) on both rows. Enter Fail at time
500 seconds in first row and Recover at time 1000 seconds in the second
row.
In order to find out the IP of the intended destination of the Ping-traffic,
Eastber.PARAM, run a simulation with IP Interface Addressing Mode set
to Auto-addressed/Export (see Figure 11). The output file after the run
will be in your op_dirs-directory, called <name>_Routing-OSPFip_addresses.gdf and is a regular text file. Search for "# Node Name:
Enterprise network. EASTBER.PARAM" and copy the IP Address
(192.0.26.2 in this case).
Open the Northberg subnet and edit the Router's attributes. On IP Ping
Traffic, make four rows as in Figure 12 with the above IP as Destination.
Return to the main network.
Right-click on a free area of the "background" and select Choose
Individual Statistics. Select
Global Statistics->OSPF->Traffic Sent (bits/sec),
Node Statistics->OSPF->Traffic Sent (bits/sec),
Node Statistics->OSPF->Traffic Received (bits/sec) and
Node Statistics->IP->Traffic Dropped (packets/sec).
Run a simulation. Select 1500 seconds as duration, 128 as seed, 100
values per statistic, 1500 as OSPF stop time or disable OSPF Sim
Efficiency because it can't update the links after the OSPF stop time,
Auto Addressed as IP Interface Addressing Mode, OSPF as IP Dynamic
Routing Protocol. The simulation will take about 60 seconds and
consume about 100 MB of RAM.
19
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 11 IP Interface Addressing Modes.
Figure 12 IP Ping Traffic Table.
20
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4.2.4 Results of OSPF-simulation
There are two different places to examine the results of the simulation: the
simulation log and the simulation results. In the simulation results, examine
Global Statistics->OSPF->Traffic Sent (bits/sec), Object
Statistics->Enterprise Network->BACKBONE ROUTER 4 <-> BACKBONE
ROUTER 2 [0]->point-to-point-> <select both throughput-statistics here>.
The resulting graph can be examined in Figure 13, where the upper two graphs
shows the lack of traffic during link failure and the bottom graph shows the
OSPF-traffic. Notice the initial flooding and the two tops where traffic is
increased after link failure and after link recovery when the routers notice
changed link costs as mentioned earlier. Figure 14 only shows the dropped pingpacket at 10 seconds. The rest of the time all packets are safely delivered, thanks
to the rapid update of the routing tables.
Figure 13 Statistics of OSPF failure/recovery.
Figure 14 Dropped packets for OSPF-scenario.
In the simulation log the result of the Ping-traffic is collected. Open it by right
clicking in a free area of the main network and select View Simulation Log.
There are four rows of interest for us and they are at times (leftmost column):
10, 400, 700 and 1200 seconds.
21
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001


At 10 seconds the network has just started. The routers are busy trying to
exchange information regarding what router can access what hosts with
the currently used OSPF-protocol. The result of a Ping to a remote
network is: "The IP routing table on this node does not have
a route to the destination 192.0.26.2. The corresponding
IP datagram [ID 58, Tree ID 58] is being dropped.".
At 400 seconds, the routers have stabilized and are only sending updatetraffic to each other and serving all applications using the network. The
result of a Ping goes through routers 2 and 4 in the backbone:
192.0.7.2
192.0.5.1
192.0.11.1
192.0.26.1
192.0.26.2
192.0.11.2
192.0.5.2
192.0.7.1

network.NORTHBERG.ROUTER
network.BACKBONE ROUTER 2
network.BACKBONE ROUTER 4
network.EASTBER.ROUTER
network.EASTBER.PARAM
network.EASTBER.ROUTER
network.BACKBONE ROUTER 4
network.BACKBONE ROUTER 2
At 700 seconds, the link between router 2 and 4 has failed and the
OSPF-protocol has negotiated new links to the destination (as seen in
Figure 13). A Ping during these condition renders traffic via routers 1, 3
and then 4 (the seed during the simulation and a few other parameters
may change the route to 2, 3, 4 etc.):
192.0.1.2
192.0.0.1
192.0.8.1
192.0.11.1
192.0.26.1
192.0.26.2
192.0.11.2
192.0.8.2
192.0.0.2
192.0.1.1

Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
network.NORTHBERG.ROUTER
network.BACKBONE ROUTER 1
network.BACKBONE ROUTER 3
network.BACKBONE ROUTER 4
network.EASTBER.ROUTER
network.EASTBER.PARAM
network.EASTBER.ROUTER
network.BACKBONE ROUTER 4
network.BACKBONE ROUTER 3
network.BACKBONE ROUTER 1
Finally at 1200 seconds, the link has recovered and more OSPF-traffic
has recreated the ability for traffic to flow via that link and a Ping will
render traffic via routers 2 and 4 again:
192.0.7.2
192.0.5.1
192.0.11.1
192.0.26.1
192.0.26.2
192.0.11.2
192.0.5.2
192.0.7.1
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
Enterprise
22
network.NORTHBERG.ROUTER
network.BACKBONE ROUTER 2
network.BACKBONE ROUTER 4
network.EASTBER.ROUTER
network.EASTBER.PARAM
network.EASTBER.ROUTER
network.BACKBONE ROUTER 4
network.BACKBONE ROUTER 2
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4.2.5 Description of IGRP-model
For simplicity, we'll use the same model as in the OSPF-simulation. Duplicate
the scenario in the Scenarios-menu and make sure the new scenario is selected.
One simple way of changing routing protocol in the entire model is in the Rundialog->IP Dynamic Routing Protocol. Make sure the selected protocols'
Sim Efficiency is disabled. Another way is to explicitly change the routing
protocol on wanted router ports: Select the router, Edit properties->IP
Address Information -> select wanted routing protocol on suitable ports.
Look last in the View Node Description for a mapping between the router's
port and -number in the list.
Remember to change in the simulation results to Global Statistics->IGRP
->Traffic Sent (bits/sec) and Traffic Received (bits/sec).
4.2.6 Results of IGRP-simulation
A simulation with IGRP takes about 60 seconds and the graphs looks like
Figure 15. Unfortunately, IGRP run into some kind of problem during the link
failure and no traffic is re-routed, which is reflected in the Simulation Log:
At 725 seconds:
The IGRP timeout timer for the following route entry has
expired: Destination address: 192.0.1.0 Next address: 192.0.5.1
This means that no routing updates for the route entry have been
received for the duration set by the "IGRP Timeout Value"
attribute.
At 819 seconds:
The IP routing table on this node does not have a route to the
destination 192.0.18.2.
At 1005 seconds:
The IGRP flush timer for the following destination entry has
expired: Destination address: 192.0.3.0 This means that the all
route entries to this destination are deleted from the routing
table.
At 1200 seconds does the ping get through via routers 2 and 4, but the
background HTTP-traffic is still having problems.
IGRP does not handle this kind of network and failure very well, which can be
seen in Figure 16 where many packets are dropped during the link failure, in
addition to the dropped initial ping packet at 10 seconds. This strengthens the
theories about very long propagation time for information about a failed link for
distance-vector protocols. Figure 16 also shows how much and often the updates
are sent to the neighbors.
23
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 15 IGRP graphs.
Figure 16 Dropped packets for IGRP-scenario.
4.2.7 EIGRP
The interested reader may try using EIGRP instead of IGRP. It is a Ciscoprotocol with very fast (0.001 seconds in the above case) convergence, load
balancing and several other interesting features. It handles the above network
very well. There is a bundled example in OPNET using EIGRP that shows its
potential.
24
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
25
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4.3
Modeling Quality of Service (QoS)
A big problem in today's network in general and on Internet in particular is the
combination of "first in first out" (FIFO) manner in which packets are
transferred and packet dropping due to buffer overflow by traffic exceeding the
capacity of the network. The latter was introduced in order to avoid denial of
service by gracefully degrade the service [Stardust]. The only way to guarantee
a certain QoS with FIFO is by heavily over-dimensioning the links. It is a very
expensive method and not very wise in all situations - some routing protocols
may route more and more traffic to the "fast" link, thereby saturating it so the
QoS can't be maintained anyway. The variable delays in even an unloaded IP
network may also adversely affect real-time applications [Stardust].
There are a number of ways to achieve QoS, for example by maintaining and
manipulating several FIFO-queues with different priorities (differentiated
services) in the routers. Incoming packets are sorted to the different queues,
depending on their traffic class, parameters (such as the IP-header's Type of
Service field), sender or destination. The queues are emptied for example in a
weighted round-robin fashion in order to treat certain packets better than other
packets [RFC2474, 3, 14].
Another way to achieve QoS is by utilizing a reservation (integrated services) in
conjunction with a flow: a host negotiates with the closest router, the router
negotiates with the next router and so on along the path and all of them enter a
contract about a certain QoS and delivers the answer with a returning message.
The sender sends a flow tag on all packets so the routers quickly can recognize
them and keep their part of the contract. The routers must be careful not to enter
contracts that together exceed its capacity or the sender won't get the agreed
capacity [RFC2205, 3] and the sender must be aware of the routers' right to drop
packets if they arrive in a different manner than agreed upon in the contract.
The QoS architects should follow the principle of leaving complexity on the
edges, and keeping the network core simple. Multicast is a fundamental feature
in a QoS protocol, but it is a complex matter [Stardust].
Off-the-shelf, OPNET supports five different QoS policies [Opnet, 620]:





Reservation Protocol, RSVP
Committed Access Rate, CAR
Custom Queuing, CQ
Priority Queuing, PQ
Weighted Fair Queuing, WFQ
26
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Since the exercise is a comparison between QoS for packet coupled networks
(IP over Ethernet) and switched virtual circuit networks (IP over ATM), RSVP4
would be the most interesting because it is run directly above IP. It means that
all nodes with an IP stack support RSVP, even ATM nodes [RFC2379, 1] and
RSVP has a high QoS-level [Stardust, table 1], but unfortunately the tested
version of OPNET (6.0 L) lacks RSVP on the clients as [SNA, 2] describes, so
all QoS-examples are based on just WFQ and ToS instead of WFQ and RSVP.
4.3.1 Description of the Ethernet-example
In Figure 17 the Ethernet-example is depicted with clients and router spread
across California while the server and router are in the Dallas-Forth Worth
metroplex in Texas. All clients are accessing the server via FTP and each is
downloading on average 240 files of about 1 MB per hour, which in total is
about 210 kB/s, or 2.1 Mbps.
Client_0 has ToS=0 (Best effort), Client_2 has ToS=2 (Standard effort) and
Client_6 has ToS=6 (Interactive Voice). The goal of the example is to show
when QoS is needed and how it affects the traffic.
4.3.2 Slow link between the routers
In this first example, the link between the routers is an E1-link (2.048 Mbps),
which pretty well coincides with the 2.1 Mbps traffic generated by the three
clients. All other links are 100 Mbps Ethernet-links and should not affect the
traffic at all.
The clients wait initially 100 seconds before sending any data so the routers can
establish contact and exchange routing information.
4
Read [Stardust, RSVP] for an excellent explanation of RSVP
27
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 17 QoS experimental setup.
The animation-viewer will be used in this example to find out if and why there
are differences in queuing-delay between the two scenarios. A right-click on the
background and enabling of "Record Animation" is needed for that. After the
simulation, we'll select Results -> Play Animation and examine the animations
to 4:40 minutes. It is possible to open both animations at the same time and
compare them in real time. Unfortunately, the animation-viewer is very crude
and lacks the ability to fast-forward to interesting situations, so it takes about
one hour to get to 3:00 total time at highest speed.
4.3.3 Results with a slow link
In Figure 18 and Figure 19, the reader can see how the link between the routers
is utilized from Texas to California and how the queues are affected by the QoS.
The link is used to 100 % on several occasions in both scenarios, which is
expected from the heavy load. More striking is the difference in behavior of the
point-to-point queuing delay. In the case without QoS, it early builds up a half a
second delay and reaches a peak of over two seconds during the long period of
100% utilization, after which it decreases down to about a half second again.
The QoS-scenario immediately reaches 0.006 seconds of delay and keeps it
there during the entire simulation.
The reason for this behavior can be discovered by tedious examination of
animations of the traffic in the animation viewer. The traffic patterns are very
similar in all respects, except for the QoS-scenario's initial (when the traffic
starts after 100 seconds) very intensive traffic. After 7 seconds of traffic, QoS
has 1800 as packet number while non-QoS only has 580. The difference keeps
growing until the difference is about 2500 packets after 10 seconds of traffic.
This difference is
28
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
maintained until about 3 minutes of traffic (4:40 total time) when non_QoS
decreases its queuing delay, hence decreases the difference.
This difference in packet-numbers does not seem to depend on a faulty
configuration, because the QoS is a "duplicate scenario" of the no_QoS-scenario
and the only difference between them is WFQ respectively FIFO as IP Queuing
schemes. It may be a result of buffer-management in the routers: in no_QoS the
router seem to buffer 0.5 seconds of data which increases if a bottleneck occurs,
while the QoS-configured router seems to dispatch the data immediately with
only management overhead.
The big difference between traffic with different QoS can be seen in Figure 20
and Figure 21. Without QoS, all traffic is competing for the available resources
under equal conditions (FIFO) and the variations between the flows are
minimal. They get on average the same capacity and the same delays - from 20
seconds to a peak of 40 seconds.
With QoS, the traffic is divided into different groups with FIFO-behavior within
the group but with more advanced management between the groups, as can bee
seen in the latter figure: Client_6 who has traffic with high priority maintains a
steady 10 seconds delay. This increased degree of service can only be achieved
at the expense of another flow because of the limited maximum capacity;
Client_2 has somewhat higher delays, but still lower than those in Figure 20
without QoS do. The big loser is Client_0 who only has a contract for
background traffic, hence is almost only allowed access to the link when the
other clients aren't using it. During the period of 100% utilization, it is almost
totally denied access to the link according to the linearly increasing delay-plot
between 18 minutes and 25 minutes in Figure 21.
Figure 22 is interesting. It shows total average delays for each scenario and the
QoS-scenario has worse average response-time than the one without QoS,
because of the very high delays Client_0 suffered in the QoS-scenario. If
Client_0's traffic only contains delay-independent traffic, such as News or Email, it is fully acceptable because both Client_2 and Client_6 received much
better delays than their peers without QoS did.
29
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 18 Point-to-point utilization and
queuing delay, No -QoS-scenario.
Figure 19 Point-to-point utilization and
queuing delay, QoS-scenario.
Figure 20 Average FTP response time, no-QoS. Figure 21 Average FTP response time, QoS.
Figure 22 Average FTP response time, QoS vs
no_QoS.
4.3.4 Fast link between the routers
30
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
In the above example, the link between the routers was saturated several times
during the simulation and there were big differences between traffic with QoSrouting and traffic with only best effort routing. What will happen if we heavily
over-dimension the link instead? Are there still big differences? What happens
if we add 80% background traffic on the fast link?
The link between the routers is upgraded from an E1-link at 2.048 Mbps to a
DS3-link at 44.736 Mbps, or about 22 times faster. With 80% background
traffic, 8.95 Mbps is still available - still a four-fold increase from the E1-link.
This setup should give us interesting results compared to the previous example.
We will avoid using the link to 100%, or even near that, thereby trying to get
low delays and high throughput for all clients, with or without different levels of
QoS, hence trying to verify the statement from [Stardust] mentioned a few
pages ago: "The variable delays in even an unloaded IP network may also
adversely affect real-time applications".
4.3.5 Results with a fast link
Figure 23 through Figure 24 compares the link queuing delay between the
routers from the server to the clients. In Figure 25 the high delays (0.3 to 1.5
seconds) are discussed in the previous example.
Without background traffic, the delays for the fast link with QoS are
significantly lower in both cases. The fast link without QoS has four times
higher delays, 0.0015s compared to 0.0004s, and additionally the delays are
much more varied which may cause problems in real-time applications. The
slow link with QoS has 15 times higher delays at 0.0058s. We state that big
decreases in queuing delay are made with a faster link, both with and without
QoS under unloaded conditions, but they are significantly lower and more
constant with QoS, hence [Stardust]'s statement seem correct.
When adding 80% background traffic the picture gets quite different. The fast
link is nowhere near saturation, still performance drops rapidly! Comparing
Figure 23 and Figure 24, the average delay is about 0.006 for all cases (slow
link with QoS and fast link with and without QoS). This is the nightmarescenario after installing a 22 times faster link: with bad router configuration,
more traffic is routed through the new and fast link and no performance gain is
achieved.
Figure 26 shows how both the fast and the slow link are utilized with and
without QoS (graphs for the fast link are identical). It clearly shows how
insufficient an E1-link is for this load - peak values of the load are about twice
its capacity.
31
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 23 Link queuing delay with QoS.
Figure 24 Link queuing delay without QoS
(zoomed).
Figure 25 Link queuing delay without QoS.
Figure 26 Link throughput.
Comparing differences in average response time for the traffic, we examine
Figure 27 through Figure 32. The left column contains graphs from the
scenarios without QoS and they look very similar. The right column contains
those from the QoS-scenarios. Each row has the clients with matching levels of
QoS.
Traffic on the fast link has in all cases delays of about 9.5 seconds, while traffic
on the slow link at best has about 10 seconds of delay, but peaks that are tenfold higher.
The conclusion is that it is possible for a slow link to give similar average
response time for traffic with high QoS-level, but only if there is capacity
enough to fit that traffic on the link. It gives performance that is more constant
when the link never is saturated.
32
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 27 No QoS, Client_0.
Figure 28 With QoS, Client_0.
Figure 29 No QoS, Client_2.
Figure 30 With QoS, Client_2.
Figure 31 No QoS, Client_6.
Figure 32 With QoS, Client_6.
33
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4.3.6 Description of the ATM-example
ATM and Ethernet/IP differ fundamentally. ATM has very small packets of
constant length (53 octets) that are extremely fast to route through the network.
ATM's design goals have been low delays and low latency, because it was
originally intended for carrying telephone traffic. Ethernet/IP on the other hand
have evolved mostly by accident from the old Aloha Net and ARPANET. It has
variable length packets that demand quite a bit of processing in the routers
before they can be successfully routed. The packets are much larger, about 1500
octets, which gives less percentual overhead but may increase delays. The big
differences will make a direct comparison between them very hard so they will
be compared at a conceptual level.
The setup for the ATM-simulations can be seen in Figure 33. It is quite similar
to the Ethernet-simulations, but has 3+3 clients with the first group having
"constant bitrate" (CBR), which is the highest QoS-level, and the second group
having "available bitrate" (ABR), which is the lowest QoS-level.
The members of the two groups are all downloading 240 files of size about 1
MB per hour, but they have also different QoS-requests to the server in order to
possibly get different QoS from the server. This should give us twice the traffic
on the link compared to the Ethernet-scenario.
In the first run, the link between the routers is unloaded and in the second run it
is loaded to 90% with background traffic. The idea behind that traffic is to
analyze the traffic's behavior during saturation of the link. In both runs ATM
ABR parameter is set to "ERICA, no VSVD" as feedback scheme.
The ATM-simulations are very slow compared to the Ethernet-simulations. 30
minutes of the latter took 17 minutes of runtime while it took 500 minutes of
runtime for the former. The large amount of small packets is probably the
reason for this, because each packet generates interrupts whenever it travels
inside the network and the computer running the simulation has a limited speed
of handling those interrupts, in this case about 15 000 interrupts per second.
34
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 33 Node placement, ATM-example.
4.3.7 Results ATM-scenario
First a small comparison between Ethernet and ATM: in Figure 34 the average
download response time is plotted. It is a factor ten lower in ATM than in
Ethernet. The links are in both cases T3-links (44.736 Mbps) and the load in the
ATM-scenario is actually twice as high as can be seen in Figure 36, because of
the doubled number of clients as mentioned previously. It can be concluded for
both scenarios that the response time will increase slightly when the link is more
loaded.
Figure 38 shows how much the link between the router is utilized in the two
runs. In the first run it is relatively unloaded - about 10% of available capacity and in the second run the 90% added background traffic makes the link
saturated on a few occasions, which probably is part of an explanation to the
increased response time in Figure 36.
In Figure 35 and Figure 39 the three ABR-clients' download response time are
compared with and without background traffic on the link. As expected, the
time is increased, from about 0.9s to 1.4s, when the link is loaded. No
conclusions can be drawn from the treatment of clients with high QoS-level
from the server compared to clients with low QoS-level, but it may be a
configuration error since no setting have been changed on the server to take
QoS into account.
35
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
In Figure 37 and Figure 40, the three CBR-clients' download response time are
plotted under the same conditions as above and we see the same behavior - a
increase from about 0.9s to 1.4s when the link is loaded.
Comparing within each run gives more unexpected results - the performance in
both cases is practically identical for the CBR-clients as for the ABR-clients.
This simulation would suggest the different levels of QoS within ATM are
useless. That is not the case as has been seen in other simulations. The reason
for this behavior is still unknown.
Figure 34 Average download response.
Figure 35 ATM ABR download response time.
36
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 36 FTP traffic.
Figure 37 ATM CBR download response time.
Figure 38 Link utilization.
Figure 39 ATM ABR download response time
with BG-traffic.
37
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 40 ATM CBR download response time
with BG-traffic.
4.3.8 Conclusions
QoS is necessary in most networks to differentiate between different kinds of
traffic. A few parameters can be improved by simply increase the available
capacity of the links, but is often very costly and the simulations above have
showed little or no improvement in delay when the fast link is normally loaded,
compared to a QoS-solution on a slower and cheaper link. Traffic with high
QoS-value can easily cut queuing delays and response times in half compared to
traffic without QoS on an unloaded fast link.
In every simulation, traffic with QoS has performed very well within its
category. Traffic with "background"-quality may have high delays and low
throughput, but those parameters are obviously not important for that traffic and
it makes room for significant improvements for other kinds of traffic.
The coins downside is the needed increase in complexity, both in the network's
infrastructure, such as routers, and in assigning QoS for different applications
while still avoiding greedy users from trying to increase all their traffic to the
highest QoS-level, thereby ruining the entire concept.
38
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
4.4
Modeling background traffic
OPNET is a software package intended for production-level simulations and has
the ability to simulate very small networks and vast networks with tens of
thousands of users, spanning across the Earth or even to interstellar satellites.
The size of the network is generally static during the simulation, but the
generated traffic of a large system may vary wildly during the course of
simulation. Each packet in transit occupies a certain amount of memory and
generates events (interrupts) each time it flows from layer to layer or between
nodes. Under heavy traffic, the memory consumption easily goes beyond
several gigabytes, which in conjunction with the enormous amount of generated
events, places a great burden on the workstation running the simulation.
To solve this problem, background traffic was introduced. It maintains the
behavior of the packets, but doesn't require huge amounts of memory and CPU
time [Opnet, 633] and it simplifies the construction of a large network.
There are two kinds of background traffic in OPNET; background utilization
traffic is the traffic on a single link, background routed traffic is traffic
originating at a source node with one or several nodes as destination [Opnet,
359].
4.4.1 Effects of background traffic
Traffic other than the one studied in a network will in several different ways
affect the studied traffic, for instance it will increase delays over saturated links,
increase packet drops, increase response time and so on, hence it is often vital
for the correctness of the results to include all traffic in the studied network.
4.4.2 Description of the constructed model
In OPNET the background traffic is simulated above the IP layer, hence
switches and hubs are incapable of handling it, which we have to bear in mind if
those components are part of the network or if the topology changes during
simulation. We have to specify end-to-end traffic instead of component-bycomponent background traffic [Opnet, 640] if the effect on those components is
to be included in the results.
In Figure 41 the entire scenario is depicted. There will be three runs, one
without background traffic, one with 40 Mbps traffic over the link marked "A"
and lastly one with 40 Mbps of traffic routed from BG_traffic_node to the
FTP_server, marked by an arrow near "B". To spice up the model, an IP-cloud
is introduced that all traffic need to pass through. It will both delay all packets
0.001s and discard 1% of all packets. This is like using a real Internet - it takes a
while to get across and a few packets don't make it to the destination by
different reasons.
39
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 41 Background traffic scenario.
4.4.3 Results
By studying Figure 42 and Figure 43, we can see the difference between routed
traffic and background traffic on a bi-directional link. The former only generates
traffic in the direction entered in the Traffic Browser (Figure 47, found in the
Network-menu) that affects all nodes along the path and the latter, on a bidirectional link, generates traffic in both directions, but only on the link.
Another difference can be seen in Figure 45 where the Ethernet delay of the
FTP_Server is plotted. The routed traffic will create activity, even though the
server don't explicitly handle the traffic, that will increase the delays to almost
three times higher than without routed traffic.
From the "classical" graph in Figure 44, there are no conclusions to be drawn
whether one form of background traffic is better - the delays are practically
identical.
Figure 46 contains a plot over the average number of packets dropped in the
simulation. It was set to drop around 1% according to a normal distribution. One
could analyze what impact different delays and percentage dropped packets
gives, but that is for another exercise.
All simulations took between 15 and 20 minutes to execute.
40
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
Figure 42 Link utilization Cloud->Router_2.
Figure 43 Link utilization Router_2->Cloud.
Figure 44 Average response time.
Figure 45 Ethernet delay at FTP_Server.
Figure 47 Traffic Browser.
Figure 46 Dropped packets.
41
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
42
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
5 Is OPNET suitable at Umeå University?
5.1
OPNET from ground up
OPNET is a very advanced tool for simulating networks. It can be used on
several platforms and models imported and exported between them. OPNET can
also be extended with several different modules [Opnet.com]:



A radio-module for simulating radio-LANs, cellular phones and even
satellite communications.
A multiprocessor module, for the ability to run simulations on several CPUs
at once, to decrease the wall clock time of the simulation process.
A module for import of traffic data from real networks from several
different commercial probe-packages.
Because OPNET uses a hybrid between analytical modeling (formulas for
utilization and latency in all components) and explicit modeling (actually
sending virtual packets through virtual protocol stacks and across virtual links),
it is easy to model the problem and receive accurate results.
Bundled with OPNET are models of lots of commercially available equipment,
such as routers, switches, bridges etc that easily can be used as building blocks
in the simulations. It is possible to change certain parameters on all products,
but they are divided into three classes of objects: standard, intermediate and
advanced that denotes how many and what parameters can be changed. E.g.
intermediate or advanced routers are needed to access OSPF on their ports
[Opnet, 606].
To facilitate the choice of router they are, in addition to their normal trade
names, described according to their interfaces. For instance Cisco's 7507 router
is called "CS_7507_7s_e6_f_fe2_fr4_sl4_tr4" which means it has 7 slots that
can be populated by cards with 6 10BaseT Ethernet ports, 1 FDDI port, 2 Fast
Ethernet ports, 4 Frame Relay ports, 4 IP serial interfaces (PPP) and 4 Token
Ring ports. More information is always listed in the description, accessible by
right clicking on the object.
The author has thoroughly used Opnet Modeler 6.0 patch level 12, but version
7.0 has been on the market for about 6 months and there are also several patch
levels available for that version. The newer version is included in the package
the University has bought and it is highly recommended to always use the latest
version, because the Opnet Helpdesk (accessible via e-mail) are using the latest
version and the older versions can not very often import projects made in newer
versions.
43
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
5.2
Suitability to examined models
OPNET Modeler and the author have been acquainted with each other after the
countless hours together. For every hour passing, all kinds of strange behavior
become "normal" so it is very difficult to say if and how things in OPNET
should be improved.
In parallel with this Master Thesis another student have evaluated Ns/Nam, an
open source-networking simulator, and a few comparisons have been made
between the programs. Ns/Nam is not as graphically advanced as OPNET when
it comes to drag-and-drop, but it certainly has its advantages. One of them is a
small meter on all nodes, displaying how full the local buffer is and dropped
packets are really visibly dropped from the simulation. That adds to the
comprehension of the entire system.
ns/Nam can generate new traffic or read the current network traffic and directly
include it in the running simulation. OPNET has no such feature.
OPNET's different kinds of background traffic is excellent and gives the
network designer a powerful tool, while still keeping the wall time at a
minimum during simulation.
Regarding the list of requirements in chapter 3, OPNET passes with flying
colors. It has support for almost all kinds of protocols and networking products
currently in use, but it was a pity that RSVP and IPv6 couldn't be tested - it
would really have added an extra dimension to the program and its usability in
class.
OPNET has a vast userbase in large companies doing advanced R&D and at
universities around the world, many of which are members of a mailinlist, that
nowadays is a webbased, searchable, database with threaded subjects. A large
leap forward!
OPNET is very easy to install and has support for a server running the
authorization software.
OPNET has many examples, but one is often required to install the newest
version and latest patches to be able to run them. It may be a lot of work when
running on many clients, but I hope it is enough to update the software on the
server and make it propagate automatically to the clients.
The support (reachable via e-mail) is very skilled and answers all questions
within 24 hours with very good and correct answers. They are very thorough
and do follow-ups and ask after one week if one was successful with their
solution, if one don't write and tell them that the problem is solved. Very
professional!
The hardest example to make was 4.1.1, Modelling TCPs slow-start, where
modifications to the source code was needed. It took many days to get it to
44
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
work, even though the final result only contained very minor changes. It's
always like that - it is most difficult to invent a feature, using it after it has been
invented is simple!
5.3
Overall handling
When evaluating a software package, it would be wrong not to mention both
good and bad features:
5.3.1 Pros






OPNET's intended users are highly experienced professionals on the
cutting edge of the science. OPNET still haven't sacrificed the user
friendliness and they are constantly improving the design and features of
the package.
OPNET runs on several different platforms.
Online manual is built-in the program and needs Adobe's Acrobat
Reader (free).
With a reasonable short introduction, the students can construct
interesting simulations of e.g. M/M/1-queues and small networks of
switches, routers, servers and workstations and analyze utilization etc.
The idea of simulation is a very appealing form of education. Students
can visualize complex events, thereby gain a deeper understanding of the
mechanisms and remember them better.
Incredibly stable software. Only a few crashes during several months of
hard testing on the Windows 2000-platform. Impressive!
5.3.2 Cons
OPNET is very expensive, even though universities get 90% discount, and the
fee is paid yearly.
Visual C++ is needed to be able to compile process models in NT. No support is
given for other, free, compilers. This adds to the cost of using OPNET.
OPNET is a memory hog. There is no idea trying to have less than 256 MB
memory, rather 512 MB or more.
A severe problem the author encountered was from using a 6-12 months old
version - the OPNET support sometimes sent very interesting scenarios, but
they were only readable in the newer version of OPNET.
As mentioned previously OPNET support several platforms. To simplify the
porting they invented their own graphical user interface (GUI). It isn't very
aesthetically pleasing and has uncountable minor glitches that distract the user
during the creative process. A list of glitches are compiled below:
45
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001


















No information in the logfiles of runtime. Start time is written in each
log so it would be easy to add a line-containing end time and duration
(difference between them). It is a quite important factor.
The graphs are unsuitable for pasting into documents because they only
differ in color and they should be able to differ in pattern, because laser
printers tend to make all curves black or grey so it is impossible to
match curve with legend.
Unconventional behavior when switching windows between minimized
mode and normal mode.
Space wasting borders around windows.
Drop boxes several screens tall that scroll very slowly and have no
means of jumping.
Memory function of recently used files/projects is reset after a restart.
The scroll wheel on the mouse doesn't work in the program, because of
the non-standard GUI. Very disturbing!
Many windows aren't resizable even though they contain lots of
information that doesn't fit in the original size.
The Proto-C-editors always open a very small window and doesn't even
remember how they were left last time.
The editors don't support text-selection with the cursor-keys.
Very deep sub-menus in a couple of places, e.g. when changing server in
"Custom application" for a client.
Graphs can't be minimized.
If you want to look at the "Contributed projects" that are bundled with
OPNET or downloaded from their website, you can't simply select "I
only want to see project files, *.prj" and browse the directory structure
and open a project. You need to enter the path to the project in Edit>Preferences->Model Dirs before you can open a project (if you can find
it amongst the already present objects).
The Tutorial is excellent, but two of the examples wouldn't work, even
after the kind help from their email-support.
An unrealistic problem is for instance if a client generates huge amounts
(57 Mbps) of traffic via a simple switch to a server, the usage of the
links surpasses 400 Mbps and vast amounts of memory are used. The
support could not find the reason, but they thought traffic were buffered
in the stacks, hence the memory usage. Sounds strange with "unlimited"
bufferspace in the stacks. It should start destroying packets.
Would be nice with "Next" and "Previous" and ability to resize the
Simulation Log-window.
The animation player can't go other than forward or jump to the
beginning. It isn't possible to play in reverse or jump to an interesting
section of the animation. There is no way to fast-forward other than to
"next event" either and the fastest playback is 1/100 sec per second.
Examining what happens after 20 minutes of simulated time takes hours
to reach!
The ablility to select buttons and choose items by only using the
keyboard is often much faster for the everyday user. OPNET have no
such features.
46
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
5.4
Final verdict
Excellent!! This is really a versatile tool for educating students about networks.
Opnet can handle almost everything, so the only limit is the fantasy of the
teacher and the cleverness of the students. Lacking features such as RSVP can
in theory be added to the package, but it would be a very timeconsuming
project.
The online documentation in PDF-format is very suitable in class, because the
paperversions (that don't contain all pages the online version contain, especially
in the Simulation Kernel-book where only a few functions are listed in each
segment) weigh about 8 kg in A4-format and the distribution of all those books
would be a nightmare. Unfortunately they are a bit harder to find in and Adobe
Acrobat has a strange format on the table of contents.
47
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
48
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
6 Suitable project in class
6.1
Background
The main idea behind this Master Thesis was to examine how OPNET Modeler
works, how different scenarios are modeled and how it can be used as a tool for
students in advanced courses in computer communication.
The author has a rather wide knowledge about the program after the many hours
with it and many contacts with the support department at Opnet and it is a good
idea to extract as much of that knowledge while it is fresh in memory to get
inspiration to projects at an intermediate level to be used in class.
The method of testing the projects listed are very different, but often a server
and a client in each end plus different statistics are helpful.
6.2


6.3








Examples of easy projects
An M/M/1-queue is listed in the [OpnetTutorial, 68-93] and also in the
installed PDF-files.
A comparison between Ethernet and FDDI with a variable number of
hosts and load.
Examples of intermediate projects
The CSMA/CD-example listed in [OpnetTutorial, 232-300].
An IP-header compressor. It is already possible to do it via the normal
settings, but a stand-alone version would be interesting.
A small simple router with several queues of different priority that are
emptied by weighted-round-robin.
Implement a subset of the IPv6-protocol (it is not going to be
implemented within the next 12 months in Opnet by Opnet
Technologies) and try to send data in those packets through routers.
Probably one team need to build the router and one team the protocol.
A comparison in price/performance between one powerful global
webserver with high-capacity links and several smaller servers, one per
continent, with slower and cheaper links.
Modify protocol already present in OPNET, such as TCP/IP, for better
performance in a certain scenario, such as satellite-links with high
delays, webpages with many short connections etc.
Analyze and simulate the difference between multicasting and normal
TCP-connections, especially the difference between many listening hosts
in a dense environment and scattered across the world. Remember that
very few of all routing equipment supports multicasting.
Construct and test a firewall that only accepts certain packets. There
already exists a working model in OPNET, but it can easily be removed.
49
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001




Construct a proxyserver and try it!
Analyze the traffic between a bunch of routers getting to know each
other with a routing protocol, such as RIP or IGRP. Compare with
theoretical analysis.
Analyze TCPs slow-start and congestion control. Remember to use
"advanced ppp-links" or it will be very problematic.
Try different kinds of background traffic and how it influences on
rendering-time and performance in the simulation.
50
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
7 Acknowledgements
The author want to thank his supervisor, Dr. Jerry Eriksson, for all support and
help during the months of work with OPNET. Dr. Eriksson had many
constructive ideas on how to examine OPNET and what would be suitable
features of a network simulator used in class.
A huge thanks goes to the author's mother and father who have supported him
during all years of his education. Without you, he would not have come this far!
You have stood behind him both when he did great and the years when he
almost didn't pass a single exam. It's because of you he managed to get back on
top again and finally achieve his goal - a Masters Degree, or a "Civilingenjör"
as it is called in Sweden - that he set in fourth grade back in 1984, when he
heard of it for the first time.
The author's siblings, Robert, Åsa and Fredrik were kind enough to leave him
alone whenever he needed some privacy with his work, both during projects and
before written exams.
Thanks to the author's grandparents, Signe & Per and Gun & Karl-Gösta. You
have supported and shared both happiness and sorrows during the twenty years
in school. Thank you!
51
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
8 References
[Diary]
Snyder, J., "Review: Diary of an IPv6 tester, 09/25/00", September
2000, http://www.nwfusion.com/reviews/2000/0925rev.html
[Halsall]
Open
Halsall, Fred, "Data Communications, Computer Networks and
Systems", fourth edition, 1996, ISBN 0-201-42293-X, Addison-
Wesley
Publishers Ltd.
[Lindgren]
Lindgren, C., "Video on Demand-Test hos BoNet Fas III", E-mail,
2000-10-26.
[MASH]
"The MASH project home page", October 2000,
http://www-mash.cs.berkeley.edu/mash/
[Mattgrand] Björnerbäck, T., "100 Mbps Internet-access at home! Måttgränd,
Umeå", 2000-10-01, http://www.bjornerback.com (click on "100
Mbps@home!").
[Opnet]
OPNET Technologies, Inc., "OPNET Modeling Concepts Vol.
1&2", version 2, part nr D00115-2, 1999-2000,
http://www.opnet.com
[OpnetTutorial]
OPNET Technologies, Inc., "OPNET Modeler Tutorial", version
1, part nr D00142, 1999, http://www.opnet.com
[RFC1884] Hinden, R. and Deering, S., "IP Version 6 Addressing
Architecture", RFC 1884, December 1995,
http://www.ietf.org/rfc/rfc1884.txt?number=1884
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit,
and Fast Recovery Algorithms", RFC2001, January 1997,
http://www.ietf.org/rfc/rfc2001.txt?number=2001
[RFC2205] Braden, R. et al, " Resource ReSerVation Protocol (RSVP) -Version 1 Functional Specification", RFC2205, September 1997,
http://www.ietf.org/rfc/rfc2205.txt?number=2205
[RFC2357] Mankin, A. et al., "IETF Criteria for Evaluating Reliable Multicast
Transport and Application Protocols", RFC2357, June 1998,
http://www.ietf.org/rfc/rfc2357.txt?number=2357
52
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
[RFC2379] Berger, L., "RSVP over ATM Implementation Guidelines",
RFC2379, August 1998,
http://www.ietf.org/rfc/rfc2379.txt?number=2379
[RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6)
Specification", RFC2460, December 1998,
http://www.ietf.org/rfc/rfc2460.txt?number=2460
[RFC2474] Nichols, K. et al, "Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998, http://www.ietf.org/rfc/rfc2474.txt?number=2474
[RMTcharter]
Mankin, A. et al, "Reliable Multicast Transport (rmt) Charter",
October 20, 2000, http://www.ietf.org/html.charters/rmtcharter.html
[SNA]
Cohen, Alain J and Shobana Narayanaswamy, "Standard Network
Applications", July 13, 2000, only available from OPNET support,
support@opnet.com
[Stallings]
Stallings, William, "High-speed networks TCP/IP and ATM design
principles", 1998, ISBN 0-13-525965-7, Prentice-Hall Inc.
[Stardust]
"QoS protocols & architectures at Stardust.com", August 17, 1999,
http://www.stardust.com/qos/whitepapers/protocols.htm
[Wireless]
Duffy Marsan, C., "Wireless boosting IPv6, 10/23/00", October
2000, http://www.nwfusion.com/news/2000/1023ipv6.html
53
Analysis of a Network Simulation Tool for Advanced Courses in Computer
Communication, January 2001
9 Authors' Address
Tomas Björnerbäck
Måttgränd 7
906 24 Umeå
Sweden
Phone: +46-90-186506
E-mail: tomas.bjornerback@home.se, c95tbk@cs.umu.se
Home page: http://www.bjornerback.com
ICQ#: 15 95 87 30
10 Full Copyright Statement
Copyright (C) Tomas Björnerbäck (2000).
All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be
modified in any way, such as by removing the copyright notice or
references to Tomas Björnerbäck. If required to translate it
into languages other than English, please contact Tomas
Björnerbäck for a written permission.
The limited permissions granted above are perpetual and will not
be revoked by Tomas Björnerbäck or his successors or assigns.
This document and the information contained herein is provided
on an "AS IS" basis and TOMAS BJÖRNERBÄCK DISCLAIMS ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
54