1 modeler day 3 © copyright 2003 opnet technologies, inc. modeler day 3

Modeler Day 3

ModelerModelerDay 3Day 3

Modeler Day 3

Course ContentDAY 3:

• Configuring Standard Applications {LABs}

• Traffic Modeling Techniques {LABs}

• Modeling Large Networks

• Importing Topology and Traffic

DAY 4:

• Process Modeling Methodology

• Accelerating Wireless Simulations{LABs}

• Custom Wireless Effect {LABs}

• Debugging Simulation Models{LABs}

Modeler Day 3

Configuring Configuring Standard Standard

ApplicationsApplications

Modeler Day 3

Agenda• Application basics

• Network traffic (users, devices, networks, etc.)• Modeling traffic in OPNET• Application modeling techniques• OPNET application architecture

• Configuring applications workflow• Configure applications• Define profiles• Configure server/peer• Deploy profiles• Lab 1: OPNK2003 cyber café

• Configuring analytical traffic on client-client applications• Concepts and attributes• Lab 2: VoIP configuration

• Easy configuration of application traffic• Concepts and attributes• Lab 3: application demands

• Troubleshooting• Lab 4: troubleshooting (bonus)

Modeler Day 3

Take-Away Points

• Standard applications available

• Application configuration

• Defining user profile

• Client & server setup for standard applications

• Application demands

• Application modeling techniques

• Application troubleshooting

Modeler Day 3

• Easy configuration of application traffic• Concepts and attributes• Lab 3: application demands

Modeler Day 3

How Do We Define Network Traffic?

• Source (user, group of users)

• Destination (user, server)

• Traffic patterns

Modeler Day 3

Applications

• Client-server applications

• Examples: HTTP, FTP

• Peer-peer applications

• Examples: voice, video

• Multi-tier applications

• Examples: web-based applications, e-commerce, home-grown applications

REQUEST

RESPONSE

REQUEST

RESPONSE

REQUESTRESPON

Modeler Day 3

Application Modeling Techniques

• Explicit• Simulate all packets in detail

• Very high fidelity results

• Potentially longer run times

• Analytical• Simulate majority of traffic using mathematical representation

• Faster simulation run times

• Hybrid• Combination of both explicit and analytical modeling techniques

Modeler Day 3

OPNET Application Architecture

PhasesD e fine com m u n ica tio n p a tte rns w ith in ea ch ta sk

TasksD e sc rib e b as ic un it o f u se r ac tiv ity

Applica tionsD e fine a pp lica tio n co n fig u ra tion

Pro filesD e scrib e use r b e h av io ur

Custom application

Modeler Day 3

Profile and Applications: Example

H T T P F T P

E n g in e er

V id eo H T T P

M a rke tin g D e p a rtm e nt

V o ice D a tab a se

S a le s E n g in e erProfiles

Modeler Day 3

Configuring Application Models: Workflow

Configure applications

Define profiles

Configure servers/peers

Deploy profiles

Modeler Day 3

• Easy configuration of application traffic• Concepts and attributes• Lab 3: AppDemands

Modeler Day 3

Configuring Applications

Define profiles

Deploy profiles

Modeler Day 3

Configure Applications

Modeler Day 3

Applications: Built-in Common Applications

Custom Application

Name Description

Database

E-mail

Remote Login

Video Conferencing

Generic/customizable application

Data entry/query application

E-mail application

File transfer protocol application

Web-browsing application

Print job

Telnet application application

Client-to-client voice application

Client-to-client video application

Standard applications

Modeler Day 3

Applications

• Session of specific request/response patterns

• Commonly used applications: email, http, ftp…

• Common settings to all applications• Type of service

• Symbolic server name

• RSVP parameters

• Specific settings to each application• HTTP page configurations

• FTP file sizes

• Database query ratio

Modeler Day 3

Application Definition Utility

• Contains all application definitions• Reusability

• Across clients• Across scenarios

• Easier deployment• Easier change

II’m running “FTP (Light)”

II’m running “FTP (Light)” I

I’m running “FTP (Light)”

II’m running

“FTP (Light)”

II’m running

“FTP (Light)”

“FTP (Light)” Application Definition

Modeler Day 3

Symbolic Server Name

Application has a symbolic server name, e.g. “FTP (Light)”

Actual server name is specified in server, e.g. WashingtonDC_Server

