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 nodes power consumption due to a lower transmission power required, and they increase the nodes mobility. To make this work, though, ad-hoc networks require a critical mass of wellbehaving nodes, willing to forward others 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 years 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

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

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 users 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 doesnt 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 users 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.

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
9

demand from additionally activated nodes through reactive flooding. The choice for one or 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.

10

2. Any dependence of performance with traffic load thwarting the negligence of distance may occur in overload.

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 that reference level.

The triplet (t, oid, r) is called the reference level. And the tuple (d, i) is said to be an offset within

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
11

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 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:
12

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 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. is best in shown the by an example from the that original the RR paper. flag
Park1997

This Circles

pictures

below

signify

is

set

node

requires

route,

so

it

broadcasts

QRY

13

The QRY propagates until it hits a node which has a route to the destination, this node then
14

sends

an

UPD

message

The

UPD

is

also

propagated,

while

node

sends

new

UPD

15

16

Fig 2.1 Route Discovery in TORA

2.2.2 Route Maintenance

17

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.

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
18

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 neighbors 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.

19

Example

The link between B and E fails

20

B still has a downstream link to the destination, so no action is needed

The link between D and H fails

21

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.

22

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.

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)

23

Here the link F to G fails, partitioning G from the rest of the network

F defines a new reference level and sends an update message with oid=F and the time of the link failure

24

The

links

D-F

and

E-F

reverse.

Node

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.

25

Node

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.

26

The links are now reversed in the opposite direction, but the reflection bit is set.

27

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 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

28

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

29

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).

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.

30

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 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

31

Fig 2.6 Route Maintenance in AODV

Advantages

Loop free routing Optional multicast Reduced control overhead Delay caused by route discovery process Bidirectional connection needed in order to detect an unidirectional link

Disadvantages

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 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.

32

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 isnt the target and it forwards the Route Request to his neighbors (except to the initiator).

33

Path-finding-process: Route Request & Route Reply

Fig 2.8 Route Request & Route Reply

34

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 cant 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 (beaconless). 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.
35

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

36

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)
37

4.3 Network Interface

Label packets with incoming interface identifierit 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. Its 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 links 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 objects 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
38

many versions are available current version used for our project is network simulator ns22.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) set val(prop) set val(netif) set val(mac) set val(ifq) set val(ll) set val(ant) set val(ifqlen) set val(nn) set val(rp) Channel/WirelessChannel Phy/WirelessPhy Mac/802_11 LL 50 5 AODV ;# channel type Propagation/TwoRayGround ;# radio-propagation model ;# network interface type ;# MAC type ;# interface queue type ;# antenna model ;# link layer type ;# max packet in ifq ;# number of mobilenodes ;# routing protocol
39

Queue/DropTail/PriQueue Antenna/OmniAntenna

set val(x) set val(y) set val(stop) set ns set tracefd set namtrace

500 400 150 [new Simulator] [open aodv1.tr w] [open aodv.nam w]

;# X dimension of topography ;# Y dimension of topography ;# time of simulation end

#Creating trace file and nam file set windowVsTime2 [open aodv.tr 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]
40

} # 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
41

$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
42

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) set val(prop) set val(netif) set val(mac) set val(ifq) set val(ll) set val(ant) set val(ifqlen) set val(nn) set val(rp) set val(x) set val(y) set val(stop) set ns Channel/WirelessChannel Phy/WirelessPhy Mac/802_11 CMUPriQueue LL 50 5 DSR 500 400 150 [new Simulator] Antenna/OmniAntenna ;# channel type Propagation/TwoRayGround ;# radio-propagation model ;# network interface type ;# MAC type ;# interface queue type ;# link layer type ;# antenna model ;# max packet in ifq ;# number of mobilenodes ;# routing protocol ;# X dimension of topography ;# Y dimension of topography ;# time of simulation end

#Creating trace file and nam file set tracefd set namtrace [open dsr1.tr w] [open dsr.nam w] set windowVsTime2 [open dsr.tr w]

43

$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

44

$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
45

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
46

5.3 TORA PROGRAM

# wrls1.tcl # A 5-node example for ad-hoc simulation with TORA # Define options set val(chan) set val(prop) set val(netif) set val(mac) set val(ifq) set val(ll) set val(ant) set val(ifqlen) set val(nn) set val(rp) set val(x) set val(y) set val(stop) set ns set tracefd set namtrace Channel/WirelessChannel Phy/WirelessPhy Mac/802_11 LL 50 5 TORA 500 400 150 [new Simulator] [open tora.tr w] [open tora.nam w] ;# channel type Propagation/TwoRayGround ;# radio-propagation model ;# network interface type ;# MAC type ;# interface queue type ;# antenna model ;# link layer type ;# max packet in ifq ;# number of mobilenodes ;# routing protocol ;# X dimension of topography ;# Y dimension of topography ;# time of simulation end

