The aim of this compilation is to overview some of the simulators currently available. It focuses on network simulators specifically and summarizes the information available so far about some of the most popular ones. It gives a description of the simulator, its use and target, the tools provided with it and try to describe the simulation engine and the implementation of the network components to be simulated.
This compilation doens't pretend to be exhaustiv since many research centers have designed simulators for their own purpose and specifically designed for the simulation of a particular protocol or problem. This results in a plethora of simulators, sometimes based on a more general one or a common initial framework that evolved differently over time, which where not intended to evolve and are unsuitable for other simulations. Moreover, the documentation available is often sparse and poor, or confidential, bugs are not fixed, later versions are not made available and the simulators have not evolved with the protocol they were intended to simulate at the time being.
As a result, some simulators are better described than the others in this compilation which retained only those where enough information was provided to understand their purpose and operation. I have sometimes added some comments.
The following were considered:
Links to the appropriate web sites were to find more details are always given for each simulator presented here. There is an interesting web site that points to some of them.
NETSIM is an event driven simulator for packet-switched networks designed at the MIT LCS Advanced Network Architecture group for their personal use. The simulator isn't intended to evolve, but is made freely available here to anyone interested. The documentation mentions the latest version 3.1 (25/5/94), but it doens't seem to be available on-line.
The package also comprises an event manager, I/O routines, various structural tools such as queues and lists used to build components, and a toolkit. The toolkit is a library of C functions that eases the manipulation of components and allows to create, save, load and display the network configuration, and to associate information windows with the components.
In order to run a simulation, the user has to write new components in C, to modify a few files and to compile and link them. He then creates the simulation with the toolkit.
The action routine is called whenever an event is sent to the component. Events handled by a component are of three types: command, regular and private. Private events are events a component sends to itself, regular events are those which are concerned with the actual running of the simulation, and commands are those which perform housekeeping actions. The action routine has to respond to a predefined set of events besides user-defined ones since the management of components (creation, deletion, ...) has to be coded by the user in the action routine. The action of components is therefore entirely defined by the user and written in C and is not affected by the framework of the simulator.
Parameters are information that characterize a component and need to be displayed on the screen or saved in a file (inputs given by the user and outputs produced by the simulator). Input parameters may be specidied at the time of component creation or may be modified during run time. They are stored in a singly-linked list and may as well directly be referenced by a pointer in the data structure of the component, this avoiding the action routing to search through the list.
The simulator implements static routing by the use of components of type connection. A route is a list of adjacents components, starting and ending with a connection component.
Components available in the current version are an Ethernet link, a point-to-point link, a switch (switches packets between several links), a host (about the same as a switch), Purdue's implementation of TCP, data supplier and consumer from TCP, a simple Poisson traffic source and a packet sink.
Since the simulator was designed for packet-switched networks, it includes a packet data type, but its data structure is not constrained to any particular format. The user may therefore implement new data types like cells or any other convention to communicate between components, but components have to be rewritten in order to correspond to the new data structure.
There are two implementations of list. One kind allocates a chunk of memory where to store a pointer once a new element is added to the list. Adding and removing an event is slower, but an element can be placed on several lists. The other requires that the element being placed on the list contains the pointer to link it into the list. No extra memory is needed to link it into the list, but it can only be on one list at a time. In addition to lists, the simulator includes a hash table and a memory pool modules originally written to speed up memory allocation.
Time is maintained in an unsigned 32-bit value. The simulator can then run for almost 12 hours of simulated time.
The National Institute of Standards and Technology (NIST) has developed its ATM network simulator for studying and evaluating the performance of ATM networks and is based on NETSIM developed at MIT. The user manual and the source code are freely available. It gives a good example of use of NETSIM.
However, the user can now direcly create a new network topology with the GUI.
In NIST, available classes of components are Physical links, ATM switches, Broadland Terminal equipment (B-TE) and ATM applications. More precisely, ATM applications are traffic generators, of type TCP/IP, CBR, VBR (batch or poisson), and ABR (constant, batch, or poisson).
As an instance of parameters, the input parameters of a switch provided by the user may be the delay to process a cell, the slot time, the output queue size, etc, whereas the output parameters monitored by the simulator may be the number of cells received or dropped, etc.
CPSim is a parallel general-purpose simulation tool commercially available created by Groselj Boyan (BoyanTech Inc.)
There exists two possible approaches for parallel simulation: optimistic and it conservative. CPSim employs the conservative rule. In the optimistic approach, events are processed at each object as soon as they become available, whereas in the conservative approach they are processed at simulation time t only if no more event is expected at simulation time t.
The CPSim kernel exists in two versions, one for parallel architectures, and the other for uniprocessors. This allows portability on many platforms, but above all, the uniprocessor version allows to develop and debug the model before executing it and the parallel version. BojanTech Inc. claims that CPSim simulations executed on a single processor can outperform a classical event-list simulation.
Discrete-event simulations are written in C. The simulation model is represented by a directed graph of communicating objects, partitioned among the processors. The graph is static during simulation, but future versions of CPSim will allow modification of the graph on-the-fly. The underlying programming model is event message passing between objects.
The granularity of the objects is defined by the user. An object could for instance be a telephone switch. To create a simulation, the user defines the event data structure, the object graph and writes code for processing the events.
An object may have several input queues, but the scheduler takes the event with the smallest time-stamp among all of them. Synchronization between objects is handled by null events that carry time-stamps of future event messages. Upon scheduling of a null event, the object is blocked and an other object is examined by the scheduler. Each object maintains a local simulation time at which it is ready to accept an event.
INSANE is a network simulator designed at University of California at Berkeley in 1996.
INSANE was used to simulate a wide-area ATM backbone (similar to XUNET II testbed). Since results are processed off-line, they ran a serie of postprocessing scripts over the output file to analyse the network performance.
The simulator is a single process, but in order to run large simulations, a GUI facilitates the monitoring of multiple simulation jobs running on various machines.
It uses traffic models derived from Danzig and traffic traces that mimic applications. Applications run on top of the simulated Internet protocol stack which in turn can use two different data link layers (ATM or a generic LAN). The ATM stack uses FIFO and RCSP (Rate-Controlled Static Priority) queueing. It provides a simple AAL protocol similar to AAL5 which perform fregmentation and reassembly of packets, and a signalling protocol to perform admission control and resource allocation for new channels. The simulated switch implements Early Packet Discard (EPD). The IP module use a static routing table loaded at configuration time.
INSANE's objects are basically implemented in the fashion of a finite state machine. Objects communicate by posting events to each other. They react to events by updating their own state and causing events to happen. Events are messages containing the time at which the event should fire, the destination object, the type and a data field.
The scheduler delivers events to the relevant object according to their chronological order. It is apparently based on a calendar queue. Calendar queues are a particular implementation of priority queues, and are said to require heavy processing.
NEST was developed at Columbia University department of Computer Science and stands for NEtwork Simulation Testbed. Code and documentation are freely available. The tool is targetted for simulating and prototyping distributed algorithms and systems.
Dividing the simulation and the GUI offers several advantages. First, it allows to save CPU resources by running the simulation on a dedicated CPU whereas the GUI runs on a workstation. Basically, a complex simulation study can be executed on a remote super-computer This is particularly useful for a multisite project and this permits to support clients over a wide-area network. Secondly, this separation allows multiple GUIs to interact with the simulation at the same time. Users can connect and disconnect at any time.
The topology is represented as a connectivity graph of links and nodes stored internally as a table. The user develops the topology of a communication network using a set of graphical tools. New node functions and communication link behaviors created by the user are linked with the network model.
NEST is not a discrete-event based simulator. The simulation proceeds in a series of synchronization passes, whose length can be specified by the user and modified dynamically. The scheduler selects the node with the earliest simulated time using a round-robin scheduling so that each node receives equal amount of running time. Several lists of nodes are maintained based on the status, availability of messages and the progress of the simulation of other nodes.
Once selected, a node runs for a fixed amount of simulated time equal to the pass time. It is then moved to the run list for the next pass, unless it performs the call awaiting for messages, in which case it is suspended and placed on a wait list where the node with the earliest available message is at the head. This is necessary to ensure the correct ordering of events since other nodes running later in real time but earlier in simulated time might have posted messages to this node with an earlier simulated time. Once all nodes on the run list have been run, the scheduler takes nodes off the wait list.
Since the user is allowed to dynamically modify the configuration, additional constraints must be added to preserve consistency when those real-time events are sent by the user. This can therefore only take place between passes in order to ensures that messages are dequeued in the proper order.
REAL (REalistic And Large) is a network simulator written at Cornell University by S. Keshav and based on a modified version of NEST 2.5.
The description of the network topology, protocols work-load and control parameters are transmitted to the server using a simple ascii representation called NetLanguage where the network is modeled as a graph. This latest release now includes a GUI written in Java. The topology is created graphically, and simulations can be directly run on a server located at Cornell University without having to download and build the simulator.
Node functions implement computation at each node in the network whereas queue management and routing functions manage buffers in nodes and packet switching. Routing is static and is based on Dijkstras's shortest path algorithm. A node could be a source, a router or a sink. Source nodes implement TCP-like transport layer functionality. Routers implement the scheduling disciplines, while the sinks are universal receivers that only acknowledge packets.
Since NEST didn't not allow for timers, REAL sends out a timer packet from a source back to itself to return after some specified time, but timers cannot be reset using this method.
You may find more information about REAL here.
NS is a object-oriented discrete-event simulator for networking research based on REAL. Initially, NS version 1.0 was developed by the Network Research Group at the Lawrence Berkeley National Laboratory (LBNL). Its development is now part of the VINT project under which NS version 2.0 was released.
The aim is not to design a new network simulator, but to unify the effort of all people working in the field of network simulation. Basically, most of the current network simulators focus only on single protocols and simulate protocols in isolation. They do not address interactions with other components of the architecture. Efforts are therefore narrow, primitive and isolated. There is also a lack of comparability across simulations. There is here a tremendous duplication of effort.
Furthermore, the various components of a network (application types, load, topology, ...) are continuously involving over time. Since the internets are becoming more and more complex in terms of scale, number of interacting protocols and hardware and operating systems issues, it is harder to design, prove the correctness of protocols and to evaluate their performance. Startup costs for the design of a simulator are so high that it is beyond the scope of any single commercial company or university.
At last, but not least, current simulators rarely provide tools for visualization and interpretation of results.
The VINT project therefore proposes to increase synergy among the simulation community. Effort from all the researchers will interact. and enhance the initial framework. The researchers involved in the project have extensive experience with network simulation based on the experience with MIT's NETSIM, University of Maryland's MARS, UC Berkeley's REAL, Columbia's NEST and LBNL's NS. The project will build on NS and NAM (Network ANimator, an animation tool for viewing the simulations results and packet trace data).
The VINT project will target on evaluating both the correctness and performance of wide area internet networks at all levels, from routing to session protocols. It will push the scaling capabilities as fas as possible and will offer a composable simulation network (in order to model the modularity of the Internet and to support component modules from many contributors), various abstraction techniques and tools (to provide the ability to vary the level of abstration), visualization techniques (to better interpret results, according to various level of granularity), an emulation interface (to allow the actual nodes to interface with the simulator) and extensible and extensive libraries of network topologies and traffic generators.
The VINT project is looking forward to be used by the reliable multicast group at the IRTF. This should promote VINT as a community standard for simulation comparisons in published work.
The complete project is likely to take 3 years.
NS is written in C++. The package provides a compiled class hierarchy of objects written in C++ and an interpreted class hierarchy of objects written in OTcl (MIT's object extension to Tcl - Tool Command Language) which are closely related to the compiled ones. The user creates new objects through the OTcl interpreter. New objects are closely mirrored by a corresponding object in the compiled hierarchy.
Tcl procedures are used to provide flexible and powerful control over the simulation (start and stop events, network failure, statistic gathering and network configuration). The Tcl interpreter has been extended (OTcl) with commands to create the networks topology of links and nodes and the agents associated with nodes.
The function of a node is to receive a packet, to examine it and map it to the relevant outgoing interfaces. A node is composed of simpler classifier objects. Each classifier in a node performs a particular function, looking at a specific portion of the packet and fowarding it to the next classifier.
Agents is another type of components of a node: those model endpoints of the network where packets are fed or consumed. Users create new sources or sinks from the class Agent. NS currently supports various TCP agents, CBR, UDP, and others protocols, including RTP, RTCP, SRM. There is no mention of ATM protocols.
Links are characterized in terms of delay and bandwidth. They are built from a sequence of connectors objects. The data structure representing a link is composed by a queue of connector objects, its head, the type of link, the ttl (time to live), and an object that processes link drops. Connectors receive packet, perform a function, and send the packet to the next connector or to the drop object. Various kinds of links are supported, e.g. point-to-point, broadcast, wireless.
The output buffers attached to a link in a ``real'' router in a network are modeled by queues. In NS, queue are considered as part of a link. NS allows the simulation of various queueing and packet scheduling disciplines. C++ classes provided include drop-tail (FIFO) queueing, Random Early Detection (RED) buffer management, CBQ (priority and round-robin), Weighted Fair Queueing (WFQ), Stochastic Fair Queueing (SFQ) and Deficit Round-Robin (DRR).
Traffic generation in NS looks rather basic in the current implementation. For the purpose of TCP, only FTP and Telnet traffic can be generated; otherwise, NS provides an exponential on/off distribution and it allows to generate traffic according to a trace file.
In order to analyze results, NS provides classes to trace each individual packet as it arrives, departs or is dropped, and to record any kind of counts, applied on all packets or a per-flow basis. The trace can be set or unset as desired by the user.
The user has to specify the routing strategy (static, dynamic) and protocol to be used. This is done with a procedure in the class simulator. Supported routing features include asymetric routing, multipath routing, Distance Vector algorithm, multicast routing (PIM, ...).
Other features of NS include error models where the unit could be packet, bit or time based, and mathematical classes for the approximation of continuous integration by discrete sums and for random number generation (implementation of the minimal standard multiplicative linear congruential generator of Park et al). In order to verify some aspects of the protocol to be simulated, NS includes some validation tests distributed with the simulator. Is as well includes capabilities to make the simulation topologies dynamic although this latest point is still somewhat experimental.
Events are described by a firing time and a handler function. The type of event scheduler used to drive the simulation can be chosen among the four presently available: a simple linked-list (default), heap, calendar queue, and a special type called real-time. Each one is implemented using a different data structure.
The simple linked-list scheduler provides a list of events kept in time-order, from the earliest to the latest. This requires scanning the list to find the appropriate entry upon insertion or deletion. The entry at the head is always executed first. Entries with the same simulated time are extracted according to their order in the list.
The heap scheduler code is borrowed from the MARS-2.0 simulator (that itself borrowed the code from MIT'S NETSIM). This implemetations is superior to the linked list scheduler when the number of events is large. Insertion and deletion times are in O(logn) for n events.
In the calendar queue scheduler implementation, events with the same ``month/day'' of multiples ``year'' are recorded in one ``day''.
The real-time scheduler is still under developpement and is currently a subclass of the list scheduler. It is well suited when events arrive with a relatively slow rate. Execution of events should occur in real time.
NS represents an underlying transmission link and its corresponding scheduling and queueing algorithms in a single object, but the VINT simulation framework will require their separation in order to flexibly combine different scheduling algoritms with different underlying link technologies. In the current implementation of NS, each modules that implemtents a scheduling discipline need be changed when adding modules to support a new link type.
Another modification is the performance improvement to the event scheduler. The linear search insertion algorithm should be replaced with a heap or a calendar queue. Coexistent sheduling algorithms can be derived from base class abstraction and are easily implemented in NS due to its C++ implementation.
A tool that generate random topologies according to user-specified parameters will help in describing very large topologies; a tool for the manipulation of data packets at the bit level allows detailed tests.
For the study of protocol interaction and behavior at significantly larger scale, the simulator will provide two levels of abstraction. The detailed level simulator is the one currently built. It allow a fine abstraction of the distincts modules of the simulation and will later include an emulation interface that will allow to incorporate a real network node as a component of the simulation. The session level simulator will give a coarse-grain abstraction. Data packets will be represented by flows instead of individual packets. This will reduce the number of events and state required, at the cost of lost detail in the simulation. As an instance, instead of tracing each packet through each router and link, the simulator only calculate the time for that packet to be received by the sink according to the path used.
The project also hope to apply parallel network simulation techniques because the limits of a single-processor computational power will necessarily be stressed. The projec will implement a distributed version of the simulator.
OPNET (Optimized Network Engineering Tools) is a commercial tool from MIL3 Inc. It is being developed for almost 15 years. As everyone should guess, no much technical detail are available about the internals.
Network with several hundreds of nodes can be simulated, but it would take time for the computation. OPNET is used by companies like Thomson-CSF or CNET which use it to model ATM networks and validate various layers protocols, packet switched radio networks, .. You can see an example of use of OPNET from George Mason University (Quality of Service IP Network Simulation).
The software comprises several tools and is devided in several parts, OPNET Modeler and OPNET Planner, the Model Library, and the Analysis tool. Features included in this generic simulator are an event-driven scheduled simulation kernel, integrated analysis tools for interpreting and synthesizing output data, graphical specification of models and a hierarchical object-based modeling..
OPNET Modeler is intended for modeling, simulating and analysing the performance of large communications networks, computer systems and applications. Common uses are assessing and feasibility of new designs, optimizing already developed communication systems and predicting performance.
The modeling methodology of OPNET is organized in a hierarchical structure. At the lowest level, Process models are structured as a finite state machine. State and transitions are specified graphically using state-transition diagrams whereas conditions that specify what happen within each state are programmed with a C-like language called Proto-C. Those processes, and built-in modules in OPNET (source and destination modules, traffic generators, queues, ...) are then configured with menus and organized into data flow diagrams that represent nodes using the graphical Node Editor. Using a graphical Network Editor, nodes and links are selected to build up the topology of a communication network.
The Analysis Tool provides a graphical environment to view and manipulate data collected during simulation runs. Results can be analysed for any network element.
OPNET Planner is an application that allows administrators to evaluate the performance of communications networks and distributed systems, without programming or compiling. Planner analyses behavior and performance by discrete-event simulations. Models are built using a graphical interface. The user only chooses pre-defined models (from the physical layer to the application) from the library and sets attributes. The user cannot define new models, he should contact MIL3's modeling service.
The modeling libraries are included with OPNET Modeler and OPNET Planner and contains protocols and analysis environments, among them ATM, TCP, IP, Frame Relay, FDDI, Ethernet, link models such as point-to-point or bus, queueing service disciplines such as First-in-First-Out (FIFO), Last-In-First-Out (LIFO), priority non-preemptive queueing, shortest first job, round-robin or preempt and resume.
In the ATM library, 16 processes models implement the functions of ATM, the AAL and the IP interface. It provides for buffer management, congestion control, segmentation and reassembly, modeled explicitly or analytically. The ATM library can be used for instance to model and evaluate Adaptation Layer (AAL) protocols; or to analyse the behavior of virtual path and circuits under various best effort congestion control schemes at the physical layer
In the IP library, interfaces to other protocols such as ATM or Ehernet are provided.
There are many more simulators. I have just listed some of them. Note that various people named their simulator NetSim, not necessarily derived from the initial MIT's, which adds some extra difficulties to clear one's mind in this plethora of special purpose simulators.
MARS is a discrete event simulator designed for the study of network routing protocols. It allows to add new routing protocols modules. Its support for transport layer protocol and application source models is very limited. A primitive GUI is provided.
Netsim is a single process discrete event simulator designed for the study of Local Area Network network performance. It provides a very detailed description of single bus segment networks running the Ethernet (CSMA/CD) protocol. It includes a modeling of signal propagation and is implemented in C. It simulates a finite population network (the author claims this produces more accurate results since a simulation based on an infinite population model produces asymptotic delay behavior), and does not model packet buffering at individual station since each station is assumed to generate a new arrival only after their previous packet has been successfully transmitted. It uses a simple single ordered queue of events that contains one entry for each station on the network.
The project focuses on design methodology for reactive systems (reactive systems are those that interact with their environment at the speed of the environment.) and uses multiple models of computation in a hierarchical heterogeneous design environment. It is intended for specifying, simulating and generating code for signal processing and communication systems. Ptolemy is divided in a set of domains: the synchronous dataflow domain models synchronous signal processing systems, discrete-event domain for the simulation of systems in time and the finite state machine domain. The package includes a GUI interface to design tools (eg: Matlab), Tcl and X window toolkit called Tk that allows for customized, animated, interactive simulations. For more information, see Ptolemy's web page or its mirror site in France and Ptolemy's archives
Last modified: 31 August 2000
Thierry Ernst - Thierry.Ernst@inrialpes.fr at Inria Sophia-Antipolis for Projet Mistral