Configuring Applications

Configuring Applications and Profiles

1 Introduction
Once you have constructed the network topology, you are ready to model network traffic. There are two techniques
for representing network traffic: the first technique is to import traffic as conversation pair traffic and the second
technique is to model application traffic by setting up various application attributes. The first topic is covered
elsewhere in the documentation and will not be discussed here. This document deals with the second technique and
outlines the process for configuring application models.
To configure a workstation or LAN to model the behavior of a user or group of users, you need to describe their
behavior. A users behavior or profile can be described by the applications he or she uses and how long and often
the applications are used throughout the day. An application can be described in terms of its actions, which are
referred to as tasks in OPNET.
OPNET provides global objects for defining profiles and applications. The advantage of using a global object is
that once you have defined the profiles and applications, you can re-use them across the entire topology. These
global objects are portable entities that are defined independent of each other and of other objects. Therefore, you
can copy and paste global objects from one project or scenario to another and re-use the same profiles and
applications.
OPNET ships with pre-defined profiles and applications that may suit the behavior you wish to describe. You may,
however, wish to modify the existing definitions to suit your needs or even create new application and profile
definitions. This paper provides the background needed to customize and create application and profile definitions.
2 Architecture
The figure below depicts the hierarchy involved in constructing an application profile: a profile consists of
applications. Applications can be represented as simple traffic sources, complex protocols or a discrete set of tasks.
Tasks may consist of many phases where each phase describes a pattern of data exchange between a source and
destination. The first two elements of this hierarchy, profiles and applications, are described in detail in the
following sections. The configuration of the other two elements, tasks and phases, applies to only one type of
application, the custom application. Refer to the Custom Application Model paper for detailed information on tasks
and phases.
Confidential--not for release without the written authorization of OPNET Technologies, Inc.
Page 1
7/16/01
Profiles
Profile Definition
Object
Applications
Application
Definition Object
Tasks
Task Definition
Object
Phases
Figure 1: The Application Model Hierarchy
2.1 Profile Configuration

Profiles describe the activity patterns of a user or group of users in terms of the applications used over a period
of time. You can have several different profiles running on a given LAN or workstation. These profiles can
represent different user groups for example, you can have an Engineering profile, a Sales profile and an
Administration profile to depict typical applications used for each employee group.
Profiles can execute repeatedly on the same node. OPNET enables you to configure profile repetitions to run
concurrently (at the same time) or serially (one after the other).
Profiles contain a list of applications. You can configure the applications within a profile to execute in the
following manner:
at the same time
one after the other in a specific order you determine
one after another in a random order
In most cases, when describing the actions of a single user, the actions are serial since most people can only
perform one activity at a time. However, when using applications that can perform non-blocking tasks, you can
have more than one task running at a time. When describing the activities of a group of users, concurrency is
common. Like profile repetitions, application repetitions within the profile can execute either concurrently or
serially.
The diagrams below depict possible profile configurations.
Figure 2: Profile Configuration (Serial Mode)

Page 2
7/16/01
Figure 3: Profile Configuration (Simultaneous Mode)
Figure 4: Simultaneous applications within a profile

The Profile Definition Object defines all profiles that can be used within a scenario. Only profiles that have
been defined in the Profile Definition Object can be applied to the workstations or LANs of a project and only
applications that have been defined in the Application Definition Object can be used in profile definitions.
2.2 Application Configuration

A profile is constructed using different application definitions; for each application definition, you can specify
usage parameters such as start time, duration and repeatability. You may have two identical applications with
different usage parameters; you can use different names to identify these as two distinct application definitions.
For example, the engineer may browse the web frequently in the morning but occasionally in the afternoon.
Hence, you can create two different application definitions for web browsing, such as web_browsing_morning
and web_browsing_noon, with two different usage patterns. You can also create application definitions based
on different workgroups. For example, you may have an engineering_email and a sales_email where the former
may send 3 emails/sec while the latter may send 10 emails/sec.
The software allows you to specify a user profile consisting of many applications. There are two types of
application models that are supported by the software: Standard Network Applications and a custom
application. Before you can select a model, you must first thoroughly understand the software models.
Instructions on selecting a particular model, configuring and using it, appear in sections 3 and 4.
2.3 Standard Network Applications

A number of common network applications such as FTP, e-mail, Telnet, etc., are native to the software, and
each has its own parameters. Since each application in this general category is unique, a separate paper entitled
Page 3
7/16/01

Standard Network Applications describes each in detail. Key attributes and instructions on configuration are
provided in that document.
Standard Network Applications
Brief Description
FTP
File transfer
E-mail
Sending and receiving e-mail
Remote Login
Rlogin (telnet)
Video Conferencing
Video conferencing involving image exchanges
Database
Database queries and updates
HTTP
Web browsing
Print
Print job submission
Voice
On-Off voice model

