Routing in Ad-Hoc Networks

And the DSR Protocol

Computer Networks
Dr. Jorge A. Cobb
Routing Overview
 Network with nodes, edges
 Goal: Devise scheme for
transferring message from one
node to another
 Two orthogonal axis:
• When is the route found? (on- msg

demand or always available)

• Who decides the packet route?
(source or intermediate nodes)

2
When is the route found?
 Proactive Protocols  Reactive Protocols
• Continuously evaluate • On Demand
routes • Route discovery by
• Table driven some global search
• No latency in route • Bottleneck due to latency
discovery of route discovery
• Large capacity to keep • May not be appropriate
network information for real-time
current communication
• A lot of routing
information may never
be used!

3
Who determines route?
 Source (“path”) routing  Destination (“hop-by-hop”) routing
• Source specifies entire • Source specifies only
route: places complete destination in message
path to destination in header: G
message header: A – D • Intermediate nodes look at
–F–G destination in header, consult
• Intermediate nodes just internal tables to determine
forward to specified next appropriate next hop
hop: D would look at • Like postal service – specify
path in header, forward only the final destination on an
to F envelope, and intermediate
• Like airline travel – get post offices select where to
complete set of tickets to forward next…
final destination before
departing…

4
Comparison
 Source routing  Destination routing

• Moderate source storage • No source storage

(entire route for each
desired dest.) • High intermediate node
storage (table w/ routing
• No intermediate node instructions for
storage destinations.)

• Higher data message • Lower data message

overhead (entire path in overhead (just
message header) destination in header)

5
Mobile wireless hosts

• May communicate only subset within range at given

time
• Want to communicate with any other node

6
Mobile Ad-Hoc Network (MANET)
 Collection of mobile nodes forming a
network
 Conferences/Meetings
 No centralized administration or
standard support services
 Search and Rescue
 Highly co-operative, each host is an
independent router  Disaster Recovery
 Hosts use wireless RF transceivers
as network interface  Automated Battlefields
 Network topology is dynamic
(frequent network changes – links
break, nodes come and go)
 Possible unidirectional links

7
 Ad Hoc Routing Protocols

 Standardization effort led by IETF Mobile Ad-hoc

Networks (MANET) task group
• http://www.ietf.org/html.charters/manet-charter.html
• 9 routing protocols in draft stage, 4 drafts dealing with
broadcast / multicast / flow issues
 Other protocols being researched
• utilize geographic / GPS info, ant-based techniques,
etc.

8
Conventional Routing Protocols?
 Mostly proactive
 Not designed for highly dynamic, low bandwidth
networks
 “Count-to-infinity” problem and slow convergence
 Loop formation during temporary node failures and
network partitions
 Protocols that use flooding techniques create
excessive traffic and control overhead

9
Leading MANET Contenders

 DSR: Dynamic Source Routing

• Source routing protocol
 AODV: Ad-hoc On-demand Distance Vector Routing
• “Hop-by-hop” protocol
 Both are “on demand” (reactive) protocols: route
information discovered only as needed
 ZRP: Zone routing protocol, a mixture of reactive and
proactive.

10
Reactive Mobile Routing Protocols

 DSR: source routing

 AODV: destination (hop-by-hop) routing

11
Distributed Source Routing
 On demand: No periodic router advertisements
 Source routing: to send a packet to another host, the sender
constructs a source route in the packet’s header
 Caching: each mobile host participating in the ad hoc network
maintains a route cache in which it caches source routes
 If no route found, the sender may attempt to discover one using
the route discovery protocol.
 Host monitors the correct operation of a route in use, we call
this route maintenance

12
Two Main Components
 route discovery
• the mechanism by which a sending node S obtains a
route to destination D

 route maintenance
• the mechanism by which a sending node S detects
that the network topology has changed and its route to
D is no longer valid

13
Route Discovery in DSR
Y

Z
S E
F
B
C M L
J
A G
H D
K
I N

Represents a node that has received RREQ for D from S

14
Route Discovery in DSR
Broadcast Y
[S]
Z
S E
F
B
C M L
J
A G
H D
K
I N

Represents transmission of RREQ

[X,Y] Represents route record stored in RREQ
15
Route Discovery in DSR
Y

[S,E] Z
S E
[S,B] F
B
C M L
J
A [S,C] G
H D
K
I N

• Node H receives packet RREQ from two neighbors:

potential for collision

16
Route Discovery in DSR
Y

Z
S E
F [S,E,F]
B
[S,B,A] C M L
J
A [S,B,H] G
H D
[S,C,G] K
I N

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

it again, because C has already forwarded RREQ once

17
Route Discovery in DSR
Y

Z
S E
F [S,E,F,J]
B
C M L
J
A G
H [S,B,H,I] D
K
I [S,C,G,K] N

J and K both broadcast RREQ to D