Mapping between symbolic server name and actual server name

Modeler Day 3

Application Definition Object

Modeler Day 3

Example: File Transfer Protocol• Upload or download of files:

• Using file size distribution

• Using Inter-request time distribution

Common settings

Specific FTP settings

FTP (Application)

PUT PUT GET PUT

Inter-Request

Modeler Day 3

Example: Hypertext Transfer Protocol (HTTP)

• Download of a web page:• Using distribution for number of objects in page and sizes

• Using page interarrival time distribution

Common settings

Specific HTTP settings

HTTP (Application)

Web page download

Page Inter arrival Time

timeWeb page download

Web page download

Modeler Day 3

Hypertext Transfer Protocol (cont.)

Modeler Day 3

Define profiles

Profiles

Deploy profiles

Modeler Day 3

Define Profiles

Modeler Day 3

Profiles

• Profile = Reusable collection of applications• Describes activity patterns of:

• an individual user• a group of users

Engineer

CEOCFO

Engineer

Help desk

Marketing department

Modeler Day 3

Profile Configuration Object

• Contains all profile definitions• Reusability

• Across clients• Across scenarios

• Easier deployment• Easier change

II’m an

engineer

II’m an engineer

Engineer Profile

Definition

Modeler Day 3

Profile Properties

Profile Name

Applications

Operation Mode

Start Time

Duration

Repeatability

Modeler Day 3

Profile Name, Start Time, and Duration

Engineer

9:00am 12:00pm 5:00pm

Start Time

Duration

• Example:• “Engineer” profile• Starting at 9:00am• Lasting 8 hours

Modeler Day 3

Profile Repeatability

• Serial mode

Engineer Engineer Engineer EngineerInter-repetition time Inter-repetition time Inter-repetition time

• Concurrent mode

Engineer

EngineerInter-repetition time

Inter-repetition time

Modeler Day 3

Applications in Profile

I have the definitions of the following applications:• Database Access (Light)• Email (Light)• Web Browsing (Light)• FTP

Modeler Day 3

Application Scheduling

“Engineer” profile

Web Browsing

9:00am 17:00pm

Web Browsing Web Browsing

FTP FTP FTP FTP FTP

Database

12:00pm

• Multiple applications per profile

Modeler Day 3

Operation Mode

• Simultaneous

Web Browsing

Database

9:00am 12:00pm 17:00pm

• Serial (ordered/random)

EmailWeb BrowsingDatabase

9:00am 12:00pm 17:00pm

Modeler Day 3

Applications in Profile

Start Time Offset

Duration

Repeatability

Modeler Day 3

Name, Start Time Offset, and Duration

• Example:• “FTP” application• Starting 2 hours after profile “Engineer” starts• Lasting 4 hours

DurationStart time offset

9:00am 5:00pm11:00am 3:00pm

Note: an application will not last longer than the profile

PUT PUT GET PUT

FTP (Application)

Engineer (Profile)

Modeler Day 3

Application Repeatability

• Serial mode

FTP FTP FTP FTPInter-repetition time Inter-repetition time Inter-repetition time

• Concurrent mode

FTPInter-repetition time

Inter-repetition time

Note: an application will not repeat and last longer than the profile

Modeler Day 3

Configure Servers/Peers

Define profiles

Deploy profiles

Modeler Day 3

Configure Server/Peers (cont.)

Modeler Day 3

Server Supported Service Setup

Modeler Day 3

Server CPU Setup

Modeler Day 3

Server Address

• Uniquely identifies server

• Server address to be mapped to the symbolic server name

Modeler Day 3

Deploy profiles

Deploy Profiles

Define profiles

Modeler Day 3

Deploy Profiles (cont.)

Modeler Day 3

Client Profile Setup

Modeler Day 3

Destination Preferences

• No destination preference => Randomly select among destinations supporting service• Selection weight set on destinations

Explicitly configure destination(s) => Randomly select among destinations specified on client Weight set on client

Server1

Server2

Client

Server2 is 5X more likely to be chosen

Server1

Server2Client

Server1 is 2X more likely to be chosen

I have to choose between: - Server1: weight 20 - Server2: weight 10

My weight is 10Choose me!

My weight is 50Choose me!

Modeler Day 3

Configuring Destination Preferences

Application refers to a symbolic server name, e.g. web_browsing_server

