1 / 62

Opnet

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

jacob
Download Presentation

Opnet

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Opnet

  2. Introduction

  3. 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

  4. 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

  5. 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

  6. 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

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. Events

  19. 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

  20. 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

  21. 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

  22. 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

  23. Node level TCOM512

  24. Node level TCOM512

  25. 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

  26. 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

  27. Process TCOM512

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

  33. 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

  34. 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

  35. 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

  36. Event package TCOM512

  37. Event package TCOM512

  38. Event package TCOM512

  39. 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

  40. ICI package TCOM512

  41. ICI package TCOM512

  42. ICI package TCOM512

  43. ICI package TCOM512

  44. 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

  45. 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

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

  47. Interrupt package TCOM512

  48. Packet package • Contains collection of kernel procedures concerned with manipulating packets TCOM512

  49. Packet package TCOM512

  50. Packet package TCOM512

More Related