Opnet

1
Introduction

2
 Questions and objectives
 What does modeler do?
 How can it help you?
 How easy it is to use?
 How to get started?
 Objectives
– How to use Modeler software in a hands-on environment?
– How to use Modeler to solve practical problems?
 Prerequisites
– Basic understanding of networks (TCOM 500)
– Ability to program in C/C++

TCOM512
3
 Approach
 Opnet uses a project-and-scenario approach to modeling networks
– Project is a collection of related network scenarios in which each explores a
different aspect of network design
» A project contains at least one scenario
– Scenario is a single instance of a network.
 Workflow
– Create project
– Create baseline scenario
» Import or create topology
» Import or create traffic
» Choose results and reports to be collected
» Run simulation
» View results
– Iterate by duplicating the scenario and changing parameters

TCOM512
4
 Project editor
 Need to map from network specifications to a modeled network
– Use the Startup Wizard to specify the initial environment of a scenario
– Select objects from an Object Palette
– Use Node and Link objects to represent an actual topology
– Use rapid configuration to quickly deploy common network topologies
– Edit the attributes of nodes and links to customize their behavior

TCOM512
5
 Remarks
 Annotation palette
– Topology-> open annotation palette
– A documentation tool
– Annotations can be hidden
» View->show annotations in subnet
 Subnets
– Abstracts network components specified within it into a single object
– Powerful mechanism for breaking down a network’s complexity
» Makes use of links and nodes
 Nodes represent servers, workstations, switches etc
 Links represent the physical links between nodes
 Modeler provides a suite of standard and vendor models
– Can create a new model or derive models from an existing database

TCOM512
6
 Model library
 Extensive library of standards-based and vendor models
 Variety of objects for creating networks
– Traffic generators (servers, workstations etc)
– Network devices (hubs, routers, switches etc)
– Links (SONET, 10BaseT etc)
– Vendor device models (Cisco, HP, Lucent)
 Available libraries
– Standard model libraries
– Vendor model libraries
– Specialized model libraries

TCOM512
7
 Model naming convention
 Naming convention for the node models
– <protocoln>…<protocoln>_<function>_<modifier>
– <protocoln> is an abbreviation that specifies a particular protocol that is
supported in the model. N represents the number of protocol interfaces
– <function> indicates the general function
– <modifier> indicates level of derivation
– Example: ethernet128_hub_adv
 Naming convention for vendor models
– <vendor_name>_<device_name>_<number_of_slots>_<configuration>
– Eg: CS_4000_3s_e6_f_fr2_sl2
» Represents cisco systems 4000 router with 3 slots, 6 ethernet ports,
1FDDI port, 2 frame relay ports and 2 SLIP ports

TCOM512
8
 Choosing link models
 Appropriate link must be chosen to match interfaces on
connected devices
– Reqs being data rate, protocol and number of available interfaces
– Link model naming convention
» <protocol>_<modifier>
» Eg: 10BaseT_adv

TCOM512
9
 Object palettes
 Graphical dialog box that displays a group of node and link
models
 Change palettes using the pull-down menu
 Palettes can be customized to contain only the nodes and links
that you require
 Deriving new models
– Right click on an object in the palette
– Makes it easy to configure and integrate models for specialized needs
 Device creator
– Can select any number of interfaces and protocols a device needs
– From the “Topology” pull-down menu

TCOM512
10
 Object attributes
 Attributes define the object and govern the way the object
behaves
– Every object has attributes
– To view/modify an object’s attributes
» Right-click on the object
» Select “edit attributes” or “advanced edit attributes”
» Group of objects can have their attributes assigned simultaneously
by using “Apply changes to selected objects” button

TCOM512
11
 Choosing statistics
 DES -> choose individual statistics
 Types
– Global: related to the entire network
– Node: related to individual nodes
– Link: related to individual links
– Collect stats on individual nodes and links
» Right click on an object and select choose individual DES stats
» To obtain complete definitions of statistics, right click on the
statistic in the “Choose Results” window

TCOM512
12
 Running simulation
 Run simulation
– DES/Configure/Run Discrete Event Simulation
 After simulation completes
– Check simulation log for errors
» DES/ Open DES Log
» Contains errors generated during simulation
» Always check DES log for errors before trusting results
– Network objects – nodes
» Subnets, links
» modules
 Includes processors, queues, transceivers and generators
 Processors: primary general purpose building blocks of node models
 Queues: offer all functionality of processors and can also buffer and
manage a collection of data packets

TCOM512
13
 Models
 Node model
– Layering of protocol functions
 Process model
– Initial state
– Forced state: does not allow pause during the process (Green)
– Unforced state: allows pause during the process (Red)
– Transitions describe the possible movement of a process from state to
state and the conditions allowing such a change
– Executive blocks
» Each state has enter executives and exit executives
 Kernel procedures
– Pre-written functions
– All begin with prefix “op_”

