Issues: Routing in Ad-hoc Networks Mobility Bandwidth constraint - - PowerPoint PPT Presentation

Issues: Routing in Ad-hoc Networks

 Mobility  Bandwidth constraint  Error-prone and shared channel  Location-dependent contention  Other resource constraints

TDDD36: Routing

Issues: Multicas routing ...

 Robustness  Efficiency  Control overhead  Quality of service  Efficient group management  Scalability  Security

TDDD36: Routing

Unicast Routing Protocols

 Many protocols have been proposed  Some have been invented specifically for

MANET

 Others are adapted from previously

proposed protocols for wired networks

 No single protocol works well in all

environments

 some attempts to develop adaptive protocols

TDDD36: Routing

The ideal protocol (p303)

 Distributed  Localized (and scalable)  Adaptive  Minimal maintenance and overhead  Loop free (and free from stale routes)  Balance scares resources usage against

performance (and/or QoS)

TDDD36: Routing

Routing protocol classification

 Route information mechanism

 Proactive (table-driven)  Reactive (demand-driven)  Hybrid

 Temporal information

 Past vs. Future information

 Routing toplogy

 Flat vs. hierarchical

 Specific reources

 Geography or Power

TDDD36: Routing

Route update mechanism

 Proactive (or table-drive) protocols:

 Determine routes independent of traffic pattern  Traditional link-state and distance-vector routing protocols

• Destination Sequenced Distance Vector (DSDV)
• Optimized Link State Routing (OLSR)

 Reactive (or demand-drive) protocols

 Route is only determined when actually needed  Protocol operates on demand

• Dynamic Source Routing (DSR)
• Ad hoc On-demand Distance Vector (AODV)
• Temporally Ordered Routing Algorithm (TORA)

 Hybrid Protocols:

 Combine these behaviors (e.g., table in limited zone, and demand

drive otherwise)

• Zone Routing Protocol (ZRP)
• Greedy Perimeter Stateless Routing (GPSR)

TDDD36: Routing

Routing protocols for wireless ad hoc networks

Response time, bandwidth Energy Mobile ad hoc networks Sensor networks Proactive protocols Reactive protocols

Destination-Sequenced Distance-Vector (DSDV) Optimized Link- State Routing (OLSR) Ad Hoc On-Demand Distance-Vector (AODV) Dynamic Source Routing (DSR) Geography- based routing Cluster-based (or hierarchical) routing GPSR TDDD36: Routing

Some general trade-offs

 Latency of route discovery

 Proactive protocols may have lower latency

• Routes are maintained at all times

 Reactive protocols may have higher latency

• Route from X to Y will be found only when X attempts to send to Y

 Overhead of route discovery/maintenance

 Proactive protocols can (but not necessarily) result in

higher overhead due to continuous route updating

 Reactive protocols may have lower overhead

• Routes are determined only if needed

 Which approach achieves a better trade-off

depends on the traffic and mobility patterns

TDDD36: Routing

Ad hoc networks: terminology

 Broadcast: message sent to all neighbors

within range

 Flooding: message sent to all nodes in the

network by neighbors forwarding message to their neighbors etc.

 Different from wired network!

TDDD36: Routing

Dynamic Source Routing (DSR) [Johnson96]

 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

TDDD36: Routing

Reactive protocols – DSR

 In a reactive protocol, how to forward a packet to

destination?

 Initially, no information about next hop is available at all  One (only?) possible recourse: Send packet to all

neighbors – flood the network

 Hope: At some point, packet will reach destination and an

answer is sent pack – use this answer for backward learning the route from destination to source  Practically: Dynamic Source Routing (DSR)

 Use separate route request/route reply packets to

discover route

• Data packets only sent once route has been

established

• Discovery packets smaller than data packets

 Store routing information in the discovery packets

TDDD36: Routing

Dynamic source routing (DSR)

 Reactive routing protocol  2 phases, operating both on demand:

 Route discovery

