Chapter 3 Network Simulator
3.1 NS2 architecture overview
Figure3.1 The advantage and disadvantage of network simulator
3.1 NS2 architecture overview
NS is an event driven network simulator developed at UC Berkeley that simulates variety of IP networks. The changing history of the NS is NEST ( Network Simulation Testbed ) , and REAL ( Realistic and Large ) , and NS-1 and NS-2 finally [11]. It implements network protocols such as TCP and UPD, traffic source behavior such as FTP, Telnet, Web, CBR and VBR, router queue management mechanism such as Drop Tail, RED and CBQ, routing algorithms such as Dijkstra, and others. It is important for us that NS also implements multicasting and some of the MAC layer protocols for LAN simulations. The NS project is now a part of the VINT project that develops tools for simulation results display, analysis and converters that convert network topologies generated by well-known generators to NS formats. Currently, NS (version 2) written in C++ and OTcl (Tcl script language with Object-oriented extensions developed at MIT) is available.
49
zEvent Scheduler Objects zNetwork Component Objects zNetwork Setup Helping Modules
(Plumping Modules)
NS Simulation Library Simulation Results
NetworkNAM Animator
Figure3.2 User’s view of NS[10]
As shown in Figure3.2, in a simplified user's view, NS is Object-oriented Tcl (OTcl) script interpreter that has a simulation event scheduler and network component object libraries, and network setup (plumbing) module libraries (actually, plumbing modules are implemented as member functions of the base simulator object). In other words, to use NS, you program in OTcl script language. To setup and run a simulation network, a user should write an OTcl script that initiates an event scheduler, and 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. The term "plumbing" is used for a network setup, because setting up a network is plumbing possible data paths among network objects by setting the
"neighbor" pointer of an object to the address of an appropriate object. When a user wants to make a new network object, he can easily make an object either by writing a new object or by making a compound object from the object library, and plumb the data path through the object. The plumbing OTcl modules actually make the job very easy. The power of NS comes from this plumbing. Another major component of NS
50
C++
OTcl
beside network objects is the event scheduler. An event in NS is a packet ID that is unique for a packet with scheduled time and the pointer to an object that handles the event. In NS, an event scheduler keeps track of simulation time and fires all the events in the event queue scheduled for the current time by invoking appropriate network components, which usually are the ones who issued the events, and let them do the appropriate action associated with packet pointed by the event. Network components communicate with one another passing packet, however this does not consume actual simulation time. All the network components needing to spend some simulation time handling a packet use the event scheduler by issuing an event for the packet and waiting for the event to be fired to itself before doing further action handling the packet. For example, a network switch component that simulates a switch with 40 microseconds of switching delay issues an event for a packet to be switched to the scheduler as an event 40 microsecond later. The scheduler after 40 microseconds dequeues the event and fires it to the switch component, which then passes the packet to an appropriate output link component. Another use of an event scheduler is timer.
Timers use event schedulers in a similar manner that delay does. The only difference is that 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.
Figure3.3 C++ and OTcl : The Duality[11]
51
NS is written not only in OTcl but also in C++. Figure3.3 shows an object hierarchy example in C++ and OTcl. For efficiency reason, NS is comprised with the data path implementation and control path implementations. In order to reduce packet and event processing time, the event scheduler and the basic network component objects in the data path are written and compiled using C++. These compiled objects are made available to the OTcl interpreter through an OTcl linkage that creates a matching OTcl object for each of the C++ objects and makes the control functions and the configurable variables specified by the C++ object act as member functions and member variables of the corresponding OTcl object. In this way, the controls of the C++ objects are given to OTcl. It is also possible to add member functions and variables to a C++ linked OTcl object. The objects in C++ that do not need to be controlled in a simulation or internally used by another object do not need to be linked to OTcl. Likewise, an object (not in the data path) can be entirely implemented in OTcl. One thing to note in the Figure3.3 is that for C++ objects that have an OTcl linkage forming a hierarchy, there is a matching OTcl object hierarchy very similar to that of C++.
Event
Scheduler NS-2
tclcl Sim ula to r Ne tw ork
otcl tcl8.0
Figure3.4 Architecture view of NS[11]
52
Figure3.4 shows the general architecture of NS. In this figure, a general user can be thought of standing at the left bottom corner, designing and running simulations in Tcl using the simulator objects in the OTcl library. The event schedulers and most of the network components are implemented in C++ and available to OTcl through an OTcl linkage that is implemented using tclcl. The whole thing together makes NS, which is a extended Tcl interpreter with network simulator libraries.
If we want to obtain the simulation results, as Figure3.2, when a simulation is finished, NS produces one or more text-based output files that contain detailed simulation data, if specified to do so in the input Tcl (or more specifically, OTcl) script. The data can be used for simulation analysis or as an input to a graphical simulation display tool called Network Animator (NAM) that is developed as a part of VINT project. NAM has a nice graphical user interface similar to that of a CD player (play, fast forward, rewind, pause and so on), and also has a display speed controller.
Furthermore, it can graphically present information such as throughput and number of packet drops at each link, although the graphical information cannot be used for accurate simulation analysis.
In a word, ns is the simulator itself. Nam is the network animator which can visualize ns output and use GUI interface to generate ns scripts. The pre-processing are traffic and topology generators. The post-processing are simple trace analysis, often in Awk , Perl , or Tcl. Then I will briefly introduce some function of the ns platform.
53