The Network
Simulator 2
The Network Simulator (version 2) is an object-oriented,
discrete event driven network simulator that
was originally developed at the University
College of Berkeley. It is written in C++ and
oTcl. NS is primarily useful for simulating
local and wide area networks (LAN, WAN), and
thus invaluable when designing a new Protocol.
The disadvantage of the Network Simulator is
that it is a considerably large system with
a relatively steep initial learning curve.
Initially it is quite difficult for a first
time user to use or attempt to extend the Simulator,
as there are few user-friendly manuals.
The NS-2 simulator was chosen over other available
simulators for a number of reasons.
- NS-2
is the most widely used simulator for network
simulations.
- The Simulator is an open source, freely
downloadable piece of software, which runs on
Linux platform and on windows platform under
Cygwin.
- NS-2 is easily extensible once familiar
with the software; any extensions to existing
network protocols can be implemented with ease.
- Since NS-2 is widely used, there are
many simulation results available, which
can be used for comparison for new Agent/Protocol
simulations.
The Network Simulator is capable of simulating
a wide variety of IP networks. It implements
network protocols such as TCP and UPD, traffic
source behaviour such as FTP (File Transfer
Protocol), Telnet, Web, CBR and VBR. It also
is capable of simulating router queue management
mechanisms such as Drop Tail, RED (Random Early
Detection) and CBQ (Class Based Queuing), routing
algorithms such as Dijkstra etc. Currently,
NS is written in C++ and oTCL (Object-oriented
Tcl script language).
Figure Simplified users view of the Network
Simulator
Figure 5 depicts a simplified user's view.
NS is fundamentally an Object-oriented Tcl
(oTcl) script interpreter that has a simulation
event scheduler and network component object
libraries. In order to join these network
objects so that they can interact NS has
network setup (plumbing) module libraries
(actually, plumbing modules are implemented
as member functions of the base simulator
object). In order to use NS, the OTcl script
language is used. Examples of such scripts
can be found in Chapter 5. To setup and run
a simulation network, a user should write
an OTcl script that initiates an event scheduler,
sets up the network topology using the network
objects and the plumbing functions in the
library, and tells traffic sources when to
start and stop transmitting packets through
the event scheduler. In the network setup,
the possible data paths among network objects
are connected by setting the ‘neighbour’ pointer
of an object to the address of an appropriate
object. When a new network object is required,
it can be created either by writing a new
object or by making a compound object from
the existing object library, and connect
the data path through the object. The plumbing
or interconnecting OTcl modules simplify
the process significantly. The power of NS
comes from this interconnecting.
Another major component of NS beside network
objects is the event scheduler. An event in
NS is a unique packet ID which has a scheduled
time and the pointer to an object that handles
the event. It is the event scheduler that keeps
track of simulation time and runs all the events
in the event queue scheduled for the current
time by invoking appropriate network components.
It is usually these network components that
issued the events, and let them do the appropriate
action associated with packet pointed by the
event. Network components communicate with
one another passing packets between each other.
This passing of packets however does not consume
actual simulation time. If on the other hand
a network components needs to simulate time
handling a packet it simply uses the event
scheduler by issuing an event for that packet.
It then waits for the event to be fired to
itself before doing further action handling
the packet. Another use of an event scheduler
is the timer. For example, the Transmission
Control Protocol uses a timer to keep track
of a packet transmission time out. Timers use
event schedulers in a similar manner that delay
does. The only difference is that the timer
measures a time value associated with a packet
and does an appropriate action related to that
packet after a certain time goes by, and does
not simulate a delay.
|
