• Skeleton simulation, Index, Code.
• Media Access simulation: Index, Code.
• Data Link Layer simulation: Index, Code.

In this document, I will try to supply the information required to accomplish several goals, among them are:

• Supply a brief background on event driven simulations of network protocols.
• Provide a "skeleton" which can be used (modified) to test many protocols.
• Document the procedure by which the skeleton is modified to test a protocol.
• Provide the lecture notes which discuss the data link layer protocol at a relatively high level.
• Provide examples (2) of protocol simulations which show:
  • Ideas of enhancing the skeleton to make it better
  • Concrete examples which use the skeleton to test a protocol
  • Sample runs of the simulations
  • All of the intermediate files which are used/produced during the simulation

In short, the task at hand is to supply a set of software which can be used to test different network protocols.

The motivation for this is to take the emphasis off of writing software and onto understanding the different events in the protocol and how they effect change in the state of the system.

I have attempted to make this a "stand-alone" document in that a user need not have any more than a basic understanding of Computer Networks and Network Protocol Simulations...

...however, this is only 1 of many references on event driven simulations for network protocols. It would require a few hundred more pages to cover the most important 10% of

For further information, see:

• The Society For Computer Simulation International
• Scalable Simulation Framework
• SIMUTools

Editing of my code is strongly encouraged. Some suggestions:

• Fewer global variables....pass variables into each function.
• Some controls would be nice also. Error checking is a minimum - both in the scripts and in the programs.
• The code could also be a bit more modular. Find sections of code which appear more than 2 or 3 times and turn them into macros and functions.

Since you have this tutorial as a starting point, the pressure is on to "build a better simulation".

Often in hardware design, it is desirable to attempt to accurately simulate the anticipated behavior of the hardware before it is actually cast in silicon. By simulating the behavior, this can demonstrate how successful (or unsuccessful) your design will be when it is fabricated. The simulation can be subjected to a variety of conditions to demonstrate how it will behave in complex systems. It is also far easier to implement design changes to a simulation and in a CAD layout than it is to actually change the design, extract it, test it, re-fabricate it, and then test a prototype.

For networks, different data link layer and media access protocols can be simulated to see how they perform under various loading conditions - far more extensively than if one were prototpying (also far cheaper and easier).

Statistics can be kept during the simulation:

• Channel utilization
• Average delay associated with a packet transmission
• Average number of retransmissions
• Number / frequency of collisions
• Throughput

These statistics (among others) can be graphed against various channel loads to obtain a tremendous amount of information about the behavior of a protocol before the protocol is implemented in an actual network.

There are 2 dominant methods for simulating the behavior of a system in software:

• Exhaustive simulation
• Event Driven Simulation

In this document, I will be focusing on event driven simulations.

The following example illustrates the differences between the two methods of simulation:

If you were going to simulate the floating point unit (FPU) of a Pentium CPU, one way to do it would be to examine every clock cycle to see what is happening in the FPU (an exhaustive simulation). The information you would be interested in capturing would be "events" which cause a change in the state of the system. Sample event possibilities (a simplified list) might consist of:

• Division Operation Begins
• Division Operation Completes
• Multiplication Operation Begins
• Multiplication Operation Completes
• Interrupt Event

A sample trace of this exhaustive simulation might look something like the following:

This is an exhaustive simulation because we're looking at every clock cycle, regardless of whether there is activity (a change in the state of the system) at every clock cycle.

An event driven simulation trace (of the same events as above) might look something like this:

The 2 traces contain the same amount of information - it's just that the event driven simulation "skips time" when there is no change in the state of the system and only examines the changes (events).

Event driven simulations lend themselves so well to network protocol simulations because to quantify time - so that the simulation can exhaustively look at every distinct moment of time - results in such a large amount of processing overhead that the simulation takes far too long.

For example, if there is a possibility that system loading is such that there could be 1000 events in a second, then "time" must be quantified into pieces each 0.001 seconds long, and each of these 1000 units of time must be examined during the simulation to see if an event has occurred.

If only 50 of these events actually occur, it is still necessary to examine all 1000 "units of time" in the exhaustive simulation, whereas in the event driven simulation, you only examine the 50 changes of state to the system resulting from events occurring to/in that system.

This saves a tremendous amount of processing time to complete the simulation. Rarely are exhaustive simulations done anymore - the emphasis is on event driven.

I would appreciate any feedback you could supply regarding this turorial. You had:

• Questions/comments/flames?
• Success?
• Failure?
• No idea what i'm talking about?
• You were able to simulate an entire FDDI network with 300 nodes...?!? (great!)

Let me know - i'll try to help you out...