TCOM512
14
 Data flow among objects
 Packets are the basic unit of information exchange in
Modeler simulations
– A single system might have multiple types of packets with different
formats
 Information is exchanged among different objects via various
communication mechanisms
– Node to node: Links
– Module to module: packet streams and statistic wires
» Packets flow between modules via packet streams
– State to state: transitions

TCOM512
15
 Modeling approach
 Modeler provides a structured modeling approach
– Nodes and links make up the network model
– Node model contains various modules
– Each module contains one or more processes
– Each process has a state transition model
– Each state of the state transition model contains logic in C/C++.
 A different editor for each of the above entities

TCOM512
16
 Simulation approach
 Steps
– Understanding the proposed system
– Understanding the goal
– Choose aspects to be modeled
– Determine the granularity
– Define data input and output
» Vary a few inputs and focus on the important outputs
» Vary the input over a range
– Specifying the system model
» Keeping in mind the features/constraints of the simulation software
– System results “explainable”
– Results sufficiently detailed
– Results statistically justifiable
» Simulate for longer durations
TCOM512
17
Events

18
 Simulation type
 Event driven simulation
– Event is a request for a particular activity to occur at a particular point in time
– Time, in the simulation advances when the event occurs
» OPNET, ns2 are event driven simulation packages
– Other option
» To have a simulator that samples at regular intervals
 Inefficient and accuracy limited
 Event list
– OPNET maintains a single global event list
» Tuple of time, event type, module
– All objects access a shared simulation time clock
– Events are scheduled on the list in chronological order
» Event has data associated with it
– Event removed from the list when it has been processed
– Simulation time advances only when an event with a later time is taken from the list
– No simulation time occurs during an invocation of a process model
– No time elapses during transition between states
» Process model must be in an unforced state (see later) for time to advance
TCOM512
19
 Opnet simulation
 Interrupts
– The event at the head of the list becomes an interrupt
» Delivered by the simulation kernel to the designated module
» Process in the module gains control and processes interrupt
 More events might be added to the event list during this processing
 Simultaneous events
 Event that reaches first is executed first
 Events from a higher priority module are executed first
» Simulation regains control from module, deletes event from event list and
attends to the new event at the head of the list
– Data associated with the event can be obtained by the module when the interrupt
occurs
– Initial interrupts on the event list can be placed by certain modules, processes
and queues
 Simulation kernel
– Simulation Kernel manages the event list
– Each event is delivered in sequence to the appropriate module
– New events are inserted in the event list by the simulation kernel

TCOM512
20
 Opnet simulation
 Event list
– Some events have to be initialized on the list
– Event list is dynamic (events being added and deleted from the list)
– Event is pending until it is executed
– Pending events can be cancelled
 States in the process FSM
– Forced states
» Process invokes the enter and then the exit executives
» Evaluates the condition statements associated with transitions
» If exactly one condition evaluates to true, that transition is executed
– Unforced states
» Invokes the enter executive and stops after this
» Releases control to the simulation kernel and becomes idle
» Resumes at the suspension point and executes the exit execs when next
invoked
» Followed by executing a transition based on the condition that is true
 Process model example
TCOM512
21
 Opnet simulation
 BEGSIM Interrupt
– BEGSIM is a special type of interrupt that occurs at time 0.0
– Usually initializes an interrupt and schedules future events
– Any processor or queue can have this interrupt enabled
» The event is then places on the event list for time 0.0
 Simulation termination
– Simulation terminates when
» Event list is emptied
» Simulation attribute “duration” expires
» Process calls for termination using a KP (op_sim_end())
» Fatal error occurs

TCOM512
22
Node level

TCOM512
23
Node level

TCOM512
24
 Node editor
 Processor: building block of node models. Can be connected to other
modules to share information or packets
 Queue: superset of a processor module. Can be connected via packet streams
to other modules
 Packet streams: connection between modules that carries data packets from
source module to destination module.
 Statistic wire: connection between modules that conveys numeric values
between devices or processes in the same node
 Logical association: connection used to indicate a logical relationship
between two modules. Does not carry any data.
 Transmitters: outbound interface between packet streams inside a node and
links outside the node.
 Receivers: inbound interface
 Antenna: module used to specify the antenna properties for transmitters and
receivers.

TCOM512
25
 Node editor
 Node interfaces
– Interfaces -> node interfaces
– Can be used to specify various node characteristics
» Node type, attributes, comments
 Node statistics
– Interfaces -> node statistics
– To select which statistics have to be collected in project editor

TCOM512
26
Process

TCOM512
27
 Process model
 Process model
– Series of logical operations performed on data
– In OPNET describe real-world processes such as queuing disciplines, traffic
generators, communication protocols
 Toolbar
– Create state
– Create transition
– Set initial state
– State variables block
– Temporary variables block
– Header block
– Function block
– Diagnostic block
– Termination block
– Compile code
TCOM512
28
 Traffic types
 Three different types of traffic
