Report

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.


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


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_(2) set X_ 150.0

$node_(2) set Y_ 240.0


$node_(3) set X_ 250.0

$node_(3) set Y_ 240.0


$node_(4) set X_ 500.0

$node_(4) set Y_ 500.0


# Generation of movements

$ns at 10.0 "$node_(0) setdest 250.0 250.0 3.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


$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(ifq) CMUPriQueue ;# interface queue type





set val(rp) DSR ;# routing protocol





#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






create-god $val(nn)



-llType $val(ll) \









-agentTrace ON \

-routerTrace ON \

-macTrace OFF \

-movementTrace ON



}





40

$node_(1) set X_ 490.0

$node_(1) set Y_ 285.0


$node_(2) set X_ 150.0

$node_(2) set Y_ 240.0


$node_(3) set X_ 250.0

$node_(3) set Y_ 240.0


$node_(4) set X_ 500.0

$node_(4) set Y_ 500.0








$tcp set class_ 2









41


global ns

set time 0.01

set now [$ns now]









}




}





proc stop {} {


$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(ifq) Queue/DropTail/PriQueue ;# interface queue type





set val(rp) TORA ;# routing protocol





set tracefd [open tora.tr w]

set windowVsTime2 [open tora1.tr w]

set namtrace [open tora.nam w]






create-god $val(nn)

# Create nn mobilenodes [$val(nn)] and attach them to the channel.


43


-llType $val(ll) \









-agentTrace ON \

-routerTrace ON \

-macTrace OFF \

-movementTrace ON



}





$node_(1) set X_ 490.0

$node_(1) set Y_ 285.0


$node_(2) set X_ 150.0

$node_(2) set Y_ 240.0


$node_(3) set X_ 250.0

$node_(3) set Y_ 240.0


44

$node_(4) set X_ 500.0

$node_(4) set Y_ 500.0








$tcp set class_ 2










global ns

set time 0.01

set now [$ns now]







45



}




}





proc stop {} {


$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

Fig 6.1 AODV Snap shots

60

6.2 DSR SNAPSHOT

61

Fig 6.2 DSR Snap shot

63

6.3 TORA SNAPSHOT

64

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

Report

Documents

Transcript of Report