Table 1: Standard Network Applications
2.4 The Custom Application

The custom application is a generic model can represent a broad class of applications. It can be used when the
application of interest does not correspond to any of the standard applications. The custom application provides
attributes that allow you to configure various aspects of the application in detail.
A custom application can be used to represent any number of tiers, including a two-tier application. The custom
application can then replay the application transactions in one of two modes: deterministic (exactly as
measured) and statistical (transactions are randomized but statistically similar to those actually measured).
Details about the various attributes and how to configure them appear in a separate paper entitled The Custom
Application Model.
3 Selecting an Application Model

Once you have an understanding of the standard network applications and the custom application (see the
documents referred to above), you should be able to determine which option best describes the behavior of the
application whose activity you wish to model. There may be more than one application model you can use for a
distinct scenario. The compatibility of an application model will likely depend on the objective of your simulation
study. In this section, five practical examples show how to choose an application model suited to particular
simulation studies.
1.
Server-Based E-mail Application: When a client sends an e-mail, the e-mail is stored on the server. The client
polls the server on a regular basis, and receives e-mail destined to it. You can model this architecture easily by
configuring the e-mail Standard Application Model, which provides a Send Interarrival Time attribute and a
Receive Interarrival Time attribute (Note: interarrival time, the time between successive messages, is the
inverse of the rate). Inter-arrival times are configurable on an individual basis for each client. Send and receive
inter-arrival times are independent (i.e., a client can be a frequent sender of messages but an infrequent
recipient).
Page 4
7/16/01
Figure 5: Email Attributes on a client

2.
Networked Calendar Application: A networked calendaring application is used to schedule meetings and to
book resources for those meetings. When a calendar entry is made, the client application contacts the server
separately for each staff member or resource involved in the entered event. As each new data item is received,
schedule conflicts are generated and analyzed at the server side. The server then responds to the client,
indicating that it is prepared to process the next item. Once all information has been received and processed by
the server, the final entry is made, and a confirmation is returned to the client.
A custom application is a good choice to represent it because no standard calendaring application is provided.
Another reason to choose the custom application model in this instance is that the request-responses are serial in
nature, i.e., the next request is made only when the previous response is completed.
3.
Intranet Application: An I.S. department has deployed an intranet application that lets employees use services
such as the company directory, and marketing information. Each employee has a browser installed on her
desktop. A central web server serves the intranet site. The web-browsing application is two-tier with the
browser issuing requests to the web server and the server returning pages, text or images.
The HTTP application model will represent the above architecture appropriately because it allows the user to do
the following:
select the average number of pages downloaded and the average number of objects per page
choose the average page size and the number of servers accessed to download various objects on the page
The number of TCP connections that can be opened simultaneously by the browser can be specified.
Page 5
7/16/01
Figure 6: Web Browsing Attributes

4.
Three-Tier Customer Relationship Management Application: A sales department uses a proprietary GUI to
create, browse, and edit customer information stored in a single database. The application is three-tier with a
thin client submitting requests to an application server. The application server submits queries to the database
server, organizes the returned information, and sends formatted text information back to the client for display.
Of specific interest to this case study are searches performed to display a collection of records for clients
responding to common criteria (e.g., all clients located in Virginia).
The application is programmed as follows: 1) the client submits a completed form to the application server; 2)
the application server processes the form and generates one or more queries to the database server, one query at
a time; 3) the database server responds to each query and the application server accepts and accumulates the
returned records; 4) the application server organizes the records and generates content which is sent to the
client; and, 5) the client parses the content and displays a form with appropriate information in each field.
CA is the most applicable model for the following reasons: (1) there is no corresponding standard application;
(2) there are more than two tiers; and, (3) on each of its tiers, the application consists of a series of blocking
(i.e., serial) requests, followed by responses.
5.
General Data Traffic from a LAN: A number of users on a LAN segment generate a variety of data traffic,
i.e., they transfer documents and images to and from one or more servers. The rate and size of these documents
can be measured using a protocol analyzer. A recommended approach to doing this is to use the analyzer to
monitor the behavior of typical users over a sufficient period of time. Relative to capturing all of the users
traffic, this method reduces the volume of data to analyze.
Since the application model is being used to represent the traffic of an entire LAN, the various documents
and/or images are transferred independently. These can occur at any time, and without blocking for each others
completion. The Custom Application corresponds well to this behavior. Furthermore, the Custom Application
can be scaled easily to represent many similar users, all users adhering to the same profile while acting
independently.
4 Configuring an Application Model

Setting up nodes to use applications for traffic generation is a multi-step process. Since each step depends on
definitions from the previous step in the procedure, it is important that the steps are completed in the order specified
on the following pages.
Page 6
7/16/01
4.1 Step 1: Define the application.