Actual server name is specified in server, e.g. WashingtonDC_Server

Mapping between symbolic server name and actual server name

Modeler Day 3

Configuring Destination Preferences (cont.)

Modeler Day 3

Application Statistics

• Local and global statistics• Client/Server statistics or

calling/called party statistics

• Specific to each application

• Local statistic results will be grouped per profile/application

Modeler Day 3

Lab 1: OPNK2003 Cyber Cafe• Objective

• Apply workflow to configure application traffic

• User behavior profiles

• Configure servers to support applications

• Deploy user profiles

• Refer to lab handout “Lab1: HTTP Application Configuration Lab” on page 1

Define profiles

Deploy profiles

Modeler Day 3

• Troubleshooting• Lab 4: troubleshooting

Modeler Day 3

Configuring Analytical Traffic on Voice and Video Applications• Voice and video: intensive discrete-event applications

• Streaming applications

• Each small packet is modeled

• Long simulation run

• Not scalable

• Solution to improve simulation performances• Analytical traffic

• Interpret all traffic as a background traffic flow

• Loss of accuracy

• Hybrid traffic

• Model part of the discrete traffic in an analytical flow

• Keep accurate response time and jitter

• Still model specific internals of voice application

Modeler Day 3

Hybrid Traffic ConceptDiscrete event traffic

Analytical traffic

Hybrid traffic

Modeler Day 3

VoIP “Traffic Mix” Attribute

Modeler Day 3

Video Conferencing “Traffic Mix” Attribute

Modeler Day 3

Methodology

• Configure most of your VoIP or video nodes with background traffic

• Configure the node of interest to use discrete traffic

Modeler Day 3

Lab2: Configuring VoIP

• Objective• Apply hybrid traffic to generate VoIP traffic and get end-to-end delay

• Refer to lab handout “Lab2: VoIP Application Configuration Lab” on page 26

Modeler Day 3

Application Demand Definition• Abstract of a client-server or client-client application

• Connects two end-nodes• Request/response oriented configuration• Available in “applications” object palette

• Advantages• Configuration friendly• Custom-made traffic• Possibility to use discrete, hybrid, or analytical traffic• Visual representation of the application flows

• Limitations• No specific internals of a standard application• Only for simple traffic patterns

Modeler Day 3

Application Demand Concepts

Client or

server

Client or

server

Requests

TimeStart Time

End Time

Rate (requests/hour)

Responses

Modeler Day 3

Application Demand Deployment

• Click and connect• No need for configuration objects

• Right-click on demand to configure

• Demands can be copied and pasted for duplication

Modeler Day 3

Application Demand Attributes

• Generic traffic configuration• Duration• Request parameters• Response parameters

• Hybrid traffic• Transport protocol

Modeler Day 3

Application Demand Deployment Wizard• Faster deployment to create application demands

• Full mesh

• From one node to many nodes

• From many nodes to one node

• Note:• If 2 or more nodes are selected before starting wizard, configuration applies to selected nodes only• If no node is selected before starting wizard, configuration applies to all nodes in network

Modeler Day 3

Application Demand Statistics

• Statistics per demand collected on end-nodes• Traffic sent/received

• Response time

• No global statistics

Modeler Day 3

Lab3: Deploying Application Demands• Objective

• Generate traffic quickly using Application Demands

• Please refer to lab handout “Application Demand Configuration Lab”

Modeler Day 3

Troubleshooting Guidelines• «I don't see any traffic» or «I don't see expected traffic»

• Check simulation logs

• Look at the “Common problems” section of this presentation

• Use constant distributions to make profile scheduling deterministic

• Collect application Traffic Sent/Received stats in “All Values” mode

• Shows exact size and time data was sent

• Make sure this is not a network issue

• Connect an application demand between your client and server

• See if you get application demand response time statistics

• Scale down the network

• Isolate the problem

• Use “User Defined Reports” in “Scenarios” menu

• Globally visualize attribute settings

• Use “Network Difference Report” in “Scenarios” menu

• Compare to a similar working scenario

Modeler Day 3

Troubleshooting: Simulation Logs

• Simulation = first place to look at

• Available in “DES” menu

Modeler Day 3

Troubleshooting: Simulation Logs (cont.)

“FTP” application “HTTP” application

Simulation

Profile won't repeat if profile duration is equal to simulation duration.