• Used only when source S attempts to to send a packet

to destination D

• Based on flooding of Route Requests (RREQ)

 Route maintenance

• Makes S able to detect, while using a source route to

D, if it can no longer use its route (because a link along that route no longer works)

TDDD36: Routing

DSR: Route discovery (1)

E G M H R F A B C I D S K N L P J Q

TDDD36: Routing

DSR: Route discovery (2)

E G M H R F A B C I D S K N L P J Q (S)

TDDD36: Routing

DSR: Route discovery (3)

E G M H R F A B C I D S K N L P J Q (S,A) (S,E)

TDDD36: Routing

DSR: Route discovery (4)

E G M H R F A B C I D S K N L P J Q (S,E,G) (S,B,C)

TDDD36: Routing

DSR: Route discovery (5)

E G M H R F A B C I D S K N L P J Q (S,E,G,J) (S,A,F,H)

TDDD36: Routing

DSR: Route discovery (6)

E G M H R F A B C I D S K N L P J Q (S,A,F,H,K)

TDDD36: Routing

DSR: Route discovery (7)

E G M H R F A B C I D S K N L P J Q (S,A,F,H,K,P)

TDDD36: Routing

DSR: Route discovery (8)

E G M H R F A B C I D S K N L P J Q RREP(S,E,G,J,D)

TDDD36: Routing

DSR: Route Discovery (9)

 Route reply by reversing the route (as

illustrated) works only if all the links along the route are bidirectional

 If unidirectional links are allowed, then

RREP may need a reverse route discovery from D to S

 Note: IEEE 802.11 assumes that links are

bidirectional

TDDD36: Routing

DSR: Data delivery

E G M H R F A B C I D S K N L P J Q DATA(S,E,G,J,D)

TDDD36: Routing

DSR: Route maintenance (1)

E G M H R F A B C I D S K N L P J Q DATA(S,E,G,J,D)

X

TDDD36: Routing

DSR: Route maintenance (2)

E G M H R F A B C I D S K N L P J Q

X

RERR(G-J)

When receiving the Route Error message (RERR), S removes the broken link from its cache. It then tries another route stored in its cache; if none, it initializes a new route discovery

TDDD36: Routing

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

TDDD36: Routing

Route Reply in DSR

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

TDDD36: Routing

Route Reply in DSR

 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 bi-directional  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)

TDDD36: Routing

Dynamic Source Routing (DSR)

 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

TDDD36: Routing

Data Delivery in DSR

B A S E F H J D C G I K Z Y M N L DATA [S,E,F,J,D] Packet header size grows with route length

TDDD36: Routing

When to Perform a Route Discovery

 When node S wants to send data to node D,

but does not know a valid route node D

TDDD36: Routing

DSR modifications, extensions

 Intermediate nodes may send route replies in case

they already know a route

 Problem: stale route caches

 Promiscuous operation of radio devices – nodes can

learn about topology by listening to control messages

 Random delays for generating route replies

 Many nodes might know an answer – reply storms  NOT necessary for medium access – MAC should take care

• f it

 Salvaging/local repair

 When an error is detected, usually sender times out and

constructs entire route anew

 Instead: try to locally change the source-designated route

 Cache management mechanisms

 To remove stale cache entries quickly  Fixed or adaptive lifetime, cache removal messages, … TDDD36: Routing

DSR: Optimization of route discovery: route caching

 Principle: each node caches a new route it learns

by any means

 Examples

 When node S finds route (S, E, G, J, D) to D, it

also learns route (S, E, G) to node G

 In the same way, node E learns the route to D  Same phenomenon when transmitting route

replies

 Moreover, routes can be overheard by nodes in the

neighbourhood

 However, route caching has its downside: stale

caches can severely hamper the performance of the network

TDDD36: Routing

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

TDDD36: Routing

Use of Route Caching

 When node S learns that a route to node D

is broken, it uses another route from its local cache, if such a route to D exists in its cache. Otherwise, node S initiates route discovery by sending a route request

 Node X on receiving a Route Request for

