opnet l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Opnet PowerPoint Presentation
Download Presentation
Opnet

Loading in 2 Seconds...

play fullscreen
1 / 62

Opnet - PowerPoint PPT Presentation


  • 803 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Opnet' - jacob


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
questions and objectives
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

approach
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

project editor
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

remarks
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

model library
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

model naming convention
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

choosing link models
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

object palettes
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

object attributes
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

choosing statistics
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

running simulation
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

models
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

data flow among objects
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

modeling approach
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

simulation approach
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

simulation type
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

opnet simulation
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

opnet simulation21
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

opnet simulation22
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

node editor
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

node editor26
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

process
Process

TCOM512

process model
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

traffic types
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

tradeoffs
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

debugging
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

debugging32
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

simulation kernel
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

distribution package
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

event package
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

interface control information package
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

identification package
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

internal model access package
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

interrupt package
Interrupt package
  • Concerned with providing a process with information about incoming interrupts and the ability to schedule outgoing interrupts

TCOM512

packet package
Packet package
  • Contains collection of kernel procedures concerned with manipulating packets

TCOM512

programming package
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

process package
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

simulation package
Simulation package
  • Collection of kernel procedures concerned with providing simulation-wide services

TCOM512

statistic package
Statistic package
  • Mechanisms for writing user-defined and automatically computed statistics to simulation output data files

TCOM512