In serial mode, an application will not start if previous application duration is equal to profile duration.

Modeler Day 3

• Profile set on a client doesn't exist

Service set on server doesn't exist

?“FTP (Light)” application

I’m an engineer

Sorry, I don’t know what an engineer is.

I’m running “FTP

(Light)”

Sorry, I don’t know what “FTP (Light)” is.

Modeler Day 3

• All required application parameters are not configured

“FTP (Light)” is a FTP application

Sorry, I need more information to use “FTP (Light)”:

• File size

• Inter-request time

Service set on server doesn't exist

?Profile

“engineer” uses “FTP (Light)”

Sorry, I don’t know what “FTP (Light)” is.

Modeler Day 3

Common Problems ‘Profile start time + application start time offset’ < ‘Convergence time of routing protocols

and spanning tree algorithm etc’

I want to send this FTP packet

Wait, I don’t have a route to the server yet

‘Profile start time + application start time offset’ > ‘Simulation end time’ Common when using exponential distribution with start time and/or start time offset

Simulation

“FTP” application

“Engineer” profileSimulation

Profile start time

Profile start time Application start time offset

Modeler Day 3

Common Problems (cont.) If application duration is longer than profile duration, application will

be terminated when profile is over.

The symbol map “Unlimited” for profile and application “Repeatability” has a default interarrival time of 300 secs by default.

Simulation

300 secs 300 secs 300 secs

Etc…

Modeler Day 3

Common Problems (cont.)

Voice and video conferencing can be configured between two clients/LANs only.

Applications other than voice and video conferencing can be configured between a client/LAN and a server/LAN only.

Voice/Video

FTP, email, database, http,

remote login, print

Modeler Day 3

Advanced Troubleshooting

• Diagnostic traces• Per application type: “ltrace gna_<application_type_name>”

Examples: “ltrace gna_email”, “ltrace gna_ftp”, “ltrace gna_http”• For all applications: “ltrace gna”• Simple example

• Start simulation under ODB • ODB> ltrace gna• ODB> cont

• This is an advanced technique. For more details, see session 1502: Debugging Simulation Models — Introduction

• Run OPNET debugger (ODB)

Modeler Day 3

Lab4: Troubleshooting

• Objective• Learn how to troubleshoot an application setup

• Please refer to lab handout “Application Troubleshooting Lab”

Modeler Day 3

Configuring Custom Application: Workflow

Define Profiles

Configure tiers

Deploy profiles

Configure tasks

Configure custom app

Break down the application

Modeler Day 3

Breakdown of the Application• Identify the tiers

For example, an online e-commerce application might involve• Client• Web server• Authentication server• Database server

Modeler Day 3

Summary

• Standard applications available

• Profile configuration

• Client & server setup for standard applications

• Application demands

• Application modeling techniques

• Troubleshooting

Modeler Day 3

Traffic Modeling Traffic Modeling TechniquesTechniques

Modeler Day 3

Outline

• Motivation for traffic modeling

• Traffic representation

• Traffic generation: sources and import methods

• Traffic modeling: comparison of various OPNET approaches

• Lab #1• Compare accuracy and speed of explicit traffic simulation

with background traffic

• Lab #2• End-to-end delays using hybrid simulation

Modeler Day 3

Motivation

• It is critical to provide good inputs (garbage in → garbage out)• network topology

• traffic

• It is equally critical to choose a traffic modeling technique• simulation speed vs. accuracy

• This session focuses on modeling traffic

Modeler Day 3

Outline

• Lab #3• Flow Analysis

Modeler Day 3

Real-world Traffic Representation• Types of traffic

• WAN, LAN, application traffic

• Traffic representation in OPNET

• Choice of representation depends on modeling purpose• Packet by packet

• End-to-end delays, protocol details, segmentation effects

• Aggregated traffic

• Capacity planning, steady-state routing analysis

Traffic Flows, Device/Link Loads

(Background Traffic)

Aggregated Traffic

Explicit TrafficPacket by Packet

OPNET RepresentationTraffic Type

Modeler Day 3

Parameters in Traffic Representation

• Traffic Parameters• Packet inter-arrival time or arrival rate

• seconds, packets/second

• Packet size

• bits, bytes etc.

• bits/sec = bits/pkt * pkts/sec

• Variability settings• Probability Distribution Function (PDF)