some node D can send a Route Reply if node X knows a route to node D

 Use of route cache

 can speed up route discovery  can reduce propagation of route requests

TDDD36: Routing

Use of Route Caching

B A S E F H J D C G I K [P,Q,R] Represents cached route at a node (DSR maintains the cached routes in a tree format) M N L

[S,E,F,J,D] [E,F,J,D] [C,S] [G,C,S] [F,J,D],[F,E,S] [J,F,E,S]

Z

TDDD36: Routing

Use of Route Caching: Can Speed up Route Discovery

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

[S,E,F,J,D] [E,F,J,D] [C,S] [G,C,S] [F,J,D],[F,E,S] [J,F,E,S] RREQ

When node Z sends a route request for node C, node K sends back a route reply [Z,K,G,C] to node Z using a locally cached route

[K,G,C,S] RREP

TDDD36: Routing

Use of Route Caching:

Can Reduce Propagation of Route Requests

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

[S,E,F,J,D] [E,F,J,D] [C,S] [G,C,S] [F,J,D],[F,E,S] [J,F,E,S] RREQ

Assume that there is no link between D and Z. Route Reply (RREP) from node K limits flooding of RREQ. In general, the reduction may be less dramatic.

[K,G,C,S] RREP

TDDD36: Routing

Route Error (RERR)

B A S E F H J D C G I K Z Y M N L RERR [J-D] J sends a route error to S along route J-F-E-S when its attempt to forward the data packet S (with route SEFJD) on J-D fails Nodes hearing RERR update their route cache to remove link J-D

TDDD36: Routing

DSR: Strengths

 Routes are set up and maintained only

between nodes who need to communicate

 Route caching can further reduce the

effort of route discovery

 A single route discovery may provide

several routes to the destination

TDDD36: Routing

DSR: Weaknesses

 Route requests tend to flood the network and

generally reach all the nodes of the network

 Because of source routing, the packet header size

grows with the route lengh

 Risk of many collisions between route requests by

neighboring nodes  need for random delays before forwarding RREQ

 Similar problem for the RREP (Route Reply storm

problem), in case links are not bidirectional Note: Location-aided routing may help reducing the number of useless control messages

TDDD36: Routing

Destination Sequenced Distance Vector Algorithm (DSDV)

DSDV is based on idea of classical Bellman- Ford Routing Algorithm

Each node maintains a routing table listing all available

• destinations. The attributes of each destination are the

next hop, the number of hops to reach to the destination, and a sequence number, which is originated by the destination node.

Both periodic and triggered routing updates to maintain table

Destination Sequenced Distance Vector Algorithm (DSDV)

1.

Based on Bellman-Ford Next Hop Routing.

2.

Each Node Maintains Tables for :

A.

Next Hop on Path

B.

Distance (in hops) to destination.

C.

Sequence Number ( keep current route)

3.

Nodes Exchange Updates With Neighbours

• Full Routing Updates
• Incremental Updates

Problems of Distance Vector

Pro-active routing based on Distance Vector

 Topology changes are slowly propagated

 Count-to-infinity problem

 Moving nodes create confusion:

 they carry connectivity data which are wrong at

new place  Table exchange eats bandwidth

DSDV

How DSDV addresses the problems?

 Tagging of distance information:

 The destination issues increasing sequence

number

 Other nodes can discard old/duplicate updates

 Changes are not immediately propagated

 Wait some setting time

 Incremental updates instead of full table

exchange

GPSR

 Separate slides …

TDDD36: Routing

More stuff …

TDDD36: Routing

TDDD36: Routing

Ad Hoc On-Demand Distance Vector Routing (AODV)

 As it is based on source routing, DSR includes

source routes in data packet headers

 Large packet headers in DSR  risk of poor

performance if the number of hops is high

 AODV uses a route discovery mechanism similar to

