Notes about network simulators

Compiled by Thierry Ernst ­ INRIA Sophia­Antipolis 
MISTRAL Team ­ France 
30/10/1997

1.  Introduction

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: 

l MIT's NETSIM 
l NIST 
l CPSIM 
l INSANE 
l NEST 
l REAL 
l NS 
l OPNET 
l And some others... 

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. 

2.  MIT's NETSIM 3.1

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.  

l Use

All kinds of networks made of components that send messages to one another can be modeled. 

l The package

The simulator framework only provides the means to schedule events and to communicate with the user. It provides a simple X window graphic user interface 
(GUI) representation capability to display the topology of the network and the data of its operation. The GUI displays graphic objects (components buttons, 
information windows, meters) and information objects (parameters and queues). Some component parameters may be changed during runtime by clicking in the 
relevant window, this affecting the simulation. 

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. 

l Implementation of the simulator

Components are things like links, hosts, switches and network connections. Every component has a class (e.g. link) and a type and has to handle a set of events. 
They are stored in a doubly­linked list while Netsim is running and are represented by a data structure and an action routine. 

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 
 Components are things like links, hosts, switches and network connections. Every component has a class (e.g. link) and a type and has to handle a set of events. 
They are stored in a doubly­linked list while Netsim is running and are represented by a data structure and an action routine. 

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. 

l Simulation engine

There is not much information available, but we can conclude that the simulator engine is very simple. It's a single process written in C. It merely provides the means 
to schedule events. Events may include a packet and are inserted in an event queue and ordered according to the fire time. The event queue is therefore not a FIFO 
nor a LIFO. Events that should have occured in the past (i.e. with a fire time smaller than the clock) are not allowed to be inserted in the queue. There is no 
particular order for concurrent events scheduled to fire at the same time. The scheduler extracts the event at the head of the queue, it sets the logical time of the 
clock to that of the fire time of the event if it is greater and calls the action routine of the component related to the event. The action routing produces other events 
and defines the time at which they should fire. 

Time is maintained in an unsigned 32­bit value. The simulator can then run for almost 12 hours of simulated time.  

3.  NIST

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. 

l Use

The simulator has two major uses: ATM network planning and ATM protocol performance analysis. As a planning tool, the simulator is run with various network 
configurations and traffic loads and produce statistics (link utilization, throughput rates of VCs). As a protocol analysis tool, it is used to study the total system 
effect of a particular protocol, such as mechanisms for fair bandwidth allocation, protocol overhead, bandwidth utilization, effectiveness of flow control mechanisms. 
The designers claim that modules simulating components can be easily changed or added. 

l The Package

There are basically no major differences with MIT's NETSIM. The tool is therefore written in C and it provides an interactive modelling environement with a GUI 
using the X window system running on a UNIX platform. This displays the topology of the network and the parameters associated with the components which are 
simulated. Input and output parameters of the component appear in information windows, while network activity is recorded in meter windows (binary meters, 
bar graph, histogram, etc). The simulator also has an event manager, I/O routines and other tools in order to build components. 

However, the user can now direcly create a new network topology with the GUI. 

l Implementation of the simulator

Most files look much the same, so does the scheduler, but components have been replaced in order to match the ATM requirements. Components are sending 
messages to one another and are represented by an action routine and a data structure. Every component has a class a type and particular class may contain several 
types of components. For more details, see NETSIM. 

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. 

4.  CPSIM

CPSim is a parallel general­purpose simulation tool commercially available created by Groselj Boyan (BoyanTech Inc.)  

l Use
4.  CPSIM

CPSim is a parallel general­purpose simulation tool commercially available created by Groselj Boyan (BoyanTech Inc.)  

l Use

Parallel discrete­event simulation (PDES) is well­suited for large discrete­event simulations such as computer networks. A freely available version is limited to 
256 simulated objects. 

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. 

l The Package

The objective of the designers is performance. There is no graphical user interface; the authors claim that it makes little sense to specify a model by dragging and 
dropping icons on a screen. The simulator is designed to give the user complete freedom in creating models. There are no built­in functions neither. It is therefore 
designed for simulation professionals. 