• standard (exponential, bernoulli etc)

• custom

• build your own with PDF editor

• scripted

Interarrival time

File Size

Modeler Day 3

Outline

Modeler Day 3

Sources of Explicit Traffic• Explicit traffic injected at

• Application Layer

• email, HTTP, FTP etc

• ACE, app_demands

• Network Layer

• RPG (self-similar traffic generator)

• Lower layers

• Native protocol sources

• Ethernet, ATM, Frame Relay etc

Modeler Day 3

Sources of Aggregated Traffic• Traffic flows injected at

• Application Layer

• app_demands

• Network Layer

• IP traffic flows

• Lower Layers

• ATM traffic flows

• Element loads• CPU utilization

• Link loads

• Do not require source models

IP Traffic Flow

app_demand

Modeler Day 3

Traffic Data Import

Traffic Data

Network monitoring software samples traffic periodically using probes

Export to text files or OPNET recognizable formats

Import into OPNET

Modeler Day 3

Importing Explicit Traffic – Packet Trace

• Packet traces captured using network analyzer• Sniffer analyzer

• tcpdump

• windump

• Application Characterization Editor (ACE)

Modeler Day 3

Importing Server Data• Import from

• HP OpenView Performance Agent

• BMC Patrol• Concord SysEDGE• NetIQ AppManager• Generic XML

• Server Characterization Editor (SCE)

Modeler Day 3

Importing Aggregated Traffic – Flow Data• Flow-specific data • Demand objects

Modeler Day 3

Importing Aggregated Traffic – Link Loads

• Link load information from• Concord NetworkHealth

• MRTG

• Spreadsheet (text info)

• Can be converted into traffic flows

Modeler Day 3

Outline

Modeler Day 3

Simulation Techniques

• Discrete event simulation• Model all traffic (data, signaling, management) using packets

• Account for all timers in every protocol layer

• Perform every state/event transitions of all protocol layers

• Analytical simulation• Abstract queue performance using mathematical equations

• Model traffic as state information in various network elements

• Hybrid simulation• Mix of modeling approaches (discrete event + analytical)

• Mixture of traffic types (explicit traffic + aggregated traffic)

Modeler Day 3

Comparison of Various Simulation Techniques

Modeler Day 3

Examples of Analytical Methods

Used by mac layer in LAN models

Used by IP CPU

Modeler Day 3

Analytical Simulation

• Delay estimation

• Capacity planning

• Routing analysis

• QuickPredict

• Flow Analysis performs analytical simulations for steady-state analysis

Modeler Day 3

Example of Discrete Traffic Simulation

• TCP congestion window management

• End-to-end delays at application layer

Application

Presentation

Transport

Network

Data Link Layer

Physical

Session

Application

Presentation

Transport

Network

Data Link Layer

Physical

Session

Congestion Window

E2E Delay

Modeler Day 3

Discrete Event Simulation

• Packet retransmission due to varying acknowledgment delays

• TCP/ATM connection setup delay for varying congestion levels of a network

Modeler Day 3

Micro-Simulation – Delay Estimation

• Delay estimator (t) for explicit packets due to additional aggregated traffic contending for a common resource (such as a link)

• Retrospective micro-sim as lazy evaluation on real packet arrival

• Sensitive to queuing schemes like PQ, CQ and WFQ

b1 b2 b3

Micro-simulation

Modeler Day 3

Analytical Coupled with Micro-Simulation

b1 b2 b3

Micro-simulationAnalytical-simulation

When real packets are separated by a long intervalLazy evaluation in two stages: analytical + micro-simulation

Currently implemented for FIFO queues onlyGain in simulation speed compared to pure micro-simulation

Modeler Day 3

Hybrid Simulation

Modeler Day 3

Outline

Modeler Day 3

• Create a simple network with explicit traffic and run a simulation

2. Duplicate the network and replace the explicit traffic with corresponding background traffic

• Run the simulation with background traffic

• Assess/compare the accuracy and speed of the two traffic modeling approaches

• Refer to lab manual for instructions

Lab 1: Overview

Modeler Day 3

Destination nodes

Source nodes (video servers) with different ToS (1,2,3) Interface with WFQ

100 video users (MPEG4) - 3 available service classes

Queuing delays ?

Lab 1: Network Model

Modeler Day 3

