Ad hoc on demand distance vector aodv ro (4)

Ad-Hoc On-Demand Distance Vector

(AODV) Routing

Charles E. Perkins, Elizabeth M. Belding-Royer, and Samir Das,

Proceedings of IEEE WMCSA'99,New Orleans, LA,

February 1999

Presented by

민 병 호

Contents

ƒ

Ad-Hoc Network Routing Constraints

ƒ

Ad-Hoc On-Demand Distance Vector (AODV)

ƒ

AODV Algorithm

ƒ

Path Discovery

ƒ

Route Table Management

ƒ

Path Maintenance

ƒ

Local Connectivity Management

ƒ

Simulation and Results

ƒ

Current Status and Future Work

Ad-Hoc Network Routing Constraints

ƒ

No Infrastructure Support

ƒ

No Specialized Routers

ƒ

(Physically) No Fixed Routers

ƒ

Frequent Topology Change

ƒ

Mobility

ƒ

Problems Due to Wireless Media

ƒ

Bandwidth

ƒ

Range of Communication

Ad-Hoc On-Demand Distance Vector

(AODV)

ƒ

A Source Initiated Routing Protocol

ƒ

Premise

ƒ

Symmetric Links

ƒ

Features

ƒ

Pure On-Demand Acquisition

ƒ

Broadcast only when necessary

ƒ

Notion of

‘

_Active

’

_Paths

ƒ

No centralized topological knowledge

ƒ

Neighborhood detection

ƒ

Topological Maintenance

AODV Algorithm

ƒ

Path Discovery

ƒ

Reverse Path Setup

ƒ

Forward Path Setup

ƒ

Route Table Management

ƒ

Path Maintenance

Path Discovery

ƒ

When?

ƒ

No Information on Some Node to Which Communication Is

Requested

ƒ

Each Node Has Two Counters

ƒ

Path Discovery Process

ƒ

Source Node

B

roadcasts a Route Request (RREQ)

Packet to

Its Neighbors

ƒ

Neighbors Forward the Request to Their Neighbors, and so

on until Either the Destination

or

an

Intermediate Node with a “Fresh Enough” Route to the

Destination

Is Located

More on RREQ

ƒ

broadcast_id

Is Incremented for New RREQ

ƒ

RREQ from Same Node with Same

broadcast_id

Will

Not Be Broadcasted More than Once

A

B

C

D

B won’t rebroadcast this RREQ

Route Requests

Represents transmission of RREQ

Z

This example is taken

from Wireless Internet

Route Requests (Cont’d)

Represents links on Reverse Path

Z

Y

M

N

Reverse Path Setup

•

Node C receives RREQ from G and H, but does not forward

it again, because node C has

already forwarded RREQ

once

Z

Y

M

N

Reverse Path Setup

•

Node D does

not forward

RREQ, because node D

is the

intended target

of the RREQ

M

N

Route Reply

Represents links on path taken by RREP

M

N

Forward Path Setup

Forward links are setup when RREP travels along

the reverse path

Data Delivery

Routing table entries used to forward data packet.

Route is

not

included in packet header

.

Path Discovery (Cont’d)

ƒ

RREQ Generates Backward Path to Source

ƒ

RREP Generates Forward Path to Destination

Route Reply (RREP)

Message Format

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type |R|A| Reserved | Prefix Sz | Hop Count |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Destination IP address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Destination Sequence Number |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Originator IP Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Lifetime |

Route Table Management

ƒ

Route Request Expiration Timer

ƒ

Purges Reverse Paths That Do Not Lie on Active Route

ƒ

active_route_timeout

ƒ

Is Used to Determine If Neighboring Node Is Active i.e.

Sends at Least One Packet in This Time

ƒ

Route Cache Timer

ƒ

Each Route Table Entry Contains

ƒ

Destination

ƒ

Next Hope

ƒ

Number of Hops

ƒ

Sequence Number for the Destination

ƒ

Active Neighbors for This Route

ƒ

Expiration Time for the Route Table Entry

ƒ

When a Route Entry Is Used to Transmit Data from

Source to Destination,

Timeout

for Each Entry Is

Reset to Current Time +

active_route_timeout

ƒ

When a New Route Is Available, Route Table Will Be

Updated Only If New Route Has

ƒ

Larger

dest_sequence_#

Or

ƒ

Same

dest_sequence_#

but with Smaller

hop_cnt

to the

Destination

ƒ

If Source Node Moves during an Active Session

Æ

It Can Redo Path Discovery

ƒ

If Destination or Intermediate Nodes Move

Æ

A Special RREP Is Sent to Affected Source Nodes

ƒ

On link breakage, affected node propagates an unsolicited

RREP <

dest_sequence_#+

1,

∞

> to all active neighbors

Æ

Source May Restart Route Discovery Process

ƒ

If Link between C and D Is Broken, a Special RREP

Will Be Sent to B and E by C

ƒ

C Will Increase Its

dest_sequence_#

by 1

and Set

hop_

count

to

∞

)

ƒ

Then B and E Will Send This RREP to Its Active

Neighbors F and G

ƒ

At the End, All Active Source Nodes Are Notified

ƒ

When Source Finds Out a Link to Destination Is

Broken, and It Likes to Rebuild the Path to

Destination, Source Will Send a RREQ with Last

dest_squence_#

+ 1

A

B

C

D

100

100

₁₀₀

₁₀₀

Local Connectivity Management

ƒ

Two Ways for a Node to Find Its Neighbors

ƒ

Receiving Broadcast from Its Neighbors

ƒ

Send Its Neighbors Hello Messages Containing Its Identity

and Sequence Number

ƒ

Sequence number is not changed for hello message

ƒ

Nodes can not rebroadcast hello messages (TTL=1)

ƒ

Local Connectivity Is Changed If

ƒ

Receiving a Broadcast or a Hello from a New Node

ƒ

Failing to Receive

allowed_hello_loss

Consecutive Hello

Message from a Node Previously in the Neighborhood

ƒ

Neighbors Only Communicate When Heard Each

Other

’

s Hello Message

Current Status and Future Work

ƒ

Current Status

ƒ

Multicast

ƒ

RREQ, RREP, and Multicast validation message

ƒ

Future Works

ƒ

Intermediate Node Route Rebuilding

ƒ

Try

‘

repair

’

before link failure notification

ƒ

Elimination of Hello Messages

ƒ

Locality of Association and QoS

Conclusion

ƒ

Storing Only the Needed Routes

ƒ

Minimized Need for Broadcast

ƒ

Reduced Memory Requirements and Needless

Duplications

ƒ

Quick Response to Link Breakage in Active Routes

ƒ

Loop-Free Routes Maintained by Use of Destination

Sequence Numbers