Network Simulation with OMNeT++

1. Network Simulationwith OMNeT++ András Varga AU Seminar, RMIT University, Melbourne April 8, 2005

2. Part One Introducing OMNeT++

3. What is OMNeT++? Generic simulation framework • for the simulation of complex distributed systems: distributed hardware and software architectures, communication networks, … • technically: a C++-based simulation kernel plus a set of libraries and tools (GUI and command-line)

4. Model Structure Component-oriented approach:- The basic building block is a module. - Simple modules can be grouped to form compound modules.- Modules are connected with each other.

5. NED(Network Description Language) defines topology: how modules are assembled to form larger modules and whole models The graphical editor GNED operates directly on NED files Components (simple modules) modules are programmed in C++ send messages, react to received messages collect statistics using the simulation class library random number generation statistics collection (histograms, etc) queues and other containers topology discovery and routing ... Defining the Model // // Host with an Ethernet interface // module EtherStation parameters: ... gates: ... submodules: app: EtherTrafficGen; llc: EtherLLC; mac: EtherMAC; connections: app.out --> llc.hl_in; app.in <-- llc.hl_out; ... endmodule

6. An Example Component • A module which generates jobs at random intervals // // Generates jobs with exponential // inter-arrival times of mean=1s // simple Source gates: out: out; endsimple C++ which defines behaviour #include <omnetpp.h> class Source : public cSimpleModule { public: Module_Class_Members(Source,cSimpleModule,0); virtual void initialize(); virtual void handleMessage(cMessage *msg); }; Define_Module(Source); void Source::initialize() { cMessage *msg = new cMessage("timeout"); scheduleAt(0.0, msg); } void Source::handleMessage(cMessage *msg) { cMessage *job = new cMessage("job"); send(job, "out"); scheduleAt(simTime()+exponential(1.0), msg); } NED definition Usage in NED ... submodules: src: Source; ... connections: src.out --> ... Appearance in the GUI