Aggregated Traffic – Just a Number to Compute a Delay• Aggregated traffic in OPNET

• Traffic flows (routed background traffic)

• Device/link loads (static background traffic)

• Common to both type of aggregated traffic• Internal representation: just a number for a given node/link

• Effects: only one effect – to produce a delay

• One difference between the two types of aggregated traffic• Traffic flows (routed background traffic) needs to be propagated to each

node in the flow path tracer packets (propagators)

Modeler Day 3

Defining Traffic Flows

• 3 basic steps

Modeler Day 3

Defining Traffic Flows (cont.)

• Each flow is broken down into intervals as specified

Interval : 300-600 seconds

Modeler Day 3

I1 I2 I3 I4 I5

Simulating Traffic Flows

• Refresher tracer packets

P1 P3 P4 P5P2

Modeler Day 3

Simulating Traffic Flows (cont.)

• Sending new information on traffic level changes

start time = 150.00.0 I1 I2 I3 I4 I5

Modeler Day 3

Effects on Traffic Flows

• Clipping• Effect: to reduce traffic flows to within bottleneck capacities

• Modeled as: state information on each node, bps and pps rates inside tracer packet diminished downstream of the bottleneck

• Segmentation:• Effect: to reduce packet size to within MTU

• Modeled as: bps and pps rates inside the tracer adjusted to account for overhead due to segmentation

• Load Balancing:• Split traffic flows proportionally among available paths

• Modeled as: create copies of tracer packets with modified bps and pps rates

Modeler Day 3

Load Balancing Traffic Flows

0.5 * 0.75 = 0.375

0.3750.375

Modeler Day 3

Outline

Modeler Day 3

Lab 2: Hybrid Simulation - Overview

• Video Conferencing end-to-end delays

• WAN – with background traffic

• Create one explicit flow – hybrid simulation

• Observe dependence of the explicit traffic end-to-end delay on Type of Service (ToS) used

Modeler Day 3

Lab 2: Network Model

• WAN with many background traffic flows• One explicit video traffic flow from Seattle Houston

(130 kbps – 360 kbps)• End-to-End delays ?• Refer to lab manual for instructions

Modeler Day 3

ModelingModelingLarge NetworksLarge Networks

Modeler Day 3

Agenda• Conceptual goals

• Importing network topologies

• Choosing aggregation levels

• Using LAN models

• Importing traffic

• Using routed background traffic

• Managing projects and scenarios

• Navigating Large Topologies

• Controlling Simulation Runtime

• Effectively Using Background Traffic

• Software goals• Import topology

• Question and answer browser

• Import traffic

• Network browser

• Traffic browser

• Efficiency Modes

• Static Background Traffic

• Event Speed Parameter

• Specifying Traffic Growth

• Scheduling Automated Simulations

• Viewing and Editing Scheduled Simulations Log

Modeler Day 3

Overview – Large networks

• The concept of a “large” network does not necessarily refer to the number of nodes or the geographic extent of a network.

• A large network is any model that will generate a significant amount of events. This translates into longer simulations and memory limitation issues.

• We will explore methods for increasing the efficiency of your models when the economies of scale become an issue.

Modeler Day 3

Common Pitfalls

• OPNET is powerful software that tempts users with “grand designs”.

• Common Pitfall: “I will model everything”

• Developing models without clear direction and a solid understanding of the questions that need answering leads to inefficiency, and results that aren’t useful.

Modeler Day 3

Questions Should Drive Model Design

• It essential to first determine which questions to answer.

• Design the model to answer those questions. Don’t try to answer everything.

• A key factor in effective modeling is flexibility. Realize that over the course of the modeling process that the questions may change.

Modeler Day 3

LAN Models

• Single nodes may be used to model entire LANs.

Modeler Day 3

Why Use LAN Models?• LAN models are a powerful

mechanism for abstracting complex local area networks that may contain multiple nodes with the same configurations.

• LAN models reduce clutter in the workspace.

• LAN models use less memory.

• LAN models generate fewer simulation events allowing simulations to run faster.

These models represent the same network.

Modeler Day 3

• LAN Models behave as if they were specific nodes modeled using OPNET.

• The key difference is that you can collect statistics on the LAN models but not on the specific nodes and links within the model.

Additional Information About LAN Models

Modeler Day 3

Modeling Techniques

• Design Accurate, Efficient Models