The first step to using applications for generating traffic at a node is to create and configure the application
definitions. As mentioned in section 2 on Architecture, the Application Definition Object is used to define and
configure applications.
1.
Place a new Application Definition Object in your project by dragging it from the Utilities object palette
into the workspace. Right click on the object and select Edit Attributes from the pop-up menu. Edit the
value of the Application Definitions attribute.
Figure 7: The Application Definition Object Attributes

2.
In the Applications Definitions Table, add a new row by changing the Rows value to 1. Give the application
you will create a descriptive name such as Engineers Email.
Figure 8: Application Definitions Table

3.
To describe the behavior of the application definition you just created, double-click in the Description field.
For standard applications such as E-mail, you can select any of the pre-configured settings such as Low
Load, Medium Load or High Load. If the pre-configured settings suit your modeling purpose, you are
done with this step. However, if you want to edit any of these pre-configured settings, you should first
select it and then click on the field again to edit its value.
Page 7
7/16/01
Figure 9: Application Definition Configuration

4.
If the standard applications are not suitable and you want to customize your application, you should use the
Custom Application model. This model requires that the applications tasks have been defined in a separate
object, the Task Definition Object. Therefore, create a Task Definition Object using the Utilities object
palette and configure the task definition. Since task definition is a detailed process, please refer to the paper
entitled The Custom Application Model to understand task architecture and configuration.
Once you complete the task definition, you can come back to the application definition and select the list of
tasks for your custom application specification.
Page 8
7/16/01
Figure 10: Application Definition Configuration for a custom application
4.2 Step 2: Construct the profiles

Once the applications have been defined, the second step is to include the application definitions in profile
definitions that are later deployed to workstations and LANs. This step uses the application definitions that were
configured in Step 1.
Page 9
7/16/01
Figure 11: Profile Definition Configuration

1.
Add a profile Definition Object to the project workspace from the Utilities object palette. Right click and
select Edit Attributes. Edit the value of the Profile Configuration attribute.
2.
Enter a Profile Name. You can use any name for the profile; typically, you may want to base the name on
workgroups such as Engineer or Sales Person if your objective is to represent different user types
based on divisions within your organization. However, a profile can be constructed to represent not only
traffic generated by an individual, but also aggregate traffic on a LAN or even just one application. Choose
a name that appropriately reflects what you are trying to model.
For each profile, you can configure the applications it supports by using the start time, duration, operation
mode and repeatability attributes. The operation mode refers to the order in which applications within the
profile are executed. Serial (Ordered) implies that applications are executed one after another in the order
specified in the table. Serial (Random) implies that the applications are executed serially but the order of
execution is random. Simultaneous implies that applications are executed at the same time.
Figure 12: Profile Configuration Table
Page 10
7/16/01

3.
Edit the value of the Applications attribute. Add as many rows to the Applications Table as the number of
applications you want to support in this profile. In each row, you will have to specify the application name,
its start time offset (relative to the profile start time), duration and repeatability.
The application name fields pull down menu lists applications that have been defined in the Application
Definition object. This object was configured in step 1. If you did not execute step 1, there will be no
application definitions listed in the Name field pull-down menu.
The Start Time Offset is the time between the profiles start time and the applications start time. To have
the application start at the same time as the profile, set the start time offset to 0. The Duration attribute
specifies the applications duration in seconds. If you set the duration to the End of Profile, the
application will end at the same time that the profile ends. The Repeatability attribute specifies the number
of application sessions for this application within the profile.
Note: If you have specified the Operation Mode for the applications as Serial (Ordered) or Serial
(Random) and you have multiple applications in the application table, you should not set the Duration for
any application to End of Profile. This will cause only one application to execute until the end of the
profile. Since the second application cannot begin until the first one completes, the second application will
never be executed.
Figure 13: Applications Table
4.3 Step 3: Assign the profiles to the LAN/workstation

Once you have configured your applications and profiles, you are ready to deploy these profiles on individual
workstations, servers and LANs. Typically, profiles are specified on workstations or LANs since they are
traffic sources. However, a profile may be deployed on a server if the server acts as a source for any application
task. This implies that if you have configured a task table such that the server is an independent source, you
should ensure that you support that profile on the server object. Please refer to The Custom Application
Model paper for details on the custom application task configuration.
1.
Edit the Application: Supported Profiles attribute on the object that will execute this profile.
2.
Add the desired number of rows and select the profiles you wish to support. Note that if you have not
executed steps 1 and 2 as described earlier, there will be no profiles available for selection. In this case,
OPNET will automatically place a default application and profile definition object and give you a list of
default profiles that are available.
Page 11
7/16/01
Figure 14: Deploying a Profile to a workstation
4.4 Step 4: Configure the server to support the applications