Their transmissions may collide at D
18
Route Discovery in DSR
Y

Z
S E
[S,E,F,J,M]
F
B
C M L
J
A G
H D
K
I N

D does not forward RREQ, because D is the intended

target

19
Route Reply in DSR
Y

RREP [S,E,F,J,D] Z
S E
F
B
C M L
J
A G
H D
K
I N

Represents RREP control message

20
DSR route discovery – basic idea
 S broadcasts route-request to D
• route request contains:
• route record (path followed),
• request id (sequence number)
 each node forwards request by adding own address
and re-broadcasting
 requests propagate outward until:
• target is found, or
• a node that has a route to D is found

21
Forwarding Route Requests
 A request is forwarded if all below hold:
• Receiving node is not the destination
• Receiving node not already listed in recorded source
route
• Avoid loops
• Receiving node has not seen request with same
sequence number
• Forward each request only once
• IP TTL field may be used to limit scope
 Destination D copies route into a Route-reply packet
and sends it back to S

22
Route Cache
 All source routes learned by a node are kept in
Route Cache

• Reduces cost of route discovery

 What to cache?

• Cache the route record of each route-request

• Cache the path in each route-reply

• Cache the path in each data packet.

 When to remove cache entries
• Entries have limited lifetime – it is not specified how to
determine this.
23
Early Route-Replies
 If intermediate node receives RReq for D and has
entry for D in route cache, it responds to RReq and
does not propagate RReq further

• Reduces the overhead of route requests

• Encourages “expanding ring” search for route

24
Unidirectional Links
 With unidirectional links, path from S to D is not the
same as from D to S
 Destination may need to discover route to source to
deliver Route Reply
• If a route exists in its cache, use it
• O.W. piggyback Route Reply onto new Route
Request
• This is flooded towards the source
• This should not be terminated by an early route
reply, i.e., it should broadcast all the way to the
source.

25
Unidirectional Links - Caching
 If your network allows unidirectional links, it limits
caching
 Assume we have a path A --> B --> C --> D --> E
 A sends data packets to E
 What will C cache?
• If the network allows unidirectional links, you only cache
the path C --> D --> E
• If the network allows bidirectional links, you also cache
the path C --> B --> A

26
Route Discovery Summary

 On demand discovery of source routes

 Route requests sent to local neighbors and if no reply, via

controlled flooding

 Cache as much as you can

27
Sending Data
 Check cache for route to D

 If route exists then

• if reachable in one hop

• send packet
• else insert routing header to D and send

 If route does not exist, buffer packet and initiate

route discovery

28
Route Maintenance
 Used when link breakage occurs
 Link breakage may be detected using:
• link-layer ACKs (MACAW),
• “passive ACKs”
• overhearing the xmission of your packet at the next hop
• DSR ACK request
• Send a DSR packet asking for an ACK
• If A->B unidirectional, the ACK from B to A may arrive
via a different path.

29
Router Error Messages
 Route Error message sent to source of message
being forwarded when break detected
 Intermediate nodes “eavesdrop”, adjust cached
routes
 Source deletes route; tries another if one cached, or
issues new Route Request
• Source piggybacks Route Error on the new Route
Request to clear intermediate nodes’ route caches
• This prevents return of invalid route via early reply

30
How to send Route Error Messages?
 If MAC protocol is bidirectional, use reverse path as
data

 O.W. if have an entry in the cache use it

 O.W. piggyback it on a RREQ towards the source

31
The Optimization in DSR
 Full use of the Route Cache

 Piggybacking on Route Discoveries

 Reflecting Shorter Routes

 Improved Handling of Errors

32
Full Use of Route Cache
 We described already that you cache all you can
 You can keep the cache at node A in the form of a
tree rooted at A
 For new route A → E, only <C,E> is enough

A B C D

33
 Piggybacking on Route Discoveries
 Recall that if sender doesn’t have a route cached to the
destination host, initiate a route discovery

• This delays the transmission of the first packet

 The delay for route discovery, and total number of

packets transmitted, is reduced by allowing data to be
piggybacked on route request packet

 Use piggyback also when sending route reply

34
Reflecting Shorter Routes
 Assume two hosts communicate using cached
routes
 We can use shorter routes if nodes move sufficiently
closer together
 Improvement
• Let host operate in promiscuous receive mode
• D hears the transmission from B to C, and sends an
unsolicited route-reply to the source

B C D

Mobile host D notices that the route can be shortened

35
Improved Error Handling
 If a destination is not reachable, a Route Reply is not
received.
• If the application wants to send a lot of data to this
destination, then we will generate many failed Route
Requests, consuming lots of bandwidth.
• Use exponential backoff, if a Route Request fails, then
wait twice as long before sending another one.
 Operate in promiscuous mode
• Learn as much as possible from Route-Error
messages.

36