• Two Techniques• Approximation

• Reduction

Modeler Day 3

Approximation

• Tradeoff: Precision vs. Performance

• Loss in precision means higher variance

• Overall results are still accurate

• Approximation Approach

• Apply a combination of analytically and explicitly modeled traffic

• Allows you to limit the number of variables, while retaining the proper traffic behavior for the model

Modeler Day 3

Traffic Types

• Three different types of traffic • Loads

• Also called “Device/Link Loads”• Represent percentage of capacity being used • Can be imported or manually created

• Flows • Visualized as demand objects• Can be imported or manually created

• Packets• Provide detailed performance statistics

• Delay, response time, jitter• Represent different types of application traffic• Can be imported from optional ACE module or manually created

• All three can exist simultaneously in the network model

Modeler Day 3

Importing and Characterizing Applications• With the Application Characterization Environment (ACE) module,

you can model any networked application by capturing the packets associated with that application, then importing them into Modeler.

Modeler Day 3

Link Loads

• Represent utilization of individual links

• Values are represented in percentage utilization for each time period• Utilization A->B

• Utilization B->A

• To set link loads manually:• Right-click a link, edit attributes

• Expand “Background Utilization” attribute

• Set utilization percentages for multiple time periods

• To import data from management platforms:• Traffic / Import Device/Link Loads

• MRTG

• InfoVista

• Concord eHealth-Network

• Text Files

Modeler Day 3

• Represent flow of network traffic between sources and destinations in network

• Flows are represented in bits/sec and packets/sec

• Flow data can be imported from management platforms• Cisco NetFlow (AS Aggregation or No Aggregation)

• Cflowd

• NetScout

• NetScout Ngenius

• NAI Distributed Sniffer / Sniffer Pro

• Agilent NetMetrix

• Spreadsheet / text files

• You can add new flows manually by choosing: Protocols / IP / Demands / Configure Traffic Demands Among Selected Nodes

Modeler Day 3

• Flows are a type of traffic demand. Demands appear as dotted blue lines from source to destination.

• Right-click a traffic demand to edit its attributes or hide the demand

• Use View / Demand Objects to hide/show all demands

• Use Traffic / Open Flows Browser to quickly examine many flows

Modeler Day 3

Packets

• Only used for discrete event simulation (DES) • Represent individual packets in network

• Application traffic• LSAs

• Application Configuration node used to globally define application traffic

• LSAs automatically sent by routers during simulation• Capture the transient behavior of the network

• Convergence• Latency• Queue depth • Protocol effects

• Verify Service Level Agreement compliance

Modeler Day 3

Converting Loads to Flows

• Import load traffic

• Gather information about traffic characteristics in real network

• Traffic / Convert Link Utilizations to Flows…

• Give Modeler constraints:

• List of possible endpoints of traffic flows

• Max/min amounts of traffic per endpoint

• Modeler performs conversion

• Caveat: This is an approximation!

• More constraints = more realistic flows

• Flow traffic can be used for failure, routing, and QoS studies

Modeler Day 3

Summary: Traffic Modeling

• Different traffic types available for different types of studies

• Three types available for import or creation:• Flows

• Loads

• Packets

• Flows are best choice for failure studies

• Loads are often easiest to obtain and best for viewing utilization of current network

• Packets are only used in discrete event simulation. Packets give the most detailed results and are the best choice for QoS studies.

Modeler Day 3

Object Reduction

• Each and every object in a model uses memory.

• Reducing the number of objects in a simulation allows for more efficient simulations, possibly allowing the workstation to overcome memory limitations (reduce swapping).

• Modeler provides LANs, Clouds and devices with varying interfaces to allow you to keep the number of objects in the network model to a minimum without sacrificing precision.

Modeler Day 3

Object Reduction

• LANs allow you to represent any number of workstations and a server as a single object.

• IP Clouds abstract numerous IP devices into a single cloud object.

• Each interface in a device requires memory. Creating devices that have the minimum amount of interfaces required for a model reduces memory needed to run simulation. • Example-- If all the hubs in a model will only have 8 connections, it is more

efficient to use an ethernet8_hub than an ethernet64_hub. Even if this doesn’t represent your actual hardware, it will not affect the precision of the simulation.

Modeler Day 3

Alternative Solutions

• There are other solutions that don’t involve model design.