DSR, but it maintains routing tables at the nodes

 AODV ages the routes and maintains a hop count  AODV assumes that all links are bi-directional

TDDD36: Routing

AODV

 Route Requests (RREQ) are forwarded in a manner

similar to DSR

 When a node re-broadcasts a Route Request, it

sets up a reverse path pointing towards the source

 AODV assumes symmetric (bi-directional) links

 When the intended destination receives a Route

Request, it replies by sending a Route Reply

 Route Reply travels along the reverse path set-up

when Route Request is forwarded

TDDD36: Routing

Reactive protocols – AODV

 Ad hoc On Demand Distance Vector routing

(AODV)

 Very popular routing protocol  Essentially same basic idea as DSR for

discovery procedure

 Nodes maintain routing tables instead of source

routing

 Sequence numbers added to handle stale caches  Nodes remember from where a packet came

and populate routing tables with that information

TDDD36: Routing

Ad Hoc On-Demand Distance Vector Routing (AODV) [Perkins99Wmcsa]

 DSR includes source routes in packet headers  Resulting large headers can sometimes degrade

performance

 particularly when data contents of a packet are small

 AODV attempts to improve on DSR by maintaining

routing tables at the nodes, so that data packets do not have to contain routes

 AODV retains the desirable feature of DSR that

routes are maintained only between nodes which need to communicate

TDDD36: Routing

AODV : Route discovery (1)

E G M H R F A B C I D S K N L P J Q

TDDD36: Routing

AODV : Route discovery (2)