l Implementation of the simulator

There is a strict separation between CPSim kernel and CPSim library. The kernel provides for synchronization, scheduling, deadlock prevention and message 
passing on multicomputer platforms. The library consists of C functions. 

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. 

l Simulation engine

Event­scheduling is done locally at each processor. Events arriving at a particular object are non­decreasing. Insertion therefore takes constant time since they are 
always inserted at the tail of the queue. 

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. 

5.  INSANE

INSANE is a network simulator designed at University of California at Berkeley in 1996. 

l Use

INSANE stands for Internet Simulated ATM Networking Environement and is a special purpose simulator constructed for evaluating performance of various IP 
over ATM policies in heterogeneous internetwork. The PhD's thesis and one paper written by the author, Bruce Mah explain the simulation and evaluation process 
that led to the construction of this simulator and show how they use it to measure the performance of several simulated Internet applications in a heterogeneous 
network of more than a thousand hosts. 

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. 

l The Package

INSANE is an object­oriented, discrete­event simulator. The core and some primitive objects are written in C++. Built­in objects include various types of 
queues and some protocols modules (IP, TCP, UDP) and export a set of commands which allows new composite objects such as an ATM switch to be created 
and manipulated by using Tcl scripts invoked from configuration files. A library of Tcl scripts is provided with the source distribution. Simulation and customization 
is therefore performed with Tcl scripts; the advantage is that no compilation is required to construct new simulations. Tcl is an interpreted language, but there is no 
performance degradation in using Tcl since the actual computation is performed by the compiled C++ code. This approach is taken by other simulation packages, 
as for instance Ptolemy or NS. 

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

6.  NEST 2.5

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. 

l Use

It has been used for the simulation of a load­balancing system based on microeconomic principles, for the study of the ARPANET topology update problem, 
and by the Northrop Research and Technology Center to simulate Noahnet protocols (network architecture based on flooding protocols). It is well suited to 
understands behavior of routing protocols, as routing loops for instance. The authors describe the simulation of the Routing Information Protocol (RIP) in a 
paper published in Communications of the ACM (Oct 1990, Vol.33, No.10), 

l The package

The tools is best described as a client­server model: display clients are connected to the simulation server by a socket. The simulation server is responsible for the 
execution of simulation runs. Clients are independent programs used to create, configure a simulation model and control its execution, using a GUI that 
communicates with the simulation via a TCP/IP connection and allows to dynamically create or modify the network configuration. The system requires low 
communication bandwidth. 

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. 

l Implementation of the simulator

NEST is implemented as a library of functions linked together with the user's code. It is written in C although any language could in theory be used as soon as it 
follows the standard stack discipline (eg: C, Pascal). The simple communication facilities of NEST allow the user to concern only with the highest level of a protocol 
or distributed system. 

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.  

l Simulation engine

The simulation runs within a single unix process. This involves a minimum amount of context switching overhead compare to multi­tasking implementations. NEST 
supports a lightweight process mechanism to facilitate simulation of complex distributed system (hundreds to thousands of nodes are claimed). Each node has a 
thread of control (lightweight process) associated with it. This means that each node has its own stack for local variables while global variable and dynamically 
allocated memory are shared. On the other hand, links functions do not have a separate thread of control. They are called when a message is sent from one node to 
another. An important function of the scheduler is therefore performing the context switching between nodes. The node functions must be re­entrant (i.e. no global 
or static variables) since the same functions may be performed by more than one node. The communications between nodes is represented as messages, simulated 
by a shared memory model. Messages are queued at the receiving node in the order in which they would have arrived in the simulated network. 

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.  

7.  REAL 5.0 (08/97)

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. 

l Use

NEST is intended for studying the dynamic behavior of flow and congestion control schemes in packet­switched data networks (namely TCP/IP). 

l The package
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. 

l Use

NEST is intended for studying the dynamic behavior of flow and congestion control schemes in packet­switched data networks (namely TCP/IP). 

l The package