• These alternative solutions can be characterized as “brute force” methods.

• The advantage to alternative solutions is that it gives you more latitude in your model designs.

• Increasing physical memory is always an effective way to increase workstation performance.

• Increasing the swap space is another effective method to get a better performance from a computer.

Modeler Day 3

Controlling Simulation Runtime

• Every protocol in Modeler has attributes associated with them. These attributes represent real-world application of a protocols procedures and techniques.

• In many cases, although representing a protocol’s actual behavior, certain attributes may not add value to a user’s model. In fact they will generate events that are not helpful to the results of the model and will actually increase simulation run-time.

• Modeler accounts for this by enabling certain efficiency modes in order to decrease the number of unimportant events and accelerate simulation run-time.

Modeler Day 3

Controlling Simulation Runtime

• When configuring a simulation, you will be able to view and edit a list of simulation attributes. These attributes will change based on the protocols being modeled.

• Among these attributes are a variety of efficiency modes that are enabled.

• Right-clicking on a simulation attribute will provide you with a complete description of that attribute.

Modeler Day 3

Importing Topology Information

• OPNET can import topologies from• ACE

• ATM Text files

• HP Network Node Manager

• Device Configurations (MVI Module)

• XML files

• VNE Server

Modeler Day 3

Aliases• An alias is a name used to reference a particular node in OPNET.

• An alias may be an IP address, MAC address or a user friendly name.

• An object may have multiple aliases.

• These aliases are used as endpoints for imported traffic.

• LAN models retain the aliases for all nodes that are contained in the LAN.

• This makes it possible to address traffic to the appropriate LAN model.

Modeler Day 3

Navigating Large Topologies

• OPNET provides you with various tools to facilitate the locating and selecting of nodes in a large network:

• Select Objects Logically

• Network Browser

Modeler Day 3

Edit / Select Objects

• Choose Edit / Select Objects to select certain objects throughout network based on the value of attributes.

• Ex: Select all links with a data rate greater than 1.544 Mbps

Modeler Day 3

Network Browser

• The Network Browser can be used to locate objects in your network.

• Choose View / Show Network Browser

• Type a search string into the “Find” box to show objects with that string in their names.

Modeler Day 3

Network Browser• To view an object’s attributes, right-click the object in the workspace

or the list and select “Edit Attributes.”

Modeler Day 3

Managing Projects and Scenarios

• Managing scenarios allows you to examine the status of scenario results, change project/scenario names and run multiple simulations sequentially.

Change the scenario name here.

Change the simulation duration.

Collect results on multiple scenarios by changing the results column to <recollect>. Clicking OK will start a simulation run for each scenario with <recollect> set.

Change the project name here.

Ok will write all of the changes to the project.

Modeler Day 3

Summary• Networks can be imported in a variety of manners.

• Modeler’s power as modeling software becomes evident with the analysis of large networks. As the size of the model increases so does the importance of efficient modeling.

• Avoiding common pitfalls and understanding the efficiency techniques inherent in Modeler leads to useful results and efficient models.

• By skillfully using the combination of the three types of traffic, you can achieve a comfortable balance of performance and precision.

1 modeler day 3 © copyright 2003 opnet technologies, inc. modeler day 3

opnet technologies

traffic day

modeler day

traffic modeling techniques

applications workflow

analytical traffic

majority of traffic

bonus slide

Documents

performance evaluation of 802.11p-based ad hoc vehicle...

simulation model to improve qos performance over fixed...

1 modeler day 1 © copyright 2003 opnet technologies, inc....

network simulation tools â€“ opnet modeler - king fahd...

chapter 1 introduction -...

sdp implementation in manet using opnet modeler...

opnet tm modeler cs 541 advanced networking spring 2009

opnet modeler overview

network simulation tools â€“ opnet modeler

development of laboratory exercises based on opnet...

opnet modeler day 1. © copyright 2001 opnet technologies,...

overview riverbed opnet network r&d solutions · defacto...

network simulation in the classroom for teaching ... ·...

1 modeler day 1 © copyright 2003 opnet technologies, inc....

investigation of bandwidth requirement of smart meter...

simulating wireless networks using opnet...

opnet modeler

jpa modeler - netbeans day, hyderabad 23-april-2016

1 introduction to modeler © copyright 2004 opnet...

introduction to opnet modeler -...