Queue/DropTail/PriQueue Antenna/OmniAntenna

set windowVsTime2 [open tora1.tr 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
47

$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
48

$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 } {

49

# 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 endto-end delays.

50

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 protocols 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 0 0.0 1.0 0 2 0.51 0 1 cbr 500 0 0.0 1.0 0 2 r 0.514 0 1 cbr 500 0 0.0 1.0 0 0

51

Event

Abbreviation Type double string string string double string string string string double string string string double string string string

Value Time ID Source Destination Time ID Source Destination Route Time ID ID (Should be Source???) Destination Time Use TAP Snoop Source Routes Snoop Forwarded Errors

%.9f _%s_ originating %s -> %s

Send

%.5f _%s_ %s -> %s %s

Have A Route

S$hit

%.5f _%s_ %s -> %s

Don't Have A Route

S$miss

Configuration parameters. All Sconfig strings are either "on" or "off"

%.5f tap: %s snoop: rts? %s errs? %s

%.5f salvage: %s !bd replies? %s

52

double Time 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 string string string

Time ID Source 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 string string string double string string string string

Time ID Route Route Copy Time ID Source Destination Route

%.9f _%s_ liberated from sendbuf %s->%s %s

%.5f _%s_ unwrapping nested route error

double Time string ID

_%s_ tap saw error %d

53

string ID int Header UID

_%s_ tap saw route reply %d %s

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 string int int int int double string string int double double string string int double double string string string int double Errors SDFU

Time ID Number Of Route Errors Report To Address From Address To Address Time ID Path Link Type Time Added Time ID Path Link Type Time Added Time ID Path Next Path Link Type Time Added

%.9f _%s_ adding %s [%d %.9f] ...

%.9f _%s_ checking %s [%d %.9f] ...

%.9f _%s_ freshening %s->%s to %d %.9f

%.5f _%s_ dumping maximally nested error %s %d -> %d

double Time
54

string string int int

ID Tell ID From To

ran off the end of a source route non route containing packet given to acceptRouteReply route error beyond end of source route???? route error forwarding route request???? %.9f _%s_ %d [%s -> %s] %d(%d) to %d

Flowstate

SFs

double string int string string int int int double string int string string int int int string double string int string string int int double string int int int int

Time ID Header UID Source Destination Flow ID Flow Header Next Hop Time ID Header UID Source Destination Flow ID Flow Header Next Hop Addresses Time ID Header ID Source Destination Flow ID Amt Time ID Source Flow Destination Flow ID (-1 For Default) Count (-1 For No Flow Index)

%.9f _%s_ %d [%s -> %s] %d(%d) to %d %s

Established Flowstate

SFESTs

%.9f _%s_ %d [%s -> %s] %d %d

Flow ARS

SFARS

%.9f _%s_ from %d re %d : %d [%d]

Flow Error

SFEr

%.5f _%s_ %d -> %d : %d

55

Unknown Flow

SFErr

double string int int int double string int string string int int

Time ID Source Flow Destination Flow ID Time ID Header ID Source Destination Flow ID Next Hop

%.9f _%s_ %d [%s -> %s] %d to %d

Flow Forward

SFf

%.5f _%s_ len %d

Interface Queue

SIFQ

double Time string ID int Queue Length

%.9f _%s_ originating %s %s

Send Out Packet With Route SO

double string string string

Time ID Protocol Name 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 string int int int int int double int int int int int int int int
56

Time ID Route Count Route Bad Count Subroute Count Subroute Bad Count Link Bad Count Average Bad Time Per Link Link Bad Tested Link Good Tested Route Add Count Route Add Bad Count Subroute Add Count Subroute Add Bad Count Link Add Tested Route Notice Count

int int int int int int int int int int double double int int int int int int string int int int int int string double int int int int int int string double string string string string

Route Notice Bad Count Subroute Notice Count Subroute Notice Bad Count Link Notice Tested Route Find Count Route Find For Me Route Find Bad Count Route Find Miss Count Subroute Find Count Subroute Find Bad Count Link Good Time (Only In First Format) Time Source Node Primary Cache Current Size Primary Cache Maximum Size Cache Entry Index Cache Entry Length Cache Entry Address Cache Entry Dump Secondary Cache Current Size Secondary Cache Maximum Size Cache Entry Index Cache Entry Length Cache Entry Address Cache Entry Dump Time Source Node Secondary Cache Current Size Secondary Cache Maximum Size Cache Entry Index Cache Entry Length Cache Entry Address Cache Entry Dump Time ID Destination Primary Or Secondary Cache Route

%.9f _%s_ cache-dump p %d %d | %d %d %d %s | ... | s %d %d | %d %d %d %s | ... |

Route Cache - Node Cache SRC Dump (only with patch)

%.9f _%s_ cache-dump s %d %d | %d %d %d %s | ... |

Route Cache - Node Cache Dump, No Primary Cache SRC (only with patch)

%.9f _%s_ $hit for %s in %s %s

Route Cache - Find Route SRC Cache Hit

%.9f _%s_ find-route [%d] %s->%s miss %d %.9f

57

Route Cache - Find Route SRC Cache Miss

double string int string string int double double string string int int string double string string int int string double string string string double string int int string double string string string double string string string string
58

Time ID Hardcoded Zero ID (Should Be Source???) Destination Hardcoded Zero Hardcoded Zero Time ID Cache Name (primary, secondary) Path Length Route Length Route Dump Time ID Cache Name (primary, secondary) Path Length Route Length Route Dump Time ID Name Dumped Route Time ID Route Length -1 Number Of Bad Routes Name Time ID Name Added Path Time ID Name Route Owner

%.9f _%s_ %s suffix-rule (len %d/%d) %s

Route Cache - New Route SRC Contains Cached Route

%.9f _%s_ %s prefix-rule (len %d/%d) %s

Route Cache - New Route SRC Contained In Cache

%.9f _%s_ %s evicting %s

Route Cache - Discard Route SRC

%.9f _%s_ evicting %d %d %s

Route Cache - Discard Route SRC

%.9f _%s_ while adding %s

Route Cache - Add Route SRC After Dumping Route

%.9f _%s_ %s truncating %s %s

Route Cache - Truncating SRC Route To Remove Dead Link

%.9f _%s_ to %s %s

Route Cache - Truncated Or Removed Route With Dead SRC Link

double string string string double string string string

Time ID Route Owner Time ID From To

%.9f _%s_ dead link %s->%s

Route Cache - Dead Link

SRC

%.9f _%s_ %s [%d %d] %s->%s dead %d %.9f

Route Cache - Dead Link

SRC

double Time string ID Operation In Progress (add-route, noticestring route, find-route, dead-link, evictingroute, check-cache) int Route Length int Route Index string Route string Next Route int Link Type double Time Added
%.9f _%s_ dead %d %.9f resurrected-link [%d %d] %s->%s

Route Cache - Resurrected SRC Link

double string int int string string int double double string string string double string int int int
59

Time ID Route Length Route Index Route Next Route Link Type Time Added Time ID Route From Time ID Destination Index Estimated Shortest Path To Vertex (d)

%.9f _%s_ adding rt %s from %s

Route Cache - Add Route

SRC

Route Cache - Dump Dijkstra SRC

%.9f _%s_ dijkstra *%d* %d,%d,%d ...

int double string int int double string int int int int

Predecessors For Vertex (pi) Time ID Index Link Destination Time ID Expire Stats 0 Expire Stats 1 Expire Stats 2 Expire Stats 3

%.9f _%s_ dump-link %d->%d, ...

Route Cache - Dump Link

SRC

%.9f _%s_ cache-expire-bits %d %d %d %d

Route Cache - Cache Expire SRC Bits

Table 5.2 Tracing File Detail 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: 500400 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:

60

FIELDS Source id Destination id Unique request id MAC address list ACK bit Trust estimate value Time Security bit

EXPLANATION Address of the source The address of destination A unique id that identify the message A list of address of all intermediate nodes that the message passes before the destination Identify that message has received Identify the node either malicious or friend Estimate Message receive and replay Initially set 1 for rout request and 1 for packet forward

Table 6.1 Simulation field details

The 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 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.

61

6.1 AODV SNAPSHOT

62

63

64

Fig 6.1 AODV Snap shots

6.2 DSR SNAPSHOT

65

66

67

Fig 6.2 DSR Snap shot

6.3 TORA SNAPSHOT

68

69

70

71

Fig 6.4 TORA Snap shot 6.4 COMPARISON OF TORA, AODV & DSR ROUTING ALGORITHM

72

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
73

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.

74

6.4 Comparison of TORA, AODV and DSR routing protocol

75