– Loads
» Represent utilization of individual links
» Can be imported or manually created
» Right click a link, edit attributes-> background utilization
– Flows
»Can be imported or manually created
»Represented in bits/sec and packets/sec
»Traffic->create IP traffic flows
»Add new flows: protocols/IP/Demands/Configure traffic demands …
»View/demand objects to hide/show all demands
– packets
» Provide detailed performance statistics
 Delay, response time, jitter
– All three can exist simultaneously

TCOM512
29
 Tradeoffs
 Load
– Easiest data to obtain
– Can’t be rerouted in failure case
 Flow
– Data routed according to routing protocol settings
– Good for failure studies
 Packet
– Provides very detailed statistics
– Simulated in DES
– Configured manually
– Lengthy simulations

TCOM512
30
 Debugging
 Error log
– New entries at end of file
– Should be occasionally cleared
 FIN, FOUT and FRET Macros
– FIN: Macro used to label a function
» Used by OPNET to populate function call stack
» Place after local variables in C
– When using FIN macro replace return keyword with
» FRET(value) replaces return(value)
» FOUT replaces return;
– FIN without FRET/FOUT will result in a standard function stack
imbalance
 Compiler warnings
– Results in <home>/op_admin/tmp/cc_err
TCOM512
31
 Debugging
 ODB capabilities
– Execute single and multiple events
– Set breakpoints for specific events, times, modules and processes
 Activating ODB
– From simulation editor,
» check box for Use OPNET Simulation debugger
– From the command line
» op_runsim –net_name project1-scenario1 –debug
– To end the simulation
» quit (terminates normally) or exit (immediate)

TCOM512
32
 Simulation kernel
 Distribution package
 Event package
 Interface control package
 Identification package
 Internal model access package
 Interrupt package
 Packet package
 Programming package
 Process package
 Simulation package
 Statistic package
 Topology package
TCOM512
33
 Distribution package
 Collection of kernel procedures concerned with generating
stochastic values according to a specified prob. distribution
 KP
– op_dist_exponential()

– op_dist_uniform()

TCOM512
34
 Event package
 Collection of kernel procedures concerned with providing a
process about events in the simulation
– Event package uses Evhandle’s to refer to events
– So provides access to the events in the event list
– local events
» Events scheduled to occur at the module that calls the KP
– Self interrupts, remote interrupts
– Scheduled or forced events
» Scheduled event placed in the list
» Forced event by-passes the event list and interrupts immediately

TCOM512
35
Event package

TCOM512
36
Event package

TCOM512
37
Event package

TCOM512
38
 Interface control information package
 Structured collection of data transferred between processes
– A form of inter-process communication
– Main application
» Layered protocol interfacing
– ICI is associated with an interrupt if the process installs the ICI prior
to taking the action that causes the interrupt
– Dynamic simulation entities
– A format associated with ICI
» Created using the ICI format editor

TCOM512
39
ICI package

TCOM512
40
ICI package

TCOM512
41
ICI package

TCOM512
42
ICI package

TCOM512
43
 Identification package
 ObjectId
– Uniquely identifies a single object within a simulation
– Hierarchical relationship
» Parent-child
» Nodes are parents of modules, subnets are parents of nodes and links
– Processes are not objects
» So ObjectId of a process is that of the surrounding processor or queue

TCOM512
44
 Internal model access package
 Provides dynamic access to simulation entities
– That belong to simulation as a whole and not an object
– Attributes are declared within process models

TCOM512
45
 Interrupt package
 Concerned with providing a process with information about
incoming interrupts and the ability to schedule outgoing
interrupts

TCOM512
46
Interrupt package

TCOM512
47
 Packet package
 Contains collection of kernel procedures concerned with
manipulating packets

TCOM512
48
Packet package

TCOM512
49
Packet package

TCOM512
50
Packet package

TCOM512
51
 Programming package
 Collection of kernel procedures concerned with providing
advanced programming services
– List sub-package
– Log sub-package
– Memory and pooled memory sub-package

TCOM512
52
Programming package

TCOM512
53
Programming package

TCOM512
54
Programming package

TCOM512
55
 Process package
 Provide the ability to create and manage multiple processes within the
context of a single processor or queue
– Root process
» The process associated with each processor or module
– Child process
– processID
» Unique positive integer assigned to each process
– Shared memory mechanisms
» To support communication of information between processes that co-exist
in a queue or processor
» Module memory
 Installed for a module by any process that is owned by that module
» Parent-to-child memory
 Provided by parent to child processes
» Argument memory
 Provided on an invocation by invocation basis

TCOM512
56
Process package

TCOM512
57
Process package

TCOM512
58
Process package

TCOM512
59
 Simulation package
 Collection of kernel procedures concerned with providing
simulation-wide services

TCOM512
60
 Statistic package
 Mechanisms for writing user-defined and automatically
computed statistics to simulation output data files

TCOM512
61
Statistic package

TCOM512
62