Opnet

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