View
518
Download
0
Category
Tags:
Preview:
Citation preview
CHAPTER 1
INTRODUCTION
1.1 Definition of ad hoc network
There is no unique definition what an ad-hoc network is, but one which describes the subject
very well was formulated by the IETF work group on Mobile Ad-hoc Networks (MANET):
“A mobile ad hoc network is an autonomous system of mobile routers … connected by
wireless links – the union of which form an arbitrary graph. The routers are free to move
randomly and organize themselves arbitrarily; thus, the network's wireless topology may
change rapidly and unpredictably. Such a network may operate in a standalone fashion, or
may be connected to the larger Internet.”
1.2 How they work
To give a very simple example, let us assume that there is already a small ad-hoc network in
place. When a new node – in this example it can be the PDA of Tom – joins the ad-hoc
network, there are a number of things to do: The device needs to set up contact to other nodes
in range, telling them: “I am here”. By this, the new node learns who the neighbor nodes are,
and vice versa. Another point is that the new node, in this example the PDA, needs a unique
identifier to make it addressable – an IP address in IP networks. For all this, the new node is
on its own, as there is neither a central controlling entity nor a pre-existing fixed
infrastructure in ad-hoc networks. When Tom wants to send a message from his PDA to that
of Maria, other nodes serve as a relay station in a process called multi-hop routing, if the
PDA of Maria is not in direct reach, using one of the routing protocols designed for ad-hoc
networks.
This small example shows a few imminent advantages of ad-hoc networks: They can extend
the range of the wireless technology in use, e.g. WLAN or Bluetooth, they can reduce the
node’s power consumption due to a lower transmission power required, and they increase the
node’s mobility. To make this work, though, ad-hoc networks require a critical mass of well-
behaving nodes, willing to forward other’s traffic.
1.3 Future for mobile ad-hoc networks
Ad-hoc networks have already been specified in the early seventies, but there has not been a
commercial breakthrough since then. Nevertheless, ad-hoc networks have received an
1
increased attention recently. For example, among the topics where papers could be submitted
to this year’s IST Mobile Summit, the area of ad-hoc and sensor networks has received the
highest number of submissions. One reason for the current uptake of ad-hoc networks are
certainly the great advances in wireless technologies over the last years. Examples are the
IEEE 802.11 series (many DSL users have their own hot-spot at home), the recent 802.16
WiMAX specification, which enables a significantly larger range of up to 10 km, or
Bluetooth for shorter distances. Another focus of current research are 4G mobile networks.
4G networks aim at integrating the various access and network technologies in order to
implement ubiquitous services. Ad-hoc networks are one piece of this concept.
The Suburban Ad Hoc (Area) Networking group focuses its research activities on techniques
for implementing Suburban Ad Hoc Networks. These are self organizing, quasi-static ad hoc
(typically wireless) networks which provide an alternative technology for providing high
speed digital connectivity to households, small businesses and distributed campuses. Specific
areas of research interest include security, low level routing protocols, access controls and
propagation behavior.
The ad hoc network is a communication network without a pre-exist network infrastructure.
In cellular networks, there is a network infrastructure represented by the base-stations, Radio
network controllers,… etc. In ad hoc networks every communication terminal (or radio
terminal RT) communicates with its partner to perform peer to peer communication. If the
required RT is not a neighbor to the initiated call RT (outside the coverage area of the RT),
then the other intermediate RTs are used to perform the communication link. This is called
multi-hope peer to peer communication. This collaboration between the RTs is very
important in the ad hoc networks. In ad hoc networks all the communication network
protocols should be distributed throughout the communication terminals (i.e. the
communication terminals should be independent and highly cooperative).
1.4 Creation of ad hoc network
Ad hoc networks are temporary wireless networks that allow two computers to share files and
an Internet connection. Computers can create a wireless network without the need for a
router, especially for a quick network setup. Any computer with a wireless card can connect
to one central computer, which acts like a router. Ad hoc networks can be secured with
2
passwords to prevent outside access. Windows provides users with a quick way to create ad
hoc networks and share their Internet connections in the process
1.Select your central computer. This computer must remain on at all times in order for
other computers to connect to the ad hoc network.
2. Click "Start" and press "Connect To." Choose "Show All Connections." If you don't see
"Connect To," go to "Control Panel" and select "Network Connections."
3. Click "Set up a connection or network" for Vista operating systems. Choose "Set up an ad
hoc network" and click "Next." Follow the steps in the network creation wizard to create your
network.
For XP systems, continue to Step 4. Vista users continue to Step 6.
4.Right-click your wireless connection under "Network Connections." Choose "Properties."
Click the "Wireless Networks" tab.
5. Press "Add" to create a new network. Type a short name for your network in the "Network
Name" box. Add a password to your network by choosing "WEP" from the "Network
Authentication" drop down box. Type a password into the two password boxes.
Check the "This is a computer to computer (ad hoc) network" checkbox at the bottom of the
screen. Press "OK" to create the network.
Right-click your Internet connection and choose "Properties." Go to "Advanced" and check
the "Allow other users to connect through this computer's Internet connection" box. Choose
"Wireless" as your connection type. Press "OK" to share your Internet connection.
6. Connect other computers to the ad hoc network. Open the computer's "Network
Connections" as stated in Step 2. Right-click the computer's wireless connection and select
"View Available Wireless Networks." Select the ad hoc network and press "Connect
1.5 Characteristics
Mobile Ad hoc Network (MANET) is a collection of independent mobile nodes that can
communicate to each other via radio waves. The mobile nodes that are in radio range of each
other can directly communicate, whereas others need the aid of intermediate nodes to route
3
their packets. These networks are fully distributed, and can work at any place without the
help of any infrastructure. This property makes these networks highly expiable and robust.
The characteristics of these networks are summarized as follows:
• Communication via wireless means.
• Nodes can perform the roles of both hosts and routers.
• No centralized controller and infrastructure. Intrinsic mutual trust.
• Dynamic network topology. Frequent routing updates.
• Autonomous, no infrastructure needed.
• Can be set up anywhere.
• Energy constraints
• Limited security
Generally, the communication terminals have a mobility nature which makes the topology of
the distributed networks time varying. The dynamical nature of the network topology
increases the challenges of the design of ad hoc networks. Each radio terminal is usually
powered by energy limited power source (as rechargeable batteries). The power consumption
of each radio terminal could be divided generally into three parts, power consumption for
data processing inside the RT, power consumption to transmit its own information to the
destination, and finally the power consumption when the RT is used as a router, i.e.
forwarding the information to another RT in the network. The energy consumption is a
critical issue in the design of the ad hoc networks.
The mobile devices usually have limited storage and low computational capabilities. They
heavily depend on other hosts and resources for data access and information processing. A
reliable network topology must be assured through efficient and secure routing protocols for
Ad Hoc networks.
1.6 Attacks in Ad Hoc Network
The fundamental aspects of computer security like confidentiality, integrity, authentication
and non-repudiation are valid when production of routing in network is discussed.
Confidentiality ensures that classified information in the network is never disclosed to
unauthorized entities. Sensitive information, such as strategic military decisions or location
4
information requires confidentiality. Leakage of in the network. Availability implies that the
requested services (e.g. bandwidth and connectivity) are available in a timely manner even
though there is a potential problem in the system. Availability of a network can be tempered
for example by dropping off packets and by resource depletion attacks.
Authenticity is a network service to determine a user’s identity. Without authentication, an
attacker can impersonate any node, and in this way, one by one node, it can gain control over
the entire network. finally, non-repudiation ensures that the information originator cannot
deny having sent the message. Non-repudiation is useful for detection and isolation of
compromised nodes such information to enemies could have devastating consequences.
Integrity guarantees that a message being transferred between nodes is never altered or
corrupted. Data can be altered either intentionally by malicious nodes in the network or
accidentally because of benign failures, such as radio propagation impairment or through
hardware glitches.
1.6.1 Passive attacks: A passive attack does not disrupt the normal operation of the
network; the attacker snoops the data exchanged in the network without altering it. Here the
requirement of confidentiality gets violated. Detection of passive attack is very difficult since
the operation of the network itself doesn’t get affected. One of the solutions to the problem is
to use powerful encryption mechanism to encrypt the data being transmitted, there by making
it impossible for the attacker to get useful information from the data overhead.
1.6.2 Active attacks: An active attack attempts to alter to destroy the data being exchanged
in the network there by disrupting the normal functioning of the network. Active attacks can
be internal or external. External attacks are carried out by nodes that do not belong to the
network. Internal attacks are from compromised nodes that are part of the network.
Type Of Attacks
Passive Attacks: An attacker stay quietly and listening to the route traffic. The purpose of
passive attack is to discover routing information, relationship between nodes, and the network
topology.
Active Attacks: An attacker performs actions which to cause interruption and congestion to
the network traffic by modifying the content of routing packet, broadcasting wrong
information or old information.
5
Denial of Service Attacks: An attack on the network that causes a loss of service to other
nodes, either by consuming the bandwidth or overloading the system.
Impersonation Attacks: An attacker broadcast wrong routing information to other nodes and
terminates the traffic for the desired destination node.
Military Attacks: An attempt to destruct enemy networks in preparation for battle including
intelligence gathering. An attacker use passive attack to gathering information about network
topology. To disable some part of the network temporarily by using denial of service attacks
1.7 Security in ad hoc
Among the requirements, the protection of information plays a central
role. The concept of anonymity is quite recent: users want that no one can determine with
whom they communicate, implying the necessity to hide the user identity from eavesdroppers
and to resist against traffic analysis. To protect information, data can be ciphered using a
secret key cryptosystem which decreases the performance. We propose an original solution
inspired by network coding techniques and the McEliece public key cryptosystem (see [9]).
This technique has the advantage to provide anonymity and confidentiality without affecting
too much the quality of service. However we do not claim to guarantee perfect security
(which is impossible) but rather an average security. We focus on a solution that ensures a
relative security for information during a relatively limited period of time. The main objective
of our solution is to discourage attackers by requiring too much effort to recover the
information compared to the time when the information is relevant. Our proposal assumes
that a multipath routing or forwarding protocol is available. Multiple paths between a source
and a destination ensure packet diver- sity, which improves anonymity: the information is
scattered into several packets which belong to different flows. This strong requirement for
network protocols allows us to detect intrusion and to protect information as described later
in the document.
1.8 Solutions improving network performances
The above deviation from a pure on-demand routing approach is also tackled by
MASK [35] to improve not only directly privacy protection but also anonymous routing
performances in term of network capacity. MASK integrates a proactive neighbor detection
protocol to create one-hop anonymous links with its neighbors prior to on-demand route
discovery scheme to establish virtual anonymous circuit. This knowledge of the node
neighborhood aims at reducing crypto-functions processing overheads naturally induced by a
6
pure reactive approach (through its on-demand route discovery function). This proactive
neighbor detection scheme is identity-free (as originally proposed globally by ANODR) and
is performed through a pairing-based anonymous handshake [28] between any pair of
neighbors. For key exchanges between a given node and its new detected neighbors, MASK
relies on a three step handshake. Once the handshake procedure is ended, each pair of nodes
shares a chain of secret keys and locally unique link identifiers pair that corresponds to the
pseudonyms used during handshake. In the proactive neighbor detection part of MASK,
HELLO messages are periodically sent to hold the pairing cryptographic materials. Then,
MASK relies on classical pure on-demand route discovery scheme. As for ASR, intermediary
forwarding node keeps an information state about previously RREQ message sent by a source
node. Once it receives a RREP message, this information is used by each intermediary node
to decide whether it should forward the information and to which node. However, MASK
presents some drawbacks concerning privacy protection by focusing on the improvement of
network capacity, contrary to ASR or SDAR. For example, as summarized by [27], the final
destination appeared in plain text in each RREQ. Moreover, MASK relies on a tight
synchronization between keys and pseudonyms of neighboring nodes. More recently, ODAR
[52] has been proposed to tackle also performance issues at different levels, necessary to
design a suitable anonymous routing solution for Ad Hoc networks: storage, processing and
communication. This approach is based on a reactive routing approach and relies on Bloom
filters, previously used in [44] to provide node, link, path anonymity and efficiency at once.
By definition, the wireless environment is constraining because communication performance
largely depends on the quality of the radio transmission and on the capacity of the networked
device. Errors bits or burst due to this transmission are common in such an environment, the
capacity could be weak (50kits/sec) and the mobile devices like PDAs and laptops are not so
efficient as an actual fixed computer. This means that such an environment has also to face
CPU-related constraints, and it is a difficult, but interesting challenge to propose some
solution which may improve or at least not degrade the performance of a given service and
which warrants the user’s privacy. For sensor networks, energy is an additional constraint
which is an important factor. In fact, many efficient solutions can be found in the literature
but they rarely treat simultaneously privacy in a very constraining context. Traditionally,
strong security and communication service are complementary; it is very often a question of
trade-off. A strong security is time consuming and needs a large resource which can alter the
quality of the services.
7
CHAPTER 2
ROUTING PROTOCOLS
2.1 List of ad hoc routing protocols
An ad hoc routing protocol is a convention, or standard, that controls how nodes
decide which way to route packets between computing devices in a mobile ad hoc network .
In ad hoc networks, nodes do not start out familiar with the topology of their
networks; instead, they have to discover it. The basic idea is that a new node may announce
its presence and should listen for announcements broadcast by its neighbors. Each node
learns about nodes nearby and how to reach them, and may announce that it, too, can reach
them.
1. Pro-active (table-driven) routing
2. Reactive (on-demand) routing
3. Flow-oriented routing
4. Adaptive (situation-aware) routing
5. Hybrid (both pro-active and reactive) routing
6. Hierarchical routing protocols
7. Host Specific Routing protocols
8. Geographical routing protocols
9. Power-aware routing protocols
10. Multicast routing
11. Geographical multicast protocols (Geocasting)
12. Other protocol classes
13. External links
2.1.1 Pro-active (table-driven) routing
This type of protocols maintains fresh lists of destinations and their routes by periodically
distributing routing tables throughout the network. The main disadvantages of such
algorithms are:
1. Respective amount of data for maintenance.
2. Slow reaction on restructuring and failures.
Example:
1. DSDV ( Dynamic Destination-Sequenced Distance Vector routing protocol)
2. OLSR (Optimized Link State Routing Protocol)
8
2.1.2 Reactive (on-demand) routing
This type of protocols finds a route on demand by flooding the network with Route
Request packets. The main disadvantages of such algorithms are:
1. High latency time in route finding.
2. Excessive flooding can lead to network clogging.
Example:
1. DSR (Dynamic Source Routing)
2. AODV (Ad hoc On-demand Distance Vector)
2.1.3 Flow-oriented routing
This type of protocols finds a route on demand by following present flows. One option is
to unicast consecutively when forwarding data while promoting a new link. The main
disadvantages of such algorithms are:
1. Takes long time when exploring new routes without a prior knowledge.
2. May refer to estimative existing traffic to compensate for missing knowledge on
routes.
Example:
1. LMR (Lightweight Mobile Routing protocol)
2. LQSR (Link Quality Source Routing)
2.1.4 Adaptive (situation-aware) routing
This type of protocols combines the advantages of proactive and of reactive routing. The
routing is initially established with some proactively prospected routes and then serves the
demand from additionally activated nodes through reactive flooding. Some metrics must
support the choice of reaction. The main disadvantages of such algorithms are:
1. Advantage depends on amount of nodes activated.
2. Reaction to traffic demand depends on gradient of traffic volume.
An example of adaptive algorithms is:
1. TORA (Temporally-ordered routing algorithm routing protocol)
2.1.5 Hybrid (both pro-active and reactive) routing
This type of protocols combines the advantages of proactive and of reactive routing. The
routing is initially established with some proactively prospected routes and then serves the
demand from additionally activated nodes through reactive flooding. The choice for one or
9
the other method requires predetermination for typical cases. The main disadvantages of such
algorithms are:
1. Advantage depends on amount of nodes activated.
2. Reaction to traffic demand depends on gradient of traffic volume.
Example:
1. OORP (Order One Routing Protocol
2. TORA (Temporally Ordered Routing Algorithm)
2.1.6 Hierarchical routing protocols
With this type of protocols the choice of proactive and of reactive routing depends on the
hierarchic level where a node resides. The routing is initially established with some
proactively prospected routes and then serves the demand from additionally activated nodes
through reactive flooding on the lower levels. The choice for one or the other method requires
proper attributation for respective levels. The main disadvantages of such algorithms are:
1. Advantage depends on depth of nesting and addressing scheme.
2. Reaction to traffic demand depends on meshing parameters.
Examples of hierarchical routing algorithms are:
1. CBRP (Cluster Based Routing Protocol)
2. DDR (Distributed Dynamic Routing Algorithm)
2.1.7 Host Specific Routing protocols
This type of protocols requires thorough administration to tailor the routing to a certain
network layout and a distinct flow strategy. The main disadvantages of such algorithms are:
1. Advantage depends on quality of administration addressing scheme.
2. Proper reaction to changes in topology demands reconsidering all parametrizing.
Example:
HSR (Hierarchical State Routing)
2.1.8 Geographical routing protocols
This type of protocols acknowledges the influence of physical distances and distribution of
nodes to areas as significant to network performance. The main disadvantages of such
algorithms are:
1. Efficiency depends on balancing the geographic distribution versus occurrence of
traffic.
2. Any dependence of performance with traffic load thwarting the negligence of distance
may occur in overload.
10
2.1.9 Power-aware routing protocols
Energy required to transmit a signal is approximately proportional to dα, where d is the
distance and is the attenuation factor or path loss exponent, which depends on the
transmission medium. When α = 2 (which is the optimal case), transmitting a signal half the
distance requires one fourth of the energy and if there is a node in the middle willing to spend
another fourth of its energy for the second half, data would be transmitted for half of the
energy than through a direct transmission - a fact that follows directly from the inverse square
law of physics.
The main disadvantages of such algorithms are:
1. This method induces a delay for each transmission.
2. No relevance for energy network powered transmission operated via sufficient
repeater infrastructure.
2.2 TEMPORALLY-ORDERED ROUTING ALGORITHM (TORA)
The Temporally Ordered Routing algorithm presented by Park and Corson in Park1997
belongs to the family of link reversal routing algorithms. It is based on the ideas of the GB
and LMR algorithms. It uses Query and Reply packets as in LMR but combines this with the
notion of height as in the GB partial reversal algorithm. The main enhancement comes from
the introduction of a time value which stores the time since a link failure.
TORA also maintains a DAG by means of an ordered quintuple with the following
information:
t time of a link failure
oid originator id
r reflection bit indicates 0=original level 1=reflected level
d integer to order nodes relative to reference level
i the nodes id
The triplet (t, oid, r) is called the reference level. And the tuple (d, i) is said to be an offset
within that reference level.
As with the GB algorithms the heights of the nodes for a given destination to each other
determine the direction of the edges of the directed acyclic graph. The DAG is destination
oriented (routed at the destination) when the quintuples which represent the heights are
maintained in lexicographical order, the destination having the smallest height, traffic always
11
flowing downstream. Heights are however not needed for route discovery, instead a
mechanism as in LMR is used. Also nodes which do not currently need to maintain a route
for themselves or for others won't change a height value. Each node has a Route-required flag
for that purpose; additionally the time since the las UPD (update-) packet was sent is
recorded.
Each node maintains a neighbor table containing the height of the neighbor nodes. Initially
the height of all the nodes is NULL. (This is not zero "0" but NULL "-") so their quintuple is
(-,-,-,-,i). The height of a destination neighbor is (0, 0, 0, 0, dest).
2.2.1 Route creation
A node which requires a link to a destination because it has no downstream neighbors for it
sends a QRY (query) packet and sets its (formerly unset) route-required flag. A QRY packet
contains the destination id of the node a route is seeked to. The reply to a query is called an
update UPD packet. It contains the height quintuple of the neighbor node answering to a
query and the destination field which tells for which destination the update was meant for.
A node receiving a QRY packet does one of the following:
if its route required flag is set, this means that it doesn't have to forward the QRY,
because it has itself already issued a QRY for the destination, but better discard it to prevent
message overhead.
if the node has no downstream links and the route-required flag was not set, it sets its
route-required flag and rebroadcasts the QRY message.
if a node has at least one downstream neighbor and the height for that link is null it
sets its height to the minimum of the heights of the neighbor nodes, increments its d value by
one and broadcasts an UPD packet.
if the node has a downstream link and its height is non-NULL it discards the QRY
packet if an UPD packet was being issued since the link became active (rr-Flag set).
Otherwise it sends an UPD packet.
A node receiving an update packet updates the height value of its neighbor in the table and
takes one of the following actions:
if the reflection bit of the neighbors height is not set and its route required flag is set it
sets its height for the destination to that of its neighbors but increments d by one. It then
12
deletes the RR flag and sends an UPD message to the neighbors, so they may route through
it.
if the neighbors route is not valid (which is indicated by the reflection bit) or the RR
flag was unset, the node only updates the entry of the neighbors node in its table.
This is best shown by an example from the original paper. Park1997
Circles in the pictures below signify that the RR flag is set
node C requires a route, so it broadcasts a QRY
13
The QRY propagates until it hits a node which has a route to the destination, this node then
sends an UPD message
14
The UPD is also propagated, while node E sends a new UPD
15
Fig 2.1 Route Discovery in TORA
16
2.2.2 Route Maintenance
Fig 2.2 Flowchart for Route maintenance in TORA
Case 1 Generate: The node has lost its last downstream link due to a failure. The
node defines a new "reference level", so it sets oid (originator id) to its node id and t to the
time of the failure. This is done only if the node has upstream neighbors. If not it sets its
height to NULL.
Case 2 Propagate: The node has no more downstream link due to a link reversal
following the receipt of an update packet and the reference levels (t,oid,r) of its neighbors are
not equal. The node then propagates the references level of its highest neighbor and sets the
offset to a value which is lower (-1) than the offset of all its neighbors with the maximum
level.
17
Case 3 Reflect: The node has lost its downstream links due to a link reversal
following the receipt of an update packet and the reference heights of the neighbors of the
node are equal with the reflection bit not set. The node then reflects back the reference height
by setting the reflection bit. It's d value is set to 0.
Case 4 Detect: The node has lost its downstream links due to a link reversal following
the receipt of an update packet and the reference heights of the neighbors of the node are
equal with the reflection bit set. This means that the node has detected a partition and begins
the route erasure procedure. The height values are set to NULL.
Case 5 Generate: The node has lost its last downstream link due to a link reversal
following the receipt of an update packet and the reference heights of all the neighbors are
equal with the reflection bit set and the oid of the neighbor’s heights isn't the node's id. The
node then sets t to the time of the link failure and sets oid to its own id. The d value is set to
0. This means that the link failure required no reaction. The node experienced a link failure
between the time it propagated a higher reference (from someone else) and the time this level
got reflected from a place further away in the network. Because the node didn't define the
new reference level itself this is not necessarily an indication of a partitioning of the network.
So the node simply defines a new higher reference level with the time of the link failure.
Example
The link between B and E fails
18
B still has a downstream link to the destination, so no action is needed
The link between D and H fails
19
Node D defines a new reference level. It sets the originator id to his own id since it was node
D that defined the new level. The logical time of the link failure is also recorded (t=1). The
new reference level is now higher than that of the neighbors, so the update message has as
effect the reversal of the links to A and B. This is case 1 of the decision tree.
Node B has lost its downstream not because of a link failure, but because of a link reversal. It
propagates the reference level that was defined by D. Because the node must have a lower
height than the upstream node D it has to set it's sub height (offset) lower than that of D, so
d=-1. This is case 2 of the decision tree.
20
Fig 2.3 Route Maintenance in TORA
Node A has now also has lost its last downstream due to an update and propagates the
reference level and sets its d to the lowest of its neighbors -1. (also Case 2)
2.2.3 Partition detection and route erasure
The graphics below where copied from a presentation of TORA by Jeff Dobbelaere, Wireless
& Mobile Systems Working Group at the College of William and Mary, Williamsburg VA,
USA http://www.cs.wm.edu/~kearns/swg97/tora.pdf)
Here the link F to G fails, partitioning G from the rest of the network
21
F defines a new reference level and sends an update message with oid=F and the time of the
link failure
The links D-F and E-F reverse. Node D propagates the reference level.
Node E now "reflects" the reference level. The reference heights of the neighbors are equal
with the reflection bit not set. E sets the reflection bit to indicate the reflection and sets its
offset to 0. Node C just propagates the new reference level.
22
Node A now propagates the reference level.
Now node B reflects the reference level, because all of its neighbors have the same reference
height and their reflection bits are not set. The offset (d) is set to 0 to make node B now be
higher than its neighbors and the reflection bit is set.
The links are now reversed in the opposite direction, but the reflection bit is set.
23
Fig 2.4 Partition detection and route erasure
When node D propagates the reference level the reference heights of the neighbors of F are
equal, but the reflection bit is set. F has detected a partition and sets its height to NULL
indicating that the route to the destination no longer exists. The route erase protocol is
triggered.
2.3 AD HOC ON-DEMAND DISTANCE VECTOR ROUTING
PROTOCOL (AODV)
The Ad Hoc On-Demand Distance Vector Routing Protocol is a reactive routing protocol
based on DSDV. It was introduced in 1997. AODV is designed for networks with tens to
thousands of mobile nodes. One feature of AODV is the use of a destination sequence
number for each routing table entry. The sequence number is created by the destination node.
The sequence number included in a route request or route reply is sent to requesting nodes.
Sequence number are very important because they ensures loop freedom and is simple to
program. Sequence numbers are used by other nodes to determine the freshness of routing
24
information. If a node has the choice between 2 routes to a destination, a node is required to
select the one with the greatest sequence number.
AODV deals with routing table. Every node has a routing table. When a node knows a route
to the destination, it sends a route reply to the source node. Its entries are:
Destination IP Address
Prefix Size
Destination Sequence Number
Next Hop IP Address
Lifetime (expiration or deletion time of the route)
Hop Count (number of hops to reach the destination)
Network Interface
Other state and routing flags (e.g., valid, invalid)
Route Requests (RREQs), Route Replies (RREPs) and Route Errors (RERRs) are message
types defined by AODV. The next pictures will give an example of AODV.
2.3.1 Route creation
S would like to communicate with D
The node broadcasts a RREQ to find a route to the destination. S generates a Route Request
with destination address, Sequence number and Broadcast ID and sent it to his neighbor
nodes
25
Each node receiving the route request sends a route back (Forward Path) to the node.
A route can be determined when the RREQ reaches a node that offers accessibility to the
destination, e.g., the destination itself).
26
The route is made available by unicasting a RREP back to D and is written in the routing
table from S. After receiving the route reply every node has to update its routing table if the
sequence number is more recent.
Now node S can communicate with node D.
Fig 2.5 Route creation in AODV
When a link break in an active route is detected, the broken link is invalid and a RERR
message is sent to other nodes. If the nodes have a route in their routing table with this link,
the route will be erased. Node S sends once again a route request to his neighbor nodes. Or a
27
node on the way to the destination can try to find a route to D. That mechanism is called:
Local Route Repair.
2.3.2 Route Maintenance
Fig 2.6 Route Maintenance in AODV
Advantages
Loop free routing
Optional multicast
Reduced control overhead
Disadvantages
Delay caused by route discovery process
Bidirectional connection needed in order to detect an unidirectional link
2.4 DYNAMIC SOURCE ROUTING (DSR)
DSR is a reactive routing protocol which is able to manage a MANET without using
periodic table-update messages like table-driven routing protocols do. DSR was specifically
designed for use in multi-hop wireless ad hoc networks. Ad-hoc protocol allows the network
to be completely self-organizing and self-configuring which means that there is no need for
an existing network infrastructure or administration.
For restricting the bandwidth, the process to find a path is only executed when a path
is required by a node (On-Demand Routing). In DSR the sender (source, initiator) determines
the whole path from the source to the destination node (Source-Routing) and deposits the
addresses of the intermediate nodes of the route in the packets. Compared to other reactive
28
routing protocols like ABR or SSA, DSR is beacon-less which means that there are no hello
messages used between the nodes to notify their neighbors about her presence. DSR was
developed for MANETs with a small diameter between 5 and 10 hops and the nodes should
only move around at a moderate speed.
DSR is based on the Link-State-Algorithms which mean that each node is capable to
save the best way to a destination. Also if a change appears in the network topology, then the
whole network will get this information by flooding.
2.4.1 Route Discovery
Fig 2.7 Route Discovery in DSR
If node A has in his Route Cache a route to the destination E, this route is immediately used.
If not, the Route Discovery protocol is started:
1. Node A (initiator) sends a Route Request packet by flooding the network
2. If node B has recently seen another Route Request from the same target or if the
address of node B is already listed in the Route Record, Then node B discards the
request!
3. If node B is the target of the Route Discovery, it returns a Route Reply to the initiator.
The Route Reply contains a list of the “best” path from the initiator to the target.
When the initiator receives this Route Reply, it caches this route in its Route Cache
for use in sending subsequent packets to this destination.
4. Otherwise node B isn’t the target and it forwards the Route Request to his neighbors
(except to the initiator).
29
Path-finding-process: Route Request & Route Reply
Fig 2.8 Route Request & Route Reply
30
2.4.2 Route Maintenance
In DSR every node is responsible for confirming that the next hop in the Source
Route receives the packet. Also each packet is only forwarded once by a node (hop-by-hop
routing). If a packet can’t be received by a node, it is retransmitted up to some maximum
number of times until a confirmation is received from the next hop.
Only if retransmission results then in a failure, a Route Error message is sent to the initiator
that can remove that Source Route from its Route Cache. So the initiator can check his Route
Cache for another route to the target. If there is no route in the cache, a Route Request packet
is broadcasted.
Fig 2.9 Route Maintenance
1. If node C does not receive an acknowledgement from node D after some number of
requests, it returns a RouteError to the initiator A.
2. As soon as node receives the RouteError message, it deletes the broken-link-route
from its cache. If A has another route to E, it sends the packet immediately using this
new route.
3. Otherwise the initiator A is starting the Route Discovery process again.
Advantages
Reactive routing protocols have no need to periodically flood the network for
updating the routing tables like table-driven routing protocols do.
Intermediate nodes are able to utilize the Route Cache information efficiently to
reduce the control overhead.
The initiator only tries to find a route (path) if actually no route is known (in cache).
Current and bandwidth saving because there are no hello messages needed (beacon-
less).
Disadvantages
The Route Maintenance protocol does not locally repair a broken link.
The broken link is only communicated to the initiator.
The DSR protocol is only efficient in MANETs with less then 200 nodes.
31
CHAPTER 3
PROJECT DESCRIPTION
3.1 Problem definition
Mobile Ad-Hoc networks, nodes are able to move and synchronize with their
neighbors. Due to mobility, connections in the network can change dynamically and nodes
can be added and removed at any time. We are going to compare Mobile Ad-Hoc network
routing protocols TORA, AODV and DSR using network simulator NS 2.34. We have
compared the performance of three protocols together and individually too. The performance
matrix includes PDR (Packet Delivery Ratio), Throughput, End to End Delay, Routing
overhead. We are comparing the performance of routing protocols when packet size changes,
when time interval between packet sending changes, when mobility of nodes changes.
In Ad-Hoc networking the method which is already existed used to have some
drawbacks such as delay in packet transmission, data dropping, data corruption, Attacks in
nodes, time taken for route selection etc.. Space allocation for this network also considerable.
These factors are based on the routing algorithm used in the Ad hoc network. The problems
which is above mentioned and energy conservation for movement of nodes are can be
modified by using the routing algorithm used in the Ad hoc network, because of these
problems the Ad hoc network is get delay to develop.
3.2 Block Diagram:
Fig 3.1 Block diagram of Ad hoc
32
CHAPTER 4
SYSTEM SPECFICATION
4.1 Hardware requirements
According to hardware description the implementation of security algorithm in hardware
section is not yet done. The research of security algorithm is on process. Since the hardware
implementation is high cost for this network, it is more efficient for packet transmission. The
research is only tested by using simulation tools like network simulator2 software tool. The
devices used for this network may be as like a Bluetooth device. Device implementation may
be change according to their applications. For communication purpose or for internet
accessing the device may change but for the any Ad hoc device our routing algorithm is in
build
SECURE MULTIPATH ROUTING
The DSR is a simple and efficient routing protocol designed specifically for use in
multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be
completely self-organizing and self-configuring, without the need for any existing network
infrastructure or administration. The protocol is composed of the two main mechanisms of
“Route Discovery” and “Route Maintenance’, which work together to allow nodes to
discover and maintain routes to arbitrary destinations in the ad hoc network All aspects of the
protocol operate entirely on DSR protocol include easily guaranteed loop-free routing,
operation in networks containing unidirectional links, use of only “soft state” in routing, and
very rapid recovery when routes in the network change.
In DSR, Route Discovery and Route Maintenance each operate entirely “on
demand”. In particular, unlike other protocols, DSR requires no periodic packets of any kind
at any layer within the network. For example, DSR does not use any periodic routing
advertisement, link status sensing, or neighbor detection packets, and does not rely on these
functions from any underlying protocols in the network. This entirely on demand behavior
and lack of periodic activity allows the number of overhead packets caused by DSR to scale
all the way down to zero, when all nodes are approximately stationary with respect to each
other and all routes needed for current communication have already been discovered.
4.2 Software Requirements
OPERATING SYSTEM : Linux ( Ubuntu 10.0)
SOFTWARE : NS 2.34 (With g++, gcc, tcl Compiler)
33
4.3 Network Interface Label packets with incoming interface identifier—it is used by some multicast
routing protocols. The class variable “Simulator Number Interfaces_ 1” tells ns to add these
interfaces, and then, it is added to either end of the simplex link. Multicast routing protocols
are discussed in a separate chapter.
Dynamic Link Object that gates traffic depending on whether the link is up or down. It
expects to be at the head of the link, and is inserted on the link just prior to simulation start.
It’s status_ variable control whether the link is up or down. The description of how the Dyna
Link object is used is in a separate chapter.
Delay Link Object that models the link’s delay and bandwidth characteristics. If the link is
not dynamic, then this object simply schedules receive events for the downstream object for
each packet it receives at the appropriate time for that packet. However, if the link is
dynamic, then it queues the packets internally, and schedules one receives event for itself for
the next packet that must be delivered. Thus, if the link goes down at some point, this object’s
reset () method is invoked, and the object will drop all packets in transit at the instant of link
failure. We discuss the specifics of this class in another chapter.
Queues - Model the output buffers attached to a link in a “real” router in a network. In ns,
they are attached to, and are considered as part of the link. We discuss the details of queues
and different types of queues in nsin another chapter.
TTL Checker - will decrement the ttl in each packet that it receives. If that ttl then has a
positive value, the packet is forwarded to the next element on the link. In the simple links,
TTL Checkers are automatically added, and are placed as the last element on the link,
between the delay element, and the entry for the next node.
Network simulator software:
Before implementing the ad hoc network practically the network is
tested by simulating platforms there are some platforms available for creating networks such
type of software used for testing the ad hoc network is network simulator software there are
34
many versions are available current version used for our project is network simulator ns2-
2.34. to work in this platform there are simulation codlings are available thes codings are c++
based codings the main note of it is these program can execute only in linux operating system
the procedure for executing in linux os are follows
1)go to the “APPLICATION” in the task bar of screen select “TEXT EDITOR”
2) The codings should type there after complete typing the coding save the file as “FILE
NAME . tcl”
3)for executing the coding open the terminal icon this terminal is like a commend window
used in xp operating system
5)first commend should be typed is “SU” this refers to super user then click enter next type
“cd Desktop”
This commend refers to change the directory to desktop
6) after click enter type “ls” this commend stands for listing the items in desktop
7) finally type “ns file name.tcl” for executing the coding and the output of the coding is
executed
CHAPTER 5
PROGRAMMING
5.1 AODV PROGRAM
# wrls1.tcl
# A 5-node example for ad-hoc simulation with AODV
# Define options
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# max packet in ifq
set val(nn) 5 ;# number of mobilenodes
set val(rp) AODV ;# routing protocol
35
set val(x) 500 ;# X dimension of topography
set val(y) 400 ;# Y dimension of topography
set val(stop) 150 ;# time of simulation end
set ns [new Simulator]
#Creating trace file and nam file
set tracefd [open aodv1.tr w]
set windowVsTime2 [open aodv.tr w]
set namtrace [open aodv.nam w]
$ns trace-all $tracefd
$ns namtrace-all-wireless $namtrace $val(x) $val(y)
# set up topography object
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)
# configure the nodes
$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace ON
for {set i 0} {$i < $val(nn) } { incr i } {
set node_($i) [$ns node]
36
}
# Provide initial location of mobilenodes
$node_(0) set X_ 5.0
$node_(0) set Y_ 5.0
$node_(0) set Z_ 0.0
$node_(1) set X_ 490.0
$node_(1) set Y_ 285.0
$node_(1) set Z_ 0.0
$node_(2) set X_ 150.0
$node_(2) set Y_ 240.0
$node_(2) set Z_ 0.0
$node_(3) set X_ 250.0
$node_(3) set Y_ 240.0
$node_(3) set Z_ 0.0
$node_(4) set X_ 500.0
$node_(4) set Y_ 500.0
$node_(4) set Z_ 0.0
# Generation of movements
$ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0"
$ns at 15.0 "$node_(1) setdest 45.0 285.0 5.0"
$ns at 110.0 "$node_(0) setdest 480.0 300.0 5.0"
# Set a TCP connection between node_(0) and node_(1)
set tcp [new Agent/TCP/Newreno]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns attach-agent $node_(0) $tcp
$ns attach-agent $node_(1) $sink
37
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 10.0 "$ftp start"
# Printing the window size
proc plotWindow {tcpSource file} {
global ns
set time 0.01
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
puts $file "$now $cwnd"
$ns at [expr $now+$time] "plotWindow $tcpSource $file" }
$ns at 10.1 "plotWindow $tcp $windowVsTime2"
# Define node initial position in nam
for {set i 0} {$i < $val(nn)} { incr i } {
# 30 defines the node size for nam
$ns initial_node_pos $node_($i) 30
}
# Telling nodes when the simulation ends
for {set i 0} {$i < $val(nn) } { incr i } {
$ns at $val(stop) "$node_($i) reset";
}
# ending nam and the simulation
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
$ns at $val(stop) "stop"
$ns at 150.01 "puts \"end simulation\" ; $ns halt"
proc stop {} {
global ns tracefd namtrace
$ns flush-trace
close $tracefd
38
close $namtrace
exec nam aodv.nam &
exit 0
}
$ns run
5.2 DSR PROGRAM
# wrls1.tcl
# A 5-node example for ad-hoc simulation with DSR
# Define options
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) CMUPriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# max packet in ifq
set val(nn) 5 ;# number of mobilenodes
set val(rp) DSR ;# routing protocol
set val(x) 500 ;# X dimension of topography
set val(y) 400 ;# Y dimension of topography
set val(stop) 150 ;# time of simulation end
set ns [new Simulator]
#Creating trace file and nam file
set tracefd [open dsr1.tr w]
set windowVsTime2 [open dsr.tr w]
set namtrace [open dsr.nam w]
39
$ns trace-all $tracefd
$ns namtrace-all-wireless $namtrace $val(x) $val(y)
# set up topography object
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)
# configure the nodes
$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace ON
for {set i 0} {$i < $val(nn) } { incr i } {
set node_($i) [$ns node]
}
# Provide initial location of mobilenodes
$node_(0) set X_ 5.0
$node_(0) set Y_ 5.0
$node_(0) set Z_ 0.0
40
$node_(1) set X_ 490.0
$node_(1) set Y_ 285.0
$node_(1) set Z_ 0.0
$node_(2) set X_ 150.0
$node_(2) set Y_ 240.0
$node_(2) set Z_ 0.0
$node_(3) set X_ 250.0
$node_(3) set Y_ 240.0
$node_(3) set Z_ 0.0
$node_(4) set X_ 500.0
$node_(4) set Y_ 500.0
$node_(4) set Z_ 0.0
# Generation of movements
$ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0"
$ns at 15.0 "$node_(1) setdest 45.0 285.0 5.0"
$ns at 110.0 "$node_(0) setdest 480.0 300.0 5.0"
# Set a TCP connection between node_(0) and node_(1)
set tcp [new Agent/TCP/Newreno]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns attach-agent $node_(0) $tcp
$ns attach-agent $node_(1) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 10.0 "$ftp start"
# Printing the window size
41
proc plotWindow {tcpSource file} {
global ns
set time 0.01
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
puts $file "$now $cwnd"
$ns at [expr $now+$time] "plotWindow $tcpSource $file" }
$ns at 10.1 "plotWindow $tcp $windowVsTime2"
# Define node initial position in nam
for {set i 0} {$i < $val(nn)} { incr i } {
# 30 defines the node size for nam
$ns initial_node_pos $node_($i) 30
}
# Telling nodes when the simulation ends
for {set i 0} {$i < $val(nn) } { incr i } {
$ns at $val(stop) "$node_($i) reset";
}
# ending nam and the simulation
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
$ns at $val(stop) "stop"
$ns at 150.01 "puts \"end simulation\" ; $ns halt"
proc stop {} {
global ns tracefd namtrace
$ns flush-trace
close $tracefd
close $namtrace
exec nam dsr.nam
exit 0
}
$ns run
42
5.3 TORA PROGRAM
# wrls1.tcl
# A 5-node example for ad-hoc simulation with TORA
# Define options
set val(chan) Channel/WirelessChannel ;# channel type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy ;# network interface type
set val(mac) Mac/802_11 ;# MAC type
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 50 ;# max packet in ifq
set val(nn) 5 ;# number of mobilenodes
set val(rp) TORA ;# routing protocol
set val(x) 500 ;# X dimension of topography
set val(y) 400 ;# Y dimension of topography
set val(stop) 150 ;# time of simulation end
set ns [new Simulator]
set tracefd [open tora.tr w]
set windowVsTime2 [open tora1.tr w]
set namtrace [open tora.nam w]
$ns trace-all $tracefd
$ns namtrace-all-wireless $namtrace $val(x) $val(y)
# set up topography object
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)
create-god $val(nn)
# Create nn mobilenodes [$val(nn)] and attach them to the channel.
# configure the nodes
43
$ns node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-channelType $val(chan) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace OFF \
-movementTrace ON
for {set i 0} {$i < $val(nn) } { incr i } {
set node_($i) [$ns node]
}
# Provide initial location of mobilenodes
$node_(0) set X_ 5.0
$node_(0) set Y_ 5.0
$node_(0) set Z_ 0.0
$node_(1) set X_ 490.0
$node_(1) set Y_ 285.0
$node_(1) set Z_ 0.0
$node_(2) set X_ 150.0
$node_(2) set Y_ 240.0
$node_(2) set Z_ 0.0
$node_(3) set X_ 250.0
$node_(3) set Y_ 240.0
$node_(3) set Z_ 0.0
44
$node_(4) set X_ 500.0
$node_(4) set Y_ 500.0
$node_(4) set Z_ 0.0
# Generation of movements
$ns at 10.0 "$node_(0) setdest 250.0 250.0 3.0"
$ns at 15.0 "$node_(1) setdest 45.0 285.0 5.0"
$ns at 110.0 "$node_(0) setdest 480.0 300.0 5.0"
# Set a TCP connection between node_(0) and node_(1)
set tcp [new Agent/TCP/Newreno]
$tcp set class_ 2
set sink [new Agent/TCPSink]
$ns attach-agent $node_(0) $tcp
$ns attach-agent $node_(1) $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ns at 10.0 "$ftp start"
# Printing the window size
proc plotWindow {tcpSource file} {
global ns
set time 0.01
set now [$ns now]
set cwnd [$tcpSource set cwnd_]
puts $file "$now $cwnd"
$ns at [expr $now+$time] "plotWindow $tcpSource $file" }
$ns at 10.1 "plotWindow $tcp $windowVsTime2"
# Define node initial position in nam
for {set i 0} {$i < $val(nn)} { incr i } {
45
# 30 defines the node size for nam
$ns initial_node_pos $node_($i) 30
}
# Telling nodes when the simulation ends
for {set i 0} {$i < $val(nn) } { incr i } {
$ns at $val(stop) "$node_($i) reset";
}
# ending nam and the simulation
$ns at $val(stop) "$ns nam-end-wireless $val(stop)"
$ns at $val(stop) "stop"
$ns at 150.01 "puts \"end simulation\" ; $ns halt"
proc stop {} {
global ns tracefd namtrace
$ns flush-trace
close $tracefd
close $namtrace
exec nam tora.nam &
exec xgraph tora.tr -geometry 800x400 &
}
$ns run
5.4 TRACING Tracing in JoBS is handled internally, by the scheduler. Each Jobs queue can
generate a trace file containing the following information. Each line of the trace file consists
of 17 columns. The first column is the simulation time, columns 2 to 5 represent the loss rates
over the current busy period for classes 1 to 4, columns 6 to 9 represent the delays for each
class (average over a 0.5 seconds sliding window), columns 10 to 13 represent the average
service rates allocated to each class over the last 0.5 seconds, and columns 14 to 17 represent
the instantaneous queue length in packets. Additionally, Demarkers can be used to trace end-
to-end delays.
46
Event Time From node
To node
Pakt type
Pakt
Size
Flag Fid Source add
Dest
Add
Sequ
No
Pkt id
Table 5.1 Tracing files content
1) The first field is event type. It gives by one of four possible symbols r, +,-, d correspond
which correspond respectively to receive (at the output of the link) enqued dequed and
dropped
2) The second link gives the time at which the event occurs.
3) Gives the input node of the link at which the event occurs.
4) Gives the output node of the link at which the event occurs.
5) Gives the packet type (for example CBR or TCP the type correspond to the name that we
gave thoi those applications. For examples the TCP application called “tcp”
6) Gives the packet size.
7) Some foags (that we shall see later)
8) This is the flow id (fid) of ipv6 that a user can set for each flow at the input OTcl script
one can further use the field for analysis purposes it is also used when specifying stream color
is the NAM display
9) This is the source address given in the form of “node port”
10) This is the destination address given in the same form
11) This is the network layer protocol’s packet sequence number even though UDP
implementation is real network do not use real number ns keep the track of UDP packet
sequence number for analysis purpose
12) Last field shows the unique id of the packet.
For example:<event> <time> <from> <to> <pkt> <size><flowid> <src> <dst> <seqno> <aseqno>+ 0.51 0 1 cbr 500 00.0 1.0 0 20.510 1 cbr 500 00.0 1.0 0 2r 0.514 0 1 cbr 500 00.0 1.0 0 0
47
Event Abbreviation Type Value
Send S
%.9f _%s_ originating %s -> %s
double Time string ID string Source string Destination
Have A Route S$hit
%.5f _%s_ %s -> %s %s
double Time string ID string Source string Destination string Route
Don't Have A Route S$miss
%.5f _%s_ %s -> %s
double Time string ID string ID (Should be Source???) string Destination
Configuration parameters. All strings are either "on" or "off"
Sconfig %.5f tap: %s snoop: rts? %s errs? %s
double Time string Use TAP string Snoop Source Routes string Snoop Forwarded Errors %.5f salvage: %s !bd replies? %s
double Time
48
string Salvage With Cache string Don't Salvage Bad Replies %.5f grat error: %s grat reply: %s
double Time string Propagate Last Error string Send Grat Replies %.5f $reply for props: %s ring 0 search: %s
double Time string Reply From Cache On Propagating string Ring Zero Search %.5f using MOBICACHE
double Time %.5f using LINKCACHE
double Time Debug message Sdebug %.5f _%s_ stuck into send buff %s -> %s
double Time string ID string Source string Destination %.5f _%s_ checking for route for dst %s
double Time string ID string Destination %.5f _%s_ send buf pkt to %s liberated by handle PktWOSR
double Time string ID string Destination %.9f _%s_ splitting %s to %s
double Time string ID string Route string Route Copy %.9f _%s_ liberated from sendbuf %s->%s %s
double Time string ID string Source string Destination string Route %.5f _%s_ unwrapping nested route error
double Time string ID _%s_ tap saw error %d
string ID int Header UID _%s_ tap saw route reply %d %s
49
string ID int Header UID string Reply Path _%s_ tap saw route use %d %s
string ID int Header UID string Route %s consider grat arp for %s
string ID string Route _%s_ not bothering to send route error to ourselves
string ID %.5f _%s_ sending into dead-link (nest %d) tell %d %d -> %d
double Time string ID int Number Of Route Errors int Report To Address int From Address int To Address %.9f _%s_ adding %s [%d %.9f] ...
double Time string ID string Path int Link Type double Time Added %.9f _%s_ checking %s [%d %.9f] ...
double Time string ID string Path int Link Type double Time Added %.9f _%s_ freshening %s->%s to %d %.9f
double Time string ID string Path string Next Path int Link Type double Time Added
Errors SDFU %.5f _%s_ dumping maximally nested error %s %d -> %d
double Time string ID string Tell ID int From int To ran off the end of a source route
50
non route containing packet given to acceptRouteReplyroute error beyond end of source route????route error forwarding route request????
Flowstate SFs
%.9f _%s_ %d [%s -> %s] %d(%d) to %d
double Time string ID int Header UID string Source string Destination int Flow ID int Flow Header int Next Hop
Established Flowstate SFESTs
%.9f _%s_ %d [%s -> %s] %d(%d) to %d %s
double Time string ID int Header UID string Source string Destination int Flow ID int Flow Header int Next Hop string Addresses
Flow ARS SFARS
%.9f _%s_ %d [%s -> %s] %d %d
double Time string ID int Header ID string Source string Destination int Flow ID int Amt
Flow Error SFEr
%.9f _%s_ from %d re %d : %d [%d]
double Time string ID int Source int Flow Destination int Flow ID (-1 For Default) int Count (-1 For No Flow Index)
Unknown Flow SFErr
%.5f _%s_ %d -> %d : %d
double Time string ID int Source int Flow Destination int Flow ID
Flow Forward SFf %.9f _%s_ %d [%s -> %s] %d to %d
double Time string ID
51
int Header ID string Source string Destination int Flow ID int Next Hop
Interface Queue SIFQ
%.5f _%s_ len %d
double Time string ID int Queue Length
Send Out Packet With Route SO
%.9f _%s_ originating %s %s
double Time string ID string Protocol Name string Route
Route Cache - Summary SRC %.9f _%s_ cache-summary %d %d %d %d | %d %.9f %d %d | %d %d %d %d %d | %d %d %d %d %d | %d %d %d %d %d %d %.9f%.9f _%s_ cache-summary %d %d %d %d | %d %.9f %d %d | %d %d %d %d %d | %d %d %d %d %d | %d %d %d %d %d %d
double Time string ID int Route Count int Route Bad Count int Subroute Count int Subroute Bad Count int Link Bad Count double Average Bad Time Per Link int Link Bad Tested int Link Good Tested int Route Add Count int Route Add Bad Count int Subroute Add Count int Subroute Add Bad Count int Link Add Tested int Route Notice Count int Route Notice Bad Count int Subroute Notice Count int Subroute Notice Bad Count int Link Notice Tested int Route Find Count int Route Find For Me int Route Find Bad Count int Route Find Miss Count int Subroute Find Count int Subroute Find Bad Count
52
double Link Good Time (Only In First Format)
Route Cache - Node Cache Dump (only with patch)
SRC
%.9f _%s_ cache-dump p %d %d | %d %d %d %s | ... | s %d %d | %d %d %d %s | ... |
double Time int Source Node int Primary Cache Current Size int Primary Cache Maximum Size int Cache Entry Index int Cache Entry Length int Cache Entry Address string Cache Entry Dump int Secondary Cache Current Size int Secondary Cache Maximum Size int Cache Entry Index int Cache Entry Length int Cache Entry Address string Cache Entry Dump
Route Cache - Node Cache Dump, No Primary Cache (only with patch)
SRC
%.9f _%s_ cache-dump s %d %d | %d %d %d %s | ... |
double Time int Source Node int Secondary Cache Current Size int Secondary Cache Maximum Size int Cache Entry Index int Cache Entry Length int Cache Entry Address string Cache Entry Dump
Route Cache - Find Route Cache Hit
SRC
%.9f _%s_ $hit for %s in %s %s
double Time string ID string Destination string Primary Or Secondary Cache string Route
Route Cache - Find Route Cache Miss
SRC
%.9f _%s_ find-route [%d] %s->%s miss %d %.9f
double Time string ID int Hardcoded Zero string ID (Should Be Source???) string Destination int Hardcoded Zero double Hardcoded Zero
Route Cache - New Route Contains Cached Route
SRC %.9f _%s_ %s suffix-rule (len %d/%d) %s
double Time string ID string Cache Name (primary, secondary) int Path Length
53
int Route Length string Route Dump
Route Cache - New Route Contained In Cache
SRC
%.9f _%s_ %s prefix-rule (len %d/%d) %s
double Time string ID string Cache Name (primary, secondary) int Path Length int Route Length string Route Dump
Route Cache - Discard Route SRC
%.9f _%s_ %s evicting %s
double Time string ID string Name string Dumped Route
Route Cache - Discard Route SRC
%.9f _%s_ evicting %d %d %s
double Time string ID int Route Length -1 int Number Of Bad Routes string Name
Route Cache - Add Route After Dumping Route
SRC
%.9f _%s_ while adding %s
double Time string ID string Name string Added Path
Route Cache - Truncating Route To Remove Dead Link
SRC
%.9f _%s_ %s truncating %s %s
double Time string ID string Name string Route string Owner
Route Cache - Truncated Or Removed Route With Dead Link
SRC
%.9f _%s_ to %s %s
double Time string ID string Route string Owner
Route Cache - Dead Link SRC
%.9f _%s_ dead link %s->%s
double Time string ID string From string To
Route Cache - Dead Link SRC %.9f _%s_ %s [%d %d] %s->%s dead %d %.9f
double Time string ID string Operation In Progress (add-route, notice-
54
route, find-route, dead-link, evicting-route, check-cache)
int Route Length int Route Index string Route string Next Route int Link Type double Time Added
Route Cache - Resurrected Link
SRC
%.9f _%s_ resurrected-link [%d %d] %s->%s dead %d %.9f
double Time string ID int Route Length int Route Index string Route string Next Route int Link Type double Time Added
Route Cache - Add Route SRC
%.9f _%s_ adding rt %s from %s
double Time string ID string Route string From
Route Cache - Dump Dijkstra SRC
%.9f _%s_ dijkstra *%d* %d,%d,%d ...
double Time string ID int Destination int Index int Estimated Shortest Path To Vertex (d) int Predecessors For Vertex (pi)
Route Cache - Dump Link SRC
%.9f _%s_ dump-link %d->%d, ...
double Time string ID int Index int Link Destination
Route Cache - Cache Expire Bits
SRC
%.9f _%s_ cache-expire-bits %d %d %d %d
double Time string ID int Expire Stats 0 int Expire Stats 1 int Expire Stats 2 int Expire Stats 3
Table 5.2 Tracing File Detail
55
CHAPTER 6
SIMULATION / COMPARISON:
Results of GBDSR implementation and its comparison with DSR For implementation
of BDSR, many different simulations have been performed and we have conditions of
simulation environment and results obtained there from as follows:
1. Area of simulation: 500×400 sq meters
2. Number of nodes: 5
3. Time of simulation: 150s
4. Number of simulation frequency: 7 times
5. Physical layer of IEEE 802, 11: MAC/ in 2 Mbps and 250 meter transmission interval.
6. Movement model: random model without stop time and speed of nodes movement, 0m/s,
1m/s, 5m/s, 15m/s and 25m/s.
7. Each sender sends two data packets, each 256 bytes long, in second
8. Each receiver is a multicast group member but each sender is not group member unless all
5 nodes are receivers and members of group.
9. Each receiver belongs to a group at the beginning of simulation and senders starts sending
data after 30 seconds all senders stop sending data after 150s.
10. Traffic used in this simulation is only multicast.
Two criteria measured for assessment of GBDSR are PPR and latency as follows:
FIELDS EXPLANATION
Source id Address of the source
Destination id The address of destination
Unique request id A unique id that identify the message
MAC address list A list of address of all intermediate nodes that the message passes before the destination
ACK bit Identify that message has received
Trust estimate value Identify the node either malicious or friend
Time Estimate Message receive and replay
Security bit Initially set 1 for rout request and 1 for packet forward
Table 6.1 Simulation field detailsThe source node initially set the MAC address list of the Route Request packet to an empty
list, set source Id, destination Id, unique request Id in the message accordingly. It also set
56
security bit to 0 and then broadcasts the message. The packet is then received by nodes within
the wireless transmission range of source. The source also keeps a copy of the packet in a
buffer, referred to as the send buffer. In addition, source node time stamps the message to
determine if it should be send again or drop from the buffer depending on the response from
neighboring nodes. When a node receives a Route Request message, it examines the
destination Id to determine whether it is the intended destination of the message. If the node
is not the intended destination, it searches its own route cache for a route to the target. If a
route is found it is returned. If not, the nodes MAC address of this intermediate node is
appended to the MAC address list, and the Route Request is broadcasted again by the
intermediate node. If a node subsequently receives two Route Requests with the same request
id and the secured bit 0, it is possible to specify that only the first should be handled and the
subsequent are discarded.
6.1 AODV SNAPSHOT
57
58
59
Fig 6.1 AODV Snap shots
60
6.2 DSR SNAPSHOT
61
62
Fig 6.2 DSR Snap shot
63
6.3 TORA SNAPSHOT
64
65
66
Fig 6.4 TORA Snap shot
67
6.4 COMPARISON OF TORA, AODV & DSR ROUTING ALGORITHM
68
As with many other AODV implementations for Linux/winX, it separates functionality into a
kernel module and a user space daemon. The kernel module uses hooks in the net filter
interface to send packet headers from the wireless interface to the user space daemon. The
daemon then determines how to handle the packet. If the packet is a routing control packet,
then the daemon processes the packet in accordance with the AODV specification. If instead
the packet is a data packet, the daemon determines whether or not a route exists to the
necessary destination. If there is a suitable route, the packet is flagged and the kernel module
queues it to be sent out. If no route exists, the daemon begins route discovery. Once a route is
found, the daemon enters the route into the kernels routing table. It then flags the packet (and
any additional packets arriving during discovery) to be queued for transmission. The
implementation is written completely in Java. In order to implement SAODV, it was
necessary to have a library of cryptographic operations. We used Open SSL for this purpose,
and we developed a security library which wrapped much of Open SSL.s functionality into
components appropriate for ad-hoc routing purposes. One particularly useful feature of the
security library is that it allows easy use of several different Open SSL contexts at once. For
SAODV, this was useful as nodes must switch between signing, verifying, and hash chain
operations rapidly to both send and receive routing messages. New data structures were
added for SAODV.s single signature extension and the necessary code was added to the
message processing functions for RREQ, RREP, HELLO, and RERR messages. The design
of the AODV implementation allowed SAODV functionality to be implemented while
maintaining one binary with the ability to run both protocols.
69
6.4 Comparison of TORA, AODV and DSR routing protocol
70
Recommended