analysis of network simulation tools for advanced … · web viewthis master thesis presents the...

Analysis of a Network Simulation Tool for

Advanced Courses in Computer Communication

Master ThesisJanuary 2001

Author: Tomas BjörnerbäckSupervisor: Dr. Jerry Eriksson

Analysis of a Network Simulation Tool for Advanced Courses in Computer Communication, January 2001

2


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


4


Table of contents1 Introduction 72 Terminology 93 Requirements on the software 124 Modeling in OPNET 13

4.1.1 Modeling TCP's Slow-start 134.1.2 Characteristics of slow-start 134.1.3 Description of the constructed model 144.1.4 Implementation 144.1.5 Results 16

4.2 Modeling a routing protocol 194.2.1 Selection of routing protocol 194.2.2 Description of OSPF-model 204.2.3 Implementation 214.2.4 Results of OSPF-simulation 234.2.5 Description of IGRP-model 254.2.6 Results of IGRP-simulation 254.2.7 EIGRP 26

4.3 Modeling Quality of Service (QoS) 284.3.1 Description of the Ethernet-example 294.3.2 Slow link between the routers 294.3.3 Results with a slow link 304.3.4 Fast link between the routers 334.3.5 Results with a fast link 334.3.6 Description of the ATM-example 374.3.7 Results ATM-scenario 384.3.8 Conclusions 41

4.4 Modeling background traffic 424.4.1 Effects of background traffic 424.4.2 Description of the constructed model 424.4.3 Results 43

5 Is OPNET suitable at Umeå University? 465.1 OPNET from ground up 465.2 Suitability to examined models 475.3 Overall handling 48

5.3.1 Pros 485.3.2 Cons 48

5.4 Final verdict 506 Suitable project in class 52

6.1 Background 526.2 Examples of easy projects 526.3 Examples of intermediate projects 52

7 Acknowledgements 548 References 559 Authors' Address 5710 Full Copyright Statement 57

5


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


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


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 QoS-methods. 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


Protocol: An agreed upon form of communication. Syntax, semantic and physical characteristics of the messages.

Protocol- A hierachy of protocols that simplifies transmission of data by a stack: 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 QoS-protocols 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


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


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


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 TCP-protocol, 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. Double-click 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


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


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. Figure 3 Size of Congestion Window in bytes,

100Mbps link.

14


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


Figure 8 FTP-traffic received, all scenarios. Figure 9 FTP-traffic received, integrated amount of transferred data.

16


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.

We will use ideal links, without packet loss, to keep complexity of the exercise within reasonable bounds.

Prot

ocol

Dis

tanc

e-

vect

or

Link

Sta

te

Inte

rior

Gat

eway

Bor

der

Gat

eway

Mul

tiple

pa

ths t

o de

stin

atio

nLo

ad

Bal

anci

ng

Stat

ic C

ost

Dyn

amic

C

ost

Cos

t bas

ed

on

RIP X X ? ? Hop-count

OSPF X X X X X X Statically assigned

IGRP X X X X X Link-attribute

BGP4 X (X) IBGP4

X X X X 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, 408-416].

17


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 Eastber-subnet 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


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-OSPF-ip_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) andNode 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


Figure 11 IP Interface Addressing Modes.

Figure 12 IP Ping Traffic Table.

20


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 ping-packet 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


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 update-traffic 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 Enterprise network.NORTHBERG.ROUTER

192.0.5.1 Enterprise network.BACKBONE ROUTER 2192.0.11.1 Enterprise network.BACKBONE ROUTER 4192.0.26.1 Enterprise network.EASTBER.ROUTER192.0.26.2 Enterprise network.EASTBER.PARAM192.0.11.2 Enterprise network.EASTBER.ROUTER192.0.5.2 Enterprise network.BACKBONE ROUTER 4192.0.7.1 Enterprise 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 Enterprise network.NORTHBERG.ROUTER 192.0.0.1 Enterprise network.BACKBONE ROUTER 1 192.0.8.1 Enterprise network.BACKBONE ROUTER 3 192.0.11.1 Enterprise network.BACKBONE ROUTER 4 192.0.26.1 Enterprise network.EASTBER.ROUTER 192.0.26.2 Enterprise network.EASTBER.PARAM 192.0.11.2 Enterprise network.EASTBER.ROUTER 192.0.8.2 Enterprise network.BACKBONE ROUTER 4 192.0.0.2 Enterprise network.BACKBONE ROUTER 3 192.0.1.1 Enterprise 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 Enterprise network.NORTHBERG.ROUTER 192.0.5.1 Enterprise network.BACKBONE ROUTER 2 192.0.11.1 Enterprise network.BACKBONE ROUTER 4 192.0.26.1 Enterprise network.EASTBER.ROUTER 192.0.26.2 Enterprise network.EASTBER.PARAM 192.0.11.2 Enterprise network.EASTBER.ROUTER 192.0.5.2 Enterprise network.BACKBONE ROUTER 4 192.0.7.1 Enterprise network.BACKBONE ROUTER 2

22


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 Run-dialog->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


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 Cisco-protocol 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


25


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


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


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


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 E-mail, it is fully acceptable because both Client_2 and Client_6 received much better delays than their peers without QoS did.

29


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


In the above example, the link between the routers was saturated several times during the simulation and there were big differences between traffic with QoS-routing 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 nightmare-scenario 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


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 ten-fold 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


Figure 27 No QoS, Client_0. Figure 28 With QoS, Client_0.



33


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


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


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


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


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


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-by-component 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


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 bi-directional 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


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 46 Dropped packets.

Figure 47 Traffic Browser.

41


42


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


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


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


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


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


48


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

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

Construct a proxyserver and try it!

49


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


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


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] Halsall, Fred, "Data Communications, Computer Networks and Open

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


[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/rmt-charter.html

[SNA] Cohen, Alain J and Shobana Narayanaswamy, "Standard Network Applications", July 13, 2000, only available from OPNET support, [email protected]

[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


9 Authors' Address

Tomas BjörnerbäckMåttgränd 7906 24 UmeåSwedenPhone: +46-90-186506E-mail: [email protected], [email protected] page: http://www.bjornerback.comICQ#: 15 95 87 30

10 Full Copyright StatementCopyright (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

analysis of network simulation tools for advanced … · web viewthis master thesis presents the...

Documents