Once you setup the profiles on the workstations or LANs, you will have to configure the server to support the
application of interest.
1.
Edit the Application: Supported Services attribute on the server.
2.
Add as many rows as the number of applications you want to support. Edit the Name field. This will
automatically pop-up the list of applications you have configured on the global Application Definition
Object. Select the application of interest and edit the Description field to indicate that the application is
Supported.
Page 12
7/16/01
Figure 15: Configuring servers to support applications
4.5 Step 5: Specify the destination and source preferences.

Each application uses a symbolic name to refer to a server. For example, you may specify the symbolic server
name of the E-mail application as Corporate_Email_Server. You must resolve this reference so that the
symbolic name refers to an actual server object on the network. The Application: Destination Preferences
attribute allows you to map a symbolic name to an actual server name. For each server, you can specify a
selection weight. Additionally, you can map a symbolic name to a set of servers (more than one). In this case,
the server selection is based on the selection weights specified.
The servers Server Address attribute identifies the server by its actual name.
The advantage of using symbolic names is that you can define an application once with a symbolic name. You
can then resolve the symbolic name to different actual names on different workstations. In the above example,
the Corporate_Email_Server for all the engineers may be Server_192 (a hypothetical server) and the
Corporate_Email_Server for all sales people may be Server_198 (another hypothetical server).
[Note: If you do not set any destination preferences, the server will be selected at random from the servers that
support the application of interest.]
1.
Assign a unique name for the server or client by editing its Server Address attribute. [Note: This step is
necessary only if you want the application to select a specific server. If the application can select any
server, you can leave this address as Auto-assigned.]
Page 13
7/16/01
Figure 16: Specifying a server's address

2.
Edit the Application: Destination Preferences attribute on the object that is executing the profile. Add the
required symbolic names to the table. The choices available from the Symbolic Name pull down menu
correspond to the symbolic names specified in the global Application Definition Object. Assign actual
names for each symbolic name. Note that you can have more than one actual name for a symbolic name.
The Name field in the actual name table will automatically pop-up the list of where the Server Address has
been explicitly specified. If the Server Address attribute has not been changed from its default value of
Auto-Assigned (i.e. you have not executed step a), this server will not show up in the list.
Figure 17: Resolving the destination preferences for standard applications

3.
Specifying the destination preferences for the custom application is slightly more involved. When setting
up the CA in the Task Definition Object, names were specified for the Source and Destination of each
phase. Since phases are defined in a global object, these names did not refer to specific objects of a
particular project. For the custom application to function correctly, you need to associate the names used in
the custom application with specific objects in your project. Consider the following task configuration from
a custom application. An illustration of the configuration shown appears on the next page.
Page 14
7/16/01
Figure 18: A task's configuration

From the preceding diagrams, you can see that the following symbolic names have been used:
Originating Source for the Wkstn object.
Proxy Server for the Proxy_Server object
Main Server for the Main_Server object.
On each object, you have to list its immediate destination. Hence you have to identify the Proxy_Server and
the destination for the Wkstn object, the Main_Server as the destination for the Proxy_Server and so on.
The steps for the latter case are illustrated below:
1.
Edit the Application: Destination Preferences attribute on the Proxy_Server object.
2.
In the Symbolic Name column of the Application: Destination Preferences row, list the symbolic
destinations.
3.
In the Actual Name Table, specify the name of the node that you want the Symbolic Name to refer to.
For our example, we want the symbolic name Main Server to refer to the object called Main_Server.
Page 15
7/16/01
Figure 19: Application: Destination Preferences (custom application)

The symbolic name can reference many different server objects. In this case, the selection weight is used to
select a particular server.
4.5.1 Source Preferences

The Application: Source Preferences attribute is used to identify objects that act as starter nodes for any
phase. Typically, the source specified as part of the first phase of a task originates the task. For example, in
the above network, the Wkstn object originates the Login task. The symbolic name for the Wkstn is
the Originating Source. Hence you should set the Application: Source Preferences attribute on the Wkstn
object to refer to the symbolic name Originating Source. In effect, you are identifying the workstation as
the Originating Source.
Page 16
7/16/01
Figure 20: Application: Source Preferences (custom application)

For certain applications, you may have more than one source that acts as an independent starter node.
[Note: If the Start Application When attribute in a particular phase is set to Application Starts, then the
Source configured in this phase is a starter node.] In this case, you should identify the sources on each of
these objects separately.
2001 OPNET Technologies, Inc. All rights reserved. OPNET product names are trademarks of OPNET
Technologies, Inc.
It is illegal to reproduce any part of this document in any form without the written consent of
OPNET Technologies, Inc.
Page 17
7/16/01

Configuring Applications

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Configuring Applications

Uploaded by

Copyright:

Available Formats

Configuring Applications and Profiles