E G M H R F A B C I D S K N L P J Q Note: if one of the intermediate nodes (e.g., A knows a route to D, it responds immediately to : Route Request (RREQ)

TDDD36: Routing

AODV : Route discovery (3)

E G M H R F A B C I D S K N L P J Q : represents a link on the reverse path

TDDD36: Routing

AODV : Route discovery (4)

E G M H R F A B C I D S K N L P J Q

TDDD36: Routing

AODV : Route discovery (5)

E G M H R F A B C I D S K N L P J Q

TDDD36: Routing

AODV : Route discovery (6)

M D K L P J E G H R F A B C I S N Q

TDDD36: Routing

AODV : Route discovery (7)

M D K L P J E G H R F A B C I S N Q

TDDD36: Routing

AODV : Route reply and setup

• f the forward path

M D K L P J E G H R F A B C I S N Q : Link over which the RREP is transmitted : Forward path

TDDD36: Routing

Route reply in AODV

 In case it knows a path more recent than

the one previously known to sender S, an intermediate node may also send a route reply (RREP)

 The freshness of a path is assessed by

means of destination sequence numbers

 Both reverse and forward paths are purged

at the expiration of appropriately chosen timeout intervals

TDDD36: Routing

AODV : Data delivery

M D K L P J E G H R F A B C I S N Q Data The route is not included in the packet header

TDDD36: Routing

AODV packets

 ROUTE REQUEST  ROUTE REPLY

TDDD36: Routing

AODV : Route maintenance (1)

M D K L P J E G H R F A B C I S N Q Data

X

TDDD36: Routing

AODV : Route maintenance (2)

M D K L P J E G H R F A B C I S N Q

X

RERR(G-J) When receiving the Route Error message (RERR), S removes the broken link from its cache. It then initializes a new route discovery.

TDDD36: Routing

AODV: Route maintenance

TDDD36: Routing

AODV: Destination sequence numbers

 If the destination responds to RREP, it places its

current sequence number in the packet

 If an intermediate node responds, it places its

record of the destination’s sequence number in the packet

 Purpose of sequence numbers:

 Avoid using stale information about routes  Avoid loops (no source routing!)

TDDD36: Routing

AODV : Avoiding the usage of stale routing tables

S D A B DSN(D) = 5 : Forward path S D A B DSN(D) = 5

… …

DSN(D) = 8 1. 2. S D A B DSN(D) = 5

…

DSN(D) = 8 3. RREQ S D A B DSN(D) = 5

…

DSN(D) = 8 RREP 4.

TDDD36: Routing

AODV : Avoiding loops

A B S D C : Forward pat

• Assume there is a route between A and D; link S-D breaks; assume A is not aware of this, e.g.

RERR sent by S is lost

• Assume now S wants to send to D. It performs a RREQ, which can be received by A via path S
• Node A will reply since it knows a route to D via node B
• This would result in a loop (S-C-A-B-S)
• The presence of sequence numbers will let S discover that the routing information from A is
• Principle: when S discovers that link S-D is broken, it increments its local value of DSN(D). In

the new local value will be greater than the one stored by A.

X

TDDD36: Routing

AODV (unicast) : Conclusion

 Nodes maintain routing information only

for routes that are in active use

 Unused routes expire even when the

topology does not change

 Each node maintains at most one next-hop

per destination

 Many comparisons with DSR (via simulation)

have been performed  no clear conclusion so far

TDDD36: Routing

Flooding of Control Packets

 How to reduce the scope of the route

request flood ?

 Location Aided Routing LAR [Ko98Mobicom]  Query localization [Castaneda99Mobicom]

 How to reduce redundant broadcasts ?

 The Broadcast Storm Problem [Ni99Mobicom]

TDDD36: Routing

Location Aided Routing (LAR)

 Advantages

 reduces the scope of route request flood  reduces overhead of route discovery

 Disadvantages

 Nodes need to know their physical locations  Does not take into account possible existence

• f obstructions for radio transmissions

TDDD36: Routing

Geographic Distance Routing (GEDIR) [Lin98]

 Location of the destination node is assumed known  Each node knows location of its neighbors  Each node forwards a packet to its neighbor closest to

the destination

 Route taken from S to D shown below

S A B D C F E

• bstruction

H G

TDDD36: Routing

Geographic Distance Routing (GEDIR) [Stojmenovic99]

 The algorithm terminates when same edge traversed

twice consecutively

 Algorithm fails to route from S to E

 Node G is the neighbor of C who is closest from

destination E, but C does not have a route to E

S A B D C F E

• bstruction

H G

TDDD36: Routing

Routing with Guaranteed Delivery [Bose99Dialm]

 Improves on GEDIR [Lin98]  Guarantees delivery (using location

information) provided that a path exists from source to destination

 Routes around obstacles if necessary  GPSR: A similar idea also appears in

[Karp00Mobicom]

TDDD36: Routing

QoS: Network layer solutions

 MAC protocols: bandwidth reservation,

real-time support only for link

 Network layer is host-to-host specific

 resource negotiation  reservation  reconfiguration

 QoS routing protocols

 search for routes with resources that satisfy

QoS reqs

 find paths that consume minimum resources

TDDD36: Routing

QoS routing in ad-hoc networks

TDDD36: Routing

QoS-enabling routing protocols

 Additive metrics:  Concave metrics:  Multiplicative metrics:

Two examples follow: ticket-based and QoS- enabled AODV

TDDD36: Routing

Am = S (Li(m)), Li  P

i = 1 h

Cm = min(Li(m)), Li  P Mm = P (Li(m)), Li  P

i = 1 h

A distributed ticket-based QoS routing protocol for MANETs

 Chen and Nahrstedt (1999)  Tolerates imprecise state information

during QoS route computation

 Probes multiple paths in parallel, limited by

tickets

 Optimality is explored  Uses primary-backup-based fault tolerance

to reduce service interruption

TDDD36: Routing

QoS-enabled AODV

 QoS extensions in routing table:

 Maximum delay  Minimum available bandwidth  List of sources requesting delay guarantees  List of sources requesting bandwidth

guarantess

TDDD36: Routing

QoS frameworks for MANETs

 Service model  Routing protocol  Resource reservation signaling  Admission control  Packet scheduling

TDDD36: Routing

QoS framework: Flexible QoS Model for Mobile ad-hoc networks (FQMM)

TDDD36: Routing