REAL provides 30 modules written in C that emulate flow­control protocols such as TCP, and 5 scheduling disciplines such as FIFO, Fair Queueing, DEC 
congestion avoidance and Hierarchical Round Robin. 

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.  

l Implementation of the simulator

The NEST code has been rewritten to make it less general, cleaner and faster. REAL is still implemented as a client­server program. The code is freely available 
to anyone willing to modify it. 

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. 

8.  NS version 2.0 (VINT project)

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. 

l The VINT project

The VINT project is part of the University of Southern California and is funded by the DARPA in collaboration with Xerox PARC and LBNL. The project aims 
in building a network simulator that will offer innovative methods and tools. The work will focus on scaling and protocol interaction issues in integrated services 
internet. 

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. 

l Use

At the time being, NS is well­suited for packets switched networks and is used mostly for small scale simulations of queueing algorithms, transport protocol 
congestion control, and some multicast related work. It provides support for various implementations of TCP, routing, multicast protocols, link layer, MAC, ... 
It currently has memory limitations in the face of large simulations. See the proposition from the VINT project to make it scale for thousands of nodes. 

l The package

This current non­beta version of NS implements key protocol modules for unicast and multicast routing, reservation, transport and session protocols. The 
VINT project will particularly study the interaction of routing and reservation setup protocols and mobility, IP integrated services support over technologies such as 
ATM and wireless, security, multicast routing, Web caching and switch packet scheduling algorithms. 
 It currently has memory limitations in the face of large simulations. See the proposition from the VINT project to make it scale for thousands of nodes. 

l The package

This current non­beta version of NS implements key protocol modules for unicast and multicast routing, reservation, transport and session protocols. The 
VINT project will particularly study the interaction of routing and reservation setup protocols and mobility, IP integrated services support over technologies such as 
ATM and wireless, security, multicast routing, Web caching and switch packet scheduling algorithms. 

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. 

l Implementation of the simulator

The simulation is configured, controlled and operated through the use of interfaces provided by the OTcl class Simulator. The class provides procedure to create 
and manage the topology, to initialize the packet format and to choose the scheduler. It stores internally references to each element of the topology. The user creates 
the topology using OTcl through the use of the standalone classes node and link that provide a few simple primitives. 

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. 

l Simulation engine

The simulation engine is extensible, configurable and programmable. The current implementation is single­threaded (only one event in execution at any given time). 
It does not support partial execution of events nor pre­emption. 

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. 

l Forecoming changes to NS

NS has scaling constraints in terms of storage requirements of the routing tables: each node maintains a route to all other nodes in the network, resulting in aggregate 
memory. This grows with the number of nodes in the network. VINT proposes to replace NS's flat addressing conventions by implementing efficient hierarchical 
routing table look­ups in the nodes objects. 

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 
 memory. This grows with the number of nodes in the network. VINT proposes to replace NS's flat addressing conventions by implementing efficient hierarchical 
routing table look­ups in the nodes objects. 

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.  

l Large scale issues

Since the simulation is likely to generate enormous amounts of data, visualization will have to play a key role and will be added to all phases of the simulation 
process, from inputs to outputs. 

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. 

9.  OPNET

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. 

l Use 

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

l The package 

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. 

You can find some more information about OPNET compiled by UCL (University College London). 

10.  Other simulators and links

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. 
10.  Other simulators and links

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. 

l MARS 

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. 

l NETSIM from University of Richmond 

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.  

l SimuNet is a commercial simulation package. It is a centralysed network simulator tested for a 50 node network running OSPF. 

l The PTOLEMY project 

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 

l Prophesy is a commercial network and workflow simulator. 

l GPSS is a general purpose simulation software. 

l FAST is a hardware simulator. 

l NETSIM++ from University of Bucarest 

l IPv6 with JAVA from University of Texas 

l Quality of service ­ Java from University of Ohio. 

Last modified: 31 August 2000

Thierry Ernst ­ Thierry.Ernst@inrialpes.fr at Inria Sophia­Antipolis for Projet Mistral 

File translated from T EX by T T H, version 0.9.