ETM3056 : Communications. NetworksCN1: Communication Protocol Analysis
CN1 : COMMUNICATION PROTOCOL ANALYSIS
Faculty of Engineering
MultimediaUniversity
1. OBJECTIVES
Experiment(1): NS-2: The Beginning
Objective: To understand and construct the basic components, simulation setup and simulation animation using NS-2
Experiment(2): Simulation Analysis Tools
Objective: To understand construct, design and analyse the communication network base on the given simulation output tools and analysisusing NS-2
Experiment(3): TCP AnalysisSimple Wireless Scenario
Objective: To understand, simulate and analysestudythe different versions of TCPsimple wireless scenario.
2. LIST OF EQUIPMENTS AND SOFTWARES
Computer running ns-allinone (latest release is 2.31) is a package which contains required components and some optional components used in running NS-2. The package contains an "install" script to automatically configure, compile and install these components.
Currently the package contains:
- Tcl release 8.4.14 (Main component)
- Tk release 8.4.14 ( Main component)
- Otcl release 1.13 ( Main component)
- TclCL release 1.19 ( Main component)
- Ns release 2.31 (Main component)
- Nam (Animation purpose)
- Gnuplot (Plotting purpose)
External storage to save the simulation output.
3. INTRODUCTION
3.1 NS-2 SIMULATION TOOL
NS-2 is a network simulator.
NS-2 is an event-driven object-oriented simulator, written in C++, with an Otcl interpreter as a front-end. This means that most of your simulation scripts will be written in Tcl. If you want to develop new components for NS-2 you might have to use both Tcl and C++.
NS-2 uses two languages because any network simulator, in general, has two different kinds of things it needs to do. On the one hand, detailed simulations of protocols requires a systems programming language which can effciently manipulate bytes, packet headers, and implement algorithms that run over large data sets. For these tasks run-time speed is important and turn-around time (run simulation, find bug, fix bug, recompile, re-run) is less important. On the other hand, a large part of network research involves slightly varying parameters or configurations, or quickly exploring a number of scenarios. In these cases, iteration time (change the model and re-run) is more important. Since configuration runs once (at the beginning of the simulation), run-time of this part of the task is less important.
NS-2 meets both of these needs with two languages, C++ and Otcl. C++ is fast to run but slower tochange, making it suitable for detailed protocol implementation. Otcl runs much slower but can bechanged very quickly (and interactively), making it ideal for simulation configuration. NS-2 (via tclcl)provides glue to make objects and variables appear on both languages.
Figure 1
Traces in NS-2 format
$ns trace-all [open tr.out w]
<event> <time> <from> <to> <pkt> <size> -- <fid> <src> <dst> <seq> <attr>
+ 1 0 2 cbr 210 ------0 0.0 3.1 0 0
- 1 0 2 cbr 210 ------0 0.0 3.1 0 0
r 1.00234 0 2 cbr 210 ------0 0.0 3.1 0 0
d 1.04218 1 2 cbr 210 ------0 0.0 3.1 0 0
Queue / Time / From Node / To Node / Traff Type / Pkt Size / Flags / Flow ID / SrcPort / Dst.Port / Seq. Num. / Pkt ID+,-,r,d / double / int / int / string / int / string / int / int. int / int. int / int / int
Queue
+ queue, - dequeue, r received, d dropped
Time
time stamp
From/To Nodes
paket is between these nodes
Traffic Type
what type of agent created this traffic
Packet Size
The size of the packet moving from one node to the next
Flags
Any flow control of congestion flags
Flow ID
Helps identify which traffic path this is apart of
SourcePort and DestinationPort
The end points of the packet
Sequence Number
Used in TCP Windowing and Acking
Packet Number
Unique number used to id this single packet for monitoring sake. NAM allows you to actually track a packets movement through a network using this ID
Wireless Simulation
NS is an Application Programming Interface (API). The wireless model in NS was originally designed by CMU's Monarch group's mobility extension. In this original version, it covers the internal of a mobilenode, routing mechanisms and network components that are used to construct the network stack for a mobilenode. The components that are covered briefly are Channel, Network-interface, Radio Propagation model, MAC protocols, Interface Queue, Link Layer and Address Resolution Protocol model (ARP). CMU trace support and Generation of node movement and traffic scenario files are also covered. The original CMU model allows simulation of pure wireless LANs or multihop ad-hoc networks. Further extensions were made to this model to allow combined simulation of wired and wireless networks. MobileIP was also extended to the wireless model.
A mobilenode consists of network components like Link Layer (LL), Interface Queue (IfQ), MAC layer, the wireless channel nodes transmit and receive signals from, etc. For details about these network components refer to the NS Manual.
At the beginning of a wireless simulation, we need to define the type for each of these network components. For example, there are four different wireless ad-hoc routing protocols currently implemented for mobile networking in NS that we could choose from. They are (i) DSDV (Highly Dynamic Destination-Sequenced Distance Vector routing protocol), (ii) Dynamic Source Routing (DSR), (iii) TORA (Temporally-Ordered Routing Algorithm routing protocol) and (iv) Ad hoc On-demand Distance Vector Routing (AODV). Additionally, we need to define other parameters like the type of antenna, the radio-propagation model used by mobilenodes, etc.
See comments in the code below for a brief description of each variable defined. The array used to define these variables, val() is not global as it used to be in the earlier wireless scripts. We will begin our tcl script with a list of these different parameters described above, as follows:
# ======# Define options
# ======
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(ant) Antenna/OmniAntenna ;# Antenna type
set val(ll) LL ;# Link layer type
set val(ifq) Queue/DropTail/PriQueue ;# Interface queue type
set val(ifqlen) 50 ;# max packet in ifq
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(rp) DSDV ;# ad-hoc routing protocol
set val(nn) 2 ;# number of mobilenodes
An object god will need to be created. Quoted from CMU document on god,
"God (General Operations Director) is the object that is used to store global information about the state of the environment, network or nodes that an omniscient observer would have, but that should not be made known to any participant in the simulation."
Currently, god object stores the total number of mobile nodes and a table of shortest number of hops required to reach from one node to another. The next hop information is normally loaded into god object from movement pattern files, before simulation begins, since calculating this on the fly during simulation runs can be quite time consuming. However, in order to keep this example simple we avoid using movement pattern files and thus do not provide god with next hop information. The usage of movement pattern files and feeding of next hop info to god shall be shown in the example in the next sub-section.
The procedure create-god is defined in ~ns/tcl/mobility/com.tcl, which allows only a single global instance of the god object to be created during a simulation. In addition to the evaluation functionalities, the god object is called internally by MAC objects in mobilenodes. So even though we may not utilise god for evaluation purposes, we still need to create god.
A setdest program generates movement pattern files using the random waypoint algorithm. The node-movement files generated using setdest (like scen-3-test which we will use in Experiment 2) already include lines like above to load the god object with the appropriate information at the appropriate time.
A program called calcdest (~ns/indep-utilities/cmu-scen-gen/setdest/calcdest) can be used to annotate movement pattern files generated by other means with the lines of god information. calcdest makes several assumptions about the format of the lines in the input movement pattern file which will cause it to fail if the file is not formatted properly. If calcdest rejects a movement pattern file you have created, the easiest way to format it properly is often to load it into ad-hockey and then save it out again. If ad-hockey can read your input correctly, its output will be properly formatted for calcdest.
Both setdest and calcdest calculate the shortest number of hops between nodes based on the nominal radio range, ignoring any effects that might be introduced by the propagation model in an actual simulation. The nominal range is either provided as an argument to the programs, or extracted from the header in node-movement pattern files.
The path length information provided to god was used by CMU's Monarch Project to analyze the path length optimality of ad hoc network routing protocols, and so was printed out as part of the CMUTrace output for each packet.
4. EXPERIMENTS
4.1 EXPERIMENT(1): NS-2 SIMULATION
4.1.1 RUNNING KNOPPIX
For these experiments, we will be using Knoppix with embedded NS-2. Knoppix is a complete Linux distribution that can run fromor a single CD. Usually this kind of distribution is called a live CD where it can load Linux system without installing it on a hard drive. The distribution used for this experiment come with NS-2 embedded in it. Hence, student can run the NS-2 without having to install it on the hard drive. Please get a Knoppix CD from the lab technician.
Start using Knoppix
After Knoppix uploaded, type the command below to run the KDE environment:
startx
Bring up the CKonsole, and user need to setup path for nam and xgraph. This should be executed line by line (press Enter after each line):
PATH=”$PATH:/usr/local/ns-allinone-2.29/nam-1.11”
export PATH
PATH=”$PATH:/usr/local/ns-allinone-2.29/xgraph-12.1”
export PATH
To check either the paths are already set or not, type the commands below one by one. It should return the path to the required applications:
which ns
which nam
which xgraph
To set your working path, type
cd Desktop
From now on, do save all the documents and files on your desktop.
At the end of session (when you finish your experiment), after logout from the KDE environment, press the below keys simultaneously to eject the CD:
Ctrl+Alt+Del
Khairil/Shamini/Musli/Hadhrami/CY Changm Updated 0606-201420(CN1) 1 of 23
ETM3056 : Communications. NetworksCN1: Communication Protocol Analysis
4.1.2 RUNNING NS-2: THE BEGINNING
Objective: To understand and construct the basic components, simulation setup and simulation animation using NS-2To understand the basic components, simulation setup and simulation animation using NS-2
Step1: Login to the computer as being instructed by the technical staff.
Step2:Identify the working folder for your working space where all your files will be saved.
Step3: Now, bring up the “console” to set your working path.
Step4:To start NS-2, type inside the console:
nsStep5: In this section you are going to write a template that you can use for all your simulation scripts. A simulation in NS-2 is described by a Tcl class Simulator. A simulation script, therefore, generally begins by creating an instance of this class. This is done with the command
set ns [new Simulator]Step6: After creating the simulator object a simulation script usually calls various methods to create nodes and topologies. Next we have to define what exactly we want to happen in the simulation. Since the NS-2 simulator is an event-driven simulator this is done by scheduling events: when creating a simulator object a scheduler is created which runs by selecting the next earliest event, executing it to completion, and returning to execute the next event. An event can for example be the sending of data from one node to another node or the failure of a link. The command to schedule an event is
$ns at <time in sec> <event>
Example:
$ns at 1.0 “puts \”Hello World!\””$ns at 1.5 “exit”
Step7: After scheduling all the events, we are ready to start the simulation:
$ns runAlthough we have seen the basics of running a simulation, we don’t have a way yet to get any output from the simulation. Fortunately, NS-2 provides a number of ways of collecting output or trace data on a simulation (We will see this in Section 4.1.3).
Optionally, we can run the above scripts by inserting all the scripts inside a file (say experiment1-1.tcl) and run the file by executing:
ns experiment1-1.tcl4.1.3 CREATING A TCL FILE
Create a new file by the name “experiment1-2.tcl”. Type all the followings inside the file.
Line1: set ns [new Simulator]
The following code for example first opens the file ‘out.nam’ for writing and gives it the file handle ‘nf’. It then tells the simulator to trace each packet on every link in the topology and write the data into the file.
Line2: set nf [open experiment1-2.nam w]
Line3: $ns namtrace-all $nf
The trace data is collected in a format that can later be used by the nam program to visualize the simulation in an animation.
The only remaining step is to make sure that all the trace data is flushed into the file at the end of the simulation and that the file is closed. Furthermore, we have to run the nam tool on the created trace file to produce the animation. We do this by writing a ‘finish’ procedure that we call at the end of the simulation and that performs all these tasks.
Line4: proc finish {} {
Line5: global ns nf
Line6: $ns flush-trace
Line7: close $nf
Line8: exec experiment1-2.nam
Line9: exit 0
Line10:}
To create a node we can simply use the simulator method node. The following two lines create two
nodes and assign them to the handles ‘n0’ and ‘n1’.
Line11: set n0 [$ns node]
Line12: set n1 [$ns node]
We can then either use the simulator method simplex-link or the method duplex-link to connect the
nodes with a link:
Line13: $ns duplex-link $n0 $n1 1Mb 10ms DropTail
This creates a bidirectional link between n0 and n1 with bandwidth 1Mbps, a propagation delay of 10ms and a DropTail queue. In addition to the DropTail queue, NS-2 also supports many other queuing policies like for example FairQueueing(FQ), Random Early Detection (RED), and Class-based queuing (CBQ).
By now you have some scripts that create topologies but there is not yet trace. Trace generation in NS-2 is based on objects of two classes, the Agent and the Application.
Agents represent endpoints where network-layer packets are constructed or consumed. Every node in the network that needs to send or receive trace must have an agent attached to it. These agents can be thought of as the implementation of the transport protocol.
On top of an agent runs an application. The application determines the kind of trace source that issimulated (e.g. ftp or telnet). Applications represent the application layer in an NS-2 simulation.
Creating Agents: Corresponding to the two most popular transport protocols used in the Internet there are also two types of agents in NS-2: UDP agents and TCP agents.
The following code shows an example of attaching a UDP agent to nodes n0 and n1:
Line14: set udp0 [new Agent/UDP]
Line15: $ns attach-agent $n0 $udp0
Line16: set null0 [new Agent/Null]
Line17: $ns attach-agent $n1 $null0
Line18:$ns connect $udp0 $null0
This code first creates a UDP agent and attaches it to n0 using the attach-agent procedure. It thencreates a Null agent which will act as a traffic sink and attaches it to n1. Finally, the two agents are connected using the simulator method connect. In the next section the UDP agent will be used by anapplication to send data.
Creating Applications: In the previous section, we have set up the agents implementing the transport layer. We will now create applications that we attach to the transport agents and that will actually generate traffic. In NS-2 there are two basic types of applications: simulated applications and traffic generators.
Traffic generators generate On/Off traffic: during On-periods, packets are generated at a constant burst rate and during Off-periods no packets are generated. NS-2 provides three different classes of traffic generators which differ in how the lengths of the On and Off-periods are modelled:
- A traffic generator of the type Application/Traffic/Exponential takes the length of the On and Off periods from an Exponential distribution.
- An Application/Traffic/Pareto source generates the lengths of these periods from a Pareto distribution.
- Finally, the class Application/Traffic/CBR has no off periods and generates packets at a constant bit rate.
The following code generates one traffic generator of each class.
set exp [new Application/Traffic/Exponential]
set par [new Application/Traffic/Pareto]
set cbr0 [new Application/Traffic/CBR]
See the NS-2 manual for how to configure these traffic generators.
All traffic generators run on top of a UDP agent. Therefore, we have to attach a traffic generator toa UDP agent before we can use it to send data. The following example illustrates the use of the CBRtraffic generator that we created above.
Line19: set cbr0 [new Application/Traffic/CBR]
Line20: $cbr0 set packetSize 500
Line21: $cbr0 set interval 0.005
Line22: $cbr0 attach-agent $udp0
Line23: $ns at 1.0 ‘‘$cbr0 start’’
Line24: $ns at 4.5 “$cbr0 stop”
The simulated applications currently implemented in NS-2are Application/FTP and Application/Telnet. These try to simulate the corresponding applications in the real world: FTP and Telnet. Like the real applications the NS-2 applications can run only on TCP. They therefore have to be attached to a TCP agent.
The following line calls this procedure at the end of the simulation,
Line25: $ns at 5.0 ‘‘finish’’
Line26: $ns run
4.1.4 TRACING AND MONITORING
So far, when we wanted to see what is happening in a simulation we have used nam to visualize theevents. However, often we want more detailed trace data on a simulation which then allows us to compute numbers like packet loss rates or per-connection throughput.
The easiest way to do this is to use the simulator method trace-all which traces all the links in thetopology (insert these 2 lines into your previous file):