7. Simulation Results OMNeT++ provides support for recording and visualization of: • vector results: a sequence of (time, value) pairs recorded during simulation • examples: • queue length during simulation in the function of time • end-to-end delays of arrived packets • scalar results: values of variables, typically recorded at the end of simulation • examples: • total number of packets dropped • average throughput (total #bits / total sim. time) line charts of output vectors scalar results as bar chart and x-y plot (scatter plot)

8. Creating Model Documentation • Models can be self-documenting: neddoc tool generates fully hyperlinked HTML from commented NED sources • Links to C++ docs (Doxygen) • Built upon XML/XSLTtechnology

9. Modular Architecture simulation user interface CMDENV or TKENV or ... Simulation model ENVIRmain() SIM ModelComponentLibrary • Modular architecture enables embedding of simulations into larger systems • UI and simulations are separated, and interact via a well-defined API • default user interface can be customized (or specialized ones can be created)

10. What kind of systems can be simulated?

11. Part Two Simulation of Communication Networks with OMNeT++

12. Model Suites • INET Framework: TCP, UDP, IP, Ethernet, MPLS models • IPv6Suite: IPv6, MIPv6, HMIPv6, IEEE 802.11 • Mobility Framework: mobile and ad-hoc networks; includes IEEE 802.11 model (ad-hoc mode only) • OppBSD: ongoing effort to port the FreeBSD kernel's networking stack into OMNeT++

13. INET Framework • INET Framework: • TCP • currently Tahoe, Reno – plus well-defined extension API to implement other flavours • transmission configurable: byte count only, byte arrays, message objects • UDP • IPv4, ICMP; static routing table autoconfiguration • PPP, Ethernet (10Mb, 100Mb, 1Gb; switched/shared medium) • MPLS with signalling protocols (LDP, RSVP-TE) • several traffic generators and generic application models • other protocols can be implemented and plugged in at any layer

14. INET Framework • Coming soon: • 802.11 ad-hoc/infrastructure mode • OSPFv3 • SCTP, RTP • interoperability with the IPv6 models • TCP, UDP and all apps will automatically support IPv6 as well

15. The Mobility Framework • A framework for wireless and mobile simulations. MF can be used for: • fixed wireless networks • mobile wireless networks • distributed (ad-hoc) and centralized networks • sensor networks • many other simulations that need mobility support and / or a wireless interface • Developed at TKN (Telecommunication Networks Group), TU Berlin • http://mobility-fw.sourceforge.net

16. The Mobility Framework • The core defines a framework for constructing models of wireless nodes • supports mobility via pluggable movement models such as constant speed, random waypoint, etc. • models the physical wireless channel (computes SNR, etc.): various channel models can be plugged in • manages connectivity between nodes (based on proximity) • pluggable L2 and higher layer protocols and application models • A library of standard protocols are being developed: • 802.11, AODV, ... • goal is to have a rich library of such protocols to enable easy plug-and-play simulations of various kinds of widely used protocols.

17. Mobility Framework: Layered Architecture SNR t Blackboard: manages shared variables • node position, radio state, etc • publish-subscribe SNREval: physical layer model • input: “AirFrame” (tx power, freq) • calculates SNR changes over frame duration Decider: frame received correctly? • input: SNR, output: yes/no • may account for error correction, etc. MAC: medium access protocol • CSMA/CA, 802.11, etc

18. OppBSD • OppBSD: an effort to port the FreeBSD kernel's networking stack into OMNeT++ • every simulated host or router runs its own copy of a stripped FreeBSD kernel • advantages: exact emulation of the FreeBSD behaviour, FreeBSD kernel patches (e.g. KAMA patch for mobile IPv6) can be easily incorporated, OMNeT++ may be a good environment to try "kernel hacks" • disadvantages: monolithic model, internals not visible, relatively heavy-weight • Development at Institute of Telematics, University of Karlsruhe • project leader: Roland Bless • code available on request

19. Part Three A Simulation Case Study

20. Case Study: File System Simulator Case Study: FSS, simulation of components involved in a file system • Written by Joel Sherrill (RTEMS author, OAR Corp.) in 2000, as part of his PhD research FSS was used to investigate: • Disk Cache Management algorithms (No Cache, FIFO Cache, LRU Cache, Priority LRU Cache, Fair Share Cache, Priority LRU Cache with Priority Inheritance, …) • Disk Scheduling algorithms (FIFO, SSTF, CScan, NStep CScan, Scan, NStep Scan, Priority, Priority Scan, Priority CScan, Priority NStep Scan, Fair Share, Preemptive Priority NStep Scan, Preemptive Fair Share,…) • over various physical disks • and with various applications (disk request generators)

21. File System Simulator: Architecture Layered approach: Disk Request Generator - simulates application profiles IO Library - simulates IO Library mapping (FILE*->fd) System Call Interface - simulates the OS syscalls File System - simulates file IO to block number mapping Disk Cache - simulates various Disk Caching algorithms OF SPECIAL INTEREST IN THE STUDY Disk Driver - logical block number to physical disk location mapping Access Manager - controls access to physical disk drive Disk Scheduler - simulates various Disk Scheduler algorithms Physical Disk - simulates various physical disks

22. FSS: The OMNeT++ Model • The model: each layer = one module For any particular run, one would choose one of:No Cache, FIFO Cache,LRU Cache,…

23. FSS: Running the Model • Parameter space was systematically explored (all possible combinations were run) #! /bin/bash for cache in "NoCache FIFOCache LRUCache PriorityLRUCache..."; do for sched in "FIFOScheduler SSTFScheduler CScanScheduler..."; do ( echo "[Parameters]" echo "filesystem.generator_type = \"GenerateFromFile\"" echo "filesystem.iolibrary_type = \"PassThroughIOLibrary\"" echo "filesystem.syscalliface_type = \"PassThroughSysCallIface\"" echo "filesystem.filesystem_type = \"PassThroughFileSystem\"" echo "filesystem.cache_type = \"${cache}\"" echo "filesystem.blocktranslator_type = \"NoTranslation\"" echo "filesystem.diskscheduler_type = \"${sched}\"" echo "filesystem.accessmanager_type = \"MutexAccessManager\"" echo "filesystem.physicaldisk_type = \"HP97560Disk\"" ) >algorithms.ini ./filesystem done done

24. Part Four Advanced Usage Scenarios

25. Real-Time Simulation Real-timesimulation: virtual time is synchronized to real time Pacedsimulation: virtual time by a constant factor slower/faster than real time Implementation • every event must be synchronized to real time: the simulation kernel must wait before executing an event until “the time comes” • simulator must be fast enough (i.e. faster than real system) In OMNeT++: • configure simulation kernel to use Real-Time Scheduler Configuring for Real-Time simulation [General] scheduler-class = "cRealTimeScheduler"

26. Hardware-in-the-Loop Simulation Hybrid or HW-in-the-loop: simulation is connected to a real-world device or network • simulated device or subnet connects to a real network; • or: a real-life device (or subnet) connect into a simulated network Motivation: • test real devices (hw prototypes, embedded software) in a virtual environment, or virtual devices in a real environment • e.g. real-time training simulator for airplanes Implementing HILS: • implies Real-Time simulation • physical communication with real system must be solved (sockets, PCI, USB, etc) • "external events": anything coming from the real system to which the simulation must react • external events must be inserted into the Future Event Set • simulation kernel sleeping in R-T synchronization must be woken up whenever external events occur

27. Demo

28. Multiple Replications In Parallel • Multiple Replications in Parallel (MRIP): • Monte Carlo simulations: for statistically trustworthy results, several independent runs with the same parameter settings (but with different random number seeds!) are necessary • to save time, these simulation runs can be performed in parallel • 3rd party software: Akaroa • helps harness the computing power of a network of inexpensive workstations • created at University of Canterbury, New Zealand by Prof. Dr. K. Pawlikowski et al. • needs permission for commercial use • OMNeT++ simulations can run under Akaroa control

29. Parallel/Distributed Simulation Parallel/Distributed Simulation:Executing a single model, with its parts distributed over several processors (multi-CPU boxes, clusters) This is not MRIP (Multiple Replications in Parallel) -- here we split up the model between hosts. Motivation: • speed: we expect speedup • memory: model too large for one machine PDES: Parallel Discrete Event Simulation

30. PDES: How? LP2 (on CPU2) LP1 (on CPU1) LP3 (on CPU3) • Partitioning • Synchronization • no partition should be allowed to "rush forward" (it could receive a message from others into its past!) (LP=Logical Process)

31. PDES: OMNeT++ Support • Easy and flexible partitioning • via omnetpp.ini • Synchronization mechanism • Null Message Algorithm • Suitable models can be run without modification • suitable: no global variables, must have inherent parallelism • no instrumentation necessary [Partitioning] *.tandemQueue[0]**.partition-id = 0 *.tandemQueue[1]**.partition-id = 1 *.tandemQueue[2]**.partition-id = 2 [General] parallel-simulation=true parsim-synchronization-class= "cNullMessageProtocol" parsim-communications-class="cNamedPipeCommunications" #parsim-communications-class="cMPICommunications"

32. Parallel Simulation Architecture Simulation Model Simulation Kernel Parallel simulation subsystem Synchronization Event scheduling, sending, receiving Partition (LP) Communication communications library (MPI, sockets, etc.)

33. Demo

34. Thank You Questions? Ask now! or email me at: andras@omnetpp.org