Professional Documents
Culture Documents
OPNET Modeler
Tommy Svensson
Alex Popescu
This thesis is presented as a part of the Master of Science Degree in Electrical Engineering with emphasis
on Telecommunications and Signal Processing.
June 2003
Abstract
The primary purpose of this thesis is to develop laboratory exercises for use with several
courses at the Blekinge Institute of Technology and to offer an insight in how real
networks and protocols behave. All laboratories are developed in OPNET Modeler 9.0
simulation environment which is a network simulator that offers the tools for model
design, simulation, data mining and analysis.
The software package is licensed by OPNET technologies Inc [1].
The instructional material consists of a set of laboratory exercises, namely: Introduction
to OPNET Modeler 9.0 environment, M/M/1, Aloha, CSMA, CSMA-CD, Slow Start,
Congestion Avoidance, Fast Retransmit, Fast Recovery and OSPF, Queuing policies
, Selfsimilar.
Keywords: OPNET Modeler, Lab, M/M/1, Aloha, CSMA, CSMA-CD, Slow Start,
Congestion Avoidance, Fast Retransmit, Fast Recovery, OSPF, Areas, Balanced traffic
flow, Ethernet, FIFO, Preemptive priority queuing, Non preemptive queuing, WFQ,
Selfsimilar.
Tommy Svensson 2
Alex Popescu
Master thesis MEE 03:24
Table of contents
Abstract ...........................................................................................................................................................2
Introduction .....................................................................................................................................................6
General ........................................................................................................................................................6
Purpose ........................................................................................................................................................6
Laboratory 1 ....................................................................................................................................................7
Introduction to Opnet ......................................................................................................................................7
Objective .....................................................................................................................................................7
Overview .....................................................................................................................................................7
Preparations .................................................................................................................................................8
Project Editor...........................................................................................................................................9
The Process Model Editor .....................................................................................................................11
The Link Model Editor ..........................................................................................................................12
The Path Editor......................................................................................................................................13
The Packet Format Editor......................................................................................................................14
The Probe Editor....................................................................................................................................15
The Simulation Sequence Editor ...........................................................................................................16
The Analysis Tool .................................................................................................................................17
The Project Editor Workspace...............................................................................................................18
Begin the laboratory ..................................................................................................................................20
Laboratory 2 ..................................................................................................................................................41
M/M/1 Queue simulation ..............................................................................................................................41
Objective ...................................................................................................................................................41
Overview ...................................................................................................................................................41
Procedure...................................................................................................................................................42
Creation of the node model ...................................................................................................................43
Laboratory 3 ..................................................................................................................................................62
Ethernet simulation........................................................................................................................................62
Objective ...................................................................................................................................................62
Overview ...................................................................................................................................................62
Procedure...................................................................................................................................................63
Designing the Aloha Transmitter Process Model ......................................................................................63
Creating the Aloha Transmitter Node Model ............................................................................................70
Creating the Generic Receiver Node Process Model.................................................................................73
Creating the Generic Receiver Node Model..............................................................................................77
Creating a new link model.........................................................................................................................79
Creating the network model ......................................................................................................................80
Executing the Aloha Simulation................................................................................................................83
Creating the CSMA transmitter process model .........................................................................................87
Creating the CSMA transmitter node model .............................................................................................89
Redefining the network model ..................................................................................................................91
Configuring CSMA Simulations ...............................................................................................................92
Analyzing the CSMA results.....................................................................................................................93
Viewing Both Results on the Same Graph ................................................................................................94
Ethernet network model.............................................................................................................................97
Laboratory 4 ................................................................................................................................................104
TCP simulation............................................................................................................................................104
Objective .................................................................................................................................................104
Overview .................................................................................................................................................104
Procedure.................................................................................................................................................104
Slow start and congestion avoidance ...................................................................................................104
Slow start and congestion avoidance simulation .................................................................................106
Create the network...............................................................................................................................107
Create the Paris subnet ........................................................................................................................110
Tommy Svensson 3
Alex Popescu
Master thesis MEE 03:24
Create the Stockholm subnet ...............................................................................................................112
Create the IP Cloud..............................................................................................................................114
Choose Statistics..................................................................................................................................115
Slow start and Congestion avoidance simulation ................................................................................117
View the results ...................................................................................................................................117
Fast retransmit .....................................................................................................................................118
Fast recovery .......................................................................................................................................118
Fast Retransmit and Fast Recovery simulation....................................................................................119
Create the Tahoe scenario....................................................................................................................119
Create the Reno scenario .....................................................................................................................119
Simulate the scenarios .........................................................................................................................120
View results .........................................................................................................................................120
Laboratory 5 ................................................................................................................................................123
OSPF simulation..........................................................................................................................................123
Objective .................................................................................................................................................123
Overview .................................................................................................................................................123
Procedure.................................................................................................................................................123
Create the network...............................................................................................................................124
Configure router interfaces ..................................................................................................................126
Assign addresses to the router interfaces.............................................................................................128
Configure routing cost .........................................................................................................................129
Configure the traffic demands .............................................................................................................132
Configure Simulation ..........................................................................................................................132
Duplicate the scenario .........................................................................................................................132
Run the simulation...............................................................................................................................134
View the results ...................................................................................................................................135
Laboratory 6 ................................................................................................................................................139
Queuing policies..........................................................................................................................................139
Objective .................................................................................................................................................139
Overview .................................................................................................................................................139
Procedure.................................................................................................................................................139
Copy files ............................................................................................................................................140
FIFO queuing.......................................................................................................................................141
Create the FIFO network .....................................................................................................................142
Duplicate scenario ...............................................................................................................................145
Collect statistics...................................................................................................................................146
Run the simulation...............................................................................................................................147
View the results ...................................................................................................................................148
Priority queuing ...................................................................................................................................152
Create the Non-preemptive priority network, infinite buffer...............................................................152
Create the Preemptive priority network, infinite buffer.......................................................................156
Run the infinite buffer simulation........................................................................................................157
View the infinite buffer simulation results ..........................................................................................158
Create the Preemptive priority network, Finite buffer.........................................................................163
Create the Preemptive priority network, Finite buffer.........................................................................163
Run the finite buffer simulation...........................................................................................................164
View the finite buffer simulation results .............................................................................................164
Weighted Fair Queuing .......................................................................................................................169
Create the Weighted Fair Queuing – infinite buffer network ..............................................................169
Run the Weighted Fair Queuing – infinite buffer simulation ..............................................................173
View the Weighted Fair Queuing – infinite buffer results...................................................................173
Create the Weighted Fair Queuing – finite buffer network .................................................................175
Run the Weighted Fair Queuing – finite buffer simulation .................................................................176
View the Weighted Fair Queuing – finite buffer results......................................................................176
Laboratory 7 ................................................................................................................................................178
Self-Similar .................................................................................................................................................178
Tommy Svensson 4
Alex Popescu
Master thesis MEE 03:24
Objective .................................................................................................................................................178
Overview .................................................................................................................................................178
Procedure.................................................................................................................................................179
Create the self similar network model .................................................................................................180
Run the simulation...............................................................................................................................190
View the results ...................................................................................................................................191
Conclusions throughput.......................................................................................................................195
Conclusions delay................................................................................................................................195
Concluding Remarks ...................................................................................................................................196
Acknowledgments .......................................................................................................................................196
Glossary.......................................................................................................................................................197
References ...................................................................................................................................................198
Appendix 1 ..................................................................................................................................................199
Appendix 2 ..................................................................................................................................................221
Appendix 3 ..................................................................................................................................................244
Appendix 4 ..................................................................................................................................................255
Tommy Svensson 5
Alex Popescu
Master thesis MEE 03:24
Introduction
General
Today the field of computer networks all over the world has entered an exponential
growth phase. These demands have made the necessity of capable network engineers
extremely covet. It is therefore crucial for universities to offer networking courses that
are both educational and up to date. Due to different obstacles it is unpractical for a
university to be able to offer several types of networks to its students. An invaluable tool
in this case consists of the network simulator OPNET Modeler that offers the tools for
model design, simulation, data mining and analysis for, considering the alternatives, a
reasonable cost. OPNET Modeler can simulate a wide variety of different networks
which are link to each other. The students can therefore just by sitting at their
workstations exercise various options available to network nodes and visually see the
impact of their actions. Data message flows, packet losses, control/routing message
flows, link failures, bit errors; etc can be seen by the students at visible speed. This is the
most cost effective solution for universities to demonstrate the behavior of different
networks and protocols.
Purpose
This thesis will implement five laboratory exercises using the OPNET Modeler
simulation environment, namely:
Tommy Svensson 6
Alex Popescu
Master thesis MEE 03:24
Laboratory 1
Introduction to Opnet
Objective
This laboratory is about basics of using Optimized Network Engineering Tools (OPNET).
Overview
The OPNET is a very powerful network simulator. Main purposes are to optimize cost,
performance and availability.
The goal of this laboratory is to learn the basics of how to use Modeler interface, as well
as some basic modeling theory. The following tasks are considered:
• Build and analyze models.
• Configure the object palette with the needed models.
• Set up application and profile configurations.
• Model a LAN as a single node.
• Specify background utilization that changes over a time on a link.
• Simulate multiple scenarios simultaneously.
• Apply filter to graphs of results and analyze the results.
Before starting working on the Exercise part of this laboratory, one has to read the
Preparations part.
Tommy Svensson 7
Alex Popescu
Master thesis MEE 03:24
Preparations
To build a network model the workflow centers on the Project Editor. This is used to
create network models, collect statistics directly from each network object or from the
network as a hole, execute a simulation and view results. See Fig.1.
Figure 1 - Workflow
Tommy Svensson 8
Alex Popescu
Master thesis MEE 03:24
Project Editor
The main staging area for creating a network simulation is the Project Editor. This is used
to create a network model using models from the standard library, collect statistics about
the network, run the simulation and view the results. Using specialized editors accessible
from the Project Editor via File Æ New one can create node and process models, build
packet formats and create filters and parameters.
Depending on the type of network being modeled, a network model may consist of
subnetworks and nodes connected by point-to-point, bus, or radio links. Subnetworks,
nodes, and links can be placed within subnetworks, which can then be treated as single
objects in the network model. This is useful for separating the network diagram into
manageable pieces and provides a quick way of duplicating groups of nodes and links.
Tommy Svensson 9
Alex Popescu
Master thesis MEE 03:24
The Node Editor is used to create models of nodes. The node models are then used to
create node instances within networks in the Project Editor. Internally, OPNET node
models have a modular structure. You define a node by connecting various modules with
packet streams and statistic wires. The connections between modules allow packets and
status information to be exchanged between modules. Each module placed in a node
serves a specific purpose, such as generating packets, queuing packets, processing
packets, or transmitting and receiving packets.
Tommy Svensson 10
Alex Popescu
Master thesis MEE 03:24
To create process models which control the underlying functionality of the node models
created in the Node Editor one can use the Process Editor. Process models are represented
by finite state machines (FSMs) and are created with icons that represent states and lines
that represent transitions between states. Operations performed in each state or for a
transition are described in embedded C or C++ code blocks.
Tommy Svensson 11
Alex Popescu
Master thesis MEE 03:24
This editor enables for the possibility to create new types of link objects. Each new type
of link can have different attribute interfaces and representation. Specific comments and
keywords for easy recognition are also possible.
Tommy Svensson 12
Alex Popescu
Master thesis MEE 03:24
The Path Editor is used to create new path objects that define a traffic route. Any protocol
model that uses logical connections or virtual circuits such as MPLS, ATM, Frame Relay,
etc can use paths to route traffic.
Tommy Svensson 13
Alex Popescu
Master thesis MEE 03:24
By making use of this editor it is possible to define the internal structure of a packet as a
set of fields. A packet format contains one or more fields, represented in the editor as
colored rectangular boxes. The size of the box is proportional to the number of bits
specified as the field’s size.
Tommy Svensson 14
Alex Popescu
Master thesis MEE 03:24
This editor is used to specify the statistics to be collected. By using different probes there
are several different types of statistics that can be collected, including global statistics,
link statistics, node statistics, attribute statistics, and several types of animation statistics.
It is mentioned that similar possibilities for collecting statistics are also available under
the Project Editor. These are however not as powerful as the Probe Editor.
Tommy Svensson 15
Alex Popescu
Master thesis MEE 03:24
Tommy Svensson 16
Alex Popescu
Master thesis MEE 03:24
The Analysis Tool has several useful additional features like for instance one can create
scalar graphics for parametric studies, define templates for statistical data, create analysis
configurations to save and view later, etc.
Tommy Svensson 17
Alex Popescu
Master thesis MEE 03:24
There are several areas in the Project Editor window (a.k.a. workspace) that are important
for building an executing a model. See Figure 11 as an example.
Buttons
Several of the more commonly used menu bar can also be activated through buttons.
Each editor has its own set of buttons. The buttons shown below appear in the Project
Editor.
Tommy Svensson 18
Alex Popescu
Master thesis MEE 03:24
1 2 3 4 5 6 7 8 9 10 11
Figure 13 – Project Editor Buttons
Occasionally, the messages Modeler generates may be larger than the message area. You
can left-click on the icon next to the message area to open the message buffer, where
the entire message displays.
Tool tips
If you place your cursor over a button or a menu selection, a help balloon soon appears.
Tommy Svensson 19
Alex Popescu
Master thesis MEE 03:24
The first step in setting up the WAN is to specify the overall context for the network with
the Startup Wizard.
Steps:
1) Begin by starting up Modeler and create a new project. Select File -> New and click
OK
2) Name the new project <initials>_LAN_Mod and the scenario no_back_util, then
click OK. Write down your project name here:_____________________
3) To create an empty scenario for the Initial Topology click next when prompted by
the Startup Wizard.
4) Next you can specify a map to use as a background for your network. Click Choose
From Maps for Network Scale and click Next.
7) Finally review your settings and click OK to finish the Startup Wizard.
The workspace now shows the specified map and object palette.
8) Zoom in Sweden from the Europe map (Zoom in until you are satisfied).
Tommy Svensson 20
Alex Popescu
Master thesis MEE 03:24
To work with Modeler’s full set of node and link models would be overwhelming, so the
object palette can be configured to show only a specific subset, or model list. Further you
can use the standard model list, adapt them for your own needs, or make your own list.
For this lab we created LAN_Mod_Model_List. Now you will adapt that model list by
adding the LAN node model to it.
9) To open the Configure Palette dialog box click the Configure Palette button in the
object palette.
The Configure Palette dialog box lets you change the object palette and then save it
10) Click the Node Models button in the Configure Palette dialog box.
11) Find 10BaseT_LAN in the list and change its status from not included to included.
Tommy Svensson 21
Alex Popescu
Master thesis MEE 03:24
13) Click OK to close the Configuration Palette dialog box, then click OK again to save
the model list as <initials>_LAN_Mod_Model_List-no_back_util.
Tommy Svensson 22
Alex Popescu
Master thesis MEE 03:24
You will now configure the Application Configuration Object and the Profile
Configuration Object. Before you begin constructing the network it’s a good idea to
predefine the profiles and applications that will be used by the LAN.
14) To configure the Application Configuration Object, open the object palette in the
case it is not already open and drag an Application Config object to the project
workspace.
15) Right click and select Edit Attributes from the pop up menu.
15) Click on the question mark next to the name attribute to see a description of the
attribute. When done close the attribute description dialog box.
17) Now change the Application Definitions attribute to Default by clicking in the
attribute’s Value column and selecting Default from the pop-up list.
Tommy Svensson 23
Alex Popescu
Master thesis MEE 03:24
Selecting Default configures the application definition object to have the eight standard
applications which are: Database Access, Email, File Transfer, File Print, Telnet Session,
Video conferencing, Voice over IP Call and Web Browsing.
19) Drag a Profile Configuration object from the object palette to project workspace.
21) Set the name attribute to Profile Configuration as shown in the box above.
Tommy Svensson 24
Alex Popescu
Master thesis MEE 03:24
22) Change now the Profile Configuration attribute by clicking in its value column
and selecting Edit from the drop down menu.
25) Click in the profile’s Start Time (seconds) cell to open the Start Time Specification
dialog box.
Tommy Svensson 25
Alex Popescu
Master thesis MEE 03:24
Since you will be modeling FTP performance, that application should be included in the
profile.
28) Click in the LAN Client’s Applications column and choose Edit from the pop-up
menu
30) Set the name to File Transfer (Heavy) by clicking in the cell and selecting the
application from the pop-up menu.
By selecting Default as the value for the Application Definition attribute in this object,
you enable this list of applications. The list includes 16 entries, a heavy and a light
version for each of the eight standard applications.”
32) The completed dialog box should look like this. Verify and then click OK to close the
Applications Table dialog box.
33) Click OK to close the Profile Configuration Table, then click OK once again to
close the Attributes dialog box.
You are now ready to begin the construction of the WAN. In this scenario the network
contains 2 identical subnets in Karlskrona and Karlshamn. You can create the first subnet
in Karlskrona , with its nodes inside it, and then copy the subnet to Karlshamn. You will
also copy it to Ronneby and modify it further.
Tommy Svensson 26
Alex Popescu
Master thesis MEE 03:24
Hint: A subnet is a single network object that contains other network objects (links,
nodes and other subnets). Subnetworks allow you to simplify the display of a complex
network through abstraction.
Subnets are useful when organizing your network model. Subnets can be nested within
subnets to an unlimited degree.
35) Place a subnet over Karlskrona, Right-click to turn off node creation.
36) Right-click on the subnet and select set name. Change the name to Karlskrona.
The extent of the subnet needs to be modified. The subnet extent is the geographic area
covered by the subnet, which may be much larger than the actual area you wish to model.
37) Right-click on the Karlskrona subnet and select Advanced Edit Attributes.
The unit of measure of these attributes is determined by the unit of measure of the top-
level area, degrees in this case.
In order to see what’s inside subnets just double-click on that subnet icon and the
Modeler will change the view.
By default a subnet’s grid properties is based on its parent subnet. You can change them
to fit your network.
Tommy Svensson 27
Alex Popescu
Master thesis MEE 03:24
The network in BTH does not require modeling the precise nature of each node in each
subnet, so you can represent the subnets with a LAN model.
50) Right-click on the 10BaseT_LAN and choose the Edit Attribute menu item.
You can change the attributes so that it represents a network with a certain number of
workstations and a particular traffic profile.
54) Change the Profile Name to LAN Client, then click OK.
This LAN will now use the LAN Client profile you created earlier. This profile includes
the File Transfer (Heavy) application. The LAN will send traffic that models heavy FTP
use.
Tommy Svensson 28
Alex Popescu
Master thesis MEE 03:24
55) Change the Number of Workstations attribute to 10, then click OK.
You have now modeled a 10 workstation LAN inside the Karlskrona subnet. Further
because this LAN model is composed of workstations and links only, it must be
connected to a router. The router can then be connected to other routers in the network.
57) To create an router drag a BN_BLN_4s_e4_f_sl8_tr4 node from the object palette to
the workstation near the Office_LAN node.
58) After naming the new node router connect it to the Office_LAN nodes with a
10BaseT link. Right click to turn off link creation.
The Karlskrona subnet is now configured. Because the subnets in Karlshamn and
Ronneby are identical, you can copy the Karlskrona subnet and place it appropriately.
59) To copy the subnet you must first return to the parent subnet, this is done either by
60) After returning to the parent subnet, select the subnet and copy it, this is done either
by clicking Edit=>Copy or by pressing <Control>+c.
61) Now paste the subnet to Karlshamn and Ronneby by selecting Edit=>Paste or by
pressing <Control>+v and then click on the Karlshamn and Ronneby region. When done
the new subnets appears.
62) You will now have to rename the subnets. To do so right-click on each of the two
subnets and choose set name.
63) Next you should connect the Karlshamn and the Karlskrona subnets to Ronneby.
To do so select the LAN_Mod_PPP_DS0 link in the object palette.
Next a Select Nodes dialog box appears asking which nodes in each subnet are to be
endpoints of the link.
Tommy Svensson 29
Alex Popescu
Master thesis MEE 03:24
68) Repeat this process, drawing link from Karlshamn to Ronneby as well. Specify the
city’s router as the links endpoints.
The network should resemble the one shown in the picture below.
Tommy Svensson 30
Alex Popescu
Master thesis MEE 03:24
To complete the network, the main office in Ronneby needs to have a switch and a server
added to it.
70) To configure the network in Ronneby double-click on the Ronneby subnet to enter its
subnet view.
71) Place one <Bay Network Accelar1050> switch and one ethernet_server node in the
workspace.
This is done by right-clicking on each icon and select Set name from the menu.
74) Connect the router and the server to the switch with 10BaseT links. Right-click to
turn off link creation, and close the object palette.
75) Open the Attributes dialog box for the FTP server.
78) Select File Transfer (Heavy) from the Name column pop-up menu.
79) Click OK to close the Supported Services dialog box, and then click OK to close the
FTP Attributes dialog box.
Tommy Svensson 31
Alex Popescu
Master thesis MEE 03:24
You have now created a model to act as a baseline for the performance of the network.
Background traffic will now be added to the links connecting the cities. The results from
the two scenarios will be compared.
We begin with duplicating a scenario to be able to compare the results later.
Tommy Svensson 32
Alex Popescu
Master thesis MEE 03:24
84) Select the link between Karlskrona-Ronneby. Right-click on the link and choose
Similar Links from the pop-up menu.
85) Display the Edit Attributes dialog box for the link between Karlskrona-Ronneby.
86) Click in the Value cell for the Background Utilization attribute and select Edit...
from the pop-up menu.
Network studies show that traffic rises gradually over the course of the day as
employees/students arrive.
The last step in setting background utilization is to apply the changes made to the
Karlskrona-Ronneby link to all the selected links.
89) Check the Apply Changes to Selected objects check box in the Karlskorna-Ronneby
Attributes dialog box.
Tommy Svensson 33
Alex Popescu
Master thesis MEE 03:24
Now you have configured two scenarios, one without background utilization and one
with background utilization. You are ready to collect data and analyze it.
The relevant statistics for this network are:
• Utilization statistics for the links.
• Global FTP download time for the network.
92) Right-click in the workspace to display the workspace pop-up menu, and select
Choose Individual Statistics.
93) Select the Global Statistics => Ftp => Download Response Time (sec) statistic.
Tommy Svensson 34
Alex Popescu
Master thesis MEE 03:24
94) Select the Link Statistics => point-to-point => untilization --> Statistic.
In order to compare the statistics in the back_util scenario to the no_back_util scenario,
the same statistics must be collected in the no_back_util scenario.
Change scenario and collect statistics.
Tommy Svensson 35
Alex Popescu
Master thesis MEE 03:24
97) Collect the same statistics that you did in the back_util scenario:
• Global Statistics => Ftp => Download Response Time (sec)
• Link Statistics => point-to-point => untilization -->
The statistics are now ready to be collected by running the simulations. Instead of running
each simulation separately, you can batch them together to run consecutively.
101) Click on the Results value for the no_back_util and back_util scenarios and
change the value to <collect>.
102) Set the Sim Duration value for each scenario to 30 and the Time Units to minutes.
Tommy Svensson 36
Alex Popescu
Master thesis MEE 03:24
Modeler will now run simulations for both scenarios. A simulation Sequence dialog box
shows the simulation progress. Shut down the dialog box when the simulations are done.
Hint: You are now ready to view the results of the two scenarios. To view the results
from two or more different scenarios against each other, you can use the Compare
Results feature. With this topic you can also apply different built-in filters to the graphs.”
104) Continue by comparing the results, to do so display the workspace pop-up menu and
choose Compare Results.
105) In the Compare Results dialog box, select Object Statistics => Choose From
Maps Network => Karlshamn <-> Ronneby[0] => point to point => utilization ->.
106) Further you will also have to change the filter from menu from As Is to
time_average. This must be done because utilization varies over the course of a
simulation and it is therefore helpful to look at time average for this statistic.
Tommy Svensson 37
Alex Popescu
Master thesis MEE 03:24
107) Click Show to display the graph. The graph should resemble the one below, though
it will not match exactly.
Tommy Svensson 38
Alex Popescu
Master thesis MEE 03:24
You may want to look at the utilization of other links to determine the maximum
utilization of any link.
Let’s look at Global FTP response time.
108) Click the Unselect button in the Compare Results dialog box.
109) Check the Global Statistics => FTP => Download Response Time statistic in the
Compare Statistics dialog box.
110) Verify that the filter menu shows time_average, then click Show.
The graph should resemble the one below, though it will not match exactly.
Tommy Svensson 39
Alex Popescu
Master thesis MEE 03:24
Before you leave please remove your saved project from the computer.
By default it is located on: C:\Documents and Settings\[your login name]\op_models
Remove all your saved files.
Tommy Svensson 40
Alex Popescu
Master thesis MEE 03:24
Laboratory 2
M/M/1 Queue simulation
Objective
This laboratory is important for understanding OPNET system and user interface. The lab
contains a step-by-step example that shows how to use OPNET to construct an M/M/1
queue design and analysis.
Overview
The task is to construct an M/M/1 queue model and observe the performance of the
queuing system as the packet arrival rates, packet sizes, and service capacities change.
Two classes of statistics will be measured, Queue Delay and Queue Size. A graph of the
confidence interval will also be produced.
• Node Model
• Probe Model
• Simulation Tool
• Analysis Tool
Tommy Svensson 41
Alex Popescu
Master thesis MEE 03:24
Procedure
An M/M/1 queue consists of a First-in First-Out (FIFO) buffer (queue) with packet
arriving randomly according to a Poisson arrival process, and a processor, that retrieves
packets from the buffer at a specified service rate. Three main parameters affects the
performance of an M/M/1 queue, namely:
OPNET models are hierarchical. At the lowest level, the behavior of an algorithm or a
protocol is encoded by a state/transition diagram, called state machine, with embedded
code based on C-type language constructs. At the middle level, discrete functions such as
buffering, processing, transmitting and receiving data packets are performed by separate
objects. Some of these objects rely on underlying process models. In OPNET, these
objects are called modules and they are created, modified and edited in the Node Editor.
Modules are connected to form a higher-level node model. At the highest level, node
objects are deployed and connected by links to form a network model. The network
model defines the purpose of the simulation.
The lower-level objects for M/M/1 queue are provided by OPNET, but they need to be
combined to form a node model.
Tommy Svensson 42
Alex Popescu
Master thesis MEE 03:24
The M/M/1 queue consists of several objects in the Node Editor, namely 2 processors and
a queue. One processor is used for (source) packet generation. The second processor is
used for the sink module. The source module generates packets and the sink module
disposes the packets generated by the source. The queuing system is composed by an
infinite buffer and a server.
The source module generates packets at an exponential rate.
1) Start OPNET.
2) Open a new project and a new scenario. Name the new project
<initials>_mm1net and the scenario MM1.
4) Select File => New… , then select Node Model from the pull-down list and click
OK.
10) Left-click in the Value Column of the Packet Interarrival Time attribute to open
the Packet Interarrival Time Specification dialog box.
11) From the Distribution Name pop-up menu select Exponential, as in a Poisson
process.
12) Set the Mean Outcome to 1.0 and click OK. This sets the mean interarrival time,
λ, of a packet to 1 second.
Tommy Svensson 43
Alex Popescu
Master thesis MEE 03:24
13) Change the Packet Size attribute so that Distribution Name is exponential and
Mean Outcome is 1024. Click OK.
15) To create the queue model click first on the Create Queue Module button and
place then a module in the workspace to the right of the generator.
17) Further right-click on the queue module and select Edit Attributes to bring up its
attributes.
Tommy Svensson 44
Alex Popescu
Master thesis MEE 03:24
The acb_fifo process is an OPNET-supplied process model that provides service in the
packets arriving in the queue according to FIFO discipline. Note that when a process
model is assigned to a module, the process model attributes appear in the module’s
attribute menu. The acb_fifo process model has an attribute called service_rate. When
you select the acb_fifo process model, the service_rate attribute appears in the queue
module’s attribute menu with the default value 9600 bits per second. The name of the
model acb_fifo reflects its major characteristics:
Characteristics Indicates
A Active, acts as its own server
C Concentrates multiple incoming packet
streams into its single internal queuing
resource
B Service time is a function of the number of
bits in the packet
fifo First in first out service ordering discipline
20) Right click on service rate in the attribute column.
21) Select Promote attribute to higher level. The value for this will be set later in
the Simulation Set dialog box.
Further a sink module should be used although it is not a part of the M/M/1 queue
system. The reason for using a sink is for proper memory management, packets should be
Tommy Svensson 45
Alex Popescu
Master thesis MEE 03:24
destroyed when no longer needed. The OPNET-supplied sink process module destroys
the packet sent to it.
23) To create the sink module, activate the Create Processor Module button and then
place a processor module to the right of the queue model on the workspace.
24) Open the attribute box for the processor module by right clicking the icon.
25) Change the name attribute to sink. Notice that the default value for the process
model attribute is sink.
To transfer packets between the generator module, the queue module and the sink
module, it will be necessary to connect them together. This is done by packet streams that
provide a path for the transfer of packets between modules. They serve as one-way paths
and are depicted by solid arrowed lines.
28) Connect the source module with the queue module by clicking the source icon,
then clicking the queue icon. Remember that the first module you click becomes
the source, and the second one the destination.
29) Connect the queue module and the sink module. Remember to end the Create
Packet Stream operation by right-clicking anywhere in the window.
Tommy Svensson 46
Alex Popescu
Master thesis MEE 03:24
31) In the Node Types table, click in the Supported cell for the fixed node type. This
toggles the value to yes. Make sure mobile and satellite nodes are not supported.
The M/M/1 node model definition is complete. You are now ready to create the network
model, but first you should save your work.
33) To save select File => Save. Name the node <initials>_mm1, then click OK and
close the Node Editor.
The first step in creating the network model is to create a new model list. You can
customize the palette to display only the models needed.
39) Scroll in the table until you find the <initials>_mm1 node model. Change the
status from not included to included.
Tommy Svensson 47
Alex Popescu
Master thesis MEE 03:24
The node model you created is now included in the object palette.
Now you can create the network model.
43) Click and drag the <initials>_mm1 node model to the workspace. Right-click to
end the operation.
We will use the Probe Editor to set the statistics to collect during simulation. This could
also be done by the Choose Result option in the object pop-up menu. The Probe Editor is
a more powerful collection tool.
The Probe Editor will be used to collect queue delay and queue size statistics.
47) Select File => New… ,then select Probe Model and click OK.
You must specify the network model from which the Probe Model should collect
statistics.
We will now set the probes. Specifying appropriate probes causes the statistics to be
recorded at simulation time.
50) Click the Create Node Statistics Probe button and a probe appears below.
We will use the automatic selection method to type in the attributes for the probe.
Tommy Svensson 48
Alex Popescu
Master thesis MEE 03:24
51) Right-click on the probe and select Choose Probed Object from the pop-up
menu.
52) Expand the m1 node.
54) Right click on the probe and select Edit Attributes from the pop-up menu.
The Available Statistics dialog box shows the statistics, the group it belongs to and a
description.
58) Select queue.queuing delay from the list and click OK.
The group attributes changes to queue and the statistics attribute changes to queuing
delay in the Edit Attributes dialog box.
61) Set scalar start to 14400. This is done to eliminate the unwanted initial
oscillations.
Tommy Svensson 49
Alex Popescu
Master thesis MEE 03:24
65) Click the Create Node Statistics Probe button and a probe appears below.
66) You will now have to set new values to the attributes of the probe, to do so right
click on the new probe and select Edit Attributes.
67) When done close the probe’s Attribute dialog box by clicking OK. The changes
will then appear in the Probe Editor.
69) Right click and select choose attributed object in the pop-up menu.
Tommy Svensson 50
Alex Popescu
Master thesis MEE 03:24
71) Right click on the attribute probe and select edit attributes.
The probes are now set up correctly and will collect the desired statistics.
73) Save the probe file. File => Save. Name it <initials>_mm1probe.
It’s time to begin the simulation. We will use the Simulation Sequence Editor instead of
running the simulation form the Project Editor.
75) To open the Simulation Sequence Editor choose Simulation => Configure
Discrete Event Simulation (Advanced).
76) Now place the simulation set icon in the workspace and change its values by
selecting Edit Attributes.
77) The simulation Duration should be set to 7 hours and the Seed to 321.
The seed is an initial value for the random generator. You can choose your own arbitrary
value.
79) Now select the Advanced tab and then set the probe file to <your
initials>_mm1probe.
85) Select the m1.queue.service_rate attribute in the Simulation Set dialog box and
click the values button.
Tommy Svensson 51
Alex Popescu
Master thesis MEE 03:24
95) Right click on the new scenario and select Edit Attributes.
96) Change the Seed number to a different value, when done click OK to close the
dialog box.
Tommy Svensson 52
Alex Popescu
Master thesis MEE 03:24
Notice: It’s very important that each scenario has different Seed numbers.
98) When finished creating all the scenarios begin the simulation by clicking on the
Execute Simulation Sequence button. Wait until the simulation is completed.
In this last portion of lab you will learn how to view your results. The tool used for this
task is the Analysis Tool.
100) From the pull-down menu in the dialog box change the file type to Analysis
Configuration, then click OK. The Analysis Tool opens in a new window.
During the simulation the packets always experience some delay. This delay is named the
mean queuing delay and is the first statistic that we are going to take a closer look at.
101) To view the mean queuing delay left-click on the create a graph of a statistic
button.
102) When done the View Results dialog box opens. Expand now the following
hierarchy: File Statistics => <your initials>_mm1net-mm1 => Object Statistics
=> mm1 => queue => subqueue [0] => queue.
Tommy Svensson 53
Alex Popescu
Master thesis MEE 03:24
Tommy Svensson 54
Alex Popescu
Master thesis MEE 03:24
The large deviations early in the simulation depends on the sensitivity of averages to the
relatively small number of samples collected, as you can see the average stabilizes
towards the end of the simulation.
1
Mean service requirement, =
µ
Service capacity, C =
1
Mean Delay, W = =
µC − λ
Tommy Svensson 55
Alex Popescu
Master thesis MEE 03:24
106) In the View results dialog box, remove the check next to the queuing delay.
Tommy Svensson 56
Alex Popescu
Master thesis MEE 03:24
From this graph we can draw the conclusion that the system is stable. It reaches steady
state after about 2 hours.
λ
Ratio of Load to Capacity ρ = =
µC
ρ
Average Queue Size =
1− ρ
We will produce a queue size versus time averaged queue size graph.
112) Place a check next to File Statistics => <initials>_mm1net-mm1 => Object
Statistics => m1 => queue => subqueue [0] => queue => queue size (packets).
Tommy Svensson 57
Alex Popescu
Master thesis MEE 03:24
It’s important to know the confidence intervals of the simulation results. We will now
graph the confidence interval.
115) Load the Scalar file. File => Load output scalar file…
120) Right click on the graph and select Edit Graph Properties.
Tommy Svensson 58
Alex Popescu
Master thesis MEE 03:24
Tommy Svensson 59
Alex Popescu
Master thesis MEE 03:24
Tommy Svensson 60
Alex Popescu
Master thesis MEE 03:24
In order to get better confidence intervals you need to run more scenarios. The graph
below shows the confidence interval of 40 scenarios. The service rate is between 1024
and 1300 with step size 10.
Tommy Svensson 61
Alex Popescu
Master thesis MEE 03:24
Laboratory 3
Ethernet simulation
Objective
Networks can be generally divided into two broad categories, which are based on using
point-to-point connections and on using broadcast channels. In the broadcast channel
case, there could be competition for the use of the channel between two or more stations.
In the common literature, broadcast channels are referred to as multi-access channels, or
random-access channels. The problem of media access is therefore the most important
one for this case.
Multiple access protocols are implemented primarily in Local Area Networks (LANs).
Today’s personal computers and workstations are connected by Local Area Networks
(LANs), which use a multi-access channel as the basis of their communication.
An example of a popular LAN is the Ethernet which uses a random-access scheme for
media access. The random-access technique was first used by the ALOHA protocol
developed at the University of Hawaii in the 1970s. Another popular random-access
protocol is the Carrier Sensing Multiple Access (CSMA) scheme which was developed
by XEROX Parc. Further the Ethernet, which is using the Carrier Sensing Multiple
Access with Collision Detection (CSMA-CD) scheme, was developed by Dr. Robert M.
Metcalfe in 1978. [4]
Overview
In this laboratory we will study Multiple Access Protocols. We will look at the ALOHA,
CSMA and Ethernet (CSMA-CD) protocols. The ALOHA is the simplest Multiple
Access Protocol and implements therefore only the most basic functionality, which is to
send packets. ALOHA has no built mechanism to check if the channel is free before it
continues transmitting packets, neither the possibility to detect any collisions on the
channel. These flaws limit the use of the bus.
By adding carrier sense capability to the Aloha random access protocol the performance
is improved. The carrier sense capability is employed in the CSMA (Carrier Sense
Multiple Access) protocol. The process waits until the channel is free before transmitting
a packet. Because of finite signal propagation times, it is possible for a node to be
transmitting before it detects an existing transmission signal. This results in some
collisions. [4]
Finally the Ethernet protocol implements the capability of both transmitting and
monitoring a connected bus link at the same time. It has fullduplex capability. By
monitoring the bus link it can determine whether a collision condition exists. If that is the
Tommy Svensson 62
Alex Popescu
Master thesis MEE 03:24
Procedure
OPNET uses the Finite State Machine (FSM) to implement the behavior of a module.
FSMs determine a module’s behavior when an event occurs, detailing the actions taken
in response to every possible event.
A process model is a Finite State Machine (FSM). It represents a module’s logic and
behavior. An FSM consists of any number of states that a module may be in and the
necessary criteria for changing states.
A state is the condition of a module. For example the module may be waiting for a link to
recover.
A transition is a change of state in response of an event.
1) Start Opnet.
3) Click on the Create State button and place two states in the workspace.
Tommy Svensson 63
Alex Popescu
Master thesis MEE 03:24
The first state created is automatically the initial state and indicated by a heavy black
arrow pointed towards it (figure 60). Any state can be changed to initial state by right
clicking on the state and choose Make Initial state in the pop-up menu.
It is now time to specify the code for the process model starting with the header block.
In the header block one usually specify macros to replace more complicated expressions
in transition conditions and executives. The use of macros saves place but the key
advantage is that it simplifies the task of interpreting an FSM diagram. The header block
may also contain #include statements, struct and typedef definitions, extern and global
variable declarations, function declarations and C-style comments.
Tommy Svensson 64
Alex Popescu
Master thesis MEE 03:24
/* Conditional macros */
#define PKT_ARVL (op_intrpt_type () == OPC_INTRPT_STRM)
/* Global variable */
extern int subm_pkts;
IN_STRM and OUT_STRM will be used later to specify which stream to get packets
from and to which to send the packets to. In this process model only stream number 0
will be used. It is possible to select any stream number between 0-8. To achieve the
desired functionality these stream indices must be consistent with those defined in the
node model later.
PKT_ARVL is used to determine when a packet interrupt occurred by comparing the
value returned by the Simulation Kernel Procedure op_intrpt_type() with the OPNET
constant of OPC_INTRPT_STRM. If the comparison evaluates to true, this indicates
that the interrupt is due to a packet arriving on an input stream. In this model there is no
need to determine which input stream received the packet. A packet in only expected on
input stream 0.
The global variable subm_pkts will be used to keep track of the number of submitted
packets.
13) Create two transitions, one from idle state to tx_pkt state and the second one from
14) Right click on the idle Æ tx_pkt transition and select edit attributes.
Tommy Svensson 65
Alex Popescu
Master thesis MEE 03:24
The condition PKT_ARVL is the macro that just has been defined in the header block.
The next step is to create state executives needed in the FSM. OPNET allows one to
attach code to each part of an FSM. This code is called Proto-C. There are three primary
places to use Proto-C, namely:
• Enter Executives: Code executed when the module moves into a state.
• Exit Executives: Code executed when the module leaves a state.
• Transition Executives: Code executed in response to a given event.
Although the enter executives and exit executives of forced states are executed without
interruption, standard practice is to place all forced state executives in the enter
executives block.
To bring up the enter executives editor one double clicks on the upper half of the state.
Double clicking on the lower half of the state will bring up the exit executives editor.
(figure 63)
Tommy Svensson 66
Alex Popescu
Master thesis MEE 03:24
The max_packet_count variable is not yet defined. The variable will hold the maximum
number of packets to be processed in the simulation before it terminates. Variables can be
declared in two places. Variables declared in the temporary variables block do not
retain their values between invocations of the FSM. Variables declared in the state
variables block retain their values from invocation to invocation. The
max_packet_count variable value should be retained between invocations and therefore
declared in the state variable block.
20) Add the max_packet_count variable. The default type, int, is acceptable. When
you are finished click OK to close the dialog box.
Tommy Svensson 67
Alex Popescu
Master thesis MEE 03:24
This value is set later in the simulation attributes. To be able to set the value at simulation
run-time it needs to be defined.
21) Select Interface Æ Simulation Attributes and enter an attribute into the dialog
box table.
23) Double-click on the upper half of the tx_pkt state to open the enter executives
block.
Tommy Svensson 68
Alex Popescu
Master thesis MEE 03:24
op_pk_get(instream_index) function returns a pointer to the packet taken from the input
stream, instream_index. If the specified input stream does not contain any packets, the
value OPC_NIL will be returned by this KP. This situation can be avoided by first calling
op_strm_empty() to determine if a stream contains any packets.
op_sim_end (line0, line1, line2, line3) function takes four arguments. These arguments
are message lines. This function terminates the simulation.
subm_pkts variable is declared in the header block. It is increased every time a packet is
sent.
The out_pkt variable is a packet pointer. This variable has not been declared yet. Since
the process model acquires packets from the generator stream and immediately transmits
them, it is not necessary to retain the packet pointer between process invocations. This
variable will be declared in the temporary variable block.
/* Outgoing packet */
Packet* out_pkt;
The out_pkt entry in the temporary variable block creates a temporary packet pointer.
This is used to extract packets from one stream and insert them into another. The packet
pointers existence is only temporary. Since the packet is sent directly there is no need for
the pointer to be retained between process invocations.
The model is now complete, except for the model interface attribute.
To control the attributes visible at the node level, edit the Process Interfaces. You can
set initial attribute values or hide attributes.
29) Change the Initial Value for the begsim intrpt attribute to enabled.
Tommy Svensson 69
Alex Popescu
Master thesis MEE 03:24
30) Verify that the Initial Value for each of the following attributes is set to disabled.
endsim intrpt
failure intrpts
intrpt interval
recovery intrpts
super priority
All process models must be compiled before they can be used in a simulation. Compiling
a model makes its object code available to a processor module’s process model attribute.
34) Compile the model by clicking on the compile process model action
button.
35) Save the model as <initials>_aloha_tx.
36) Close the Process Model Editor when the compilation of the process model has
finished.
37) Select File Æ New then Node Model from the pull down menu. To accept click
OK.
38) Using the create processor action button create two processor modules.
39) Create one bus transmitter by using the bus transmitter action button .
Tommy Svensson 70
Alex Popescu
Master thesis MEE 03:24
40) Connect the modules with packet streams using the packet stream action button.
41) Right click on the first processor module and select Edit attribites.
The value for the generator’s interarrival time needs to be promoted to make it possible to
assign different values at simulation time.
43) Click on Packet Interarrival Time in the left column to highlight the Attribute
name, then right-click and select Promote Attribute to Higher Level from the
pop-up menu.
45) Right click on the second processor module and select Edit attributes
Tommy Svensson 71
Alex Popescu
Master thesis MEE 03:24
Double check the module connectivity to make sure all objects in the model has been
connected in the correct order.
49) Right click on the tx_proc module and choose Show Connectivity from the
Object pop-up menu. The objects should be connected as shown in figure 70.
Figure 70 – Connectivity
51) In the Node Types table, change the Supported value to no for the mobile and
satellite types.
52) Change the Status of all the attributes to hidden, except for the one with
promoted status, gen.Packet Interarrival Time.
Tommy Svensson 72
Alex Popescu
Master thesis MEE 03:24
The generic receiver node process model is responsible for handling received packets for
statistics gathering purposes. The goal is to count packets and record statistics. It can be
used to monitor network performance whether the packets are transmitted in accordance
with the Aloha or the CSMA channel access methods.
To process received packets for statistics collection, the cct_rx process needs one
unforced state where it waits to receive collision-free packets. Collisions are detected
later in the link model.
The process records the channel throughput and channel traffic values for analysis at the
end of the simulation. It also handles the statistics gathering variables, which should be
initiated at the simulation start.
57) Click on the Create State button and place two states in the workspace.
58) Right click on the initial state and choose Edit attributes.
59) Change the name to init and the status to forced. Click OK.
60) Right click on the second state and choose Edit attributes.
61) Change the name to idle and leave the status as unforced. Click OK.
Tommy Svensson 73
Alex Popescu
Master thesis MEE 03:24
The rcvd_pkts variable is used to keep track of the number of valid received packets. It
needs to be initiated at simulation start.
70) Double-click on the top of the init state to open the enter executives block, and
enter the following code:
/* Initialize accumulator */
rcvd_pkts = 0;
Tommy Svensson 74
Alex Popescu
Master thesis MEE 03:24
72) Open the function block and enter the following code.
The proc_pkt() function acquires each received packet as it arrives, destroys it, and
increments the count of received packets.
The record_stats() function is called when the simulation terminates.
The op_stat_scalar_write function sends the channel throughput and traffic data to a
scalar file that is specified in the simulation attributes.
The macro definitions and the functions have been defined. There is now a good idea to
change the transition conditions.
73) For the first transition between the states, change the condition attribute to
PKT_RCVD and the executive attribute to proc_pkt().
74) For the second transition between the states, change the condition attribute to
END_SIM and the executive attribute to record_stats().
75) For the first transition from idle back to itself, change the condition attribute to
PKT_RCVD and the executive attribute to proc_pkt().
76) For the second transition from idle back to itself, change the condition attribute to
default.
Tommy Svensson 75
Alex Popescu
Master thesis MEE 03:24
77) For the third transition from idle back to itself, change the condition attribute to
END_SIM and the executive attribute to record_stats().
79) Change the Initial value of the endsim intrpt attribute to enabled.
Tommy Svensson 76
Alex Popescu
Master thesis MEE 03:24
85) Begin by selecting File Î New then Node Model from the pull down menu.
Click OK to accept.
86) Click on the create processor action button and place one processor in the
workspace.
87) Create also a bus receiver module in the workspace to the right of the processor
88) Connect the two modules from the bus receiver to the processor by using a packet
stream.
89) Change the name of the processor to rx_proc and the name of the bus receiver to
bus_rx.
90) Open the processors attribute dialog box and set the process model attribute to
<initials>_cct_rx. Close the dialog box when finished.
The interface attributes remains to be set before the node model is completed.
92) The supported value should be changed to no for the mobile and satellite types
in the Node types table.
Tommy Svensson 77
Alex Popescu
Master thesis MEE 03:24
93) Further, in the Attributes table change the status to hidden for all the attributes.
94) Close the node model editor after saving the node model as <initials>_cct_rx.
Tommy Svensson 78
Alex Popescu
Master thesis MEE 03:24
This bus link model will use the default pipeline stages. Default pipeline stages are
denoted by the dbu_ prefix. The table below lists pipeline stages by function.
95) Select File Î New… then choose Link model. Click OK.
This link model supports only the bus and bus tap types.
96) In the Link Types table, change the Supported value to no for the ptsimp and
ptdup types.
97) Save the file as <initials>_cct_link and close the Link Model Editor.
Tommy Svensson 79
Alex Popescu
Master thesis MEE 03:24
The network model will be built so that it can be used when analyzing both the Aloha and
CSMA protocols. This will be done by defining the nodes so that they reference the
generic node models, and later changing the referenced process models at the node level.
The analytical Aloha model assumes that packets are always introduced into the network
at exponentially distributed interarrival times. This network model will contain a finite
number of nodes. To closely follow the analytical model’s assumptions, a relatively large
number of transmitter nodes must exist on the bus.
The network model will be constructed within a subnet so that a small scale coordinate
system can be used.
98) Select File Î New… then choose Project and click OK.
99) Name the project <initials>_cct_network and the scenario aloha, then click
OK.
In order to easily build your network, one needs a custom palette that contains the
necessary objects for your network.
104) Click on the Node Models button and add <initials>_cct_tx and
<initials>_cct_rx from the list of available node models.
106) Click on the Link Models button and add <initials>_cct_link from the list of
available link models.
Tommy Svensson 80
Alex Popescu
Master thesis MEE 03:24
108) Click on the Save button in the Configure Palette dialog and save the palette as
<initials>_cct.
The next step is to create bus network. Instead of creating the entire bus network by hand,
you can use rapid configuration to build it quickly.
117) Check the Top of bus and Bottom of bus check boxes.
Tommy Svensson 81
Alex Popescu
Master thesis MEE 03:24
All the transmitter nodes have been created. The network needs a receiver node.
121) Click and drag the receiver node <initials>_cct_rx from the palette into the left
side of the tool area.
122) Click on the <initials>_cct_link tap link in the palette and draw a tap
from the bus to the receiver node. Drawing a tap from the node to the bus may
produce different results.
Tommy Svensson 82
Alex Popescu
Master thesis MEE 03:24
The goal is to observe how the performance of the protocol varies as a function of
channel traffic. The interarrival time input parameter will be varied in a series of
simulations to produce different levels of traffic so that one can observe different levels
of throughput.
125) Change the values in the common tab: Duration to 20000 sec and seed to an
arbitrary integer.
126) Click on the Global Attributes tab and set max packet count value to 1000.
127) Click on the Object Attributes tab and click on the Add… button.
128) Add Office Network. *.gen.Packet Interarrival Time and click OK.
130) Click in the value column and choose exponential (mean) in the pop-up list.
Tommy Svensson 83
Alex Popescu
Master thesis MEE 03:24
131) Set the value 1000 by replacing mean with the value. (see figure 79)
132) Repeate the last 2 steps to enter the following values: 200, 150, 100, 80, 50, 35,
30, 25, 20, 18,15
Tommy Svensson 84
Alex Popescu
Master thesis MEE 03:24
If the output scalar file <initials>_cct_a does not exist when the simulation sequence
begins, it will be created so that scalar results may be recorded. If the file already exists,
the simulation executables will append their scalar results to this file. To avoid
viewing obsolete results which may already exist in a similarly named file, the output
scalar file <initials>_cct_a must be deleted if it exists.
141) If the list contains the output scalar file <initials>_cct_a, select the entry to
delete the file.
145) When the simulations are complete, close the Simulation Sequence dialog box
and the Simulation Sequence editor.
The results of each simulation are stored as two scalar values in the output scalar file.
That allows us to view the network’s performance as a function of an input parameter
rather than a function of time. The channel throughput as a function of the channel traffic
across all simulations can be viewed in the Analysis Configuration Editor.
146) Select File Î New… and then choose Analysis Configuration. Click OK.
149) Click on the Create graph of two scalars file action button.
Tommy Svensson 85
Alex Popescu
Master thesis MEE 03:24
Tommy Svensson 86
Alex Popescu
Master thesis MEE 03:24
153) Select File Î Open then Process Model from the pull down menu in the
Project Editor.
156) Add the following lines to the end of the existing code.
The Macro FREE makes the process verify that the channel is free before transmitting.
The Macro CH_GOES_FREE keeps track of when the channel becomes empty and
ready for a new transmission.
157) Select File Î Save to save and exit the Header Block.
158) Now create a new state in the Process Model and name it wt_free.
159) Create a transition from wt_free to tx_pkt, and change the condition to
CH_GOES_FREE.
160) Create a transition from the wt_free state back to itself and set the condition to
default.
161) Create a transition from the idle state to wt_free and change the condition to
PKT_ARVL && !FREE.
Tommy Svensson 87
Alex Popescu
Master thesis MEE 03:24
162) Add a transition from the idle state back to itself with a condition of default.
163) Change the condition on the transition from idle state to the tx_pkt state to
PKT_ARVL && FREE.
165) Create a transition from tx_pkt back to itself, and set the condition to
PKTS_QUEUED && FREE.
166) Finally, create a transition from tx_pkt to wt_free and set the condition to
PKTS_QUEUED && !FREE.
Tommy Svensson 88
Alex Popescu
Master thesis MEE 03:24
169) Select File Î Open… and choose Node Model in the roll-down list.
170) Select the <initials>_cct_tx model in the list and click OK.
175) Change the name of the new processor module to sink and the name of the
bus receiver to bus_rx.
177) Make a connection form the bus_rx receiver to the sink processor.
Tommy Svensson 89
Alex Popescu
Master thesis MEE 03:24
180) Right click on the static wire and choose Edit Attributes…
181) Set the falling edge trigger attribute to enabled and rising edge trigger
attribute to disabled. Click OK.
182) Right click on the tx_proc module and choose Edit attributes...
The processor now uses the CSMA process model created previously.
184) Select File Î Save As... and rename the model <initials>_cct_csma_tx.
Tommy Svensson 90
Alex Popescu
Master thesis MEE 03:24
The only change to the network model is to use the new CSMA transmitter node model.
It needs to be added to the object palette.
188) Open the Object palette if it’s not already opened and click on the configure
palette action button.
189) Click on the Node models action button.
191) Click on the save button and save the palette with the default name.
All transmitter nodes in the network model need to be changed to use the new transmitter
model.
192) Right-click on one of the transmitter nodes and choose Select Similar Nodes
from the Object pop-up menu.
193) Right-click on any of the selected nodes and choose Edit Attributes from the
pop-up menu.
194) Change the model attribute to <initials>_cct_csma_tx.
195) Check Apply Changes to Selected Objects check box in the bottom left, then
click OK.
The nodes are now modified to use the new node model.
Tommy Svensson 91
Alex Popescu
Master thesis MEE 03:24
198) Right-click on the simulation set and select Edit Attributes from the pop-up
menu.
199) Change the seed to any arbitrary integer.
205) Delete any existing output scalar files with the name <initials>_cct_c.
207) Close the simulation sequence editor when the simulation is finished.
Tommy Svensson 92
Alex Popescu
Master thesis MEE 03:24
208) Open the Analysis Configuration Editor, File Î New… then Analysis
Configuration. Click OK.
209) Choose File Î Load Output Scalar File.
The goal is to compare the Aloha and CSMA protocols. The easiest way to do so is to
display both traces on the same graph.
Tommy Svensson 93
Alex Popescu
Master thesis MEE 03:24
221) Open the Displayed Statistics menu, and select both displayed statistics.
Tommy Svensson 94
Alex Popescu
Master thesis MEE 03:24
224) Right-click on the multiple vector graph and select Edit Graph Properties.
Notice the pop-up menu of active traces in the top section of the dialog box.
Click and hold this menu to see the list of active traces. Both are named Channel
Throughput S. Which is the CSMA trace and which the Aloha trace?
Tommy Svensson 95
Alex Popescu
Master thesis MEE 03:24
Tommy Svensson 96
Alex Popescu
Master thesis MEE 03:24
The Ethernet model is to complex too be modeled in this lab. Instead we will use the
OPNET-supplied example model.
Our Ethernet network consists of a multi-tap bus network populated by eight nodes. The
nodes employ the node model ethcoax_station_adv.
The ethcoax_station_adv node model is significantly more complex than the Aloha or
CSMA node models. It has four processor modules, a queue module which performs the
bulk of the channel access processing, and a pair of bus receiver and transmitter modules.
(Figure 91)
Tommy Svensson 97
Alex Popescu
Master thesis MEE 03:24
The defer processor independently monitors the link’s condition and maintains a
deference flag that the mac process reads over a statistic wire to decide whether
transmission is allowed.
The bursty_gen module represents higher layer users who submit data for transmission.
It uses an ON-OFF pattern for traffic generation.
The mac process handles both incoming and outgoing packets. Incoming packets are
decapsulated from their Ethernet frames and delivered to a higher level process. Outgoing
packets are encapsulated within Ethernet frames and when the deference flag goes low, a
frame is sent to the transmitter. This process also monitors for collisions, and if one
occurs, the transmission is appropriately terminated and rescheduled for a later attempt.
Tommy Svensson 98
Alex Popescu
Master thesis MEE 03:24
242) Right click on one node and choose select similar nodes from the pop-up menu.
Tommy Svensson 99
Alex Popescu
Master thesis MEE 03:24
245) Check the Apply Changes to Selected Objects check box. (figure 95)
246) Save the project with the default name. File Î Save.
The network model is completed. To gather the statistics of interest a probe model is
needed.
247) Select File Î New… and choose probe model from the menu. Click OK.
248) Add a link statistic probe. Click on the add link statistic probe action button.
249) Choose network model to probe. Select Object Î Set Network Model.
251) Right click on the link probe and select choose probed link.
252) Expand the tree and then select top.Office Network.bus 0. Click OK.
253) Right click on the link probe and choose edit attributes.
262) Close the simulation sequence window when the simulation is completed.
263) Open the Analysis Configuration tool. File Î New… and then Analysis
Configuration.
As you can see, the throughput after 30 seconds of simulation stabilizes near
5.5 Mbps/sec. This demonstrates the superiority of the carrier-sensing, collision-
detection, and backoff strategies used by Ethernet over the less sophisticated methods
used by the pure Aloha and CSMA protocols.
Laboratory 4
TCP simulation
Objective
The purpose of this lab is to demonstrate the functioning of TCP, and particularly the four
algorithms used for congestion control: slow start, congestion avoidance, fast retransmit
and fast recovery. The lab provides a number of scenarios to simulate and compare these
algorithms.
Overview
In this lab we will study TCP’s four intertwined congestion control algorithms, namely:
slow start, congestion avoidance, fast retransmit and fast recovery.
The objectives are:
• To study the behavior and implementation of slow start and congestion avoidance
algorithms.
• To study modifications to the congestion avoidance algorithm, namely fast
retransmit and fast recovery.
Procedure
Slow start and congestion avoidance
Previous versions of TCP start a connection with the sender injecting multiple segments
into the network, up to the windows size advertised by the receiver. This is ok when the
hosts are placed on the same LAN. But if there are routers and slower links between the
sender and the receiver different problems can arise. Some intermediate router must
queue the packets and it is possible for the router to run out of space in the queue. The
algorithm to avoid this is called slow start.
Beginning transmission into a network with unknown conditions requires TCP to slowly
probe the network to determine the available capacity, in order to avoid congesting the
network with an inappropriate large burst of data.
Slow start adds another window to the sender’s TCP: the congestion window, called
cwnd. When a new connection is established with a host on another network, the
congestion window is initialized to one segment (typically 536 bytes or 512 bytes). The
sender starts by transmitting one segment and waiting for its ACK. When that ACK is
received, the congestion window is increased from one to two, and two segments can be
sent. When each of those two segments is acknowledged, the congestion window is
increased to four. This provides an exponential growth, although it is not exactly
exponential because the receiver may delay its ACK’s, typically sending one ACK every
two segments that it receives. The sender can transmit up to the minimum of the
congestion window and the advertised window. The congestion window is flow control
imposed by the sender, while the advertised window is flow control imposed by the
receiver.
At some point the capacity of the internet can be reached and an intermediate router will
start discarding packets. This tells the sender that its congestion window has gotten too
large.
Congestion avoidance is a way to deal with lost packets. Congestion can occur when data
arrives on a big pipe (a fast LAN) and outputs on a smaller pipe (a slower WAN).
Congestion can also occur when multiple input streams arrive at a router whose output
capacity is less than the sum of the inputs. There are two indications of packet loss at a
sender: a timeout occurring and the receipt of duplicate ACK’s. However, the overall
assumption of the algorithm is that packet loss caused by damage is very small (much
less than 1%), therefore the loss of a packet signals congestion somewhere in the network
between the source and destination.
Although congestion avoidance and slow start are independent algorithms with different
objectives, in practice they are implemented together. When congestion occurs TCP must
slow down its transmission rate of packets into the network, and then invokes slow start
to get things going again. [3]
The combined congestion avoidance and slow start algorithms require that two variables
are maintained for each connection:
a) Initialization for a given connection sets cwnd to one segment and sstresh to 65535
bytes.
The initial value of cwnd must be less than or equal to 2*SMSS bytes and must not be
more than 2 segments. SMSS, Sender Maximum Segment Size, is the size of the largest
segment that the sender can transmit.
The initial value of cwnd may be arbitrarily high (some implementations use the size of
the advertised window), but it may be reduced in response to congestion.
b) The TCP output routine never sends more than the minimum of cwnd and receiver’s
advertised window.
c) When congestion occurs one-half of the current window size is saved in ssthresh.
Additionally, if the congestion is indicated by a timeout, cwnd is set to one segment.
Congestion is indicated by a timeout or the reception of duplicate ACK’s.
d) When new data is acknowledged by the other end, increase cwnd. The way in which
cwnd is increased depends on whether TCP is performing slow start or congestion
avoidance. If cwnd is less than or equal to ssthresh, TCP is in slow start, otherwise TCP
is performing congestion avoidance. Slow start continues until TCP is halfway to where it
was when congestion occurred, and then congestion avoidance takes over. This is done
due to the recorded half of the window size that caused the problem.
As mentioned earlier slow start increases congestion window (cwnd) exponentially.
Congestion avoidance on the other hand dictates that congestion window (cwnd) be
incremented by segsize * segsize / cwnd each time an ACK is received, where segsize is
the segment size and cwnd is maintained in bytes. This results in a linear growth of
cwnd, compared to slow start’s exponential growth. The increase in cwnd should be at
most one segment each round-trip time (regardless how many ACK’s are received in
that RTT) whereas slow start increments cwnd by the number of ACK’s received in a
round-trip time. [2]
8) Open the Object palette if it’s not already open and make sure that the
opened palette is internet_toolbox.
11) Click in the value column on the Application Definitions row. Choose
Edit…
Attribute Value
Command Mix (Get/Total) 100%
Inter-Request Time (seconds) constant (3600)
File Size (bytes) constant (9000000)
Symbolic Server Name FTP Server
Type of service Best Effort (0)
RSVP Parameters None
Back-End Custom Application Not Used
18) Add a Profile Config object to the workspace and rename it to Profiles.
19) Right click on the Profile node and choose Edit attributes…
20) Click in the value column on the Profile Configuration row. Choose
Edit…
24) Set Start Time to constant (100) and Duration to End of Simulation.
29) Set Start Time Offset to constant (5) and Duration to End of Profile.
40) Connect the server and the router with a 100BaseT cable.
45) Edit the Server Address attribute and set value to Server_Paris.
57) Connect the client and the router with a 100BaseT cable.
58) Right click on the Client_Sthlm node and choose Edit Attributes…
68) Set the Name attribute to Server_Paris. Click OK to close Actual name
table dialog.
Choose Statistics
80) Right click on Server_Paris and select Choose Indivitual Statistics from
the pop-up menu.
81) Expand Node Statistics Î TCP Connection and select Congestion
Windows Size (bytes)
Fast retransmit
Fast recovery
Congestion avoidance without slow start is performed after fast retransmit sends what
appears to be the missing segment. It is an improvement that allows high throughput
under moderate congestion, especially for large windows.
In this case the reason for not performing slow start is that the receipt of duplicate
ACK’s tells TCP that more than just one packet has been lost. Since the receiver can
only generate the duplicate ACK when another segment is received, that segment has left
the network and is in the receiver’s buffer. In other words there is still data flowing
between the two ends, and TCP does not want to reduce the flow abruptly by going into
slow start. The fast recovery algorithm appeared in the 4.3BSD Reno release.
The fast retransmit and fast recovery algorithms are usually implemented together as
follows:
a) When the third duplicate ACK is received, set ssthresh to no more than one-half the
current congestion window, cwnd, but no less than two segments. Retransmit the missing
segment, and then set cwnd to ssthresh plus 3 times the segment size. This increases the
congestion window by the number of segments that have left the network and which the
other end has cached.
b) Each time another duplicate ACK arrives, increment cwnd by the segment size. This
inflates the congestion window for the additional segment that has left the network.
c) Transmit a segment (packet) if allowed by the new value of cwnd and the receiver’s
advertised window.
d) When the next ACK arrives that acknowledges new data, set cwnd to ssthresh. This
ACK should be the acknowledgment of the retransmission from step a, one round-trip
time after the retransmission. Additionally, this ACK should acknowledge all the
intermediate segments sent between the lost packet and the receipt of the first duplicate
ACK. This step is congestion avoidance, since TCP is down to one-half the rate it was at
when the packet was lost.
97) Right click on the IP Cloud, Europa Internet, and choose Edit Attributes.
View results
The first graph illustrates the NoDrop scenario which has no packet loss.
The second graph illustrates the Tahoe scenario which has 0.5% packet loss. When
congestion is indicated by a timeout, cwnd is set to one segment. In other words, slow
start is performed.
The third graph illustrates the Reno scenario which also has 0.5% packet loss. The
congestion window size does not drop to zero as in the Tahoe graph. Fast recovery is
performed instead of slow start.
Laboratory 5
OSPF simulation
Objective
The purpose of this lab is to demonstrate the behavior of OSPF routing protocol.
Overview
In this lab we will study the OSPF routing protocol. The objective is to construct a
network and configure it with all the necessary parameters for OSPF routing. Using this
network we will analyze the behavior of the OSPF routing protocol.
Procedure
The Open Shortest Path First (OSPF) protocol is an interior gateway protocol (IGP) used
for routing in Internet Protocol (IP) networks. As a link state routing protocol, OSPF is
more robust against network topology changes than distance vector protocols such as
RIP, IGRP, and EIGRP. OSPF can be used to build large scale networks consisting of
hundreds or thousands of routers.
Open Shortest Path First (OSPF) uses the Dijkstra’s algorithm to compute the shortest
path to a destination. The algorithm calculates the shortest path to each destination based
on the cumulative cost required to reach that destination. The cumulative cost is a
function of the cost of the various interfaces needed to be traversed in order to reach that
destination.
The cost (or the metric) of an interface in OSPF is an indication of the overhead required
to send packets across that interface. The cost of an interface is calculated based on the
bandwidth -- it is inversely proportional to the bandwidth of that specific interface (i.e., a
higher bandwidth indicates a lower cost). For example, the cost of a T1 interface is much
higher than the cost of a 100Mbit Ethernet interface because there is more overhead (e.g.,
time delays) involved in crossing a T1 interface.[5]
13. Rename all the routers as in figure 117. Right click on each router and
select Set Name from the pop up menu.
IP Routing Parameters Î Only one interface can be When one wants to add a
Interface Information Î configured at a time. protocol to those already
Routing Protocols designated on a particular
interface.
IP Dynamic Routing • Does not modify router You have configured the
Protocol simulation attributes routing protocols in your
attribute • Overrides the routing network but want to see the
protocols configured on the effects of running a single
router interfaces for the protocol throughout the
duration of the simulation network.
• One routing protocol used
on all interfaces
• When this attribute is set
to “Default,” the protocols
specified on the router
interfaces are used.
The easiest way to designate routing protocols is the Configure Routing Protocols
operation from the Protocols Î IP Î Routing menu. This operation has the same effect
as manually setting the interface routing protocol attributes, but with the added advantage
of being able to configure multiple interfaces at the same time. The previous setting on
the interface is overwritten each time this operation is used.
A Routing Domain Legend appears in the bottom left corner on the workspace. All links
should have a green O attached to it. This indicates that OSPF routing protocol is used
over that link. Figure 119.
The message Assignes 40 IP addresses appear in the status bar. Figure 120.
Cost is specified on a per interface basis and is used as the basis for the shortest path
route calculation.
There are two ways of setting this Cost attribute for each interface.
A. Per-interface: The interface information table is located by right clicking on a
router and selecting the Edit attributes option. Figure 121. One can manually
specify the cost of an interface by editing the value with the desired cost setting.
For example, the default value of Auto Calculate can be over-written by any
positive integer cost value: When set to Auto Calculate, the formula used to
calculate the cost is based on the interface speed and another configurable
Re ference _ Bandwith
attribute called Reference Bandwidth: Interface _ cos t =
Interface _ Bandwith
Note: The default value for Reference Bandwidth is 1000 Mbps; therefore, it will
cost 1,000,000,000/100,000,000 = 10 to traverse a 100Mbps Ethernet interface
and it will cost 1,000,000,000/1,544,000 = 647 to cross a T1 serial line interface.
The default for Interface Bandwidth is computed dynamically using the data rate
of the connected interface. It can be over-written by using the Bandwidth setting
in the Protocols Î IP Î Routing Î Configure Interface Metric Information
table.
B. Globally for all interfaces: If wanted to change the interface cost across all
interfaces, then, rather than individually setting them on each interface, one can
use the model-wide cost configuration option using the following menu option:
Protocols Î OSPF Î Configure Interface Cost. This operation will allow for
choosing one of the following two cost configuration options:
B1) The Reference Bandwidth will be set for all routers. All interfaces will be
set with a cost value of Auto Calculate.
B2) All interfaces will be set with the specified cost value. The
interface/bandwidth settings will be ignored.
In this lab we use different bandwidths on the links to set different costs.
1. Select the links between:
Router A Ù Router B
Router B Ù Router D
Router D Ù Router C
Router C Ù Router A
Router B Ù Router C
by shift clicking on them.
2. Open the Configure Interface Metric Information dialog. ProtocolsÎ IP Î
Routing Î Configure Interface Metric Information.
3. Set the Bandwidth value to 5000 kbps.
4. Select Interfaces across selected links radio button. Click OK.
5. Select the links between:
Router B Ù Router E
Router E Ù Router G
Router I Ù Router F
Router F Ù Router D
Router E Ù Router F
by shift clicking on them.
The paths of the traffic demands are now visible. To hide them select View Î Demand
Objects Î Hide All.
Configure Simulation
Areas scenario
The major addition in OSPF configuration, relative to other protocols, is that the OSPF
routing domain can be divided into smaller segments called areas. This reduces memory
and computational load on the routers. Each area is numbered and there must always be
an area zero, which is the backbone. All other areas attach to the backbone either
directly or via virtual links. An area should contain no more than about 50-100 routers
for optimum performance. A router that connects to more than one area is called an Area
Border Router (ABR).
Partition the network into areas. This is a physical partitioning in the sense that an
interface can belong to only one area. The distinct interfaces of the same router may still
belong to separate areas.
Balanced Scenario
Load balancing is a concept that allows a router to take advantage of multiple best paths
(routes) to a given destination. If two routes to the same destination have the same cost,
the traffic will be distributed half to each.
NoAreas scenario
1. Switch to the NoAreas scenario. Scenarios Î Switch to Scenario Î NoAreas.
2. Open the Route Report for IP Traffic Flows dialog. Protocols Î IP Î
Demands Î Display Routes for Configured Demands…
3. Expand Sources Î Router B Î Router D.
4. Select Router B Æ Router D.
5. Change the Display attribute to Yes. Figure 126.
Areas scenario
1. Switch to the Areas scenario. Scenarios Î Switch to Scenario Î Areas.
2. Open the Route Report for IP Traffic Flows dialog. Protocols Î IP Î
Demands Î Display Routes for Configured Demands…
3. Expand Sources Î Router B Î Router D.
4. Select Router B Æ Router D.
5. Change the Display attribute to Yes.
Balanced scenario
1. Switch to the Balanced scenario. Scenarios Î Switch to Scenario Î Balanced.
2. Open the Route Report for IP Traffic Flows dialog. Protocols Î IP Î Demands
Î Display Routes for Configured Demands…
3. Expand Sources Î Router C Î Router J.
4. Select Router C Æ Router J.
5. Change the Display attribute to Yes.
Laboratory 6
Queuing policies
Objective
The purpose of this lab is to demonstrate the behavior of different queuing disciplines.
Overview
In this lab we will look at one aspect of the DS (Differentiated Services) architecture
which is queue management and traffic shaping. The simulation package OPNET has
been used in this study. Based on the DS value, packets may be put in separate queues,
and various forwarding policies can be used to favor high priority packets in different
ways. The policies that are studied here are: FIFO (First In First Out), PQ (Priority
Queuing), WFQ (Weighted Fair Queuing).
Procedure
Originally, the Internet was designed for data processing applications where delays were
relatively unimportant. In most cases a best effort delivery service was adequate, and in
case of loss or corruption of data, the TCP protocol would take care of the necessary
retransmission and recovery. Nowadays these requirements have been changed due to the
growth of multimedia application which are bandwidth hungry and require megabits per
second rather than the kilobits per second required for traditional data processing
applications. Today’s application are more or less sensitive for the delays experienced
when transmitting over Internet. It is therefore important to keep track of the delay and
delay variation or jitter and insure that they don’t grow to big. There is thus a need to
support a variety of traffic with different quality of service (QoS). The central issue is
how to share available resources in times of congestion. For doing this, diverse
mechanisms are needed to differentiate between different types of traffic (priority).
Copy files
1. Copy the model files from the CD-ROM and place them on the hard drive.
2. Edit the Opnet environment file, env_db9.0. On Windows XP it is located in
C:\Documents and Settings\<profile>\op_admin
3. Add the path where the files are placed to mod_dirs.
FIFO queuing
First-in-first-out (FIFO) is the simplest type of queuing. The incoming packets are placed
in a single queue and are served in the order as they where received. This queuing policy
requires very little computation and its behavior is very predicable, i.e. packet delay is a
direct function of the queue size.
There are many undesirable properties related to this queuing policy, due to the simplistic
nature.
• It is impossible to offer different services for different packet classes since all
packets are inserted into the same queue.
• If an incoming flow suddenly becomes bursty, then it is possible for the entire
buffer space to be filled by this single flow and other flows will not be serviced
until the buffer is emptied.
1. Start OPNET and create a new project. File Î New… and choose Project.
2. Name the project <initials>_queue_ disciplines and the scenario Fifo. Click OK.
3. Click Quit.
Duplicate scenario
26. Duplicate the scenario. Choose scenarios Î duplicate Scenario… (Figure 139)
or use shortcut key Ctrl + Shift + D.
Collect statistics
32. Right click on the fifo node.
33. Select Choose individual statistics.
34. Expand Module statistics Î fifo_queue Î queue.
35. Check overflow, queue size and queue delay statistics.
Figure 147 - Fifo Queue size (packet) for infinite and finite buffers
Figure 148 - Fifo queue delay for infinite and finite buffers
Priority queuing
A simple way of offering different services to different classes of packets is Priority
Queuing. Its operation involves classifying each incoming packet into different priorities
and placing them into separate queues accordingly. The packets that have the highest
priority are transmitted on the output port before the packets with lower priority. Even
though this queuing policy is a good way of providing differentiated service, it also has
some shortcomings, like large continuous flow of high priority traffic into the queue,
equals excessive delay, and perhaps even service starvation for lower priority packets.
Further, in our case we make use of both a non-preemptive priority network and a
preemptive priority network. The difference between a so-called non-preemptive priority
queuing discipline and a preemptive priority queuing discipline is that the transmission of
a packet in a non-preemptive queuing discipline is not interrupted once it has begun.
25. Set:
Processing_rate to 30000
Subqueue Æ rows to 3
72. Right click on the preemptive node and select Choose Individual Statistics.
73. Expand Module Statistics Î preemptive_priority_queue.subqueue[0] Î
queue.
74. Check overflows statistic.
75. Right click on the overflows statistics and choose Change Collection Mode.
76. Set Capture mode to All values.
77. Repeat the same procedure on subqueue[1] and subqueue[2].
84. Right click on the preemptive node and select Choose Individual Statistics.
85. Expand Module Statistics Î nonpreemptive_priority_queue.subqueue[0] Î
queue.
86. Check overflows statistic.
87. Right click on the overflows statistics and choose Change Collection Mode.
88. Set Capture mode to All values.
89. Repeat the same procedure on subqueue[1] and subqueue[2].
Weighted Fair Queuing (WFQ) is a variation of Processor Sharing (PS) in that it supports
flows with different bandwidth requirements. It does this by assigning each queue with
different weights that corresponds to the proportion of the allocated output bandwidth. In
WFQ, each incoming packet is time stamped with a finish time in addition to being
placed into its corresponding flow queue. Unlike Processor Sharing, selection of which
packet to be serviced is now based on this time stamp on each packet. Further packets are
serviced by examining their finish times. The ones with earlier finish times are
transmitted before the ones with later finish times. It is possible for a later packet to have
a finish time stamp that is smaller than an earlier packet.
1. Start OPNET and create a new project. File Î New… and choose Project.
2. Name the project <initials>_WFQ_discipline and the scenario infinite. Click
OK.
3. Click Quit.
36. Open Configure simulation dialog. Click the Run simulation button.
37. Set duration to 1 day
Seed to any arbitrary integer (i.e. 5416)
38. Click Run and wait for the simulation to finish.
55. Open Configure simulation dialog. Click the Run simulation button.
56. Set duration to 1 day
Seed to any arbitrary integer (i.e. 2569)
57. Click Run and wait for the simulation to finish.
Laboratory 7
Self-Similar
Objective
The purpose of this lab is to understand self-similarity on physical grounds in a realistic
network environment. This understanding is important when developing efficient and
integrated network frameworks within which end-to-end QoS guarantees are fully
supported.
Overview
Self-similar traffic has been shown to exist in networks and it seems to be a ubiquitous
phenomenon that is independent of technology, protocol and environment.
In this laboratory moment we will study and compare the performance of an Ethernet
segment run with heavy-tail traffic and with exponential traffic. The performance
parameters considered here are link utilization and e2e delay. The laboratory moments
are as follows:
• Creation of the network model
• Running the simulation with different ON-OFF models
• Plotting and comparing the results
Procedure
A self-similar phenomenon represents a process displaying structural similarities across a
wide range of scales of a specific dimension. In other words, the reference structure is
repeating itself over a wide range of scales and the (main) statistics of the process do not
change. However, these properties do not hold indefinitely for real phenomena and at
some point, this structure breaks down. Self-similarity can therefore be associated with
“fractals” which are objects with unchanged appearances over different scales.
A stochastic process is called fractal when a number of relevant statistics exhibit scaling
with related scaling exponents. Since scaling leads mathematically to power-law
relationships in the scaled quantities the conclusion is therefore that the traffic shows
fractal properties when several estimated statistics exhibit power-law behaviour over a
wide range of time scales [8].
A continuous-time stochastic process X(t) is considered to be statistical self-similar with
parameter H(0.5 ≤ H ≤ 1.0) if, for any real positive “a”, the process a-Hx(at) has the same
statistical properties as x(t). This relationship may be expressed by the following three
conditions:
The parameter H is known as the Hurst parameter, or the self-similarity meter, and it is a
key measure of self-similarity. More precisely H is a measure of the persistence of a
statistical phenomenon and it is the measure of the length of the long-range dependence
of a stochastic process. A value of H=0.5 indicates the absence of long-range
dependence. The closer H is to 1 the greater the degree of persistence or long-range
dependence.
44. Right click on the workspace and choose Select Individual Statistics.
45. Expand Node statistics Î Ethernet.
46. Choose Delay (sec) and Utilization statistics.
63. Open Configure simulation dialog. Click the Run simulation button.
64. In the Common tab, Set
duration to 100 seconds
Seed to any arbitrary integer (i.e. 5416)
65. In the Global Attributes tab, Set
Eth Hub Optimization to Enabled
RPG Flow Info File to Not Used
RPG Start Time to 0
66. In the Environment Files, Set
Optimize_simulation status to included
67. Click Run and wait for the simulation to finish.
68. Close the simulation dialog.
Conclusions throughput
ExpON-PowOff
Fluctuations are much higher at traffic with heavytail than at traffic with exponential
only.
Exponential
Average throughput is more variable at ExpOn-PowOff. It is seen that OFF is heavytail.
Conclusions delay
ExpON-PowOff
It is clear that we have PowOff, long periods with very small delays
Exponential
It is clear that it is exponential only, small variations.
Concluding Remarks
This thesis consists of five laboratory exercises that cover a range of important topics in
networking and telecommunications. The students are provided an opportunity to
experience the behavior of different networks and protocols but also a chance to learn the
basic procedures of network simulation by using the OPNET Modeler simulation
environment.
This is today the most cost effective solution for universities to demonstrate the behavior
of different networks and protocols.
Acknowledgments
We would like to take this opportunity and thank the Department of
Telecommunications and Signal Processing at the Blekinge Institute of Technology.
We would also especially like to thank Prof: Arne Nilsson and Docent: Adrian Popescu
for giving us the opportunity to work with such interesting and challenging topics.
Finally we would like to give special thanks to the Ph.D. students: Doro Constantinescu,
Dragos Ilie, David Erman and Lennart Isaksson for their help and support.
Glossary
ACK - Acknowledge
ATM – Asynchronous Transfer Mode
CSMA - Carrier Sensing Multiple Access
CSMA-CD - Carrier Sensing Multiple Access with Collision Detection
cwnd - congestion window
EIGRP – Enhanced Interior Gateway Routing Protocol
E-mail – Electronic mail
FIFO – First in First Out
FSM - Finite State Machines
FTP – File Transfer Protocol
IGP – Interior Gateway Protocol
IGRP – Interior Gateway Routing Protocol
IP – Internet Protocol
LAN – Local Area Network
M/M/1 – Markov/Markov/1 queue
MAC - Medium Access Control
MPLS – Multiprotocol Label Switching
OPNET - Optimized Network Engineering Tools
OSPF – Open Shortest Path First
RIP – Routing Internet Protocol
RTT – Round Trip Time
Segsize – Segment Size
SMSS - Sender Maximum Segment Size
ssthresh - slow start threshold
TCP – Transmission control protocol
WAN – Wide Area Network
References
[1] URL: http://www.opnet.com/products/modeler/home.html (2003-05-31)
Appendix 1
/* Process model C form file: jsd_prio.pr.c */
/* Header Block */
typedef struct {
int job_type;
double job_size;
} JsdT_Job_Desc;
#include "jsd_win_avg.ex.h"
/* Function Block */
void
jsd_prio_error (msg)
char* msg;
{
/** Print an error message and exit the simulation. **/
FIN (jsd_prio_error (msg));
FOUT;
}
#undef FOUTRET_TRACING
#define FOUTRET_TRACING
void
jsd_prio (void)
{
Packet* pkptr;
Packet* low_pkptr;
Objid orig_id;
int orig_port;
int insert_ok;
int svc_time_determined;
int success_code;
int i;
int pkid;
int num_pkts;
int position;
int sub_q_no;
double pk_instructions;
double pk_svc_time;
double low_pk_svc_time;
double time_in_processor;
double svc_start;
double original_svc_time;
double processing_delay;
double mean_util;
double avg_throughput;
double mean_proc_delay;
Objid job_type_table_id;
Objid line_id;
char err_str [256];
char* line;
int dval;
int job_type;
double instructions;
double pk_prio;
FSM_ENTER (jsd_prio)
FSM_BLOCK_SWITCH
{
/*----------------------------------------------------
-----*/
/** state (init) enter executives **/
FSM_STATE_ENTER_FORCED_NOLABEL (0, "init", "jsd_prio
[init enter execs]")
FSM_PROFILE_SECTION_IN ("jsd_prio [init enter
execs]", state0_enter_exec)
{
/** These executives are encountered only once,
at the beginning of the simulation. **/
/** Their purpose is to initialize the process
model. The attributes of this particular **/
/** module are determined and state variables
are initialized. If a job_type_filename **/
/* Register Statistics. */
busy_signal_shandle = op_stat_reg ("Jsd Busy
Signal", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
inst_delay_shandle = op_stat_reg ("Jsd
Instantaneous Delay (sec)", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
inst_wk_left_shandle = op_stat_reg ("Jsd
Instantaneous Work Left (sec)", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
normalized_delay_shandle = op_stat_reg ("Jsd
Normalized Delay", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
mean_util_shandle = op_stat_reg ("Jsd Total Busy
Time", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
avg_thruput_shandle = op_stat_reg ("Jsd Total
Work", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
mean_delay_shandle = op_stat_reg ("Jsd Mean
Delay (sec)", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
}
FSM_TRANSIT_SWITCH
{
FSM_CASE_TRANSIT (0, 4, state4_enter_exec, ;,
"SVC_COMPLETION", "", "idle", "svc_comp")
if (success_code == GET_INST_SUCCESS)
{
pk_svc_time = pk_instructions /
processing_rate;
FSM_TRANSIT_SWITCH
{
FSM_CASE_TRANSIT (0, 3, state3_enter_exec, ;,
"!server_busy && insert_ok", "", "arrival", "svc_start")
FSM_CASE_TRANSIT (1, 1, state1_enter_exec, ;,
"default", "", "arrival", "idle")
success_code=0;
sub_q_no=0;
position=0;
for (sub_q_no=0;sub_q_no<3;sub_q_no++)
{
/* Determine the number of packets
currently in the queue. */
dval = op_subq_stat (sub_q_no,
OPC_QSTAT_PKSIZE);
if (dval == OPC_DBL_INVALID)
jsd_prio_error ("Unable to get
number of packets in subqueue.");
num_pkts = (int) dval;
*/
for (position = 0; position < num_pkts;
position++)
{
pkptr = op_subq_pk_access (sub_q_no,
position);
if (pkptr != OPC_NIL && op_pk_id
(pkptr) == pkid)
{
success_code=1;
break;
}
}
if (success_code==1)
break;
processing_delay = time_in_processor -
original_svc_time;
FSM_TRANSIT_SWITCH
{
FSM_EXIT (0,jsd_prio)
}
}
Compcode
jsd_prio_init (void ** gen_state_pptr)
{
int _block_origin = 0;
static VosT_Address obtype = OPC_NIL;
if (obtype == OPC_NIL)
{
/* Initialize memory management */
if (Vos_Catmem_Register ("proc state vars (jsd_prio)",
sizeof (jsd_prio_state), Vos_Vnop, &obtype) ==
VOSC_FAILURE)
{
FRET (OPC_COMPCODE_FAILURE)
}
}
FRET (OPC_COMPCODE_SUCCESS)
}
}
void
jsd_prio_diag (void)
{
/* No Diagnostic Block */
}
void
jsd_prio_terminate (void)
{
int _block_origin = __LINE__;
Vos_Catmem_Dealloc (pr_state_ptr);
FOUT
}
void
jsd_prio_svar (void * gen_ptr, const char * var_name, char ** var_p_ptr)
{
jsd_prio_state *prs_ptr;
if (var_name == OPC_NIL)
{
*var_p_ptr = (char *)OPC_NIL;
FOUT
}
prs_ptr = (jsd_prio_state *)gen_ptr;
FOUT
}
Appendix 2
/* Process model C form file: jsd_prmpt_res.pr.c */
/* Header Block */
typedef struct {
int job_type;
double job_size;
} JsdT_Job_Desc;
#include "jsd_win_avg.ex.h"
JsdT_Win_Stat_Hndl* Work_Left_Stat_Hndl;
Objid own_id;
Evhandle svc_complete;
JsdT_Job_Desc* Job_Desc_Table;
Objid job_type_table_id;
Stathandle busy_signal_shandle;
Stathandle inst_delay_shandle;
Stathandle inst_wk_left_shandle;
Stathandle normalized_delay_shandle;
Stathandle mean_util_shandle;
Stathandle avg_thruput_shandle;
Stathandle mean_delay_shandle;
int current_subq;
} jsd_prmpt_res_state;
/* Function Block */
static void
jsd_prmpt_res_error (const char * msg)
{
/** Print an error message and exit the simulation. **/
FIN (jsd_prmpt_res_error (msg));
FOUT;
}
#undef FOUTRET_TRACING
#define FOUTRET_TRACING
void
jsd_prmpt_res (void)
{
int _block_origin = 0;
FIN (jsd_prmpt_res ());
if (1)
{
Packet* pkptr;
Packet* head_pkptr;
Packet* low_pkptr;
Objid orig_id;
int orig_port;
int insert_ok;
int svc_time_determined;
int success_code;
int i;
int sub_q_no;
double pk_instructions;
double pk_svc_time;
double low_pk_svc_time;
double old_svc_time;
double time_processed;
double time_in_processor;
double svc_start;
double original_svc_time;
double processing_delay;
double mean_util;
double avg_throughput;
double mean_proc_delay;
double pk_prio;
char job_type_filename [64];
char err_str [256];
char* line;
int line_id;
int job_type;
double instructions;
FSM_ENTER (jsd_prmpt_res)
FSM_BLOCK_SWITCH
{
/*----------------------------------------------------
-----*/
/** state (init) enter executives **/
FSM_STATE_ENTER_FORCED_NOLABEL (0, "init",
"jsd_prmpt_res [init enter execs]")
FSM_PROFILE_SECTION_IN ("jsd_prmpt_res [init
enter execs]", state0_enter_exec)
{
/* Register Statistics. */
busy_signal_shandle = op_stat_reg
("Jsd.Busy Signal", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
inst_delay_shandle = op_stat_reg
("Jsd.Instantaneous Delay (sec)", OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL);
FSM_TRANSIT_SWITCH
{
FSM_CASE_TRANSIT (0, 4, state4_enter_exec, ;,
"SVC_COMPLETION", "", "idle", "svc_comp")
FSM_CASE_TRANSIT (1, 2, state2_enter_exec, ;,
"ARRIVAL", "", "idle", "arrival")
}
/*----------------------------------------------
-----------*/
{
jsd_prmpt_res_error
("Unable to set remaining service time in packet.");
}
FSM_TRANSIT_SWITCH
{
FSM_CASE_TRANSIT (0, 3, state3_enter_exec, ;,
"!server_busy && insert_ok", "", "arrival", "svc_start")
FSM_CASE_TRANSIT (1, 1, state1_enter_exec, ;,
"default", "", "arrival", "idle")
}
/*----------------------------------------------
-----------*/
FSM_PROFILE_SECTION_OUT ("jsd_prmpt_res
[svc_start enter execs]", state3_enter_exec)
FSM_PROFILE_SECTION_OUT ("jsd_prmpt_res
[svc_comp enter execs]", state4_enter_exec)
FSM_TRANSIT_SWITCH
{
FSM_CASE_TRANSIT (0, 3, state3_enter_exec, ;,
"!QUEUE_EMPTY", "", "svc_comp", "svc_start")
FSM_CASE_TRANSIT (1, 1, state1_enter_exec, ;,
"default", "", "svc_comp", "idle")
}
/*----------------------------------------------
-----------*/
FSM_EXIT (0,jsd_prmpt_res)
}
}
Compcode
jsd_prmpt_res_init (void ** gen_state_pptr)
{
int _block_origin = 0;
static VosT_Address obtype = OPC_NIL;
if (obtype == OPC_NIL)
{
/* Initialize memory management */
if (Vos_Catmem_Register ("proc state vars (jsd_prmpt_res)",
sizeof (jsd_prmpt_res_state), Vos_Vnop, &obtype) ==
VOSC_FAILURE)
{
FRET (OPC_COMPCODE_FAILURE)
}
}
}
else
{
/* Initialize FSM handling */
((jsd_prmpt_res_state *)(*gen_state_pptr))->current_block =
0;
FRET (OPC_COMPCODE_SUCCESS)
}
}
void
jsd_prmpt_res_diag (void)
{
/* No Diagnostic Block */
}
void
jsd_prmpt_res_terminate (void)
{
int _block_origin = __LINE__;
Vos_Catmem_Dealloc (pr_state_ptr);
FOUT
}
void
jsd_prmpt_res_svar (void * gen_ptr, const char * var_name, char **
var_p_ptr)
{
jsd_prmpt_res_state *prs_ptr;
if (var_name == OPC_NIL)
{
*var_p_ptr = (char *)OPC_NIL;
FOUT
}
prs_ptr = (jsd_prmpt_res_state *)gen_ptr;
FOUT
}
Appendix 3
/* Process model C form file: ta_gen.pr.c */
/* Header Block */
#define JSDC_XMT_OUT_STRM 0
/* Transition macros */
#define CREATE (op_intrpt_type () == OPC_INTRPT_SELF && \
op_intrpt_code () == JSDC_CREATE_INTRPT)
/* Function Block */
/** This function computes the time until the next packet creation
**/
/** from an exponential distribution based on the value of
**/
FOUT;
}
void
jsd_gen_error (msg)
char* msg;
{
/** Print an error message and exit the simulation. **/
FIN (jsd_gen_error (msg));
FOUT;
}
#undef FOUTRET_TRACING
#define FOUTRET_TRACING
void
ta_gen (void)
{
int _block_origin = 0;
FIN (ta_gen ());
if (1)
{
Packet* pkptr;
double dval;
double svc_time;
double instructions;
double priority;
FSM_ENTER (ta_gen)
FSM_BLOCK_SWITCH
{
/*----------------------------------------------------
-----*/
/** state (init) enter executives **/
FSM_STATE_ENTER_FORCED_NOLABEL (0, "init", "ta_gen
[init enter execs]")
FSM_PROFILE_SECTION_IN ("ta_gen [init enter
execs]", state0_enter_exec)
{
/** These executives are encountered only once,
at the beginning of the simulation. **/
/** simulation. Their purpose is to initialize
the process model. The attributes **/
/** of this particular generator are determined
and distributions are loaded. **/
FSM_TRANSIT_SWITCH
{
FSM_CASE_TRANSIT (0, 2, state2_enter_exec, ;,
"CREATE", "", "idle", "xmt")
FSM_CASE_TRANSIT (1, 3, state3_enter_exec, ;,
"ARRIVAL", "", "idle", "rcv")
FSM_CASE_TRANSIT (2, 1, state1_enter_exec, ;,
"default", "", "idle", "idle")
}
/*----------------------------------------------
-----------*/
/* instructions = op_dist_uniform
(instruction_range); */
instructions = instruction_range;
if (instructions == OPC_DBL_INVALID)
jsd_gen_error ("Unable to get instructions
from distribution.");
FSM_EXIT (0,ta_gen)
}
}
Compcode
ta_gen_init (void ** gen_state_pptr)
{
int _block_origin = 0;
static VosT_Address obtype = OPC_NIL;
if (obtype == OPC_NIL)
{
/* Initialize memory management */
if (Vos_Catmem_Register ("proc state vars (ta_gen)",
sizeof (ta_gen_state), Vos_Vnop, &obtype) ==
VOSC_FAILURE)
{
FRET (OPC_COMPCODE_SUCCESS)
}
}
void
ta_gen_diag (void)
{
/* No Diagnostic Block */
}
void
ta_gen_terminate (void)
{
int _block_origin = __LINE__;
Vos_Catmem_Dealloc (pr_state_ptr);
FOUT
}
void
ta_gen_svar (void * gen_ptr, const char * var_name, char ** var_p_ptr)
{
if (var_name == OPC_NIL)
{
*var_p_ptr = (char *)OPC_NIL;
FOUT
}
prs_ptr = (ta_gen_state *)gen_ptr;
FOUT
}
Appendix 4
/* Process model C form file: ta_wfq.pr.c */
/* Header Block */
#define SUBQ_INACTIVE 0
#define SUBQ_ACTIVE 1
#define SUBQ_EMPTY 0
#define SERVER_FREE 0
#define SERVER_BUSY 1
double VT (void);
void ta_wfq_error (char * msg);
double retmaximum (double val1,double val2);
double SoQ_calc(int sq);
double get_VFT (int sq);
/* Function Block */
return virtual_time;
}
for (i=0;i<3;i++)
{
if (active_queues[i]== SUBQ_ACTIVE )
tot_weight+=weight[i];
}
if (tot_weight==0.0)
ta_wfq_error ("Unable to determine SoQ");
SoQ_value = weight[sq]/tot_weight;
return SoQ_value;
if ( (int)dval == SUBQ_EMPTY)
{
return 0.0;
void
ta_wfq_error (msg)
char* msg;
{
/** Print an error message and exit the simulation. **/
FIN (ta_wfq_error (msg));
FOUT
}
#undef FOUTRET_TRACING
#define FOUTRET_TRACING
void
ta_wfq (void)
{
int _block_origin = 0;
FIN (ta_wfq ());
if (1)
{
Packet* pkptr;
Objid orig_id;
int i;
int subq_no;
double pk_prio;
double VST;
double VFT;
double min_VFT;
double SoQ;
double dval;
double instructions;
double SVC_TIME;
FSM_ENTER (ta_wfq)
FSM_BLOCK_SWITCH
{
/*----------------------------------------------------
-----*/
/** state (init) enter executives **/
FSM_STATE_ENTER_FORCED_NOLABEL (0, "init", "ta_wfq
[init enter execs]")
FSM_PROFILE_SECTION_IN ("ta_wfq [init enter
execs]", state0_enter_exec)
{
/** These executives are encountered only once,
at the beginning of the simulation. **/
/** Their purpose is to initialize the process
model. The attributes of this particular **/
/** module are determined and state variables
are initialized. **/
for(i=0;i<3;i++)
{
/* Get assigned value of the queue0-queue2
weight. */
for(i=0;i<3;i++)
{
active_queues[i]=SUBQ_INACTIVE;
}
FSM_TRANSIT_SWITCH
{
FSM_CASE_TRANSIT (0, 3, state3_enter_exec, ;,
"SVC_COMPLETION", "", "idle", "svc_comp")
FSM_CASE_TRANSIT (1, 2, state2_enter_exec, ;,
"PK_ARRIVAL", "", "idle", "enqueue")
}
/*----------------------------------------------
-----------*/
FSM_TRANSIT_SWITCH
{
FSM_CASE_TRANSIT (0, 4, state4_enter_exec, ;,
"!server_busy", "", "enqueue", "scheduler")
FSM_CASE_TRANSIT (1, 1, state1_enter_exec, ;,
"default", "", "enqueue", "idle")
}
/*----------------------------------------------
-----------*/
FSM_TRANSIT_SWITCH
{
FSM_CASE_TRANSIT (0, 4, state4_enter_exec, ;,
"!QUEUE_EMPTY", "", "svc_comp", "scheduler")
FSM_CASE_TRANSIT (1, 1, state1_enter_exec, ;,
"default", "", "svc_comp", "idle")
}
/*----------------------------------------------
-----------*/
if (min_VFT==0.0)
{
min_VFT=VFT;
subq_no=i;
}
else if (min_VFT>VFT)
{
min_VFT=VFT;
subq_no=i;
}
}
}
FSM_EXIT (0,ta_wfq)
}
}
Compcode
ta_wfq_init (void ** gen_state_pptr)
{
int _block_origin = 0;
static VosT_Address obtype = OPC_NIL;
if (obtype == OPC_NIL)
{
/* Initialize memory management */
FRET (OPC_COMPCODE_SUCCESS)
}
}
void
ta_wfq_diag (void)
{
/* No Diagnostic Block */
}
void
ta_wfq_terminate (void)
{
int _block_origin = __LINE__;
Vos_Catmem_Dealloc (pr_state_ptr);
FOUT
}
void
ta_wfq_svar (void * gen_ptr, const char * var_name, char ** var_p_ptr)
{
ta_wfq_state *prs_ptr;
if (var_name == OPC_NIL)
{
*var_p_ptr = (char *)OPC_NIL;
FOUT
}
prs_ptr = (ta_wfq_state *)gen_ptr;
FOUT
}