Destination-Sequenced Distance-Vector Routing (DSDV)

Based on classical distributed Bellman-Ford routing mechanism

Routing loops in a mobile network have been eliminated

Each node has a routing table (all possible destinations within network,
and number of routing hops to each destination)

A sequence numbering system to distinguish stale routes from

new ones and assigned by the destination node

Routing table updates are sent periodically (table consistency)

High volumes of control traffic meaning an inefficient utilization of network

resources

To alleviate this problem, the protocol uses two types of route update packets
Full dump
Carries all available routing info and can require multiple network protocol
data units. Infrequently transmitted while there is not much movement.
Incremental packets
These smaller packets are for relaying only the information that was updated
since the last full dump

New route broadcasts: destination address + the # of hops to get to

destination + the sequence # of the information received about the
destination + new sequence # unique to the broadcast at hand

The route with the most recent sequence # (in increasing order) is always
used

If there is an occurrence of two updates with the same sequence # ,

the route with the smaller hop count is used in order to obtain
optimized (shorter) path

Mobiles keep track of other metrics such as settling time of routes,

or the weighted average time

The broadcast of a routing update is delayed by the settling time

in order to reduce network traffic, as well as optimizing routes

Dynamic Source Routing (DSR)

When node S wants to send a packet to node D, but does not know a route to
D, node S initiates a route discovery

Source node S floods Route Request (RREQ)

Each node appends own identifier when forwarding RREQ

Represents a node that has received RREQ for D from S

[S]

[X,Y]

Represents list of identifiers appended to RREQ

[S,C]

Node H receives packet RREQ from two neighbors:

potential for collision

[S,E,F]

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

node C has already forwarded RREQ once

it again, because

[S,E,F,J]

Nodes J and K both broadcast RREQ to node D

Since nodes J and K are hidden from each other, their

transmissions may collide

[S,E,F,J,M]

Node D does not forward RREQ, because node D is the intended target of
the route discovery

Route Discovery in DSR

Destination D on receiving the first RREQ, sends a Route Reply (RREP)

RREP is sent on a route obtained by reversing the route appended to received

RREQ

RREP includes the route from S to D on which RREQ was received by

node D

Route Reply in DSR

RREP [S,E,F,J,D]

Represents RREP control message

Route Reply can be sent by reversing the route in
Route Request (RREQ) only if links are guaranteed to
be bi-directional
To ensure this, RREQ should be forwarded only if
it received on a link that is known to be bidirectional
If unidirectional (asymmetric) links are allowed, then
RREP may need a route discovery for S from node D
Unless node D already knows a route to node S
If a route discovery is initiated by D for a route to
S, then the Route Reply is piggybacked on the
Route Request from D.
If IEEE 802.11 MAC is used to send data, then links
have to be bi-directional (since Ack is used)
Node S on receiving RREP, caches the route included
in the RREP

 When node S sends a data packet to D, the entire

route is included in the packet header
hence the name source routing
Intermediate nodes use the source route
included in a packet to determine to whom a
packet should be forwarded

DATA [S,E,F,J,D]

DSR Optimization: Route Caching

Each node caches a new route it learns by any means

When node S finds route [S,E,F,J,D] to node D, node S also learns route [S,E,F]
to node F

When node K receives Route Request [S,C,G] destined for node, node K learns
route [K,G,C,S] to node S

When node F forwards Route Reply RREP [S,E,F,J,D], node F learns route
[F,J,D] to node D

When node E forwards Data [S,E,F,J,D] it learns route [E,F,J,D] to node D

A node may also learn a route when it overhears Data packets

Ad-hoc On-Demand Distance Vector Routing (AODV)

Improvement on DSDV due to minimizing number of broadcasts by creating

routes on-demand basis

Improves DSR by maintaining routing tables only at the nodes between

source and destination unlike routes being included in the data packets in
DSR

Source initiates a path discovery process to locate the destination node by

broadcasting a route request (RREQ) packet to its neighbors. The neighbors in
turn forward the request to their neighbors and so on until either an
intermediate node with valid (fresh enough) route or destination is located

Destination sequence numbers are used to ensure that routes are loop free
and has the most recent route information

Each node maintains its own sequence number and broadcast ID

(incremented with every RREQ the node initiates)

Unique RREQ: nodes IP address + broadcast ID

Source sends RREQ (which includes sequence number for the destination)
along with its own sequence number and broadcast ID

The intermediate node reply to RREQ only if

sequence number of destination <= sequence number in the current RREQ

When a node broadcasts a RREQ, a reverse path towards the source is

created

Route reply uses the reverse path when RREQ is forwarded

A routing table entry containing reverse path is deleted after a sufficient

timeout interval

A routing table entry containing forward path is deleted if it is not active for a
sufficient timeout interval

AODV Route Discovery

A node is considered active if it participates in forwarding the packets

Link failures are known to all active nodes using Route Error (RERR) messages
(destination sequence numbers are also updated)

When a node cannot forward a packet towards a destination, it generates a

RERR message; increments sequence number for destination; includes this
incremented destination sequence number in the RERR message

When a source receives the RERR, it initiates a new route discovery process
for the destination using sequence number equal or greater than the
destination sequence number in RERR message

Periodic Hello messages are used to ensure the links exist

A link failure occurs when no hello message are exchanged for a timeout
interval

Failure to receive MAC-level acknowledgement can also be interpreted as a

link failure