Network
Transcript of Network
NETWORK ANALYZER FOR
NETWORKSIMULATOR-2
USING JAVA
Contents
Abstract
1. Introduction
1.1 Purpose
1.2 Abbreviations
1.3 Definitions
1.4 Project Schedule
2. Project Description
2.1 Problem Definition
2.2 Problem Description
2.2.1 Why NS-2
2.2.2 Network Simulator NS-2
2.2.1.1 User’s View of NS
2.2.1.2 Architectural View of NS
2.2.1.3 NS Trace Format
2.2.3 Trace Analysis
2.2.2.1 Trace Support
2.2.2.2 Trace Graph Format
2.2.2.3 Trace Analysis Example
2.2.2.3.1 Understanding the Trace file
2.2.2.3.2 Sample Graph
2.2.4 Simulation Stages
2.2.3.1 Simulation Result Processing
2.2.3.1.1 Trace files processing
2.2.3.1.2 Wired Networks
2.2.3.1.2.1 Trace format of Wired Network
2.2.3.1.3 Wireless Networks
2.2.3.1.3.1 Old Wireless Trace format
2.2.3.1.3.2 New Wireless Trace format
3. Requirements
3.1 Software Requirements
3.2 Hardware Requirements
4. Design aspects
4.1 Basic idea of design
4.2 Expected output
5. Coding
6. Results
7. Conclusions
8. Future work
9. References
ABSTRACT
Establishing the computer networks in the different peripherals is cost
effective. The performance of the network may not be as good as the one estimated
before the installation and this may sometimes lead to changing of the peripherals.
Therefore it is always better to have a simulation of the network using a computer than
the actual establishment
We have many of simulators likes NS2, GLOMOSIM, SWANS etc. meant
exclusively for network simulations which helps us in estimating the performance of
network without the cost involvement. After having simulated the network, it can be
analyzed for its performance. This approach directs us to take a proper decision about
actual establishment of the network.
One of the foremost problems with the beginners of ns2 is what to do with the
enormous data provided by the trace files. Very little documentation is available which
will help the users of ns2 in extracting the required data and thus calculating parameters
like one-way delay, throughput etc. Besides calculating parameters, one is more
interested in observing the graph which gives instantaneous results.
NANS is the utility which brings all these features into one and from now onwards,
strives to eliminate the entire problem associated with it
1. INTRODUCTION
1.1 Purpose
Continuous networks development, higher and higher functionality requirements have
created the need for tools that could monitor network transmissions and analyse them.
We have many simulators like NS2, GLOMOSIM, SWANS etc. meant exclusively for
network simulations which helps us in estimating the performance of network without the
cost involvement. After having simulated the network, it can be analyzed for its
performance. This approach directs us to take a proper decision about actual
establishment of the network.
One of the foremost problems with the beginners of ns2 is what to do with the enormous
data provided by the trace files. Very little documentation is available which will help the
users of ns2 in extracting the required data and thus calculating parameters like one-way
delay, throughput etc. Besides calculating parameters, one is more interested in observing
the graph which gives instantaneous results.
This paper describes Trace graph – a data presentation system for Network Simulator -2
Trace graph system provides many options for analysis, has capabilities to calculate
many parameters characterizing network simulation. The NS2 simulator leaves lot of
statistical data as the output of a particular simulation. Using this data that particular
network can be analyzed for its performance. This analysis may include the capturing of
Information from the simulator and drawing the graphs
1.2 Abbreviations
NS - Network Simulator
TCP - Transmission Control Protocol
CBR - Control Bit Rate
ACK - Acknowledgement
RTT - Round Trip Time
TCL - Tool Command Language
OTCL - Object Tool Command Language
VINT - Virtual Inter Network Test board
LBNL - Laurence Berkeley National Laboratory
MANET - Mobile Ad-hoc Network
NAM - Network Animator
1.3Definitions
Wired Networks: A Wired network is a network with physical cables connecting each
system together.
Wireless Networks: The term wireless networking refers to technology that enables two
or more computers to communicate using standard network protocols, but without
network cabling.
Adhoc Networks: Adhoc networks are mobile wireless networks that have no fixed
infrastructure. There are no fixed routers instead each node acts as a router and forwards
traffic from other nodes.
MANET’s: A MANET is a type of ad-hoc network with rapidly changing topology.
MANETS are wireless network formed by a collection of mobile nodes without any pre
established infrastructure
Routing: Mapping of the packets from source to destination is called Routing.
Simulator: A device that enables the operator to reproduce or represent under test
conditions phenomena likely to occur in actual performance.
Simulation: is an imitation of some real thing, state of affairs, or process. The act of
simulating something generally entails representing certain key characteristics or
behaviors of a selected physical or abstract system.
NS: The Network Simulator ns-2 is a discrete event simulator, which means it simulates
such events as sending, receiving, forwarding and dropping packets. The events are
sorted by time (seconds) in ascending order.
TCP: A protocol developed for the internet to get data from one network device to
another; "TCP uses a retransmission strategy to insure that data will not be lost in
transmission". It is used to establish connection-oriented, sequenced and error-free
sessions over IP networks. TCP offers reliability by providing reliable packet delivery.
CBR: CBR is a term used in telecommunications, relating to the quality of service
compared with variable bit rate. CBR is useful for streaming multimedia content on
limited capacity channels since it is the maximum bit rate that matters, not the average, so
CBR would be used to take advantage of all of the capacity.
ACK: ACK is a message sent to acknowledge the receipt of an error free data packet
from a remote machine. Acknowledgment is service that is used by TCP, to transmit data
reliably in an IP environment.
TCL: TCL is an interpreted language that operates, like Perl, within its own shell.
OTCL: Tcl script language with Object-oriented extensions.
2. PROJECT DESCRIPTION
2.1 Problem Definition
Establishing the computer networks in the different peripherals is cost effective. The
performance of the network may not be as good as the one estimated before the
installation and this may sometimes lead to changing of the peripherals. Therefore it is
always better to have a simulation of the network using simulator’s likes NS2,
GLOMOSIM, SWANS etc. meant exclusively for network simulations which helps us in
estimating the performance of network without the cost involvement. Here we are using
NS2. After having simulated the network with NS2, it can be analyzed for its
performance. This approach directs us to take a proper decision about actual
establishment of the network.
The main problem is that NS-2 doesn’t provide any visualization options for simulation
results (trace files) analysis. Because of this reason trace graph – NS-2 data presentation
system was created. This paper describes Trace graph – a data presentation system for
Network Simulator NS-2. The simulator doesn’t have any options implemented to
analyse simulations results so it’s hard to use it. Trace graph system provides many
options for analysis; it has capabilities to calculate many parameters characterizing
network simulation, and statistical reports, saves calculation results to text files and to
process its own script files to do all the calculations automatically.
2.2 Problem Description
2.2.1 Why NS2:
In the past ten years computer networks have been significantly
developed, especially the largest one – the Internet. Nowadays networks have more and
more workstations, the transmission speed increases and the connections capabilities rise.
Continuous networks development, higher and higher functionality requirements have
created the need for tools that could monitor network transmissions and analyse them.
There have been developed network simulators, which help to design and test various
kinds of networks, protocols, etc. A simulator for communication networks developed at
LAURENCE BERKELEY NATIONAL LABORATORY (LBNL) within the VINT
project. It fast became a property of the entire research community, where everyone can
add its own modules, and contributes to the development of the simulator. The first
version of NS was experimental. Now we are working with the second version called NS-
2.The simulator works under UNIX and Windows system platforms and is mainly used
for network research. It is widely used all over the world The main advantage of
simulations is low cost of development and implementation in comparison to
experimental tests in real environment. The main problem is that ns-2 doesn’t provide
any visualization options for simulation results (trace files) analysis. Because of this
reason Trace graph – ns-2 data presentation system was created in year 2001 and has
been developed for a year and a half. This paper describes Trace graph – a data
presentation system for Network Simulator ns-2. The simulator doesn’t have any options
implemented to analyse simulations results so it’s hard to use it. Trace graph system
provides many options for analysis, has capabilities to calculate many parameters
characterizing network simulation, e.g. delay, RTT, throughput, sequence number,
processing time, to plot 250 various graphs, and statistical reports, to save calculations
results to text files and to process its own script files to do all the calculations
automatically. Trace graph has become very popular and is used by many ns-2 users.
2.2.2 Network Simulator NS-2
The Network Simulator ns-2 is a discrete event simulator, which means it simulates
such events as sending, receiving, forwarding and dropping packets. The events are
sorted by time (seconds) in ascending order. 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. It is implemented in
C++. For simulation scenario and network topology creation it uses OTcl (Object
Tool Command Language).
2.2.2 .1 User’s View of NS
Figure 1. Simplified User's View of NS
As shown in Figure 1, 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, 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 or she 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.
This may sound like complicated job, but the plumbing OTcl modules actually make the
job very easy. The power of NS comes from this plumbing. Another major component of
NS 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 that need to spend some simulation time
handling a packet (i.e. need a delay) 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 20
microseconds of switching delay issues an event for a packet to be switched to the
scheduler as an event 20 microsecond later. The scheduler after 20 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. For
example, TCP needs a timer to keep track of a packet transmission time out for
retransmission (transmission of a packet with the same TCP packet number but different
NS packet ID). 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.
2.2.2.2 Architectural View of NS
Figure 2. Architectural View of NS
Figure 2 shows the general architecture of NS. In this figure a general user (not an NS
developer) 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 OO extended Tcl interpreter with network simulator libraries. This section
briefly examined the general structure and architecture of NS. At this point, one might be
wondering about how to obtain NS simulation results. As shown in Figure 1, 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 ( simulation result analysis examples
are presented in later sections)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.
2.2.2.3 NS Packet Format
A NS packet is composed of a stack of headers, and an optional data
space (see Figure 3). A packet header format is initialized when a Simulator object is
created, where a stack of all registered (or possibly useable) headers, such as the common
header that is commonly used by any objects as needed, IP header, TCP header, RTP
header (UDP uses RTP header) and trace header, is defined, and the offset of each header
in the stack is recorded. What this means is that whether or not a specific header is used,
a stack composed of all registered headers is created when a packet is allocated by an
agent, and a network object can access any header in the stack of a packet it processes
using the corresponding offset value.
Fig
ure 3. NS Packet Format
Usually, a packet only has the header stack (and a data space pointer that is null).
Although a packet can carry actual data (from an application) by allocating a data space,
very few application and agent implementations support this. This is because it is
meaningless to carry data around in a non-real-time simulation. However, if you want to
implement an application that talks to another application cross the network, you might
want to use this feature with a little modification in the underlying agent implementation
Another possible approach would be creating a new header for the application and
modifying the underlying agent to write data received from the application to the new
header.
Simple ns script:
EXAMPLE:
set ns [new Simulator]
set nf [open out.nam w]
$ns namtrace-all $nf
proc finish {} {
global ns nf
$ns flush-trace
close $nf
exec nam out.nam &
exit 0
}
$ns at 5.0 "finish"
$ns run
Above script is a simple minimum script for any tcl file.
First two lines will create and open network simulator and nam.
The procedure ‘finish’ is to finish execution.
2.2.3 Trace Analysis
2.2.3.1 Trace Support
There are number of ways of collecting output or trace data on a simulation. Generally,
trace data is either displayed directly during execution of the simulation, or (more
commonly) stored in a file to be post-processed and analyzed. There are two
primary but distinct types of monitoring capabilities currently supported by the
simulator. The first, called traces, record each individual packet as it arrives,
departs, or is dropped at a link or queue. Trace objects are configured into a
simulation as nodes in the network topology, usually with a TCL “channel” object
hooked to them, representing the destination of collected data (typically a trace file
in the current directory). The other types of objects, called monitors, record counts
associated with all packets. To support traces, there is a special common header
included in each packet. It presently includes a unique identifier on each packet, a
packet type field, a packet size field, and an interface label.
2.2.3.2 Trace Graph Formats
we presently discuss two networks
wired trace formats
Normal trace format(wired )
Wireless trace formats:
Old wireless trace formats
New wireless trace formats
AODV routing protocol trace formats
DSDV routing protocol trace formats
DSR routing protocol trace formats
TORA routing protocol trace formats
Mobile node movement and energy trace formats
The various traces begin with a single character or abbreviation that indicates the type of
trace, followed by a fixed or variable trace format. The tables listing the trace formats
differ between fixed and variable trace formats:
For fixed trace formats, the table lists the event the triggers the trace under the
Event heading and the characters that start the trace under the Abbreviation
heading. The format is listed across the last two columns, and the type and value
for each element of the format are listed beneath under the Type and Value
headings. Some events have multiple trace formats.
For variable trace formats, the table lists the event the triggers the trace under the Event
heading and the characters that start the trace under the Abbreviation heading. The
last three columns list the possible flags, types, and values for the event under the
Flag, Type, and Value headings.
Normal trace formats
Event Abbreviation Type Value
Normal Event r: Received: Drop e: Error
+: Enqueue-: Dequeue
%g %d %d %s %d %s %d %d.%d %d.%d %d %d
double Time
int Source Node
int Destination Node
string Packet Name
int Packet Size
string Flags
int Flow ID
int Source Address
int Destination Address
int Sequence Number
int Unique Packet ID
Depending on the packet type, the trace may log additional information:
Event Type Value
TCP Trace
%d 0x%x %d %d
int Ack Number
hexadecimal Flags
int Header Length
int Socket Address Length
Satellite Trace
%.2f %.2f %.2f %.2f
double Source Latitude
double Source Longitude
double Destination Latitude
double Destination Longitude
Trace Format of Wired Network:
Event Abbreviation Type Value
Normal Event
r: Received: Drop e: Error
+: Enqueue-: Dequeue
%g %d %d %s %d %s %d %d.%d %d.%d %d %d
double Time
int Source Node
int Destination Node
string Packet Name
int Packet Size
string Flags
int Flow ID
int Source Address
int Destination Address
int Sequence Number
int Unique Packet ID
2.2.3.3 Trace Analysis Example:
This section shows a trace analysis example.
2.2.3.3.1 Understanding the Trace file:
Figure 4.Trace Format Example
Trace/Enque - A packet arrival ( usually at a queue )
Trace/Deque - A packet departure( usually at a queue )
Trace/Drop - Packet drop ( packet delivered to a drop-target )
Trace/Recv - Packet receive event at the destination node of a link.
Each trace line starts with an event (+, -, d, r) descriptor followed by the simulation time
(in seconds) of that event, and from and to node, which identify the link on which the
event occurred. The next information in the line before flags (appeared as "------" since
no flag is set) is packet type and size (in Bytes). Currently, NS implements only the
Explicit Congestion Notification (ECN) bit, and the remaining bits are not used. The next
field is flow id (fid) of IPv6 that a user can set for each flow at the input OTcl script.
Even though fid field may not used in a simulation, users can use this field for analysis
purposes. The next two fields are source and destination address in forms of "node.port".
The next field shows the network layer protocol's packet sequence number. Note that
even though UDP implementations do not use sequence number, NS keeps track of UDP
packet sequence number for analysis purposes. The last field shows the unique id of the
packet.
Having simulation trace data at hand, all one has to do is to transform a subset of the data
of interest into a comprehensible information and analyze it.A tracefile called "out.tr"
will be produced.This “out.tr” will be used for our simulation analysis. Figure 4shows the
trace format and example trace data from "out.tr".
2.2.3.3.2:Sample Graph
This section showed an example of how to generate traces in NS, how to interpret them,
and how to get useful information out from the traces. In this example, the post
simulation processes are done in a shell prompt after the simulation.
2.2.4 Simulation Stages
To create new objects, protocols, and routing algorithms or to modify them ns-2 C++
source code has to be changed. The simulator supports wired, wireless(new and old
trace),wired cum wireless. Figure 5shows the ns-2 system architecture on a simple block
diagram. One of the blocks represents Trace graph. With ns-2 comes Network Animator ,
a visualization tool for packets flows. It only shows generated packets movement
as an animation, so this is not enough to do simulation results analysis. The simulator
users have to create their own programs to process the results – trace files [1]. The ns-2
output data contains a lot of complicated information about simulation. There are a few
trace file formats and each of them can have various versions, so it can be hard to find out
how to extract necessary data. This is the reason why Trace graph is so useful. It makes
trace file processing very simple.
Fig. 5 Simulation stages
2.2.4.1.1 Trace Files Processing:
.Trace graph supports the following ns-2 trace file formats:
1) wired, – Normal trace format
2)wireless (old and new trace),
– Simple wireless– New wireless
NS-2 provides abundant implementations of protocols used in wired and wireless
networks.
2.2.4.1.2 Wired Networks:
A Wired network is a network with physical cables connecting each system together.
Wired networks are almost always faster and less expensive than wireless
networks. Once connected, there is little that can disrupt a good wired connection.
TCP, UDP, multicast are the transportation protocols used in wired networks.
Web, ftp, telnet, CBR, stochastic are the traffic sources used .
In wired networks firstly we create the event scheduler (simulator) and set
up the tracing and then create the network topology and set up the routing. We will
create connection in the transport layer and create the traffic in the application layer and
start the scheduler to postprocess the data.
Advantages over wireless networks: Throughput - A wired network offers 100Mb/s or 1000Mb/s connection speeds
while a wireless offers only 11Mb/s or 54Mb/s connection speeds.
Non-Shared - network connection speed is independent of one another so multiple
connections do not hinder total throughput of individual network
connections.
Disadvantages over wireless networks: Many cables - It may be expensive and cumbersome to run many cables between
computer systems. It may also be complicated adding new systems to the
network.
Maintainability - When changes need to be made to the network such as
relocation of computer systems it may be difficult to move the cabling required
for the network.
Mobility - When using a notebook which is required to be connected to the
network a wired network will limit the logical reason of purchasing a notebook in the first place.
3.4 Constraints: The typical problems we face when trying to run large simulations in ns,
the main constraints being that of memory and cpu-time. Of the different performance
metrics, the three significant ones highlighted here are
1) Start-up time or the time taken before the actual simulation can start,
Start-up time can be defined as the time overhead required before the actual
simulation can start in ns.
The start-up time consists of the following time-slices:
time to parse thru user script, creating topology, traffic etc
time to setup (initializing and configuring ns that consists of:)
o time to reach upto the RouteLogic procedure route-compute {}
o time to parse thru array of links and store link costs
o time to compute the next-hop by routelogic
o time taken to parse thru nodelist and populate each classifier in each node
with the next-hop information
Thus we find that start-up times mainly consist of time taken to compute routes
and create routing tables.
Run-time or how long it takes for the simulation to complete
Run-time is the time taken for the simulation to complete. The ways to reduce run-time are as
follows:
a. Turn off all tracing like trace-all and namtrace-all if tracing on ALL links
are not required.
b. Several abstraction methods discussed below under "Memory Usage" also
can be applied for reducing run-times as well.
c. Some techniques like pre-filtering, currently at an early stage of
investigation, is expected to result in significant reduction in run-times for
large simulations.
3) Memory requirement for the simulation
One of the most common problem that people face while running large
simulations is running out of memory
Packet-headers in ns
Different types of packet headers are defined for different protocols in ns.
And by default, ns includes ALL these packet headers in EVERY packet in a
simulation. Thus by default each packet-header in ns, by default becomes heavy-weight
which will continue to increase as more protocols are added in ns. One way to
significantly reduce memory requirement, especially for packet intensive large
simulations, is to remove unused packet headers.
4) Ns 2 can only be implemented either in Windows or UNIX , no other operating
system supports this ns2 installation.
5) Our project aims to implement only normal, wired, wireless trace file formats. Satellite
and other formats are not implemented
2.2.4.1.3 Wireless network:
The term wireless networking refers to technology that enables two or more
computers to communicate using standard network protocols, but without network
cabling. Strictly speaking, any technology that does this could be called wireless
networking. In wireless network nodes can move, no explicit “links” are used to
connect nodes. There are two kinds of wireless networks: There are two kinds of
wireless networks:
2.2.4.1.3.1 Old Wireless Trace format:
Event Abbreviation Type Value
Wireless Event
s: Send r: Received: Drop
f: Forward
%.9f %d (%6.2f %6.2f) %3s %4s %d %s %d [%x %x %x %x]
%.9f _%d_ %3s %4s %d %s %d [%x %x %x %x]
double Time
int Node ID
double X Coordinate (If Logging Position)
double Y Coordinate (If Logging Position)
string Trace Name
string Reason
int Event Identifier
string Packet Type
int Packet Size
hexadecimal Time To Send Data
hexadecimal Destination MAC Address
hexadecimal Source MAC Address
hexadecimal Type (ARP, IP)
Wireless traces begin with one of four characters followed by one of two different trace
formats, depending on whether the trace logs the X and Y coordinates of the mobile
node.
New Wireless Trace Format
. Similar to the old format, in the new format wireless traces begin with one of four
characters. The first letter of flags with two letters designates the flag type:
N: Node Property
I: IP Level Packet Information
H: Next Hop Information
M: MAC Level Packet Information
P: Packet Specific Information
2.2.3 4.1.3.2 New Wireless Trace Format:
Event Abbreviation Flag Type Value
Wireless Event
s: Send r: Received: Drop
f: Forward
-t double Time (* For Global Setting)
-Ni int Node ID
-Nx double Node X Coordinate
-Ny double Node Y Coordinate
-Nz double Node Z Coordinate
-Ne double Node Energy Level
-Nl string Network trace Level (AGT, RTR, MAC,
etc.)
-Nw string Drop Reason
-Hs int Hop source node ID
-Hd int Hop destination Node ID, -1, -2
-Ma hexadecimal Duration
-Ms hexadecimal Source Ethernet Address
-Md hexadecimal Destination Ethernet Address
-Mt hexadecimal Ethernet Type
-P string Packet Type (arp, dsr, imep, tora, etc.)
-Pn string Packet Type (cbr, tcp)
Note that the value for the -Hd flag may be -1 or -2. -1 means that the packet is a
broadcast packet, and -2 means that the destination node has not been set. -2 is typically
seen for packets that are passed between the agent (-Nl AGT) and routing (-Nl RTR)
levels
Depending on the packet type, the following flags may be used:
TCP Trace
-Ps int Sequence Number
-Pa int Acknowledgment Number
-Pf int Number Of Times Packet Was Forwarded
-Po int Optimal Number Of Forwards
CBR Trace
-Pi int Sequence Number
-Pf int Number Of Times Packet Was Forwarded
-Po int Optimal Number Of Forwards
3. Requirements:
3.1 Hardware Requirements:
Processor : Pentium IV or equivalent processor
RAM : 512MB or more
Hard Disk : 6GB or more
3.2 Software Requirements:
Operating System : Windows Xp (sp2), DOS
Software : JAVA, NS2
4. Design Aspects
The designer’s goal is to produce a model or representation of an entity that will
later be built.
4.1 Basic Idea of Design:
There are two major phases to design any process. The first one is diversification
and the second one is convergence.
Diversification is the acquisition of repertoire of alternatives, the raw materials of
design are components, component solution, and knowledge all contained in catalos,
textbooks, and the mind. During convergence, the designer chooses and combines
appropriate elements from this repertoire to meet design objectives, as stated in
requirements document and as agreed to by the customer. The second phase is the
gradual elimination of all but one particular configuration of components and thus the
creation of the final product. Using one of a number of design methods the design task
produces a data design, an architectural design, an interface design and a component
design. The data design transforms the information domain model created during
analysis into data structures that will be required to implement the software. The
architectural design defines the relationship between major structural elements of the
software, the “design patterns” that can be used to achieve the requirements that have
been defined for the system, and the constraints that effect the way in which architectural
patterns can be applied. The interface design describes how the software communicates
within itself, with systems that interoperate with it, and with humans who use it. The
component level design transforms structural elements of the software architecture into a
procedural description of software components.
6.Coding Trace file
Read file
Tokenize
Find different connectionsCall to collect dataCalculate sequence number data
Calculate delay data
Calculate RTT data
Calculate Throughput (one way Delay) data
Calculate Throughput(RTT) datadatra)
Collect sequence number data
Display sequence number data
Display delay data
Collect delay data Collect RTT data
Display RTT data
Display Throughput (RTT) data
Collect Throughput (delay) data
Collect Throughput (RTT) data
Display Throughput (RTT) data
Options explanation:
TRACE FILE: This is the input for out project
READ FILE: Reads the trace file
TOKENIZE: Stores the trace file data in temporary arrays .Here we split the trace
information in to tokens based on the number of fields present in the trace file
format specified
FINDDIFFDIELDS: Separates the trace file information and stores the required
fields in a temporary array. And displays them in the list box
CALL TO COLLECT DATA: This method calls the following methods based on
the selected parameters
CALC SEQUENCE NUMBER DATA: This method calls the following
methods
COLLECT SEQUENCE NUMBER DATA : collects the required
data for calculation of sequence number data from the given trace
file and stores in temporary file
DISPLAY SEQUENCE NUMBER DATA The generated temporary
file is used to generate the graph using crystal report
CALC DELAY DATA: This method calls the following methods
COLLECT DELAY DATA: collects the selected fields in list box
from temporary array and check the event field required of delay
data from the given trace file and stores in temporary file
DISPLAY DELAY DATA: The generated temporary file is used to
generate the graph using crystal report
CALC RTT DATA: This method calls the following methods
COLLECT RTT DATA: collects the required data for calculation of
RTT data from the given trace file and stores in temporary file
DISPLAY RTT DATA: The generated temporary file is used to
generate the graph using crystal report
CALC THRU PUT (ONE WAY): This method calls the following methods
COLLECT THRU PUT (ONE WAY): collects the required data for
calculation of thru put for one way delay data from the given trace
file and stores in temporary file
DISPLAY THRU PUT (ONE WAY): The generated temporary file
is used to generate the graph using crystal report
CALC THRU PUT (RTT): This method calls the following methods
COLLECT THRU PUT (RTT): collects the required data for
calculation of thru put for RTT data from the given trace file and
stores in temporary file
DISPLAY THRU PUT (RTT): The generated temporary file is used
to generate the graph using crystal report
7. SCREEN SHOTS
Sample trace files
1.1.1. simple wired trace file
+ 0.1 1 2 cbr 1000 ------- 2 1.0 3.1 0 0- 0.1 1 2 cbr 1000 ------- 2 1.0 3.1 0 0+ 0.108 1 2 cbr 1000 ------- 2 1.0 3.1 1 1- 0.108 1 2 cbr 1000 ------- 2 1.0 3.1 1 1r 0.114 1 2 cbr 1000 ------- 2 1.0 3.1 0 0+ 0.114 2 3 cbr 1000 ------- 2 1.0 3.1 0 0- 0.114 2 3 cbr 1000 ------- 2 1.0 3.1 0 0+ 0.116 1 2 cbr 1000 ------- 2 1.0 3.1 2 2- 0.116 1 2 cbr 1000 ------- 2 1.0 3.1 2 2r 0.122 1 2 cbr 1000 ------- 2 1.0 3.1 1 1+ 0.122 2 3 cbr 1000 ------- 2 1.0 3.1 1 1- 0.122 2 3 cbr 1000 ------- 2 1.0 3.1 1 1+ 0.124 1 2 cbr 1000 ------- 2 1.0 3.1 3 3- 0.124 1 2 cbr 1000 ------- 2 1.0 3.1 3 3r 0.13 1 2 cbr 1000 ------- 2 1.0 3.1 2 2+ 0.13 2 3 cbr 1000 ------- 2 1.0 3.1 2 2- 0.13 2 3 cbr 1000 ------- 2 1.0 3.1 2 2+ 0.132 1 2 cbr 1000 ------- 2 1.0 3.1 4 4- 0.132 1 2 cbr 1000 ------- 2 1.0 3.1 4 4r 0.138 1 2 cbr 1000 ------- 2 1.0 3.1 3 3+ 0.138 2 3 cbr 1000 ------- 2 1.0 3.1 3 3- 0.138 2 3 cbr 1000 ------- 2 1.0 3.1 3 3r 0.138706 2 3 cbr 1000 ------- 2 1.0 3.1 0 0+ 0.14 1 2 cbr 1000 ------- 2 1.0 3.1 5 5- 0.14 1 2 cbr 1000 ------- 2 1.0 3.1 5 5r 0.146 1 2 cbr 1000 ------- 2 1.0 3.1 4 4+ 0.146 2 3 cbr 1000 ------- 2 1.0 3.1 4 4- 0.146 2 3 cbr 1000 ------- 2 1.0 3.1 4 4r 0.146706 2 3 cbr 1000 ------- 2 1.0 3.1 1 1+ 0.148 1 2 cbr 1000 ------- 2 1.0 3.1 6 6- 0.148 1 2 cbr 1000 ------- 2 1.0 3.1 6 6r 0.154 1 2 cbr 1000 ------- 2 1.0 3.1 5 5+ 0.154 2 3 cbr 1000 ------- 2 1.0 3.1 5 5- 0.154 2 3 cbr 1000 ------- 2 1.0 3.1 5 5r 0.154706 2 3 cbr 1000 ------- 2 1.0 3.1 2 2+ 0.156 1 2 cbr 1000 ------- 2 1.0 3.1 7 7- 0.156 1 2 cbr 1000 ------- 2 1.0 3.1 7 7r 0.162 1 2 cbr 1000 ------- 2 1.0 3.1 6 6+ 0.162 2 3 cbr 1000 ------- 2 1.0 3.1 6 6- 0.162 2 3 cbr 1000 ------- 2 1.0 3.1 6 6r 0.162706 2 3 cbr 1000 ------- 2 1.0 3.1 3 3+ 0.164 1 2 cbr 1000 ------- 2 1.0 3.1 8 8
imple wireless trace file
s 0.267662078 _0_ RTR --- 0 message 32 [0 0 0 0] ------- [0:255 -1:255 32 0]
s 1.511681090 _1_ RTR --- 1 message 32 [0 0 0 0] ------- [1:255 -1:255 32 0] M 10.00000 0 (5.00, 2.00, 0.00), (20.00, 18.00), 1.00s 10.000000000 _0_ AGT --- 2 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0 0] 0 0r 10.000000000 _0_ RTR --- 2 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0 0] 0 0s 13.520299645 _0_ RTR --- 3 message 32 [0 0 0 0] ------- [0:255 -1:255 32 0] s 15.315262986 _1_ RTR --- 4 message 32 [0 0 0 0] ------- [1:255 -1:255 32 0] s 16.000000000 _0_ AGT --- 5 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0 0] 0 0r 16.000000000 _0_ RTR --- 5 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0 0] 0 0s 94.278068529 _0_ RTR --- 20 message 32 [0 0 0 0] ------- [0:255 -1:255 32 0] r 94.278504547 _1_ RTR --- 20 message 32 [0 ffffffff 0 800] ------- [0:255 -1:255 32 0] M 100.00000 1 (25.00, 20.00, 0.00), (490.00, 480.00), 15.00s 100.000000000 _0_ AGT --- 21 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0 0] 0 0r 100.000000000 _0_ RTR --- 21 tcp 40 [0 0 0 0] ------- [0:0 1:0 32 0] [0 0] 0 0s 100.000000000 _0_ RTR --- 21 tcp 60 [0 0 0 0] ------- [0:0 1:0 32 1] [0 0] 0 0r 100.000936054 _1_ AGT --- 21 tcp 60 [a2 1 0 800] ------- [0:0 1:0 32 1] [0 0] 1 0s 100.000936054 _1_ AGT --- 22 ack 40 [0 0 0 0] ------- [1:0 0:0 32 0] [0 0] 0 0r 100.000936054 _1_ RTR --- 22 ack 40 [0 0 0 0] ------- [1:0 0:0 32 0] [0 0] 0 0s 100.000936054 _1_ RTR --- 22 ack 60 [0 0 0 0] ------- [1:0 0:0 32 0] [0 0] 0 0r 100.001984108 _0_ AGT --- 22 ack 60 [a2 0 1 800] ------- [1:0 0:0 32 0] [0 0] 1 0s 100.001984108 _0_ AGT --- 23 tcp 1000 [0 0 0 0] ------- [0:0 1:0 32 0] [1 0] 0 0r 100.001984108 _0_ RTR --- 23 tcp 1000 [0 0 0 0] ------- [0:0 1:0 32 0] [1 0] 0 0s 100.001984108 _0_ RTR --- 23 tcp 1020 [0 0 0 0] ------- [0:0 1:0 32 1] [1 0] 0 0s 100.001984108 _0_ AGT --- 24 tcp 1000 [0 0 0 0] ------- [0:0 1:0 32 0] [2 0] 0 0r 100.001984108 _0_ RTR --- 24 tcp 1000 [0 0 0 0] ------- [0:0 1:0 32 0] [2 0] 0 0s 100.001984108 _0_ RTR --- 24 tcp 1020 [0 0 0 0] ------- [0:0 1:0 32 1] [2 0] 0 0r 100.006992162 _1_ AGT --- 23 tcp 1020 [a2 1 0 800] ------- [0:0 1:0 32 1] [1 0] 1 0s 100.006992162 _1_ AGT --- 25 ack 40 [0 0 0 0] ------- [1:0 0:0 32 0] [1 0] 0 0
Observed outputs
This is the output obtained for the parameter one way delay Vs time
This is the output obtained for the parameter sequence number Vs time
This is the output obtained for the parameter RTT Vs time
This is the output obtained for the parameter Throughput (RTT) Vs time
This is the output obtained for the parameter Throughput(one way delay) Vs time
DATA PRESENTATION
Simulation results can be analysed with the following graphs:
Cumulative sums of numbers of generated/sent/received/forwarded/dropped packets or bytes vs. time,
Throughput of generating/sending/receiving/forwarding/dropping packets or bits vs. time,
Packet size vs. minimal/average/maximal throughput of generating/sending/receiving/forwarding/dropping packets or bits,
Packet ID or send/receive event time vs. jitter, Throughput of sending/receiving bits vs. minimal/average/maximal delay, Throughput of sending/receiving bits vs. minimal/average/maximal jitter, Throughput of forwarding/receiving bits vs. minimal/average/maximal processing
time, Throughput of sending bits vs. minimal/average/maximal Round Trip Time, send/receive event time vs. number of intermediate nodes forwarding/receiving
packet, Packet ID vs. generate/send/receive/forward/drop event time, Packet sequence number vs. generate/send/receive/forward/drop event time, Packet size vs. minimal/average/maximal delay, Packet size vs. minimal/average/maximal processing time, Packet size vs. minimal/average/maximal Round Trip time, delay/jitter/processing time/RTT cumulative distribution, delay/jitter/processing time/RTT frequency distribution, Packet ID or send/receive event time vs. delay, Packet ID or forward/receive event time vs. processing time, Packet ID or send/receive event time vs. RTT, 3D graphs – numbers of generated/sent/forwarded/received/dropped/lost packets or
bytes at all the nodes.
6. EXPANDING SYSTEM CAPABILITIES
Trace graph architecture enables implementing new system functions very easy. For example adding a new graph can take only 10 minutes. The system could be expanded to read other trace file formats like real network traces, e.g. a trace format converter could be created for conversion to Trace graph format. Nodes movements with packets flows 2D/3D visualization could be added. More parameters from trace files could be used for new graphs implementation. MATLAB environment enables to develop the system very easy and very fast.
Future Work:
Simulation results can be analysed with the following graphs also:
cumulative sums of numbers of generated/sent/received/forwarded/dropped packets or bytes vs. time,
throughput of generating/sending/receiving/forwarding/dropping packets or bits vs. time,
packet size vs. minimal/average/maximal throughput of generating/sending/receiving/forwarding/dropping packets or bits,
packet ID or send/receive event time vs. jitter,
throughput of sending/receiving bits vs. minimal/average/maximal delay,
throughput of sending/receiving bits vs. minimal/average/maximal jitter,
throughput of forwarding/receiving bits vs. minimal/average/maximal processing time,
throughput of sending bits vs. minimal/average/maximal Round Trip Time,
send/receive event time vs. number of intermediate nodes forwarding/receiving packet,
packet ID vs. generate/send/receive/forward/drop event time,
packet sequence number vs. generate/send/receive/forward/drop event time,
packet size vs. minimal/average/maximal delay,
packet size vs. minimal/average/maximal processing time,
packet size vs. minimal/average/maximal Round Trip time,
delay/jitter/processing time/RTT cumulative distribution,
delay/jitter/processing time/RTT frequency distribution,
packet ID or send/receive event time vs. delay,
packet ID or forward/receive event time vs. processing time,
packet ID or send/receive event time vs. RTT,